Tech Due Diligence CQ-6: Dependency Management and Supply Chain
What This Control Requires
The assessor evaluates how the organisation manages third-party dependencies, including the currency of libraries, vulnerability scanning for known CVEs, license compliance, and the strategy for managing dependency updates and security patches.
In Plain Language
Your application probably pulls in hundreds of open-source libraries. Each one is a potential security hole, a licensing liability, or a ticking clock if the maintainer walks away. How you manage that supply chain says a lot about your engineering discipline.
Assessors will look at the total number of dependencies and how current they are, whether you run automated vulnerability scanning, how often you actually apply updates, whether your licences are compatible with your distribution model, and whether any critical dependencies are abandoned or maintained by a single person.
Dependency debt compounds fast. The longer you defer updates, the larger and riskier each update becomes - and known vulnerabilities sit in your codebase the entire time. Teams that keep a regular update cadence demonstrate the kind of operational discipline investors want to see.
How to Implement
Wire automated dependency scanning into your CI/CD pipeline. Tools like Dependabot, Snyk, Renovate, or npm audit can identify vulnerable dependencies and generate pull requests for updates automatically. Configure them to run on every build and block merges when critical vulnerabilities are found.
Set a clear update cadence. Security patches should land within days of release. Minor version bumps can be batched weekly or fortnightly. Major version upgrades should be planned and executed quarterly. Track dependency freshness as a metric the team owns.
Maintain a Software Bill of Materials (SBOM) listing all direct and transitive dependencies with their versions, licences, and sources. This is increasingly expected by regulators and enterprise customers. Automate SBOM generation with tools like Syft, CycloneDX, or SPDX.
Run licence compliance checks. Make sure every dependency licence is compatible with how you ship your product. Block the introduction of dependencies with incompatible licences (for example, GPL in a proprietary SaaS). Keep a list of approved and prohibited licence types.
Go beyond vulnerability scanning and assess dependency health more broadly. Is the library actively maintained? How widely adopted is it? Are there alternatives if the maintainer disappears? What does its own transitive dependency tree look like?
Lock your dependency versions for reproducible builds. Commit lock files (package-lock.json, Pipfile.lock, go.sum) and verify their integrity in CI. Never run production builds with unpinned versions.
Plan ahead for end-of-life migrations. Identify dependencies approaching EOL or maintained by a single individual, and build migration plans before the situation becomes urgent.
Evidence Your Auditor Will Request
- Automated dependency scanning tool configuration and reports
- Dependency freshness metrics (average versions behind current)
- Software Bill of Materials (SBOM) for production applications
- License compliance audit results
- Dependency update frequency and process documentation
Common Mistakes
- Dependencies significantly outdated with known critical vulnerabilities unpatched
- No automated vulnerability scanning; manual or ad-hoc dependency review
- License compliance never assessed; potential legal exposure from GPL or similar licenses
- Critical dependencies maintained by a single person or abandoned project
- Lock files not committed or not used, leading to non-reproducible builds
Related Controls Across Frameworks
Frequently Asked Questions
How many known vulnerabilities in dependencies are acceptable?
Should we avoid open-source dependencies?
Track Tech Due Diligence compliance in one place
AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.
Start Free Assessment