SBOMs' limits and false comfort

Guest:

• Dan Lorenc, Founder / CEO, Chainguard

Topics:

• We just saw a security tool (Trivy) get used to pop an AI infrastructure tool (LiteLLM) to eventually pop end users. Have we reached the point where our security tooling is actually our largest unmanaged attack surface?
• Why now? Software supply chain security had the perennial vibe of "not top concern" for most organizations, right?
• TeamPCP pushed malicious code to existing GitHub tags. We've been screaming about pinning versions to SHAs for years, but clearly, nobody is listening. Is it time to admit that 'convenience' is the primary enemy of supply chain security?
• The Axios incident showed a victim compromised in under two minutes. In a world of auto-updating dependencies, is the concept of a human-in-the-loop for software updates officially dead, or do we need to look very hard at version pinning and such?
• With XZ Utils case, we saw a long-game social engineering attack. Beyond just 'watching npm closely,' what are the realistic architectural safeguards for an org that knows they can't audit every line of an update?
• We've spent the last three years talking about SBOMs (Software Bill of Materials) like they were a pill for supply chain health. But if the scanner producing the SBOM is the one that's compromised, isn't the SBOM just a signed receipt for your own house being on fire?
• What is the one practical thing they can do to ensure their CI/CD isn't a credential-exfiltration-as-a-service platform?

Resources:

• Video version
• North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack
• EP100 2022 Accelerate State of DevOps Report and Software Supply Chain Security
• EP116 SBOMs: A Step Towards a More Secure Software Supply Chain
• EP226 AI Supply Chain Security: Old Lessons, New Poisons, and Agentic Dreams
• EP24 Linking Up The Pieces: Software Supply Chain Security at Google and Beyond
• Matt Levine blog