A widely used open-source logging library bundled into a cloud application's build is disclosed to have a critical CVE. The team needs a tool that inventories every third-party dependency, including transitive ones, and flags known vulnerabilities on each build. Which tool category fits?

Software composition analysis identifies the open-source and third-party components in an application, including transitive dependencies pulled in by other libraries, by reading package manifests, lock files and build artifacts. It matches each component version against vulnerability and license data and can generate a software bill of materials. Run on every build, it answers the question raised by a newly disclosed CVE: which applications include the affected component, in which versions, and through which dependency path. Static application security testing analyzes the organization's own code for insecure patterns; it may not examine third-party libraries at all and does not track published vulnerabilities by component version. Dynamic application security testing probes a running application from outside and may reveal some exploitable flaws, but it cannot produce a dependency inventory or reliably attribute a weakness to a specific library version. Database activity monitoring observes database queries to detect misuse, not build-time dependencies. Exam caveat: SCA supports both the software assurance objective and supply-chain management, and the SBOM it produces helps answer exposure questions within hours rather than weeks. Operational check: confirm SCA runs in the pipeline with a policy that fails builds on critical known vulnerabilities, and query the current SBOMs to list every service that includes the affected library.