Dependency Vulnerability Management

Build an evidence-based inventory

Record the components that enter source builds, deployment images, runtime environments, developer tooling, and hosted services. Include package name, resolved version, source registry, owning team, supported status, and where the component is deployed. Lockfiles, image manifests, and software bills of materials can supply evidence, but each must reflect the artifact that actually reached an environment.

Separate direct dependencies chosen by the team from transitive packages selected by other packages. Include operating-system libraries and build actions when they can affect a release. Remove unused components where practical because every retained component adds maintenance work. Protect inventory records from unauthorized changes while keeping them available during an incident or vendor outage.

Validate advisories before prioritizing

Match an advisory to the exact package ecosystem, component, version range, configuration, and deployment. Similar names can refer to unrelated projects, and a source repository version may differ from a bundled runtime version. Prefer maintainer, registry, CISA, or other accountable advisory evidence and preserve the reference used for the decision.

Assess whether the affected function is present and reachable from untrusted input or a lower-privilege actor. Then consider data sensitivity, service criticality, network exposure, existing isolation, and evidence of active exploitation. Reachability can lower urgency, but it does not erase future exposure or maintenance debt. Record uncertainty instead of changing a scanner severity without explanation.

Choose and deliver a treatment

The preferred treatment is often an update to a supported fixed version, but removal, configuration change, feature disablement, network restriction, or vendor replacement may be appropriate. Read release notes and migration guidance. For a high-consequence finding without a ready fix, involve the incident lead and service owner to choose temporary controls and monitoring rather than improvising production changes.

Apply changes through the normal reviewed build and release path. Update resolved manifests, regenerate artifacts from trusted inputs, run focused behavior and security tests, stage the release, and observe it before wider promotion. Preserve the previous trusted artifact and configuration for rollback. Do not download unofficial patches or probe third-party systems to decide whether an advisory is real.

Verify closure and govern exceptions

Closure requires evidence that deployed artifacts no longer contain the affected version or that the approved alternative control is operating. Re-scan the resulting artifact, inspect its manifest, run relevant regression tests, and confirm production rollout. Check that an older vulnerable image, function, or dormant environment is not still reachable through a forgotten route.

An exception should name the owner, affected assets, rationale, compensating controls, monitoring, expiration, and next review. Track time to triage and remediate by consequence, not raw alert volume. Review inventories, unsupported components, registry trust, exception age, restore options, and current OWASP guidance quarterly. Escalate active exploitation indicators through the incident plan.

Triage a vulnerable parsing library

An automated alert reports a high-severity issue in a transitive document parser used by an owned internal upload service.

1. Confirm the resolved package version in the deployed image and compare it with the accountable advisory range.
2. Trace whether uploaded documents reach the affected parsing function and identify the service identity, data, network, and tenant boundaries.
3. Restrict uploads or disable the parsing path if immediate consequence warrants containment, while preserving evidence and service recovery options.
4. Update the parent or transitive dependency through a reviewed build, then test representative synthetic files and failure handling in staging.
5. Verify the released artifact inventory, monitor parser errors, retain rollback, and record the evidence that closes the finding.

Dependency finding decision record

Complete one record for each material component finding so prioritization and closure remain reviewable.

• Identity: ecosystem, package, resolved version, source, artifact, environment, owner, and advisory reference.
• Exposure: affected function, reachable path, actor, privilege, data, service consequence, and uncertainty.
• Treatment: fixed version, removal, temporary control, tests, approver, deadline, and rollback artifact.
• Verification: rebuilt manifest, scan result, behavior tests, deployment evidence, monitoring, and closure reviewer.
• Exception: rationale, compensating safeguard, accountable owner, expiration, and quarterly reassessment date.

Common mistakes

• Prioritizing every scanner alert by its headline score without confirming package identity, deployed version, or reachable behavior.
• Editing a lockfile or suppressing an alert without rebuilding and verifying the artifact that actually runs.
• Leaving an accepted finding open indefinitely without an owner, protective control, expiration, or monitoring plan.

Try one

Sources

• OWASP Vulnerable Dependency Management Cheat SheetOWASP practices for inventorying and remediating vulnerable components.
• OWASP Software Supply Chain Security Cheat SheetOWASP controls for source, build, dependency, and release integrity.