In a CI/CD pipeline, where is SCA (software composition analysis) most effective, and why?
- 1Only as a one-time audit before a major release
- 2On every PR/build in CI, plus continuous monitoring of deployed dependencies for newly disclosed CVEs✓ correct
- 3Only in production via runtime instrumentation
- 4Manually by the security team during quarterly reviews
SCA should gate every PR/build so a newly introduced vulnerable or unwanted-license dependency is caught before merge — fast, automatable feedback in the developer's workflow. But that alone is insufficient: a dependency that was clean at merge time can have a CVE disclosed against it later (your code didn't change, the threat did). So SCA must also run as continuous monitoring against your SBOM/lockfile of deployed software, alerting when a known component becomes vulnerable. A one-time pre-release audit (a) misses both ongoing PRs and post-deploy disclosures; runtime-only (c) is too late and isn't what SCA does; quarterly manual review (d) doesn't scale and is far too slow for dependency risk.
SCA runs early and continuously — on every PR/build and as ongoing monitoring — because new CVEs are disclosed against dependencies you already shipped.