Software Supply Chain Security - SBOM Explained

A team ships code that passes every security scan, then gets breached anyway because the breach came through a dependency nobody was watching. This is why supply chain security and SBOMs show up constantly in DevOps and DevSecOps interviews: they test whether you think past your own code to the full attack surface.

The answer interviewers want

An SBOM, or software bill of materials, is your software's ingredient list. It tracks every dependency, its version, and its license across your application, the same way a nutrition label tells you what's actually in a product.

In production, you generate this with a tool like syft, which scans your containers and produces an SBOM in SPDX or CycloneDX format. Both are standard formats that other tools in the security chain can read and act on. The key operational point is that this isn't a one-off audit task: you automate SBOM generation inside your CI pipeline, so every build produces an up-to-date, machine-readable inventory of what's actually running.

The reason this matters for security, not just inventory, is that attackers specifically target dependencies because they're trusted by default. Your own code might get scanned and reviewed carefully, but a transitive dependency three levels deep often isn't. One compromised package can ripple out and affect thousands of applications that pulled it in without a second look. That's the real answer to why "secure" code still gets compromised: the vulnerability was never in your code, it was in something your code trusted implicitly.

Why interviewers ask this

This question separates people who think about security as a code-review problem from people who think about it as a systems problem. Interviewers want to see that you understand the attack surface extends to every dependency, container layer, and third-party package your build pulls in, not just the lines your team wrote. It also signals whether you've actually operationalized SBOM generation, versus just knowing the term.

Follow-ups to expect

"Where would you integrate SBOM generation in a CI pipeline?" Right after the build or container image step, so the SBOM reflects what's actually being shipped, not just what's in the source repo.

"What would you do with an SBOM once you have it?" Feed it into vulnerability scanning against known CVEs, track license compliance, and keep a historical record so you can quickly answer "are we affected" when a new dependency vulnerability is disclosed.

"Why not just trust a dependency once it's vetted?" Because trust at one point in time doesn't account for the package being compromised later, which is exactly why attackers target trusted, widely-used dependencies in the first place.

The common wrong answer

Candidates often define SBOM correctly as a list of dependencies but stop there, treating it as a compliance checkbox rather than a security control. They miss the attacker's logic: dependencies are high-value targets precisely because they're trusted by default and reused everywhere, so an SBOM without active scanning and CI automation behind it is just documentation, not defense.