When something goes wrong
Vulnerability monitoring with OSV, CISA KEV and EPSS
An allow list is a photograph. It is right the day somebody writes it and wrong soon after, because advisories land against versions that were fine when they were approved.
The Vulnerabilities page rechecks every version the rules allow and everything in the cache against osv.dev, which includes the GitHub advisory database. A full pass over seven thousand versions takes about twenty seconds, because the feed takes bulk queries. A version pulled for the first time is checked as it goes out. Container images are read layer by layer and checked against the advisories for Debian, Ubuntu, Alpine, Wolfi, Chainguard, Red Hat, Rocky and AlmaLinux.
The other package types use OSV's own feeds: NuGet, Maven, RubyGems, Swift (the SwiftURL feed) and Packagist for Composer. RPM mirrors are checked against the feed you pick for each mirror (AlmaLinux 8, 9 or 10, Rocky Linux 8, 9 or 10, or Red Hat), and APT mirrors against Debian 11, 12 or 13 or Ubuntu 20.04 to 26.04 LTS, by source package, so libssl3 gets the advisories of openssl. CocoaPods has no feed at OSV, so pods get no advisories.
Severity says how bad a flaw would be. CISA KEV says it is being exploited now, and FIRST EPSS says how likely that is in the next thirty days. Both are fetched daily and shown on every finding, and the dashboard puts known exploited first.
Developers hear about it without anybody breaking their build:
- npm audit is answered locally from these findings, so nothing about your project leaves the box.
- A warning during the install, in npm's own output, naming the version, the severity and the fixed release.
- Who downloaded what: every pull of a version with a known advisory is recorded with its token, application and environment.
An ordinary finding never blocks anything by itself. Blocking a version breaks whoever depends on it, and that is not a decision for a background job at three in the morning. Each finding has a block button, and safe version resolution is there when you want it automatic.
There is one exception, and it is on by default. A MAL- advisory means the package itself is malicious, not that it has a bug. When the scan records one, it goes on the kill switch and admins get the mail. It is added once, so an admin who lifts it keeps it lifted, and Kill known-malicious packages by themselves switches it off.
In short
- OSV scans of everything allowed and cached, on a schedule, for every type but CocoaPods
- CISA KEV and FIRST EPSS on every finding
- Operating system packages inside images, eight distributions
- RPM and APT mirrors checked against their own distro's feed
- Known malicious
MAL-advisories killed by themselves, once npm auditanswered locally, install time warnings- CSV and JSON export of every finding the filter matches
In the documentation
- See known vulnerabilities Developer Guide
- Vulnerabilities and safe version resolution Administrator Guide
- Image scanning and "try again in a minute" Developer Guide
Goes well with
- Safe version resolution Versions with serious advisories are left out, so a range quietly settles on the newest safe one.
- Who has it Search a package, a hash or a CVE and see the applications, environments and pipelines that pulled it.
- Waivers A written down, time boxed yes for one finding on one package, scoped to an app or environment.
One container, about two minutes
A Linux box with Docker, or one without it, and a reverse proxy for TLS. The installer does the rest and it is safe to run twice. Free, MIT licensed, nothing to sign up for.