stackconf 2024 | How to hack and defend (your) open source by Roman Zhukov.pdf

Would you like to take some practical insights from the leading company that’s in world Top 4 Open-source contributors list? There are no longer questions like “How often I reuse 3rd party tool or library in my day-to-day work?” Answer is clear – always: pypi, npm, etc. Sometimes you don’t even realize that because it’s natural, isn’t it? Let’s talk about common and unusual (may be hidden from public, but still interesting) technics of compromising your company’s assets in minutes because of unlimited power of today’s open source realm. I’ll share examples (you can use right away) of the most useful frameworks and tools that we utilize and that really helps even if you don’t have army of Security professional and your budget is tight. That also helps to tackle things from the “native developer environment” prospective. Usually, SW developers can find whether academic information (like tons of standards) or scattered data about how to consume 3rd parties securely and include essential security stuff to CI/CD pipeline. I know that it’s scary and doesn’t make sense, because I worked a lot with SMB and startups. That’s why besides “defend” part we’ll also address “hack part” to convince where the “actual” risk lives. Zero commercial or promotions – only practical cases, reals scenarios and the best tools.

2. IT'S YOUR OPEN-SOURCE, NOT SOMEONE ELSE'S

3. IT'S YOUR OPEN-SOURCE, NOT SOMEONE ELSE'S

4. HOW TO HACK AND DEFEND
(YOUR) OPEN-SOURCE
Roman Zhukov
Product Security Manager, Security Champion for LF UXL
DISCLAIMER:
The opinions expressed are solely
my own and do not necessarily
reflect the official views or opinions
of my employer.

6. https://www.sonatype.com/state-of-the-
software-supply-chain
https://www.synopsys.com/software-
integrity/resources/analyst-
reports/open-source-security-risk-
analysis.html
(companies’)

7. Software
https://shorturl.at/inxJS

8. www.google.com

9. www.google.com

10. https://www.endorlabs.com/blog/introducing-
the-top-10-open-source-software-oss-risks
UNDERSTAND WHERE RISKIS FOR YOU

11. Must have a look
•Open-Source Security Foundation (OpenSSF)
•Secure Supply Chain Consumption Framework
(S2C2F)
•
new
OWASP Product Security Capability
Framework
Worth reading
•NIST Secure Software Development Framework
(SSDF)
•CISA Open-Source Software Security Roadmap
•CIS SW Supply Chain Security benchmark
•SLSA (Supply-chain Levels for Software Artifacts)
Good, but more generic and complex
•DOD DevSecOps framework
•NSA/CISA/ODNI: Securing the Software Supply
Chain
•NIST Cybersecurity Supply Chain Risk
publications
•UK National CSC: Supply chain cyber security
•ENISA Good practices for supply chain
cybersecurity
•CNCF Secure Software Factory
•OWASP SAMM
•BSIMM
INDUSTRY BEST PRACTICES

12. Secure
sourcing
Secure
development
Build & Release
Maintaining
production
open-
source
security
Community
engagement
SBOM

13. Dependency confusion
2
3
1
4
Typosquatting, Masquerading
Trojan injection, Protestware
Repo or package Hijacking
> npminstall analytics-paypal
//Used to launch malicious script to
make DNS requests to
dns.alexbirsan-hacks-paypal.com to
run data exfiltration. Now
deprecated.
EleuterAIinstead of EleutherAI
//fake LLM model was added to
Hugging Face
> dependabot[bot] committed
//Malicious pull request that’s
accepted contains info stealer
> coa
was hijacked over npmaccount
takeover incorporating password
stealer
//command line option parser with
over 9 Million weekly downloads
Secure
sourcing

14. ASSESS 3
RD
PARTY REPOS
✓Why? Most popular ≠ Most secure
✓Each of 19 individual check returns a score
of 0 to 10, compiling to aggregate score for
the repo
✓Score >= 7 usually means very good
✓It’s easy to achieve 5.9 and not a big deal to bump to 8.1
✓Works with GitHub and GitLab repos
✓Utilize GUI by accessing URL
✓Run automatically using the GitHub Action
✓Run manually via the Command Line Interface or Docker
✓Use the REST API to query pre-calculated scores of OSS
projects
✓[new] Scorecard Monitor –auto notification, PRs, etc.
https://github.com/ossf/scorecard
Secure
sourcing

