Managing open source vulnerabilities and malicious packages

A package can be free of known CVEs and still be malicious. It can also come from the expected source and still contain vulnerable code. Managing open source risk requires two connected security workflows at different points in the dependency lifecycle: vulnerability management for selected components, and package-admission controls that act before a package executes.

The vulnerability management workflow helps teams inventory components, assess exploitability, and remediate and mitigate risks. That workflow is necessary, but not all open source risk is captured by a Common Vulnerabilities and Exposures (CVE) record. Supply chain attacks can also involve deliberately malicious packages, including typosquatted packages, compromised releases, and injected backdoors. These threats may surface outside the traditional vulnerability disclosure process and may never even receive a CVE ID.

The package-admission controls workflow addresses a different question: Should this package be allowed into the environment in the first place? These controls govern repository routes, screen packages, evaluate available provenance, apply release delays where appropriate, and manage exceptions. Neither workflow replaces the other, and a scanner built for the first doesn't cover the second.

What counts as an open source vulnerability?

An open source vulnerability is an unintentional weakness in an open source component that an attacker could exploit. It is distinct from a malicious package, which OpenSSF classifies as “a form of malware that is delivered as an open source package and published to a package repository, such as PyPI or NPM.” Both create open source dependency risk, but they require different controls.

Take a typical vulnerable dependency: a CVE record provides an identifier and public description of the vulnerability. Your Software Composition Analysis (SCA) tool can use this vulnerability data to flag affected dependencies, and your engineering team can then assess whether your application uses or can reach the vulnerable code path.

Now compare that with a lookalike package whose install script steals credentials. The package may behave exactly as its author intended and have no CVE for conventional SCA matching to flag. Malicious packages can also enter through dependency confusion, or compromised maintainer accounts.

Each threat class calls for different evidence. Version-to-advisory matching finds known weaknesses. Malware analysis looks for harmful indicators or behavior. Provenance provides evidence about where and how an artifact was built.

A clean SCA result only means that no known record matched that version. It doesn't show that the artifact you retrieved is benign or that it's the one the maintainer published.

How the two workflows divide open source dependency risk

Managing open source dependency risk requires both vulnerability management and package admission. The table below maps each threat class to the questions and controls relevant to it. The following sections examine each workflow in more detail.

These workflows are complementary, not mutually exclusive. A package that passes admission controls still requires ongoing vulnerability management, while a package with no known vulnerabilities still requires an admission decision.

Vulnerability management workflow

This workflow begins once your team has selected a component version, along with any transitive dependencies. If a vulnerability affects a dependency your team uses directly, the remediation path may be easy to identify. If it affects a transitive dependency, follow the dependency graph to identify which direct package brings it in, then map the affected application or repository to the team responsible for making the necessary change.

The vulnerability management workflow has three stages: build an accurate inventory, find, assess, and prioritize known weaknesses, then treat the exposure and verify the result.

1. Build an inventory that matches the shipped artifact

Before teams can determine whether a released application contains an affected component, they need an inventory of the exact component versions that shipped. Manifests and lockfiles provide a starting point, but neither necessarily reflects the contents of the final artifact.

Your manifest shows what was declared, while the lockfile typically shows what the resolver selected. Later build steps can add, remove, or transform components.

Generate or refresh a SBOM after dependency resolution. When later build steps change the contents, refresh it for the final release artifact and associate the SBOM with that specific release.

In your inventory, include dependency relationships, and retain enough identity information to connect your findings to the artifact that actually shipped. CISA’s Minimum Elements for a Software Bill of Materials document provides a useful baseline for component identity, versions, hashes, and dependency relationships.

2. Find, assess, and prioritize known weaknesses

Once you have this inventory built, your SCA can turn the inventory into findings by matching component identities and versions against vulnerability databases and advisories. Tools such as OSV-Scanner can inspect lockfiles, SBOMs, or project directories.

When a vulnerability is found in a dependency, first validate the match by confirming that the reported vulnerability applies to the package, version, and advisory scope in question. Then assess whether it affects your product, including whether the vulnerable functionality is present and whether the deployed application can reach it. A Vulnerability Exploitability eXchange (VEX) statement can report the product’s status as affected, not affected, fixed, or under investigation. Use that status to inform your engineering assessment alongside evidence from your application, build, and deployment, not as a substitute for that assessment.

Once applicability is established, prioritize the response. Three key data points are especially important when considering prioritization:

• A CVSS Base score communicates technical severity, though it does not measure organizational risk by itself.

• CISA’s Known Exploited Vulnerabilities (KEV) Catalog identifies vulnerabilities with confirmed exploitation.

• The Exploit Prediction Scoring System (EPSS) estimates the probability that a published CVE will be exploited in the wild within the next 30 days.

Combine these signals with internet exposure, asset criticality, likely business impact, available compensating controls, and the cost of change. Your findings can then inform the treatment plan and remediation schedule.

3. Treat the exposure, then verify the result

Once a finding has been validated and prioritized, choose the treatment that best addresses the risk. Upgrade to a fixed version, apply a patch or tested backport, remove an unused dependency, or replace the component to remediate the exposure. If a fix is not yet practical, a mitigation such as network segmentation or disabling the affected feature can reduce the likelihood or impact while the weakness remains. Document this as mitigation rather than remediation, along with the remaining risk.

Next, verify the result against the installed artifact. The verification process should be adapted to the treatment used. For example, a version scan alone may not verify a backport because the upstream version number can remain unchanged.

Even once you have addressed and verified the risks found in step 2, keep monitoring. Regenerate inventory whenever your build changes, and continue matching an unchanged inventory against new advisories, exploitation data, and affected-status evidence.

