A critical vulnerability is announced in a widely used open-source logging library. The security team must determine quickly which of the company's hundreds of applications include that library, including as a transitive dependency. Which practice makes this answerable in minutes?

A software bill of materials is a machine-readable inventory of the components, including transitive dependencies and their versions, that make up a software artifact. Software composition analysis tools generate SBOMs during builds and match components against vulnerability data. When a new critical vulnerability is published for a library, the team queries the stored SBOMs for that component and version range and immediately gets the list of affected applications and builds, even where the library arrived indirectly through another dependency. Static application security testing analyzes the organization's own code for insecure patterns; it does not reliably inventory third-party library versions and would take far longer across hundreds of repositories. Dynamic testing with the exploit string probes running applications one at a time, can miss vulnerable code paths that the probe does not reach, and risks disrupting production systems. The shared responsibility matrix explains who owns patching in a cloud service model, but it does not identify which applications contain the component. Exam caveat: an SBOM is only useful if it is generated for every build and kept current; a stale inventory gives false confidence. Operational check: confirm the CI pipeline emits an SBOM for each release, stores it centrally, and that a query for the vulnerable library returns results within minutes, including transitive matches.