Dependency Update Policies
🌟 Objective
Establish systematic practices for the proactive updating of third-party libraries and dependencies, avoiding the accumulation of technical debt and prolonged exposure to known risks.
⚠️ Many vulnerability exploits occur in libraries that already have a patch available but have not been updated. The update policy is an essential defence.
⏲ Principles of secure updating
- Every dependency must have a defined TTL (Time To Live): the maximum period before it is reviewed.
- Mechanisms for explicit version locking must be used, to avoid unaudited updates.
- Updates must be automated where possible, but always validated before deploy.
- Periodic updating must be treated as part of the development cycle, not as an exception.
🛠️ Control mechanisms by language
| Stack | Lockfile / Mechanism | Update tools |
|---|---|---|
| Node.js | package-lock.json, npm ci | npm-check-updates, RenovateBot |
| Python | requirements.txt, pip-tools | pip-review, Dependabot |
| Java (Maven) | pom.xml, fixed version | Versions Maven Plugin |
| .NET | packages.lock.json, *.csproj | dotnet outdated, NuKeeper |
| Go | go.sum, go.mod | go get -u, Dependabot |
🔐 The use of lockfiles is essential for reproducibility and traceability.
🔧 Recommended review frequency
| Project type | Minimum frequency of automated dependency review (scan) |
|---|---|
| Critical production (L3) | Weekly (automatic + manual validation) |
| Backend / API (L2) | Fortnightly |
| Internal / Tools (L1) | Monthly |
SCA findings must be handled outside this cycle, in a reactive regime (e.g. a CVE with an alert).
📅 Update strategies
- Automated proactive: bots that open update PRs with tests
- Grouped per sprint: a periodic "library update" task
- Semantic control: defined
^and~limits and ranges - Pinning of critical versions: e.g.
express@4.18.2vsexpress@latest
📄 Checklist for applying updates
| Item | Verified? |
|---|---|
| Is there a lockfile and is it versioned? | ☑ |
| Are periodic updates carried out traceably? | ☑ |
| Do all updates go through CI/CD with tests? | ☑ |
| Are the versions audited by SCA after an update? | ☑ |
| Are critical updates triaged within ≤ 24h and fixed within the level SLA (Policy 19 §4.3)? | ☑ |
🔗 Links to other files
| Document | Link with updates |
|---|---|
02-analise-sca.md | Detects vulnerabilities that may require an update |
04-integracao-ci-cd.md | Automates updates and applies validators in the pipeline |
03-governanca-libs-terceiros.md | Defines which dependencies may or may not be updated |
✅ Updating dependencies is a technical and risk management process. It must not be postponed indefinitely, nor carried out without adequate validation and traceability.