A vulnerability management and remediation workflow does not replace package admission. Any replacement artifact or new package version must still pass the organization’s package-admission controls before execution.

Package admission workflow

Malicious packages don’t always have a CVE, malicious-package report, or other record for an SCA tool to match. This is often true of typosquats that mimic legitimate package names and compromised releases. If you rely solely on your vulnerability management workflow, a malicious install script can run before any matching record reaches your vulnerability queue.

The package admission workflow asks a critical question before anything executes: Should this package be allowed into your environment or permitted to run at all?

A solid package admission workflow combines four connected controls (steps 1-4 below) and a reviewable exception process (step 5). It sets the approved repository route, the screening required before a package is served internally or executed, any release-age delay, and the origin or build evidence required where that evidence is available. Each control needs an enforcement point and an accountable exception path.

1. Enforce the approved repository route

Every other admission control depends on packages actually flowing through the approved route. Test whether developer laptops, CI jobs, and artifact managers can bypass the approved repository path. Common bypass routes include package-manager fallback behavior, upstream ordering, namespace and scope rules, alternative credentials or configuration, or network egress.

Configure builds to resolve direct and transitive dependencies through trusted repositories only, and close any route that a build could use to silently resolve a dependency directly from a public registry.

2. Define what package screening can see

Screening systems can combine several kinds of analysis and evidence, including:

• Known malicious-package reports, hashes, and other indicators of compromise

• Static analysis of package contents and install scripts

• Source-to-artifact comparison (where the necessary source and build information are available)

• Publisher, maintainer, metadata, and release-history anomalies

• Sandboxed installation or execution (including observed commands, processes, filesystem changes, and network behavior)

OpenSSF’s Package Analysis work gives a good example of how instrumented installation and execution can surface behavior that advisory matching will not.

Document the signals that your control uses, especially noting which results will cause a block, quarantine, or manual review, and what remains outside its view. A clean result tells you only that the package did not trigger those signals; it does not establish that the package is necessarily benign. Your admission process still has to make the policy decision.

3. Use cooldowns as delay, not detection

A configurable cooldown creates a waiting period before newly published packages become available. This gives the community, security researchers, and vendors more time to identify threats, but detection still relies on package screening and threat intelligence. Cooldowns can also delay urgent security fixes, so choose a duration that fits your risk tolerance and assign an owner to review and approve exceptions.

4. Verify origin and build evidence

For artifacts that carry signatures and provenance, verify the signature or attestation against an accepted identity and root of trust. Confirm that its subject digest matches the exact artifact, then compare the reported source revision, builder identity, and build process with your policy expectations. These checks can expose distribution tampering or a mismatch with the expected source or build.

SLSA’s threat model defines the boundary: its primary focus is supply-chain integrity. Provenance does not establish that the source itself is benign, protect against every malicious producer, or choose the correct package for you.

5. Make exceptions reviewable

Treat your controls as unverified until they produce records of blocks, bypasses, and approvals. Record the exact scope of every exception, including the package and version covered and the rule being overridden. Also record the owner and approver, justification, evidence reviewed, any compensating controls, and an expiry or required review date. When the exception closes, record whether it expired, was revoked, was renewed, or was replaced by a compliant package or policy change. Retain the resulting policy decisions and exception history so that, if necessary, teams can later reconstruct how and why the package was admitted.

Coordinate both workflows through evidence, ownership, and exceptions

The two workflows intersect when vulnerability remediation requires retrieving a new package version. A configured cooldown may delay a release that patches an actively exploited vulnerability. AppSec and the application owner can assess whether the deployed application is affected and how urgently it needs the fix. The package-admission policy owner can then approve an exception, select another approved version or backported fix (if one is available), or maintain the waiting period while engineers apply temporary mitigations.

Whichever path the team chooses, record who approved it, the evidence supporting the decision, and what must happen next. Once the change is deployed, verify the exact installed artifact. Then, refresh the SBOM for that release and continue monitoring. Give every temporary mitigation or exception an owner and an expiry or retirement condition so that it does not become permanent through neglect.

Shared evidence and tooling can support both workflows, but they do not collapse them into a single decision. Keep the detection signal, decision owner, response timing, and verification evidence explicit.

Use Chainguard Libraries to support both workflows

Vulnerability management and package admission remain separate security decisions, but they can share a controlled dependency source. Chainguard Libraries supports both workflows by providing remediated artifacts and source-to-artifact evidence, while also applying repository controls to eligible upstream artifacts served through optional fallback.

For Chainguard-built libraries, the Chainguard Factory rebuilds packages from a verified upstream source and distributes them with provenance and SBOMs. If there are identified CVEs in a covered library, Chainguard may build the latest public version or backport an upstream fix.

Packages served through optional protected upstream fallback retain their upstream origin but are subject to repository controls before being served. They do not receive the provenance and SBOMs provided for Chainguard-built packages.

In vulnerability management, remediated versions of covered libraries give teams another upgrade or backport path, and SBOMs for Chainguard-built artifacts feed the inventory. In package admission, Chainguard Libraries serves as the controlled repository route, and teams can verify provenance for Chainguard-built artifacts. Fallback artifacts pass repository controls before they're served but don't carry the same build evidence, so admission policy should treat the two differently.

Chainguard Libraries doesn't replace SCA or vulnerability triage. Teams must still identify and prioritize applicable vulnerabilities, test updates, and monitor deployed artifacts. What changes is the dependency path—and the evidence and controls available before and after a package is selected.

Learn more about Chainguard’s malware-prevention approach and how Chainguard Libraries can reduce reliance on direct public-registry access.