15. •Check repo maintenance cadence
•At least 1 tagged release per half a year
•More than active 1 maintainer/contributor
•Check for CVEs & Pay attention to vulnerability research
•No disclosed CVEs is not necessarily good
•What’s in Security.md file
•Examine repo documentation maturity
•License
•Contribution rules definitions, review process, etc.
•All possible verifications: checksum, signatures, provenance, malware scan
•npmci instead ofnpminstall
•Curate and mirror locally critical dependencies –update them smart
•Why are you linking all these (pre-built) binaries instead of building them from source?
•e.g, .jaror .dll
OTHER BEST PRACTICES
Secure
sourcing

16. Source health check
•Open SSF ScoreCards–supports GitHub/GitLab
•deps.dev–project to assess packages -now has
API
•npmaudit–built-in command checking for vulns
•npmdoctor–verify npmenv. Installation
•Chain-Bench–check for CIS SW Supply Chain
Security Benchmark
Local package management
•Pulp–local package organizer
•OpenSSF Package Analysis–track for malicious
behavior
•Use your SCM & CI tool native hardening features ☺
Dependencies & CVE detection + updating
•Dependabot & Dependabot core-check for CVE
and bumping up versions
•Renovatebot-bumping up versions
•PyUp(for Python)–bumping up Python components
•Intel CVE-Bin-Tool-check for CVE in (!) binaries
•OSV-Scanner (uses osv.devdatabase)–check for
CVE
•Fossa CLI, ScanCode, Dependency-Check-check
for CVE
•Trivy–scanning containers, dockerfiles,
configurations
FREE TOOLS
Secure
sourcing

17. SaaS SCM
(e.g., github.com)
Developer
Internal
Network
Runner 1 Runner 2 Runner 3
Commit/
Workflow
Push
REST API
Self-hosted Runners
GitHub
Actions
connection
Attacker
Git repository
Malicious
workflow
Malicious
push
Runner checks
out Attacker
code
Attacker server
Command & Control
connection +
RCE
Build &
Release
GitHub, GitLab, etc. allows
to run CI jobs and provides
curated runners available at
marketplace.
GitHub or GitLab allows to
using self-host runners that are
executed locally offering more
control of hardware, operating
system.
ephemeral runners perform
1 job at the time, then are
unregistered. Auto-update
option is enabled by default
(but shouldn’t be!).
non-ephemeral runners are
not stick to 1 job, any
contributor (even to
documentation) with
previous PR approved ever
can trigger it

18. •Isolate (build dev DMZ) accessing your internal infrastructure
•Harden OS
•Review access & token management
•Mange secrets properly and verify nothing is leaked
•Enable 2FA whenever possible, disable passwords
•Least privilege (root? again?)
•Leverage git permissions and branch protection
•Use JIT (ephemeral or runtime) runners
•Apply “codeowners” feature review to runners
•Prevent runners from approving PR
•Scan binaries (again!) for CVEs and malware
•Double-check supporting infra scripts (.yaml, .json)
•Connect logs and alerts to monitoring system
SUMMARY OF BEST PRACTICES Build &
Release

19. Repo and runner settings check
•Open SSF ScoreCards-yes, you can even
use it internally
Secret management
•Vault, Infisical
Secret scanning
•GitGuardian, Gitleaks, Whispers
•Detect-secrets, TruffleHog
“Classic” network security & scanning
•pfSense
•OpenSCAP, OpenVAS, Wazuh
CVE, malware & script scanning
•CVE Bin Tool–intel open-source tool
•Retire.js-CVE scan for JS-libs
•ClamAV–anti-malware scanning
•Trivy, Checkov–scripts & IaCscanning
Container specific
•Trivy, grype–dockerfiles, CVEs, secrets
•Docker Bench for Security, CIS Docker
Benchmark
FREE TOOLS Build &
Release

21. SBOM
SBOM Quality report, 2023, Purdue University, In-Q-Tel, Chainguard
SBOM –Software Bills of Material

22. •3 reasons Whyingesting SBOM:
•Inventory
•Automation
•Accountability
•Don’t be obsessed by the format, just pull
something
•Validate SBOM, provenance and signature
(where applicable) of 3rd parties
•Create your own SBOM (even if don’t ship
to US Gov)
•Leverage ingesting VEX (in machine-
readable CSAF format)
SBOMCONSIDERATIONS SBOM
VEX –Vulnerability Exploitability eXchange
https://industrialcyber.co/

23. KEY TAKEAWAYS
Highlight [your own]
open-source risks
Just doing what
leaders do solves
80% issues
Automate it!
Security is [now] dev-
friendly ☺
Be on top of hacking
techniques
2023 Intel Product Security Report

25. https://opensourcesecurityindex.io/

26. IT’S YOUR OPEN-SOURCE.
TAKE CAREOF IT.
LINKEDIN.COM/IN/ROZHUKOV
Reach out to me: