Q14 of 24 · Security
What is software composition analysis (SCA) and how does it fit into a QA team's workflow?
Short answer
Short answer: SCA scans your dependency tree for known vulnerabilities (CVEs) in third-party libraries. Tools include Snyk, Dependabot, and OWASP Dependency-Check. QA's role is to ensure SCA runs in CI, that critical/high CVEs fail the build or trigger an alert, and that remediation SLOs are defined and tracked.
Detail
Modern applications typically have hundreds of transitive dependencies. Each library version may have known CVEs tracked in the National Vulnerability Database. SCA tooling maps your dependency lock file against the CVE database and reports which of your dependencies are affected.
Common tools:
- Snyk: integrates with GitHub/GitLab as a PR check, supports npm, pip, Maven, Gradle, Composer, Go modules. Provides fix PR suggestions.
- Dependabot (GitHub native): automatically raises PRs to bump vulnerable dependencies.
- OWASP Dependency-Check: open-source, runs as a CI step, generates HTML/XML reports. Language-agnostic.
- npm audit / pip-audit / Trivy: native or lightweight alternatives per ecosystem.
QA governance responsibilities:
- Ensure SCA is configured to run on every PR and on a nightly schedule (new CVEs are published daily — a clean scan on Monday may have a critical finding by Wednesday).
- Define severity thresholds: Critical CVEs fail the build immediately. High CVEs generate a defect and must be resolved within 7 days (or an accepted-risk decision is documented). Medium CVEs go on the backlog.
- Track remediation: SCA findings need to be in the same defect tracker as functional bugs, with the same SLA governance.
What SCA doesn't catch: vulnerabilities in your own code, configuration issues, secrets in the codebase, and logic flaws. It is complementary to SAST and DAST — not a substitute.