Vulnerability Analysis of Dependencies (SCA)
🌟 Objective
Ensure that all external dependencies (direct and transitive) are analysed automatically and on a recurring basis for known vulnerabilities, with traceability between:
- Component identified in the SBOM
- Associated vulnerability (CVE)
- Affected artefact and version
- Fix, exception or mitigation task
The SCA process is essential to reduce the risk associated with reusing third-party libraries and packages.
🚀 How the SCA process works
- The generated SBOM is used as input for the scanner.
- Each component is compared against vulnerability databases (NVD, GitHub Advisories, OSV, etc.).
- For each CVE found, the following are identified:
- Severity (CVSS base score or equivalent)
- Exploitation vector (local, remote, etc.)
- Patch / fix status
- A processable report is generated (e.g. JSON, HTML, SARIF) and, where applicable, the pipeline is blocked.
🤖 Recommended open source tools
| Tool | Languages / Support | Remarks |
|---|---|---|
| Syft | Multi-stack (Node, Java, etc.) | Generates the SBOM + integrates with Grype |
| Grype | Multi-stack | Vulnerability scanner with OSV/NVD |
| Trivy | Apps, containers, IaC | SCA + SAST + secret scanning |
| OWASP DC | Java/Maven/Gradle | OWASP Dependency-Check, well supported |
| OSV-Scanner | Node, Go, Rust, Python | Uses the OSV.dev database, integrates with GitHub |
💡 Syft + Grype is a particularly effective combination for modern pipelines.
💳 Commercial tools with broader coverage
| Tool | Highlights relevant to SbD-ToE |
|---|---|
| Snyk | SCA, IaC scanning, CI/CD integration, policy enforcement |
| GitHub Advanced Security | CodeQL + SCA + Secret scanning integrated into the repository |
| Jfrog Xray | Repositories, SCA, container scanning, centralised SBOM |
| WhiteSource (Mend) | Licences, risks, policies, centralised alerts |
| Checkmarx One | SAST, SCA, IaC, API Security with integration per language and pipeline |
These tools may be justified in regulated environments or where there are large volumes of projects.
🌐 Integration into the lifecycle
| Moment | Expected action | Result |
|---|---|---|
| 📁 Build | SCA scanner run with the SBOM as input | Report + build status |
| 📑 Pull Request | Alerts visible and findings triaged | Conditional approval or blocking |
| ✅ Release | Verification of pending findings | Go/no-go |
| 🚨 Vuln. disclosed | Notification, triage and associated fix | Issue/ticket with traceability |
⚠️ Prioritising findings
Findings must be triaged on the basis of:
- Severity: CVSS > 7.0 = Critical
- Exposure: Is the application public? Is the affected function reachable?
- Impact: Are sensitive data or critical actions involved?
- Alternative mitigation: Is there a documented compensating control?
- Fix available?: Does a fixed version exist?
Findings with no plausible exploitation must not be ignored, but classified as "accepted" on the basis of justified risk.
🔗 Link to the backlog and traceability
| Element | Recommended form |
|---|---|
| Finding (e.g. CVE-2023-1234) | Create an issue with a reference to the SBOM/component |
| Status | "Pending", "Fixed", "Accepted w/ justification" |
| Tags | sca, vuln, sbom, seguranca, cve |
| Evidence of the fix | PR, commit, release, updated artefact |
💡 A dashboard per project is suggested, with the status of active findings + a link to the associated task.
📎 Cross-references
| Document | Link with SCA |
|---|---|
01-inventario-sbom.md | Source of the components to analyse |
04-integracao-ci-cd.md | Automated execution in the pipeline |
08-rastreabilidade-vulnerabilidades.md | Mapping between finding, action and release |
🔎 SCA analysis must be documented, automated and prioritised, integrating with backlog tools, code repositories and release artefacts.