Dependency Risks

What can go wrong

• A published flaw in a library version you use. Public databases track these, often with identifiers in the CVE format.
• Transitive dependencies: the packages your packages depend on. You may have hundreds you never chose.
• Abandoned packages. With no maintainer, nobody fixes problems when they appear.
• Supply chain attacks: a malicious package, a hijacked maintainer account, or a look-alike name (typosquatting) that you install by mistake.
• Licence obligations. Dependencies come with licence terms you must respect. See Licensing and Open Source.

Managing dependencies

• Add dependencies deliberately. Check that the package is maintained, widely used and needed. A few lines of your own code can be safer than a new package.
• Commit the lock file your package manager creates so builds are reproducible, and install from it in CI (see CI/CD Basics).
• Update regularly. Small, frequent updates are easier than a big jump after years, and tests give you confidence to update.
• Scan automatically. Ecosystem audit commands (for example npm audit, pip-audit or dotnet list package --vulnerable) and services such as GitHub Dependabot report known vulnerable versions and can propose updates.
• Triage alerts. Not every finding is exploitable in your usage, but understand it before dismissing it.
• Install only from trusted registries, and never run install scripts from sources you cannot vouch for.

Updating has risks too

A new version can break behaviour or, rarely, be compromised. That is why lock files, tests and review of dependency changes matter. Keep secrets out of build pipelines that run third-party code where you can.

Try it

Run your ecosystem’s audit command in a project you work on, for example npm audit, and read one finding. Which package is affected, is it a direct or transitive dependency, and what is the fixed version?