Open source risk comes in at least three forms: a package with a known flaw, a package nobody maintains, and a package that was made or changed to cause harm. Each needs different detection and a different response, and advisory scanning mainly covers the first.
Vulnerable
A published flaw affects a version you use. Detection is a lookup against advisory data. The response is to upgrade, patch or mitigate.
Prioritise with evidence. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities exploited in the wild and recommends using it as an input to prioritisation. Add reachability, meaning whether your code actually calls the vulnerable path, and where the package runs.
Abandoned
Nobody is fixing anything. Today it may have no known flaws, but the next one will have no fix. Detection comes from project health signals: no recent releases, unanswered issues, no security policy. OpenSSF Scorecard includes a check for whether a project is maintained, along with others such as code review and branch protection.
The response is planned replacement: pick an alternative, fork it if you must, or remove the dependency. The cheapest time to act is before an advisory arrives.
Malicious
The package or a release was built to do harm, either from the start or after a takeover or a compromise of a legitimate maintainer. Advisory data usually lags because there is no flaw to describe, only intent.
The xz case in March 2024 is the example most people know. Andres Freund reported on oss-security that release tarballs contained an obfuscated build step that was absent from the git source. Detection came from an engineer investigating slow logins, not from a scanner.
Defences are different here: build from source and compare artifacts, restrict install scripts, delay adoption of new releases of critical packages, and monitor for unexpected behaviour.
The three side by side
- Vulnerable: the signal is an advisory match, and the first response is to upgrade or mitigate.
- Abandoned: the signal is no maintenance activity, and the first response is to plan a replacement.
- Malicious: the signal is a behaviour or artifact mismatch, and the first response is to isolate, remove and investigate.
Which one deserves your time
For most teams, vulnerable packages produce the most volume and abandoned ones the most slow burning trouble. Malicious packages are rarer but with a larger blast radius. A programme that watches only the first leaves the other two to chance.
A starter set of controls
- An inventory that includes transitive dependencies.
- Advisory matching with exploitation and reachability context.
- A quarterly health review of critical packages.
- A short delay on new versions of the most sensitive dependencies.
Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Which kind is hardest to detect?
Malicious. There may be no advisory and no version change that stands out, so behaviour and artifact comparison matter.
Is an abandoned package a vulnerability?
Not by itself. It is a future risk, because any new flaw will go unfixed.
Sources
- Andres Freund, oss-security disclosure, 29 March 2024
- CISA Known Exploited Vulnerabilities Catalog
- OpenSSF Scorecard
Last reviewed: 19 October 2026.
