Dependency Security
💡 Practical note:
Tools such as Snyk, OWASP Dependency-Check, Sonatype, Xygeni, among others, already make it possible to detect known vulnerabilities (CVEs) in libraries and packages used at build, run or test time.
These tools are useful for applying a policy of continuous validation and automated enforcement, but they do not replace the technical team's critical analysis of the legitimacy, necessity and currency of the dependencies used.
📌 Objectives
- Reduce the risk of exploitation through outdated or compromised libraries.
- Ensure that all dependencies have a technical justification and security validation.
- Establish a traceable process for approval and version control.
- Facilitate the automation of checks (SCA) and blocking in CI/CD.
- Support internal and external audits with evidence of technical control.
This document defines the minimum criteria for the secure use of external dependencies (and reused internal ones), ensuring that they are:
- Validated for known vulnerabilities
- Technically legitimised by the team
- Up to date and traceable over time
👥 Who should apply it
- Developers: when adding or updating packages.
- Tech leads / technical reviewers: when approving PRs with changes to
package.json,pom.xml,requirements.txt, etc. - Security / AppSec team: when defining allowlists or approval rules.
⏱️ When to apply it
- Whenever a dependency is introduced or updated.
- Periodically, by automated means (e.g. nightly scans).
- Before each release or delivery to production.
- During audits or security reviews.
🧱 Mandatory requirements
-
CVE validation through SCA (Software Composition Analysis)
- Automated scans with alerts and reports per PR or build.
- Integration with CI/CD.
-
Approved list (allowlist) and exclusion policy (denylist)
- Avoid unaudited, unmaintained or abandoned libraries.
- Mandatory for projects classified L2/L3.
-
Explicit technical validation in PRs
- Justification for the inclusion.
- Assessment of the library's maintenance and origin.
-
Regular package updates
- Require updates of obsolete, vulnerable or deprecated packages.
- Automate alerts per dependency with a known, unmitigated CVE.
-
Differentiated management of runtime vs. dev/test dependencies
- Apply validation proportionate to the risk of exploitation in production.
🚨 Risk signals
- Libraries without maintenance for more than 1 year.
- Packages with fewer than 10 stars and no official release.
- Scripts or binaries included without validation.
- Private forks without upstream updates.
✅ How to validate
- Automated scans on each commit/PR (
dependency-check,snyk test, etc.). - Manual approval of each new package.
- Blocking triggers in the pipeline for severe vulnerabilities.
- Review of the dependency's changelog and repository.
🧾 How to evidence it
- Dependency scanner execution logs.
- Versioned
.approved-deps.ymlfile or equivalent. - PR comment with the validation and justification for the new dependency.
- Update history in the repository or package management system.
🔄 Link to other practices
| Theme | Associated file |
|---|---|
| Linters and validations in the pipeline | addon/02-linters-validacoes.md |
| Justification of exceptions | addon/05-excecoes-e-justificacoes.md |
| Validation integrated into code review | addon/08-validacoes-codigo.md |
| Traceability in code and PRs | addon/09-anotacoes-evidencia.md |
📌 The inclusion of insecure dependencies is one of the most common causes of application compromise.
The validation process must be systematic, traceable and blocking in critical cases.