Beyond the Code / SBOM: Supply Chain Security

VIDEO

Slides

OUTLINE

Supply Chain security is the new buzzword of the town and everyone is gaga about it. After the executive order and SSDF / SLSA documents being released, every single vendor has added SBOM capabilities and declared the problem solved. The problem is its not solved, Supply chain security is not a new problem and sbom is not the final solution. This talk wants to throw lights on supply chain security overview and then address following points.

1. How supply chain security is a age old concept.
2. What has changed in last few year and how that affects this problem space
3. At a broader level how SLSA / SSDF are trying to address the problem.
4. What is still missing in market and what is needed to be done beyond buying tools.

We will start by exploring how software supply chain problems have existed in past already, We will then talk about sbom’s what they really are and what they can do. we then focus on the shortcomings of the formats and especially where gaps occur (for example the place to record which compiler version was used to compile the code). After we have looked at sbom we will explore different scenarios where current sbom would not have helped in any ways (this includes solarwind if you are wondering) We then explore how different bodies have attempted to tackle it from npm’s trying to isolate packages, to debian trying to control central repositories, pros and cons on each side. We will then focus on how paradigm shift such as IaC and provinence tools could be of help what they can do and can’t do. we will then conclude the talk around SSDF / SLSA as frameworks to start tackling the problems but also to give people a clear idea where tooling can help and where policies and process would be helpful.

This talk is especially useful for practitioners who want to understand what is going on and how to start looking at these frameworks to put some protection in the environment.

AI Generated Summary

This comprehensive talk on supply chain security and SBOM provides historical context, practical frameworks, and critical vendor evaluation questions for practitioners.

Key Topics Discussed

Supply Chain Security Fundamentals:

• Supply chain is about establishing trust in the entire process from raw materials to end user
• Software supply chain has four primary entities: Producer (third-party libraries), Consumer (software manufacturers), Infrastructure Provider (S3, Docker Hub, cloud services), End User
• Six building blocks: Developer → Code Repositories → CI Systems → CD Systems → Containers → Dependencies → Service Provider (Azure/AWS)
• Supply chain security requires looking at the entire chain, not just individual components

Historical Context - This is NOT a New Problem:

• 1974: Air Force document first discussed compiler backdoors and trust in software building process
• 1984: Ken Thompson’s famous paper on “Reflections on Trusting Trust” - how to backdoor a compiler
• 2004-2021: OWASP has been highlighting “Vulnerable and Outdated Components” (now OWASP Top 10 A06:2021)
• 2021: US Executive Order (triggered by SolarWinds, CodeCov, Colonial Pipeline) led to NIST SSDF and Google SLSA frameworks
• Key point: “When a vendor says software supply chain is a very new problem - it has existed for a very long time. People didn’t have something to sell us, so they had something to talk about. Now when they have something to sell us, now they’re talking about it.”

What Changed:

• Executive Order from US President (for US Government software, not the world)
• NIST created SSDF (Secure Software Development Framework)
• Google and others created SLSA framework
• Industry buzzwords emerged: SBOM and Provenance

SBOM (Software Bill of Materials) Basics:

• Analogy: Recipe book with list of ingredients
• Contains: Software name, version, checksum, license information, dependencies (one level deep)
• Purpose: Inventory management - “If you don’t know your assets, you cannot protect them” (NIST CSF Identify function)
• 80% of code is not written by you - but you’re importing 100% of library code to use 10% of functionality
• SBOM trees built by plugging smaller SBOMs into one giant SBOM

What SBOM Does NOT Contain:

• What compiler was used
• What ML models are in use
• What SaaS services were used
• Which CI/CD system (GitHub, GitLab, Jenkins)
• What operating systems were in use
• Critical gap: SolarWinds hack happened because CI system got compromised - SBOM wouldn’t have prevented it

SBOM Limitations:

• Cannot tell you if bug is actually in your code path (you may import library but not use vulnerable function)
• CycloneDX working on VEX (Vulnerability Exploitability eXchange) to address this
• It’s a solution to a problem, not THE solution to all problems
• Good first step for inventory management

What SBOM Can Help With:

• Identifying which software uses specific libraries (e.g., libcurl CVE 9.8)
• Log4j incident: Organizations took 45-50 days to inventory - SBOM could prevent this
• Any inventory problem can be solved by SBOM

Provenance:

• Proof that SBOM document is authentic and hasn’t been tampered with
• Analogy: Checksum on download page - but if website is compromised, checksum can be changed
• Solution: Independent third party signs document cryptographically, stored separately
• Should be stored at third-party place OR independently verifiable without involving artifact provider

Industry Problems We Created:

• Automation → Faster release cycles → Less interest in upgrading dependencies
• Fast release cycles (every hour/10 minutes) → Developers can’t keep up with dependency updates
• Open source maintainers have no SLA with organizations, yet expected to maintain security
• Loss of feature release vs stable release segregation - now single stream with features, bug fixes, breaking changes mixed
• Dependabot creates noise - developers can’t update due to potential regressions
• Test coverage (80-90%) is unrealistic - “did you start laughing when I said 80-90% test coverage?”

Two Historical Approaches to Supply Chain Management:

1. Centralized/Vetted Software (e.g., Debian, Linux distributions):

• Pros: Single entity maintains ecosystem, security updates handled, stability focus
• Cons: Limited to 100-500 packages, can’t use latest software immediately
• Example: Debian maintains officially supported libraries, merges security fixes

2. Isolated/Decentralized (e.g., npm, Python pip/venv):

• Pros: Use latest modules, isolated environments, flexibility
• Cons: Developer has control (pro and con), must know about problems to fix them
• Example: npm install creates node_modules with 500+ dependencies for 10 top-level deps
• npm audit tells you vulnerabilities but doesn’t tell you what to do about them

