How do organisations get started with Vulnerable Dependency Management?

What to establish first in vulnerable dependency management

Start with a dependency inventory that is accurate enough to drive action, not just reporting. Teams need to know which packages are installed, where they are introduced, which applications depend on them, and which versions are pinned or floated. That baseline is what turns vulnerable dependency management from an ad hoc cleanup exercise into a repeatable control.

Once the inventory exists, the next decision is how you will recognise exposure. That usually means pairing software composition analysis with package lock files, build artefacts, and a vulnerability source such as the OpenSSF ecosystem so you can distinguish a real production dependency from a transitive package that is only present in development or test tooling.

The Open Source Security Guide is the right starting point when you need a broader view of dependency security, because it ties together SBOMs, version pinning, scorecards, trusted publishing, and vulnerability handling into one operational model. For most organisations, that broader model matters because the same dependency can be introduced through several pipelines and then reappear after a partial fix.

How to turn findings into repeatable remediation

The practical goal is not simply to identify vulnerable libraries, but to make replacement or patching the default outcome. That means defining who approves upgrades, how exceptions are granted, how long an exception can live, and what evidence is required before a vulnerability is marked closed. Without that process, teams often fix the first alert and then reintroduce the same vulnerable version later through another service, branch, or container image.

Build pipelines are the best enforcement point because they can stop newly introduced vulnerable versions before they reach production. Package lock files help preserve that decision by recording the exact resolved dependency tree, while transitive dependency review catches the cases that developers did not add directly but still inherit into the application. In practice, the process should also verify deployment, because a patched manifest does not matter if the running image or release artifact never changed.

When the issue is a vulnerable package in a public software ecosystem, the attack path can be operationally severe even if the defect looks ordinary on paper. The LiteLLM PyPI package breach illustrates why dependency hygiene is treated as a security control, not just maintenance: malicious or compromised packages can become a delivery mechanism for broader compromise, including secret exposure and downstream access abuse.

Where dependency risk becomes operationally urgent

The highest-risk dependencies are the ones that sit in internet-facing services, authentication flows, build systems, and deployment paths that can spread the same flaw across many applications. A single library update can affect dozens of services, and a single missed transitive package can leave multiple teams believing they are protected when they are not. That is why dependency management has to be tied to service criticality, not just to vulnerability count.

There is also a supply-chain dimension to watch. If a vulnerable package is replaced, the organisation still needs to know whether the new version is coming from a trusted source and whether its integrity is protected in transit and at publish time. The Zero-Day and Exploited Vulnerabilities Guide is useful here because it reinforces the operational difference between a routine vulnerability and one that is actively exploited, where emergency mitigation and fast verification matter more than normal release cadence.

That same urgency is why the EU Cyber Resilience Act matters to dependency management. It pushes organisations toward secure-by-design lifecycle handling, vulnerability disclosure, and ongoing maintenance of software with digital elements, which makes dependency control part of product governance rather than a one-time engineering task.

Practitioner Guidance

What to prioritise: Begin with the services that have the most exposure and the highest change velocity, then move inward to internal tools and lower-risk applications. That ordering reduces the chance of spending effort on low-impact libraries while an externally reachable service still ships a known vulnerable component.

What to verify: Confirm that your tooling can answer three questions for every fix: where the dependency came from, whether the vulnerable version is still present in a build or runtime artifact, and whether the deployed environment actually picked up the corrected version. A dependency program is weak if it only proves the issue was found.

Common mistake: Treating dependency scanning as a reporting function instead of a remediation workflow. The teams that get stuck usually have alerting, but no ownership, no expiry on exceptions, and no verification that replacement versions are being adopted consistently.

Practitioner takeaway: The first mature step is not broader scanning, it is tighter control over how vulnerable versions enter, persist, and reappear across the software delivery path.

Related resources from NHI Mgmt Group

• How should organisations get started with IT asset inventory management?
• How do organisations get started with Integrated Risk Management (IRM)?
• How do organisations get started with Endpoint Configuration Management?
• How do organisations get started with Privacy Programme Management?