Practice the vocabulary of tracking and verifying every dependency in a software artifact.
0 / 5 completed
1 / 5
At standup, a dev mentions generating a complete list of every third-party library and dependency used to build a software artifact, including transitive dependencies. What is this document called?
A software bill of materials, or SBOM, is a complete, generated list of every third-party library and dependency used to build a software artifact, including transitive dependencies pulled in indirectly by a direct dependency. A list of only directly installed packages misses the often much larger set of indirect dependencies that also ship as part of the final artifact. An SBOM gives a team full visibility into everything that's actually included, which is essential for assessing supply-chain risk.
2 / 5
During a design review, the team wants to automatically check a newly generated SBOM against a database of known vulnerabilities before allowing a build to be released. Which capability supports this?
Automated SBOM vulnerability scanning checks a newly generated software bill of materials against a database of known vulnerabilities, flagging a dependency with a known issue before the build is released. Manually cross-referencing every dependency by hand doesn't scale, especially given how many transitive dependencies a modern build typically includes. This automated scanning turns the SBOM from a passive inventory into an active gate that can block a genuinely risky release.
3 / 5
In a code review, a dev notices a build pipeline attaches a cryptographically signed attestation confirming exactly how and from what source an artifact was built. What does this represent?
A build provenance attestation is a cryptographically signed record confirming exactly how, from what source code, and through what build process a specific artifact was produced. This lets a consumer of the artifact verify it genuinely came from the expected trusted build pipeline, rather than being tampered with or substituted somewhere along the way. This kind of provenance verification is a key part of a broader supply-chain security framework, since it addresses integrity, a concern that an SBOM's dependency listing alone doesn't cover.
4 / 5
An incident report shows a critical vulnerability in a widely used transitive dependency went unnoticed for months because the team's build had no SBOM and no automated scanning process. What practice would prevent this?
Generating an SBOM for every build and scanning it automatically on an ongoing basis surfaces a vulnerability in a transitive dependency that would otherwise go completely unnoticed. Tracking only direct top-level dependencies misses the often much larger and less visible set of indirect ones. This continuous, automated SBOM generation and scanning is exactly the missing practice a supply-chain incident like this one reveals.
5 / 5
During a PR review, a teammate asks why the team generates an SBOM and scans it automatically instead of manually reviewing the top-level dependencies listed in the project's package manifest. What is the reasoning?
Manually reviewing only the top-level package manifest entries misses the much larger set of transitive dependencies pulled in indirectly, which is often where an unnoticed vulnerability actually lives. A generated SBOM captures that complete picture, including every transitive dependency actually shipped in the build. The tradeoff is the need to integrate SBOM generation and automated scanning into the build pipeline itself, rather than relying on a simpler, purely manual review.