Which components are vulnerable
Every component with a package URL is checked against the open vulnerability database.
CRA Article 14 — reporting live since 11 September 2026
Your SBOM has hundreds of components carrying thousands of known CVEs. A few dozen of those CVEs are actually being exploited in the wild right now. Only that second group starts a 24-hour reporting clock. Every other scanner shows you the first. Flagrante shows you the difference.
pip install flagrante
then
syft dir:. -o cyclonedx-json | flagrante
Free. No account. No dependencies. Works offline against cached feeds.
$ syft dir:. -o cyclonedx-json | flagrante 24-HOUR CLOCK LIKELY RUNNING (2) Confirmed exploited in the wild -- CISA KEV CVE-2021-44228 org.apache.logging.log4j/[email protected] listed in CISA KEV since 2021-12-10 as exploited in the wild, linked to ransomware campaigns ASSESS TODAY (16) Elevated exploitation probability, not yet confirmed CVE-2019-12384 com.fasterxml.jackson.core/[email protected] EPSS 45% probability of exploitation within 30 days 65 further known vulnerabilities with no exploitation signal (--all to list) CANNOT BE CHECKED (2) No package URL in the SBOM. An unknown, not a clear. VERDICT 1 component carries 2 vulnerabilities confirmed exploited in the wild. If any of these ship in a product you place on the EU market, assess Article 14 reporting now. ARTICLE 14 CASCADE Early warning 2026-09-04 17:10 UTC (24h) Notification 2026-09-06 17:10 UTC (72h) Final report 2026-09-17 17:10 UTC (14d)
Drop in a CycloneDX or SPDX JSON SBOM. No account, no email, nothing to install.
CycloneDX or SPDX, JSON, up to 5 MB and 1,000 components.
Don't have one? syft dir:. -o cyclonedx-json > sbom.json
An SBOM is a complete inventory of your software supply chain, so the only honest thing to do with it is nothing. It is parsed in memory, scanned, and dropped when the request ends. It is never written to disk, never logged, and never stored — there is no storage layer in the scanner to leak. If you would rather it never left your machine at all, that is what the CLI is for, and it does exactly the same thing.
Three public feeds, no API keys, no account. Flagrante does not generate your SBOM — syft and cdxgen already do that well and for free. It answers the one question they do not.
Every component with a package URL is checked against the open vulnerability database.
The Known Exploited Vulnerabilities catalogue: observed being used against real targets.
Modelled probability of exploitation within 30 days, for everything KEV has not caught yet.
Which lands each finding in one of four tiers:
| Tier | Trigger | What it means for you |
|---|---|---|
| Clock running | Listed in CISA KEV | Assess Article 14 reporting now. The 24-hour window runs from awareness. |
| Assess today | EPSS ≥ 10%, not in KEV | Not confirmed exploited. This is the group that becomes an obligation next. |
| Track | Known CVE, no exploit signal | Patch on your normal cadence. |
| Cannot be checked | No package URL in the SBOM | An unknown, not a clear. Usually a vendored binary or first-party module. |
KEV grows every week, and the 24-hour window starts when you become aware — not when you next remember to run a scan. The technical file behind an Article 14 report also has to show when you knew, and holding that evidence for ten years is part of the obligation, not a nice-to-have.
Planned pricing. Continuous watching, alerts the hour KEV changes, and a dated evidence trail you can hand to a market surveillance authority.
No charge now and no card. We will write once when it is ready, and once more if the price changes before launch. Nothing else.
A tool in this space that hides its limits is not worth trusting with a €15 million reporting obligation. Three, stated plainly:
If a feed is unreachable, Flagrante refuses to print a result rather than printing an empty one. An unreachable exploitation feed and a clean scan look identical and mean opposite things.