Modern Solutions:

• Infrastructure as Code, Compliance as Code, Policy as Code
• Better cryptographic standards
• Hardware/software/storage capacity for maintaining provenances

Frameworks:

1. SLSA (Supply-chain Levels for Software Artifacts) - Google:

• Started with 4 levels, removed Level 4 (reproducible builds) as too ambitious
• Level 1: Documentation
• Level 2: Build process that’s tamper-resistant
• Level 3: Better layers imported
• Level 4: Removed (reproducible builds - future ambition)
• Focuses on producer-consumer relationship

2. NIST SSDF (Secure Software Development Framework):

• Four top-level functions: Prepare Organization, Protect Software, Produce Well-Secured Software, Respond to Vulnerability
• Maps to existing frameworks (OWASP SAMM, NIST CSF) - don’t need to redo everything
• Example: “I’m PCI-DSS compliant, I’m done with 20-30% of this framework”
• Not prescriptive - references existing standards

3. NIST CSF v2 (Cybersecurity Framework v2):

• Draft mode but should start looking at it
• Major difference from v1.1: Added “Govern” section for governance policies
• Important for upper management discussions

Tools Mentioned:

1. OSSF Scorecard:

• Creates health stats for software projects
• Finds bugs in configurations, not code itself
• Checks: Insecure workflows, old dependencies, lack of code reviews
• Can be integrated into CI/CD (GitHub/GitLab)

2. Sigstore / Cosign:

• Distribution signing software
• Container signing process
• Creates provenance: Looks at container ingredients, checksums, creates report, signs it, seals it
• Establishes: “Whatever you were supposed to get is what you got”

3. SafeDep:

• Verification tool (can integrate into CI/CD or standalone)
• Goes through all dependencies, shows current state, drifts, versions behind, security bugs, compliance problems
• Key feature: Create organizational rules
  • “I don’t want GPL licensed dependencies”
  • “I don’t want dependencies hosted on GitHub with no activity for 6 months”
  • “I don’t want dependencies with less than 100 stars”
• Shows violations of these rules

4. StackLock:

• Visual Studio plugin - shows squiggly line when importing potentially problematic modules
• Provides rating for module
• Lists alternative modules in same sphere with higher ratings
• Answers: “What should I do? I have a problem, what should I do?”

Three Critical Questions to Ask SBOM Vendors:

1. What do I do with the SBOM?

• Ask: “What are the next steps? You got me the SBOM, what do I do with it?”
• If answer: “You don’t need to do anything, this is all you needed” → Run away

2. Are you validating vulnerabilities or just spotting them?

• Ask: “Are you just spotting vulnerability based on version number, or actually validating that my code has that vulnerability?”
• 99% of times answer will be “No” - it’s not easy to solve
• Test it: Have vulnerable dependency in sample project where you never use the code path → See if vendor flags it
• If they flag it, that’s not a product you want (false positive)

3. Do you have alternative solutions?

• Ask: “Do you have alternative solutions to the libraries?”
• StackLock provides some, but not 100% coverage
• Proprietary solutions should help find alternatives - “This is the least they can spend their money on”

Q&A Insights:

COE (Customer-Owned Environments) / User-Installed Code:

• Open source angle: Can’t do much
• Corporate angle: OSQuery can spot software installations (won’t find Excel macros specifically)
• Recommendation: If you don’t need macros, disable them at AD level

Prioritization of Vulnerabilities:

• Ideal: Third party should specify which CVEs are applicable (VEX)
• Reality: Most bugs are in transitive dependencies (2nd/3rd level), not direct dependencies
• Solution: Use Semgrep to identify if vulnerable function is actually called
• Prioritization factors:
  1. Code coverage - is the vulnerable function actually used?
  2. CVSS scoring - general severity
  3. EPSS (Exploit Prediction Scoring System) - is it being exploited now?
  4. KEV (Known Exploited Vulnerabilities) - government-maintained list of actively exploited vulnerabilities
• Key: Reachability and exploitability are the key factors (EPSS is the buzzword)

Key Insights:

• “We end up solving problems that we created a few years or months ago” - industry pattern
• SBOM is inventory management, not complete security solution
• SolarWinds couldn’t have been prevented by SBOM (CI system compromise)
• Bill of Materials will be keyword for next 5-10 years (SBOM, Cryptographic BOM, etc.)
• Inventory problem may not go away completely but SBOM helps get closer
• Test vendor claims - don’t just ask, verify with sample projects

Important Projects and Tools Mentioned:

• CycloneDX - Working on VEX and addressing SBOM gaps
• OSSF Scorecard - Software health scoring
• Sigstore/Cosign - Container signing and provenance
• SafeDep - Dependency verification with organizational rules
• StackLock - Module rating and alternative suggestions
• Semgrep - Code pattern analysis for vulnerability reachability
• OSQuery - Software inventory for corporate environments

Actionable Takeaways:

1. Ask vendors the three critical questions before purchasing SBOM solutions
2. Test vendor claims with sample projects (vulnerable dependency in unused code path)
3. Look at SLSA, SSDF, and CSF v2 frameworks
4. Use OSSF Scorecard for software health
5. Implement organizational rules for dependencies (SafeDep)
6. Prioritize vulnerabilities using: Code coverage → CVSS → EPSS → KEV
7. Use Semgrep to identify if vulnerable functions are actually called
8. Remember: SBOM is inventory management, not complete security solution
9. Provenance should be independently verifiable
10. Don’t expect SBOM to prevent all supply chain attacks (e.g., SolarWinds CI compromise)