Dependency Security

Most applications are assembled as much as they are written. A package manager brings in libraries, frameworks, plugins, and their dependencies. That saves time, but each component becomes code you must understand, update, and trust.

Dependency security is the practice of controlling that inherited risk throughout a product's life. It starts before you add a package. It continues through installation, review, release, monitoring, and replacement.

The central mistake is to reduce this work to a vulnerability scan. A scanner can match known advisories to an observed package and version. It cannot decide whether you should trust a maintainer, whether the package is actually deployed, or whether an upgrade breaks your application. It also cannot find a vulnerability that nobody has disclosed.

The mental model

Think of dependency security as a loop with five controls:

1. Know the complete dependency graph, including transitive dependencies.
2. Choose components whose source, maintenance, license, and security posture fit your use.
3. Constrain resolution with reviewed manifests, lockfiles, trusted registries, and integrity checks.
4. Detect and decide by matching advisories, then adding exploit and application context.
5. Remediate and learn through tested updates, removal, mitigation, and recorded exceptions.

A direct dependency appears in your manifest because your code requests it. A transitive dependency is pulled in by another dependency. Both can execute inside your trust boundary. OWASP therefore recommends tracking versions for direct and nested components, monitoring them, and applying risk-based updates.

Your dependency graph connects the components and versions in a build. A manifest often describes allowed versions. A lockfile records a resolved graph for repeatable installation. For example, npm documents that its package lock describes the exact generated tree. Repeatability helps review because an unreviewed release does not appear merely because a version range allowed it. A lockfile does not prove that the recorded code is safe.

An SBOM, or software bill of materials, records component identity and relationships in a machine-processable form. It supports inventory and incident response across a released product. It does not replace the package manager's lockfile, and neither artifact proves absence of vulnerabilities.

What can go wrong

Dependency risk has several forms:

• A component contains a known vulnerability.
• A package or version is obsolete, unsupported, or no longer maintained.
• A maintainer account, registry, release process, or distribution artifact is compromised.
• A confusing or malicious package name causes the wrong component to be installed.
• An update introduces an incompatible change or a new transitive dependency.
• Inventory misses vendored code, generated components, plugins, or runtime downloads.

OWASP places these failures inside its 2025 Software Supply Chain Failures category. The scope is wider than known vulnerabilities because malicious changes and weak distribution controls can matter before any advisory exists.

A working process

Start at intake. Confirm the package identity and official source. Read its maintenance and security information. Ask whether the feature is small enough to implement without another dependency. Review the permissions and data the component can reach in your application.

Record the decision in normal code review. Commit the ecosystem's manifest and lockfile when the package manager supports one. Review the whole graph change, not only the requested top-level version. GitHub's dependency review follows this principle by showing manifest and lockfile changes in pull requests, including new known vulnerabilities.

Scan the resolved or built result. The OSV API, for example, accepts a package ecosystem, name, and version and returns matching vulnerability records. Matching is the start of triage. Verify the actual package identity and affected range before acting.

Prioritize with context. A CVSS Base score measures system-independent severity, not your complete risk. Add evidence of exploitation, such as CISA's Known Exploited Vulnerabilities Catalog. Then add reachability, exposure, privileges, data sensitivity, deployment count, and available mitigations.

Remediate with the smallest supported change that removes the exposure. Test the resolved graph, application behavior, and deployment artifact. Remove unused packages. If no fix exists, reduce exposure or replace the component. Record the owner, reason, compensating control, and expiration date for every accepted exception.

Keep the loop running. New advisories, releases, deployments, and exploit evidence change the answer after merge. NIST's Secure Software Development Framework calls for maintaining well-secured third-party components and monitoring them throughout the software life cycle.

Where this course stops

Dependency security covers the components your software consumes and the decisions around them. Build-system hardening, artifact signing, provenance, registry administration, and complete SBOM programs deserve their own treatment. They connect to this course, but no single control covers the whole software supply chain.