Dependency Audit Template for Engineering Teams

Run automated vulnerability scanning (npm audit, Snyk) on every CI build. Run the full audit process described in this template quarterly. Run an emergency audit whenever a high-profile vulnerability is disclosed in your ecosystem (e.g., a CVE in a widely-used package).

If the package works and has no known vulnerabilities, continue using it but pin the version. Add it to a watch list and check maintenance status at each quarterly audit. If it becomes a security risk, consider forking it or writing a minimal replacement. Document the decision in your [Architecture Decision Record](/templates/architecture-decision-record-template).

No. Update security patches immediately. Update minor and patch versions in batches during regular maintenance sprints. Plan major version upgrades individually because they often include breaking changes. Never update everything at once. It makes it impossible to isolate the source of a regression.

If a vulnerability is in a transitive dependency, check whether your direct dependency has released a version that bumps the transitive. If not, use overrides (`npm overrides`, `pip constraints`, `cargo patch`) to force the patched transitive version. Document overrides so they can be removed when the direct dependency catches up.

MIT, Apache 2.0, BSD (2-clause and 3-clause), ISC, and Unlicense are generally safe for commercial use. GPL, AGPL, SSPL, and EUPL have copyleft provisions that may require you to release your source code. Consult your legal team for any license not on the approved list. "No license" means all rights reserved by the author, so treat unlicensed packages as high risk.