Guest: Anant Srivastava, Chief researcher & Founder @ Cyfinoid Research Pvt Ltd
Often, it’s not your code that gets breached, it’s the code you inherit. We expose the hidden dangers lurking in your Software Supply Chain and reveal the single document that can save you: the SBOM.
In this episode, Neelu and Anant delve into the concept of Software Bill of Materials (SBOM), its significance in the #cybersecurity landscape, and the challenges associated with its implementation. They discuss the limitations of current #sbom practices, the importance of understanding transitive #dependencies, and the need for a comprehensive approach to #supplychainsecurity. The conversation also touches on the static nature of #SBOMs, the debate over public versus private SBOMs, and the role of #vex and VDR in managing #vulnerabilities. Anant shares insights from his experiences in the field and emphasizes the importance of centralized dependency management in ensuring software security.
Recommended reading/viewing, Paper for practitioners
- https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
- https://knightcolumbia.org/content/ai-as-normal-technology
- https://cyfinoid.com/automating-a-known-weakness-introducing-keychecker/
- https://github.com/cyfinoid/sbomplay
- https://cyfinoid.com/introducing-sbom-play-a-privacy-first-sbom-explorer-with-vulnerability-license-insights/
AI Generated Summary
This comprehensive discussion on Software Bill of Materials (SBOM) covers fundamental concepts, implementation challenges, and future directions in supply chain security.
Key Topics Discussed
SBOM Fundamentals:
- SBOM is fundamentally an inventory, not a security solution itself - its use in security is just one application
- SBOMs should be created at build time and updated with every version change
- The “one level deep” controversy: SBOMs should capture direct dependencies, with transitive dependencies handled through a distributed ecosystem approach
- Minimum elements include provider name, SBOM builder, component list, and checksums/hashes for validation
Critical Gaps in Current SBOM Practices:
- SBOMs don’t capture the full build process: developer tools, IDE extensions, AI coding assistants, or contributions from sanctioned countries
- Missing deployment context: installers, runtime configurations (IIS, MySQL versions), and production environment specifics
- Static nature: SBOMs become stale over time, requiring continuous updates with each build
- Vendor checklist mentality: SBOMs are often treated as one-time documents rather than living artifacts
Public vs Private SBOM Debate:
- Private SBOMs may be justified for mission-critical systems (e.g., medical devices) where updates are complex and supply chains can’t be immediately fixed
- Public SBOMs empower defenders: attackers already have better visibility into tech stacks than defenders
- The “skeleton in the closet” argument: some organizations hide SBOMs to conceal outdated dependencies (e.g., Microsoft using 6-year-old runc)
- For SaaS vendors and auto-updating software, public SBOMs are generally better for security
VEX and VDR (Vulnerability Exploitability eXchange / Vulnerability Disclosure Report):
- VEX and VDR are valuable augmentations to SBOMs that distinguish inventory from vulnerability context
- VEX addresses whether vulnerabilities in dependencies actually affect the product
- VDR documents vulnerabilities in the vendor’s own code
- CycloneDX is leading standardization efforts for these formats
Software Asset Inventory:
- Organizations need comprehensive software asset visibility beyond just SBOMs
- OSQuery is highly recommended for enterprise-wide software inventory and querying
- Example: During Log4j crisis, organizations with OSQuery could quickly query “SELECT * FROM computers WHERE application LIKE ’log4j%.jar'”
- Drawing conclusions from existing logs (web gateway, AV, DNS) can identify malware and security issues
Geopolitical and Compliance Challenges:
- Data localization and contributor origin are emerging concerns
- Country of origin complexity: code may be written globally, but governed by parent company’s country regulations
- Export controls, mandatory vulnerability disclosure to governments, and GDPR implications
- Real-world example: Red Cross cannot use Microsoft Cloud if it’s considered a “conflicted party” in war zones
- Cloud service providers cutting off access due to sanctioned entity relationships
Shadow IT and AI:
- Future scenario: non-technical employees using credit cards to buy Cursor licenses, create UIs with Lovable, deploy via AI instructions - creating “shadow AI” and “shadow IT”
- This creates new supply chain risks that traditional SBOMs won’t capture
Centralized Dependency Management:
- SBOMs can help security teams identify commonly used libraries across an organization
- Security teams should provide vetted, audited library “battery packs” to developers
- Reduces tech debt by identifying problematic dependencies (e.g., npm modules that update daily)
- Organizations should either take ownership of unstable packages or find stable alternatives
Important Projects and Tools Mentioned
- SBOM Play - Privacy-first SBOM explorer with vulnerability and license insights (https://github.com/cyfinoid/sbomplay)
- OSQuery - Open-source tool for querying software inventory across enterprise environments (originally from Facebook/Meta)
- KeyChecker - Tool for automating known weakness detection (https://cyfinoid.com/automating-a-known-weakness-introducing-keychecker/)
- CycloneDX - Leading standard for VEX and vulnerability documentation
Key Insights and Quotes
- “Don’t treat SBOM as a security solution” - it’s an inventory that can be used for security, but developers need value from it too
- “Offensive problems are technical in nature. Defensive problems are political” - Hall of Flex quote explaining why attackers have better visibility
- “If I am charging you for the software, it is my responsibility to give you a correct picture” - expectation for paid software vendors vs open source
- “Your mileage will most definitely vary” - every organization’s SBOM implementation will differ based on their environment
Actionable Takeaways
- Create SBOMs at build time, not as afterthoughts
- Automate SBOM generation to avoid static document problems
- Use SBOMs to identify and consolidate commonly used libraries
- Security teams should provide vetted library packages to developers
- Consider VEX/VDR for vulnerability context beyond basic inventory
- Implement software asset inventory tools like OSQuery for comprehensive visibility
- Treat SBOMs as living documents that update with each build, not vendor onboarding checklists