Guest:

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:

EP270 The Convenience Tax: Why We Keep Failing at Supply Chain Security

Cloud Security Podcast by Google