DEV Community: Nicholas Toledo

The EU Cyber Resilience Act and the new Product Liability Directive — what an engineer actually has to do

Nicholas Toledo — Tue, 15 Sep 2026 05:08:14 +0000

Two EU instruments now touch the code you ship. They ask different questions, and conflating them is where most of the confusion comes from.

Regulation (EU) 2024/2847, the Cyber Resilience Act (CRA). Its Article 14 reporting obligations became enforceable on 11 September 2026. A regulation applies directly, with no national statute in between.
Directive (EU) 2024/2853, the new Product Liability Directive (PLD). It applies to products placed on the market after 8 December 2026. A directive binds you through your member state's transposition.

I am an engineer, not a lawyer. Everything below is engineering guidance — what you can check, what you can build, which common readings are wrong. It is not legal advice, and for the PLD the text that governs you is your national implementation.

The date that is printed wrong almost everywhere

Article 2(1) of the PLD sets the scope of the whole directive by reference to when a product was placed on the market. As published in the Official Journal, that date read 9 December 2026.

It was corrected. Corrigendum 2026/90364 (OJ L, 2026/90364, 7.5.2026) changes Article 2(1) to read "after 8 December 2026".

Three things follow, and the third catches people:

The corrigendum touches the scope sentence only. Articles 20, 21 and 22(1) still say 9 December 2026, and they should — those govern transposition and the repeal of Directive 85/374/EEC, not which of your releases falls under the new regime. Do not harmonise them in your notes.
EUR-Lex serves the original OJ text at the eli/dir/2024/2853/oj URL. Corrigenda live at separate URLs and appear in the consolidated version. If you read the directive in 2024 and wrote the date down, your note is stale.
Most secondary commentary — law-firm explainers, conference slides, the summary someone pasted into your Confluence — predates the corrigendum and still says 9 December.

The delta is one day, and it is a real day: a product placed on the market on 9 December 2026 is in scope under the corrected text and arguably out of scope under the text most people quote. Whether a release counts as "placed on the market" on a particular day is a legal question I cannot answer for you. That the text changed is a fact you can check at the link above.

Two laws, two different questions

Reduce each to the question it actually asks.

CRA Article 14 asks: is something I ship being actively exploited right now?

That is an operational reporting obligation with a cascading clock. For an actively exploited vulnerability in a product with digital elements: early warning within 24 hours, vulnerability notification within 72 hours, final report within 14 days. Reports go to the coordinating national CSIRT and to ENISA; the Commission's CRA reporting page has the mechanics. Article 14 covers more than the vulnerability limb — read it in full. I deal only with the actively-exploited path because that is the one with a 24-hour clock.

The words doing the work are actively exploited. Not critical. Not high. Not "CVSS above 9". Severity is a property of the vulnerability; exploitation is a fact about the world. A CVSS 9.8 in a library you ship, with no evidence anyone is exploiting it, starts no Article 14 clock. A medium-severity auth bypass someone is using against your customers today does.

The uncomfortable corollary: your severity triage — routing 9.8s to the on-call and 5.4s to the backlog — is not a CRA process. It sorts on the wrong axis. You need a second, smaller question alongside it: is this being used?

The PLD asks: can I still supply security updates for what I shipped?

Not a reporting obligation — civil liability exposure, running on years rather than hours. Recital 6 confirms no-fault product liability covers all movables "including software". Recital 32 says a product can be defective "on account of its cybersecurity vulnerability". Recital 19 is the one to internalise: a product remains within the manufacturer's control where the manufacturer retains the ability to supply software updates.

So: the CRA is present tense, measured in hours. The PLD is past tense — what did you put on the market, what state is it in now — measured in the lifetime of what you shipped. One is an incident process. The other follows from your maintenance posture, decided years before it matters, by whether you can still cut a patch release for the version a customer runs.

What you can actually check, with real commands

Everything here is a public endpoint: no key, no account.

1. CISA KEV: a free, dated exploitation signal

The Known Exploited Vulnerabilities catalogue is a single JSON file:

KEV=https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
curl -s "$KEV" | jq '{catalogVersion, count, first: .vulnerabilities[0].cveID}'

The shape, with values elided:

{
  "catalogVersion": "2026.09.14",
  "count": 1710,
  "vulnerabilities": [
    {
      "cveID": "CVE-...",
      "vendorProject": "...",
      "product": "...",
      "dateAdded": "2021-11-03",
      "dueDate": "...",
      "knownRansomwareCampaignUse": "Known"
    }
  ]
}

At catalogue version 2026.09.14 it held 1,710 entries, running from 2021-11-03 to 2026-09-14, with 89 added in the preceding 90 days and 360 flagged knownRansomwareCampaignUse: "Known". Reproduce both counts:

curl -s "$KEV" | jq '[.vulnerabilities[] | select(.knownRansomwareCampaignUse == "Known")] | length'
curl -s "$KEV" | jq '[.vulnerabilities[] | select(.dateAdded >= "2026-06-16")] | length'

Roughly one new entry a day — small enough for a human to read every addition, a realistic weekly input rather than another firehose.

2. OSV.dev: what advisories touch a package version

curl -s -X POST https://api.osv.dev/v1/query \
  -H 'Content-Type: application/json' \
  -d '{"package":{"ecosystem":"npm","name":"lodash"},"version":"4.17.20"}' \
  | jq '.vulns[0] | {id, aliases, summary}'

/v1/query returns full records: id, aliases, summary, affected, references. Ecosystem strings are case-sensitive — npm, PyPI, Go, Maven, crates.io. Lower-case pypi matches nothing.

3. The gotcha that returns a clean result forever

For a lockfile you want /v1/querybatch, which takes many queries per request. Here is the trap:

# BROKEN. Runs fine. Finds nothing. Ever.
osv=$(curl -s -X POST https://api.osv.dev/v1/querybatch \
  -H 'Content-Type: application/json' \
  -d '{"queries":[{"package":{"ecosystem":"npm","name":"lodash"},"version":"4.17.20"}]}' \
  | jq -r '.results[].vulns[]?.id' | sort -u)

kev=$(curl -s "$KEV" | jq -r '.vulnerabilities[].cveID' | sort -u)

comm -12 <(echo "$osv") <(echo "$kev")   # empty, always

querybatch does not return the same objects as query. It returns only:

{"results":[{"vulns":[{"id":"GHSA-xxxx-xxxx-xxxx","modified":"2026-...Z"}]}]}

Two fields. id and modified. No aliases. And the ids are GitHub Security Advisory ids — GHSA-.... KEV is keyed on CVE-.... The namespaces never collide, so that intersection is empty by construction, for every input, forever.

This is worse than a crash. A crash tells you something is wrong. This tells you that you are clean — a green check, a quiet Slack channel and a report you can show someone, indefinitely, while you ship an exploited CVE. It is the highest-confidence wrong answer here, and it is three lines of plausible shell.

The fix is a second call per advisory:

curl -s https://api.osv.dev/v1/vulns/GHSA-xxxx-xxxx-xxxx \
  | jq -r '.aliases[]? | select(startswith("CVE-"))'

/v1/vulns/{id} returns the full record including aliases, which is where the CVE lives. Resolve, then intersect.

Two notes. modified is a cache key: cache /v1/vulns/{id} on (id, modified) and a repeat run over an unchanged lockfile costs one request. And add a canary — a run that resolves zero CVE aliases across all advisories is not a clean result, it is a broken pipeline.

4. endoflife.date: what can no longer receive security updates

This is the PLD-shaped question, because Recital 19 ties control to your ability to supply updates.

curl -s https://endoflife.date/api/v1/products | jq '.result | length'   # 473, no key needed

curl -s https://endoflife.date/api/v1/products/nodejs \
  | jq -r '.result.releases[] | select(.isEol == true) | "\(.name)  eol \(.eolFrom // "unknown")"'

Releases carry isEol booleans and eolFrom dates, so that second command prints the branches that can no longer receive upstream security fixes. Run it against your runtimes, base images, database engines and frameworks — the dates move, so run it rather than trust a list.

5. A sketch that ties it together

Standard library only. A sketch, not a product: no retries, no backoff, no concurrency, no paginated OSV results, no SBOM parsing.

#!/usr/bin/env python3
"""Which of my dependencies map to a CVE that CISA lists as exploited."""
import json, sys, urllib.request

OSV_BATCH = "https://api.osv.dev/v1/querybatch"
OSV_VULN  = "https://api.osv.dev/v1/vulns/"
KEV = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"


def get(url, payload=None):
    data = json.dumps(payload).encode() if payload else None
    hdr = {"Content-Type": "application/json"} if payload else {}
    with urllib.request.urlopen(
            urllib.request.Request(url, data=data, headers=hdr), timeout=60) as r:
        return json.load(r)


def main(deps):                       # deps: [(ecosystem, name, version), ...]
    queries = [{"package": {"ecosystem": e, "name": n}, "version": v}
               for e, n, v in deps]
    batch = get(OSV_BATCH, {"queries": queries})

    # Step 1: querybatch gives {id, modified} only. No aliases. No CVEs.
    found = {}                        # osv id -> dep
    for dep, result in zip(deps, batch.get("results", [])):
        for vuln in result.get("vulns", []):
            found[vuln["id"]] = dep
    if not found:
        print("no advisories returned - check your ecosystem strings")
        return 0

    # Step 2: resolve each id to its CVE aliases. The step people skip.
    cve_of = {}                       # cve -> (osv id, dep)
    for osv_id, dep in found.items():
        for alias in get(OSV_VULN + osv_id).get("aliases", []):
            if alias.startswith("CVE-"):
                cve_of[alias] = (osv_id, dep)

    # Canary: no aliases resolved means the join below is meaningless.
    if not cve_of:
        print(f"FAIL: 0 CVE aliases from {len(found)} advisories", file=sys.stderr)
        return 2

    # Step 3: now, and only now, intersect with KEV.
    kev = {v["cveID"]: v for v in get(KEV)["vulnerabilities"]}
    hits = sorted(set(cve_of) & set(kev))
    for cve in hits:
        osv_id, (eco, name, version) = cve_of[cve]
        print(f"{cve}  {eco}:{name}@{version}  osv={osv_id}  "
              f"added={kev[cve]['dateAdded']}  "
              f"ransomware={kev[cve]['knownRansomwareCampaignUse']}")
    print(f"{len(found)} advisories -> {len(cve_of)} CVEs -> {len(hits)} on KEV")
    return 1 if hits else 0


if __name__ == "__main__":
    sys.exit(main([("npm", "lodash", "4.17.20"), ("PyPI", "django", "3.2.0")]))

A non-empty result is not a legal conclusion. It is a prompt to find out whether the exploited path is reachable in your product, which only your team can answer.

What the law does not say

This is the part that gets over-read, usually toward panic. Four corrections, each tied to text you can check. Still not legal advice — these are readings I could not support from the text.

The PLD does not oblige you to ship updates. Recital 51 says the directive imposes no obligation to provide updates. There is no statutory patch cadence in it. Recital 19 treats your ability to supply updates as evidence the product remains within your control — which affects how defectiveness is framed, not whether you owe anyone a release. "The EU now requires security patches for ten years" is not what the PLD says.

Pure economic loss is excluded. Recital 24 puts it outside the directive's damage categories. Recital 20 does make destruction or corruption of data recoverable. Line those up and a useful distinction appears: a failure mode that destroys customer data sits much closer to recoverable damage than one that takes you offline for six hours. If your worst realistic outcome is downtime, your PLD exposure may be narrower than the headlines suggest. Two caveats: whether a given SaaS is a "product" here is not something I can settle, and recoverable damage will be worked out in national courts.

The open-source carve-out is real but narrow. Article 2(2) excludes free and open-source software developed or supplied outside a commercial activity. Note what it turns on: commercial activity, not licence choice. An MIT licence file does not by itself put you in the carve-out. And it protects the FOSS developer, not the integrator — ship someone else's MIT-licensed library inside your commercial product and what you placed on the market is your product.

KEV is a US catalogue and the CRA does not point to it. Nothing in the CRA references CISA. KEV is public domain, dated, machine-readable and free, which makes it a good engineering signal, and that is the only reason it appears here. It is not a legal trigger and not exhaustive. Your own telemetry, a customer report, an upstream advisory or a researcher's email can make you aware of exploitation weeks before KEV lists it, or when KEV never does. A floor, not a definition.

And again: the PLD is a directive. Twenty-seven transpositions will differ on limitation periods, disclosure and procedure. The text that binds you is your national one.

What to actually do this week

Five things, no budget or vendor required.

Know what you ship. Generate an SBOM per release artifact and store it with the artifact. The SBOM you regenerate from main describes software nobody is running. When someone asks in fourteen months what was in version 4.2.1, the answer has to be a file, not archaeology.
Know what is on KEV. Run the intersection above against the dependency sets you shipped. Alert on non-empty, fail on zero-alias runs.
Know what is past EOL. One pass with endoflife.date over runtimes, base images and frameworks. Anything already EOL is something you can no longer patch — the capability Recital 19 talks about.
Have a written disclosure path. A SECURITY.md and a /.well-known/security.txt a stranger can find in thirty seconds, pointing at an address a human reads, plus the internal route from there to whoever can decide to report. An external reporter is a common way to learn you are being exploited, and a 24-hour clock is not the moment to find that your security alias forwards to someone who left.
Keep a dated record of reporting decisions — including the decisions not to report.

Item 5 is the one that matters. The Article 14 clock runs from awareness. Awareness is a state of mind in the past, and the only thing that evidences it later is something you wrote at the time. If you assess a vulnerability, conclude there is no evidence of active exploitation, and do not report — very often the correct call — that decision is invisible six months later unless you wrote it down. A dated note saying what you knew, when, from which source, what exploitation evidence existed, what you decided and who decided is defensible. A gap in the record is not.

Format does not matter. An append-only markdown file, or one ticket per decision: the issue, when you learned of it, where from, whether there was exploitation evidence, the decision, the decider, a review date. Five minutes each. Do it for the negatives especially — you will have far more of those, and nobody records them.

Optional but worth it: rehearse the 24-hour path once with a made-up vulnerability. Find your coordinating national CSIRT — which one depends on where you are established — and confirm the route before you need it.

Closing

None of this is legal advice. It is what I could verify, check with a command, or read directly in the text, and I have tried to be explicit about where that stops and a lawyer starts. The CRA applies directly; the PLD reaches you through your member state's law, which is what actually binds you. Read Article 14 and Article 2 yourself — both are shorter than this post.

I wrote two small open-source tools while working through the above — cra-watch and pld-watch — which do roughly what the sketch above does, with the caching and the canary in place.

Primary sources

CRA, Regulation (EU) 2024/2847: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
Commission CRA reporting: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
PLD, Directive (EU) 2024/2853: https://eur-lex.europa.eu/eli/dir/2024/2853/oj
PLD corrigendum 2026/90364: http://data.europa.eu/eli/dir/2024/2853/corrigendum/2026-05-07/oj
CISA KEV: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
OSV: https://osv.dev
endoflife.date: https://endoflife.date

If something here is wrong, say so in the comments and I will correct it.

A data migration isn't done until every row is accounted for

Nicholas Toledo — Tue, 15 Sep 2026 04:39:48 +0000

You moved data from one system to another. Now someone has to say it worked, and put their name on it.

The usual evidence is a row count and a few spot checks. "Source had 48,212 rows, target has 48,212 rows, I opened ten and they looked right." That sentence has signed off more migrations than any test suite, and it is worthless, because a row count cannot see the two failures that actually hurt:

rows that silently vanished (a join dropped them, a filter ate them, a key collided), and
rows that silently appeared (a default row, a duplicate insert, a fixture nobody removed).

If 300 vanish and 300 appear, the counts match. Spot checks find neither, because you spot-check the rows you thought of, and the rows you thought of are the ones that exist.

Every row lands in exactly one bucket

The fix is not more spot checks. It is an accounting identity: every source row and every target row must land in exactly one bucket, and the bucket totals must equal the raw row counts read from each file. If they don't, the tool refuses to write a report at all.

Source side:

bucket	meaning
`matched`	present in the target, every compared field equal after the normalisation you declared
`changed`	present in the target, at least one compared field differs
`unverified`	present, but a compared field was blank where blank means "not knowable"
`missing`	no target row, and no declared rejection
`rejected`	you declared it dropped, with a reason
`rejected_but_present`	you said you would drop it. It is in the target anyway
`duplicate_source`	the key occurs more than once in the source, so no occurrence is authoritative
`ambiguous_target`	the target holds several rows for this key, so there is nothing single to compare
`blank_key`	the key columns are empty

Target side:

bucket	meaning
`accounted`	attributed to exactly one source row
`orphan`	present in the target, absent from the source — something invented this data
`duplicate_target`	the key occurs more than once in the target
`ambiguous_source`	the source holds several rows for this key, so this row cannot be attributed
`blank_key`	the key columns are empty

orphan, rejected_but_present and the two ambiguous buckets are the whole reason to do this. They are the failures a row count cannot see, and most reconciliation scripts never look for them, because the person writing the script was thinking about the rows that should match, not the rows that should not exist.

Refusal is a feature

The rule that makes this work is the one that feels wrong at first: if the buckets don't reconcile, write nothing and exit non-zero.

A partial report with a plausible-looking total is worse than no report, because the plausible total is the one that ends up in the sign-off email. So the invariant is checked last, after all the bucketing, against the raw counts read from the files with no parsing cleverness in between:

rows_read(source) == sum(source buckets)
rows_read(target) == sum(target buckets)

Fail either, exit 2, no output. Put --strict in CI and a migration that stops reconciling fails the build instead of surfacing as a support ticket in March.

Three decisions that are usually made by accident

Blank is not zero, and blank is not a match. A missing balance and a balance of 0.00 are different facts. If the old system never captured a field, declare it — blank_policy: unknown — and those rows land in unverified rather than quietly counting as matched. You get a smaller verified number and a true one.

Date order is declared, never guessed. 03/04/2026 is March 4th or April 3rd depending on who exported it, and a tool that guesses will guess consistently wrong on exactly the twelve days a month where it matters. Say dmy or mdy in the spec. If a value can't be parsed under the declared order, that's a finding, not a coercion.

Values are text until you say otherwise. Read everything as strings. Leading zeros survive (02116 is a Boston ZIP, 2116 is not), a 16-digit account number never turns into 1.2345E+15, and 1.10 does not silently equal 1.1 unless you declared a numeric comparison with a tolerance. Most "the migration corrupted our data" stories are actually "the reconciliation script parsed the data on the way in."

The output is byte-stable on purpose

The report's content hash covers everything except the timestamp. Re-run it next quarter on the same inputs and you get the same hash, so the sign-off can cite a number that anyone can re-derive offline, and a "did the data change since we signed?" question has a one-command answer. The HTML report has no scripts, no external fonts and makes no network requests — enforced by a test — so it can be attached to a ticket and still open in five years.

Where to get it

I packaged this as the Migration Acceptance Kit: one Python file (reconcile.py, standard library only, no network access, no telemetry), its 74-test suite, a written acceptance procedure, a spec reference, worked examples, and a sign-off template. It is US$240 for one organisation, delivered automatically on payment. If you would rather build your own, the bucket tables above are the spec — the hard part is deciding to refuse, not the code.

One command:

python3 reconcile.py --spec specs/customers.json \
  --source export-source.csv --target export-target.csv \
  --rejects agreed-exclusions.csv --out reports/2026-09-15 --strict

Exit 0: reported. Exit 1: reported, but not clean under --strict. Exit 2: refused — and that refusal is the point.

Designing a compliance check that does not cry wolf in CI

Nicholas Toledo — Mon, 14 Sep 2026 20:26:48 +0000

Every team has a disabled check. It sits in .github/workflows/, commented out, with a note saying # TODO re-enable after we fix the noise. Nobody ever fixes the noise.

The check did not fail because it was wrong. It failed because it was annoying, and annoying is fatal in a way that wrong is not. A wrong check gets fixed. An annoying check gets deleted.

I spent a while building two small compliance scanners and got this wrong in several instructive ways. Below is what I would tell myself at the start — plus one bug that was much worse than noise, because it made the tool look like it was working while it found nearly nothing.

Start with the bug, because it is the important part

Both tools need to turn a declared version into something comparable against a catalogue. npm gives you ^12.0.0. Docker gives you 3.7-slim. nvm writes v16.20.2. Go modules say v1.19. You want the major, or major.minor.

The first version of that helper used this:

m = re.match(r"^(\d+)(?:\.(\d+))?", v.strip())

re.match anchors at the start of the string, and the pattern demands a digit there. Read that again against ^12.0.0.

The string starts with a caret. The match fails. The function returns the empty string. The component is dropped — silently, with no warning, no error and no log line.

Same inputs through the broken pattern and the fixed one:

input          buggy      fixed
'v16.20.2'     ''         '16.20'     <- what nvm writes into .nvmrc
'^12.0.0'      ''         '12.0'      <- npm's default range syntax
'~3.2'         ''         '3.2'
'>=16 <18'     ''         '16'
'v1.19'        ''         '1.19'      <- go.mod style
'3.7-slim'     '3.7'      '3.7'
'lts/gallium'  ''         ''          <- correctly unparseable

Every row that failed is a string that does not begin with a digit. That is the entire bug, and it happens to cover most of the ways version ranges are actually written in the wild — while leaving bare versions like 3.7-slim working perfectly.

The fix is one word:

m = re.search(r"(\d+)(?:\.(\d+))?", v.strip())

search instead of match: find the first number anywhere in the string rather than demanding it at position zero. Note lts/gallium still yields nothing, correctly — there is no version in it.

Why this is worse than a crash

A crash is self-reporting. A stack trace in CI gets fixed that afternoon.

This produced a plausible report. Here is the same project scanned with the buggy helper and the fixed one — a repo with a .nvmrc containing v16.20.2 and a Dockerfile with FROM python:3.7-slim:

################ FIXED ################
  Found    2 runtime/framework version(s)

  2 COMPONENT(S) PAST UPSTREAM END-OF-LIFE
    Node.js 16.20   (.nvmrc)
      upstream EOL   2023-09-11
    python 3.7   (Dockerfile FROM)
      upstream EOL   2023-06-27
EXIT = 1

################ BUGGY ################
  Found    1 runtime/framework version(s)

  1 COMPONENT(S) PAST UPSTREAM END-OF-LIFE
    python 3.7   (Dockerfile FROM)
      upstream EOL   2023-06-27
EXIT = 1

Both runs exit 1. Both print a real finding with a correct EOL date. Both look like a working tool doing its job. The buggy one lost an end-of-life Node runtime and said nothing about it.

That is the failure mode to fear. The only way to catch it is to already know the answer and compare — which is precisely the knowledge the tool exists to replace.

Three habits that would have caught it:

1. Test the strings the ecosystem actually emits, not the ones you find convenient. My fixtures said 16.20.2. Real .nvmrc files say v16.20.2 and real package.json files say ^16.20.2. The parametrised test that should have existed on day one:

@pytest.mark.parametrize("declared,expected", [
    ("v16.20.2",    "16.20"),
    ("^12.0.0",     "12.0"),
    ("~3.2",        "3.2"),
    (">=16 <18",    "16"),
    ("v1.19",       "1.19"),
    ("3.7-slim",    "3.7"),
    ("lts/gallium", ""),
])
def test_version_extraction(declared, expected):
    assert _major_minor(declared) == expected

A dozen lines. Would have failed on row one.

2. Report your denominator. If a tool sees 40 dependencies and can only extract versions from 3, that ratio is the most important number on screen. Both tools now print what they found and where:

  Scope    /tmp/demojava
           gradle.lockfile (3)
  Unique   3 components

Found 1 versus Found 2 in the runs above is the only visible difference between a working scan and a broken one. Print that number. Any scanner that silently drops unparseable input should be treated as suspect until it tells you how much it dropped.

3. Run it against a known-bad project first. Not to see whether it runs — to see whether it finds the thing you already know is there. If you cannot state the expected output before running, you cannot tell success from silence.

Exit codes: three states, not two

The default instinct is binary — 0 good, non-zero bad. That collapses a distinction that matters enormously in practice. Both tools use:

0 — checked, nothing found
1 — checked, found something that needs a human
2 — could not check

Case 2 is the one people skip, and skipping it is what makes checks get disabled. Consider a monorepo where the security workflow runs against every directory. Some are docs. Some are Terraform. They have no lockfiles and never will. If "no manifests found" returns 1, every one of those jobs goes red, forever, for a reason unrelated to security. Two weeks later somebody adds continue-on-error: true and the check is decorative.

Real behaviour on an empty directory:

$ cra-watch scan .

No dependency manifests found under /tmp/emptyproj

cra-watch looks for: Cargo.lock, Gemfile.lock, Pipfile.lock, composer.lock,
go.sum, gradle.lockfile, npm-shrinkwrap.json, package-lock.json,
pnpm-lock.yaml, poetry.lock, requirements-dev.txt, requirements.txt,
yarn.lock

$ echo $?
2

Exit 2, and it names every file it looked for. If you expected a finding, you can immediately see whether your manifest is on the list. "No data" and "bad news" are different facts and deserve different codes. It also hands the caller a real choice:

- name: KEV screen
  run: |
    set +e
    cra-watch scan .
    code=$?
    set -e
    case $code in
      0) echo "clean" ;;
      1) echo "::error::known-exploited component present"; exit 1 ;;
      2) echo "::notice::no manifests here, skipping" ;;
      *) echo "::warning::scanner failed, code $code" ;;
    esac

A team that wants exit 2 to be fatal — say, a repo that must always have a lockfile — can make it fatal. That is their policy decision, made explicitly, not a default imposed by my tool.

Pre-commit hooks must not block a commit they have nothing to say about

A pre-commit hook is a tax on every commit, and people notice within about two days. The rule: a hook must never block a commit in a repo where it has nothing to check. Not "should rarely". Never. The first time a hook blocks someone's commit over a repo that has no dependencies at all, they run git commit --no-verify, and once that is muscle memory the hook is gone.

pre-commit's files: regex solves this properly. Rather than run and then exit gracefully, do not run at all unless a relevant file changed:

- id: cra-watch
  name: cra-watch (EU CRA Article 14 / CISA KEV screen)
  entry: cra-watch scan
  language: python
  pass_filenames: false
  files: >-
    (?x)^(
      .*package-lock\.json|.*npm-shrinkwrap\.json|.*yarn\.lock|.*pnpm-lock\.yaml|
      .*requirements(-dev)?\.txt|.*poetry\.lock|.*Pipfile\.lock|
      .*go\.sum|.*Cargo\.lock|.*Gemfile\.lock|.*composer\.lock|
      .*gradle\.lockfile|.*packages\.lock\.json
    )$
  stages: [pre-commit, manual]

Now the hook fires when a lockfile changes and is invisible otherwise. Editing a README does not call a remote API. pass_filenames: false is deliberate too: the files: pattern decides whether to run, and the tool then scans the whole project, because a dependency change can affect the whole graph.

Cache the catalogue

Both tools read free, publicly funded APIs — CISA's KEV feed and endoflife.date. Neither charges and neither requires a key, but that is not the same as "hit it as often as you like". A pre-commit hook without caching would fetch a multi-megabyte JSON file on every commit. Multiply by a team, multiply by a year. That is how a free public service gets rate limits.

Cache on disk, respecting the platform convention:

CACHE_DIR = Path(os.environ.get("XDG_CACHE_HOME", Path.home() / ".cache")) / "cra-watch"

Then pick a TTL from how fast the data actually moves. KEV gains a handful of entries in a typical week, so a 6-hour TTL loses nothing. EOL dates are published months ahead, so 24 hours is generous. Always provide --refresh, because the moment you cache something, someone will need to not-cache it. And report the version you used, so a stale cache is visible rather than invisible:

  KEV feed    1709 entries, catalogue 2026.09.11

That line is how you notice you are looking at yesterday's answer.

Fail open on network errors

This one generates arguments, so here is the reasoning rather than the rule.

Your check calls a remote API. The API has an outage. If the tool fails closed, that outage now blocks every deploy at your company — your ability to ship a hotfix depends on the uptime of a third party you have no relationship with. Worse, the failure is unrelated to your risk: nothing about your code changed, no new vulnerability appeared, a webserver in another country returned 503.

So: warn loudly, use the cache if there is one, and exit 0.

except Exception as e:
    if cache.exists():
        eprint(f"warning: could not refresh KEV ({e}); using cached copy")
        return json.loads(cache.read_text())
    raise SystemExit(f"error: could not fetch the CISA KEV catalogue: {e}")

Same pattern for partial failures. When one OSV batch of several fails, the tool says so and continues:

warning: OSV batch 2/3 failed (timeout); those components are unchecked

The scan is now incomplete, and the output says it is incomplete. That is strictly better than either silently pretending everything is fine or blocking the release.

The counter-argument — "fail open means an attacker can bypass the check by breaking the network" — is real, and it is why this is a default, not a law. If your threat model includes that, make it fatal in your own pipeline.

The load-bearing principle

A check that fires constantly gets disabled. A check that fires rarely gets read.

Everything above is downstream of that. Exit code 2 exists so irrelevant repos stay green. The files: regex exists so the hook stays invisible. Caching exists so the check stays fast. Fail-open exists so a third-party outage does not train people to bypass it.

It is also why both tools deliberately answer narrow questions. cra-watch does not list your CVEs — only components on the CISA KEV catalogue, which is typically zero and occasionally two. pld-watch does not rank your tech debt — only components past their upstream end-of-life date. On a healthy project both print "nothing found" and get out of the way.

A security tool's most important output is the quiet one. If a developer sees your check go red, that redness needs to have meant something every previous time, or they will not look this time either.

Checklist

Three exit states: found nothing (0), found something (1), could not check (2)
"No data" is never a failure by default; let the caller escalate it
Pre-commit hooks scope with files: and stay silent otherwise
Cache public catalogues to disk, and print the catalogue version so staleness is visible
Fail open on network errors, warn loudly, use the stale cache
Print your denominator — how many things you found, how many you could parse
Test against the strings the ecosystem actually emits, not the tidy ones
Run against a known-bad project and check you get the answer you already knew

The last two caught a real bug. The rest is what keeps the tool installed long enough to matter.

Both tools are MIT and single-file: cra-watch, pld-watch. Engineering tooling, not legal advice.

Severity is not exploitation, and only one of them starts a 24-hour clock

Nicholas Toledo — Mon, 14 Sep 2026 20:25:41 +0000

Run a dependency scanner on a real project and you get four hundred CVEs. Somewhere in there might be one that matters right now. The scanner cannot tell you which, so it sorts by CVSS and hopes.

CVSS was never designed to answer "is anyone attacking this". It is a severity model — how bad would it be if exploited, given attack vector, complexity, privileges required, impact. It is a statement about the shape of a vulnerability, not about the world.

Exploitation is a statement about the world. Those are different questions, and there is now a regulation that keys on the second one and ignores the first.

The regulation that cares

The EU Cyber Resilience Act, Regulation (EU) 2024/2847. Most of it applies from December 2027, but the reporting obligations in Article 14 have been enforceable since 11 September 2026 — confirmed by the Commission — and they cover products already on the market.

Article 14(1) and 14(2)(a):

A manufacturer shall notify any actively exploited vulnerability contained in the product with digital elements that it becomes aware of [...] an early warning notification of an actively exploited vulnerability, without undue delay and in any event within 24 hours of the manufacturer becoming aware of it

Then 72 hours for a fuller notification, and a final report no later than 14 days after a corrective or mitigating measure is available.

The trigger is not "critical". Not "CVSS 9.8". Not "there's a PoC on GitHub". Article 3(42) defines it precisely:

'actively exploited vulnerability' means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner

Two properties of that definition are worth pausing on. It requires evidence, not plausibility. And the exploitation has to have actually happened. A vulnerability can be trivially exploitable, remotely, unauthenticated, with a public exploit — and if nobody has used it, it is not an actively exploited vulnerability under Article 3(42).

So: severity is a property of the vulnerability. Exploitation is a fact about the world. Only the second one starts the clock.

(I am an engineer reading a primary source, not a lawyer. Whether Article 14 applies to you, and when, is a legal question. Nothing here is legal advice.)

The closest public proxy: CISA KEV

Which raises the obvious engineering problem: how would you know?

The best public answer is the CISA Known Exploited Vulnerabilities catalogue. CISA maintains it under Binding Operational Directive 22-01, and the inclusion criteria are three things:

The vulnerability has an assigned CVE ID.
There is reliable evidence it has been actively exploited in the wild.
There is a clear remediation action, such as a vendor-provided update.

Criterion 2 is the interesting one, and CISA's own wording is close to the CRA's: "reliable evidence that execution of malicious code was performed by an actor on a system without permission of the system owner". CISA's version also includes attempted exploitation.

It is a JSON file at a stable public URL. No key, no account, no rate limit worth worrying about.

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '{title, catalogVersion, dateReleased, count}'

{
  "title": "CISA Catalog of Known Exploited Vulnerabilities",
  "catalogVersion": "2026.09.14",
  "dateReleased": "2026-09-14T19:00:02.426Z",
  "count": 1710
}

1710 entries. For scale, the CVE programme published 48,185 records in 2025 alone. KEV is roughly four digits in total, across its entire history. That gap is the whole point: it is not a smaller feed of the same thing, it is a different question being asked.

One entry:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '.vulnerabilities[] | select(.cveID=="CVE-2021-44228")'

{
  "cveID": "CVE-2021-44228",
  "vendorProject": "Apache",
  "product": "Log4j2",
  "vulnerabilityName": "Apache Log4j2 Remote Code Execution Vulnerability",
  "dateAdded": "2021-12-10",
  "shortDescription": "Apache Log4j2 contains a vulnerability where JNDI features do not protect against attacker-controlled JNDI-related endpoints, allowing for remote code execution.",
  "requiredAction": "For all affected software assets for which updates exist, the only acceptable remediation actions are: 1) Apply updates; OR 2) remove affected assets from agency networks. ...",
  "dueDate": "2021-12-24",
  "knownRansomwareCampaignUse": "Known",
  "forensicTriage": "No",
  "notes": "https://nvd.nist.gov/vuln/detail/CVE-2021-44228",
  "cwes": ["CWE-20", "CWE-400", "CWE-502"]
}

Useful fields: dateAdded (when CISA saw evidence), knownRansomwareCampaignUse (Known or Unknown), requiredAction, cwes. 360 of the current 1710 entries are flagged as known ransomware campaign use:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '[.vulnerabilities[] | select(.knownRansomwareCampaignUse=="Known")] | length'
# 360

Flatten it to a set for intersection:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' | sort > kev-ids.txt

Now you have a sorted file of every CVE with public evidence of exploitation. comm -12 it against your own CVE list and you are done. That is the entire idea.

Be honest about what KEV is not

This part matters more than the tooling.

It is a US federal catalogue. It exists to drive remediation in US civilian executive branch agencies under BOD 22-01. It is not an EU instrument and has no legal standing under the CRA.
Using it as a proxy for "actively exploited" is a judgement call, not a legal definition. The CRA's definition and CISA's criteria are close in substance. Close is not the same as identical, and no regulator has said KEV is the test.
Absence is not evidence of absence. Plenty of exploitation never makes it into KEV. A clean result means "nothing you ship appears on this particular list today", not "nobody is attacking you".
It is vendor/product-centric, not package-centric. Entries name "Apache Log4j2", not org.apache.logging.log4j:log4j-core. Mapping one to the other is the actual engineering work, and it is where a naive implementation quietly fails.
Article 14 asks about exploitation in your product. KEV tells you a vulnerability is exploited somewhere in the world. If the vulnerable code path is not reachable in your build, you may be outside the trigger. That is a human decision and nobody can automate it for you.

KEV is the best available public signal. It is a signal, not an oracle.

A worked example: log4j-core 2.14.1

Take the canonical case. A gradle.lockfile containing:

org.apache.logging.log4j:log4j-core:2.14.1=runtimeClasspath
org.apache.logging.log4j:log4j-api:2.14.1=runtimeClasspath
com.google.guava:guava:31.1-jre=runtimeClasspath

Ask OSV.dev what is known about that exact coordinate and version:

curl -s -X POST https://api.osv.dev/v1/query \
  -H 'Content-Type: application/json' \
  -d '{"package":{"name":"org.apache.logging.log4j:log4j-core","ecosystem":"Maven"},
       "version":"2.14.1"}' \
  | jq -r '.vulns[].id'

Seven advisories come back. Resolved to CVE aliases and checked against KEV:

CVE                GHSA sev  KEV?        CVSS vector
CVE-2021-44228     CRITICAL  KEV         CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:H
CVE-2021-44832     MODERATE  not on KEV  CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H
CVE-2021-45046     CRITICAL  KEV         CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H/E:H
CVE-2021-45105     HIGH      not on KEV  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
CVE-2025-68161     MODERATE  not on KEV  CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/...
CVE-2026-34477     MODERATE  not on KEV  CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/...
CVE-2026-34480     MODERATE  not on KEV  CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/...

Seven CVEs on one dependency. Two on KEV.

Look at CVE-2021-45105 — rated HIGH, AV:N/AC:L/PR:N/UI:N, network, low complexity, no privileges, no interaction. It sorts near the top of any severity-ranked list. It is a denial of service via recursive lookups, and it is not on KEV.

Meanwhile CVE-2021-45046 has AC:H — high attack complexity, which reduces its CVSS base score. It is on KEV. Attack complexity is a statement about difficulty. Difficulty did not stop anyone.

That inversion is the argument in one table. Severity ranking would have you look at 45105 before 45046. Exploitation ranking puts 45105 in the backlog, where it belongs, and 45046 in front of a human today.

Note the two KEV vectors end in /E:H — the temporal Exploit Code Maturity metric set to High. CVSS can express this, via temporal metrics. Almost nobody publishes them, and scanners almost universally sort on base score. The capability exists and is unused, which is why you go to a separate catalogue.

Automating the intersection

The pipeline is: manifests → resolved components → OSV.dev → CVE aliases → intersect KEV. Four steps, all public APIs, no account.

I wrote it up as cra-watch so I would stop rebuilding it per project. Single Python file, standard library only, MIT.

curl -fsSL https://raw.githubusercontent.com/ntoledo319/cra-watch/main/cra_watch.py -o cra-watch
chmod +x cra-watch
./cra-watch scan

On the lockfile above:

cra-watch v1.0.0
EU Cyber Resilience Act, Article 14 - actively-exploited screen

  Scope    /tmp/demojava
           gradle.lockfile (3)
  Unique   3 components

  Advisories  3 component(s) carry at least one known advisory
  KEV feed    1709 entries, catalogue 2026.09.11

  --------------------------------------------------------------------

   2 KEV MATCH(ES) - MANUAL DECISION REQUIRED NOW

  CVE-2021-45046  (GHSA-7rjr-3q55-vv33)
    component      org.apache.logging.log4j:log4j-core 2.14.1  [Maven]
    known as       Apache Log4j2 Deserialization of Untrusted Data Vulnerability
    KEV listed     2023-05-01   ransomware use: Known

  CVE-2021-44228  (GHSA-jfh8-c2jp-5v3q)
    component      org.apache.logging.log4j:log4j-core 2.14.1  [Maven]
    known as       Apache Log4j2 Remote Code Execution Vulnerability
    KEV listed     2021-12-10   ransomware use: Known

It reads 14 lockfile formats plus CycloneDX and SPDX SBOMs, and exits 0 for no KEV matches, 1 for at least one, 2 when it found no manifests at all. The "manual decision required" wording is deliberate — the tool's output is the start of a human judgement, not a verdict.

(That run says 1709 entries, catalogue 2026.09.11, while the curl earlier in this post returned 1710 and 2026.09.14. The tool caches the catalogue on disk for six hours so repeat runs stay fast and do not hammer a free public API. Printing the catalogue version is how you notice you are reading a cached answer; --refresh forces a re-download.)

Run it on a schedule, not just on push. Your dependency graph did not change last night; the KEV catalogue did. A repo that was clean yesterday can be a reporting question this morning without a single commit. That asymmetry is the strongest argument for a cron job over a pre-commit hook.

What to take away, even if you never touch either tool

Your scanner's ranking encodes an assumption: that severity predicts urgency. Sometimes it does. For the specific question "is someone attacking this right now", it does not, and there is a free public dataset that answers the real question directly.

Pull known_exploited_vulnerabilities.json, jq -r '.vulnerabilities[].cveID', and intersect it with whatever CVE list you already produce. Twenty minutes. The output is short enough that a human will actually read it — which is the only property that has ever made a security list useful.

Tool: cra-watch. Engineering tooling, not legal advice, and not a compliance determination.

Your EOL dependencies just became a legal question, not a tech-debt question

Nicholas Toledo — Mon, 14 Sep 2026 20:25:35 +0000

Every backlog has a ticket like this:

Upgrade Node 16 → 20. Priority: low. Nobody has complained.

On 8 December 2026 that ticket changes category. It stops being tech debt and starts being a civil liability question, at least for anything you place on the EU market.

This is not a scare post. The mechanism is narrow, specific and readable in about twenty minutes of primary source. Then the engineering problem — what, exactly, in my codebase can no longer receive a security update? — turns out to be a question you can answer with curl and jq today.

The legal change, in engineering terms

The relevant text is Directive (EU) 2024/2853, the revised Product Liability Directive. It replaces the 1985 directive. Three things matter to people who ship software.

1. Software is a product. Article 4(1):

'product' means all movables, even if integrated into, or inter-connected with, another movable or an immovable; it includes electricity, digital manufacturing files, raw materials and software

No qualifier about delivery mechanism. Embedded firmware, a downloaded binary, a SaaS backend — the recitals are explicit that the mode of supply does not change the answer.

2. Liability is no-fault. This is the part engineers usually get wrong. Strict liability does not mean "you were careless". A claimant does not have to prove negligence. They have to prove three things: the product was defective, they suffered damage, and the defect caused the damage. Your internal process quality, your code review standards, your intentions — none of that is an element of the claim.

Article 7(1) defines defective as not providing "the safety that a person is entitled to expect". Article 7(2) lists the circumstances a court weighs, and 7(2)(f) includes:

relevant product safety requirements, including safety-relevant cybersecurity requirements

3. "It was fine when we shipped it" got much weaker. Article 11(1)(c) is the classic later-defect defence: prove the defect came into being after you placed the product on the market and you are exempt. Article 11(2) then carves a hole straight through it:

By way of derogation from paragraph 1, point (c), an economic operator shall not be exempted from liability where the defectiveness of a product is due to any of the following, provided that it is within the manufacturer's control: (a) a related service; (b) software, including software updates or upgrades; (c) a lack of software updates or upgrades necessary to maintain safety; (d) a substantial modification of the product.

Read 11(2)(c) next to Recital 19, which says a product remains within the manufacturer's control "where the manufacturer retains the ability to supply software updates or upgrades itself or via a third party".

That is the whole chain. If you can still ship updates, the product is still yours. And a lack of the security updates needed to maintain safety is named, in the text, as something that does not get you out.

The scope limits nobody mentions

It applies to products placed on the market or put into service after 8 December 2026 (Article 2(1)). Note the date: Article 2(1) as first published said 9 December, and was corrected to 8 December by Corrigendum 2026/90364. Most commentary still says 9 December. Older products stay under the 1985 regime; it is not retroactive.
9 December 2026 is the transposition deadline (Article 22) — one day after the scope date, which is why both dates appear in commentary. This is a directive, not a regulation. The text that binds you is your member state's implementing law, which may differ at the edges.
Non-commercial FOSS is out of scope. Article 2(2): the directive does not apply to "free and open-source software that is developed or supplied outside the course of a commercial activity". That is about how it is supplied, not the licence. Maintaining an MIT library as a hobby is excluded. Selling a product built on it is not.
Recoverable damage is death, personal injury, property damage and destruction or corruption of data — not pure economic loss. A CRUD app that annoys people is not the target. A product that can hurt someone or destroy their data is.

I am an engineer, not a lawyer. The above is me reading a primary source and quoting it, and none of it is legal advice. If you ship into the EU, take real advice on scope. The engineering question below stands regardless.

The engineering question

Of everything I ship, what can no longer receive a security update at all?

That is narrower than "what has a CVE". A component past its upstream end-of-life has no future patch, by definition. If a vulnerability lands in Node 16 tomorrow, there is no fix coming. Ever. "We'll patch it when it matters" is not available to you.

Good news: there is a free public catalogue of exactly this, and you do not need a tool to query it.

Doing it with curl

endoflife.date tracks EOL dates for runtimes, frameworks, databases and OSes. The v1 API is public, unauthenticated and rate-limit-friendly.

curl -s https://endoflife.date/api/v1/products/nodejs \
  | jq '.result.releases[] | select(.name=="16")
        | {name, releaseDate, isEol, eolFrom, latest: .latest.name}'

Real output, today:

{
  "name": "16",
  "releaseDate": "2021-04-20",
  "isEol": true,
  "eolFrom": "2023-09-11",
  "latest": "16.20.2"
}

Node 16 went EOL on 11 September 2023. The last release that will ever exist is 16.20.2.

The full response is {schema_version, generated_at, last_modified, result} where result has name, label, category, tags, identifiers, links and releases[]. Each release carries isEol / eolFrom, plus isEoas / eoasFrom for end-of-active-support (security fixes only after this) and isEoes / eoesFrom for extended support.

List every dead Node line:

curl -s https://endoflife.date/api/v1/products/nodejs \
  | jq -r '.result.releases[] | select(.isEol) | "\(.name)\teol \(.eolFrom)"'

25  eol 2026-06-01
23  eol 2025-06-01
21  eol 2024-06-01
20  eol 2026-04-30
19  eol 2023-06-01
18  eol 2025-04-30
17  eol 2022-06-01
16  eol 2023-09-11

Note Node 20 in that list. An LTS release that many people still think of as current went EOL on 30 April 2026 — which means the backlog ticket at the top of this post ("upgrade Node 16 → 20") would have migrated you onto another dead runtime. That is exactly the kind of thing you want a machine to check rather than a memory.

Same shape for anything else:

curl -s https://endoflife.date/api/v1/products/python \
  | jq '.result.releases[] | select(.name=="3.7") | {name, isEol, eolFrom}'

{
  "name": "3.7",
  "isEol": true,
  "eolFrom": "2023-06-27"
}

The catalogue currently covers 473 products (curl -s https://endoflife.date/api/v1/products | jq '.total'). There is also a legacy endpoint, https://endoflife.date/api/nodejs.json, which returns a flat array of cycles with cycle / eol / latest keys. It still works and you will see it in older scripts, but the v1 endpoint is the one to build on.

You now have everything you need to write this yourself: parse .nvmrc, go.mod, Dockerfile FROM lines and package.json engines, map each to a product slug, fetch, compare eolFrom to today. It is an afternoon of work, and if you have unusual manifests it is the right call.

Doing it with a tool

I wrote the afternoon-of-work version so I would stop re-writing it: pld-watch. Single Python file, standard library only, MIT, no account and no telemetry.

curl -fsSL https://raw.githubusercontent.com/ntoledo319/pld-watch/main/pld_watch.py -o pld-watch
chmod +x pld-watch
./pld-watch scan

Against a deliberately awful test project (.nvmrc pinned to 16.20.2, FROM python:3.7-slim, next: ^12.0.0):

pld-watch v1.0.0
EU Product Liability Directive (EU) 2024/2853 - update-supportability screen

  Scope    /tmp/demoproj
  Found    6 runtime/framework version(s)
  PLD      applies from 2026-12-09 (86 days away)

  --------------------------------------------------------------------

  4 COMPONENT(S) PAST UPSTREAM END-OF-LIFE

    Node.js 16.20   (.nvmrc)
      upstream EOL   2023-09-11   latest supported: 26
    Node.js 16   (package.json engines.node)
      upstream EOL   2023-09-11   latest supported: 26
    next 12.0   (package.json)
      upstream EOL   2022-11-21   latest supported: 16
    python 3.7   (Dockerfile FROM)
      upstream EOL   2023-06-27   latest supported: 3.14

It reads .nvmrc, .python-version, go.mod, package.json (engines plus a known-framework map), requirements*.txt and Dockerfile FROM lines. Exit codes are 0 nothing past EOL, 1 at least one past EOL, 2 nothing detectable to check. Responses are cached for 24 hours under $XDG_CACHE_HOME/pld-watch so CI does not hammer a free API.

What this does not do

Be clear-eyed about it, because a tool that oversells itself is worse than no tool.

It compares declared versions against a catalogue. That is one narrow checkable fact. It does not:

prove your product is defective — that is decided by a court on the facts, not by a scanner
prove the EOL component is reachable or exploitable in your build
tell you whether you are in scope of the directive
read binaries, container image layers or your own source
know any framework outside its slug map

The EOL date is a fact about upstream. Everything downstream of it is judgement. What the tool actually buys you is that the fact stops being invisible.

And there is a broader reason to run this that has nothing to do with Brussels: a component that cannot receive a security patch is a genuine engineering liability whether or not anyone ever sues you. The directive is just the thing that finally makes it someone else's problem too.

Where to start

curl the endoflife.date API for your top three runtimes. Ten minutes.
Write down which components cannot receive a patch, and what it would cost to move each one.
Put the check in CI so the list cannot silently grow.

Step 3 is the one that matters. EOL dates arrive on a schedule you do not control — something you shipped clean today goes EOL in April without a single commit.

Tool: pld-watch. Engineering tooling, not legal advice, and not a compliance determination.

I built a free in-browser EU CRA Article 14 checker — paste a lockfile, nothing uploaded

Nicholas Toledo — Mon, 14 Sep 2026 09:32:01 +0000

I wanted to make the EU Cyber Resilience Act Article 14 question answerable in ten seconds, without installing anything.

So: cra.toledotechnologies.com/check — paste a package-lock.json, requirements.txt, go.sum, Cargo.lock, Gemfile.lock, composer.lock, gradle.lockfile, or a CycloneDX/SPDX SBOM. Get an answer.

The question it answers

Since 11 September 2026, Article 14 of the CRA has been enforceable: if a vulnerability in a product you've placed on the EU market is being actively exploited, you owe an early warning to your national CSIRT and ENISA within 24 hours of becoming aware.

The operative word is exploited. Not "critical". Not "CVSS 9.8". Not "there's a PoC". That distinction is the entire ballgame, and it's why your scanner's severity-sorted output is answering a different question than the regulator is asking.

The checker resolves your declared dependencies against OSV.dev, maps every advisory to its CVE aliases, and intersects that with the CISA KEV catalogue.

Nothing is uploaded

It runs entirely in your browser. Your file contents never reach a server of mine — package names and versions go to the public OSV.dev API for lookup, and the KEV comparison happens locally in the page. No account, no logging, no backend of mine involved at all.

One implementation note that might save you time if you build something similar: CISA's KEV feed sends no CORS headers, so you cannot fetch it from a browser. I mirror it same-origin (US Government work, public domain) with explicit provenance fields in the JSON so the copy can't be mistaken for the authoritative source. OSV.dev does send CORS headers and can be called directly from the client.

What you get

Clean:

No known-exploited components found
Checked 3 components against KEV catalogue 2026.09.11 (1709 entries).

3 component(s) do carry published advisories that are not on the KEV
list. That is ordinary patching work — not a reporting clock.

Not clean:

2 known-exploited components — decision required

CVE-2021-45046   org.apache.logging.log4j:log4j-core 2.14.1   Known
CVE-2021-44228   org.apache.logging.log4j:log4j-core 2.14.1   Known

Early warning   24 hours   2026-09-15 09:30:26 UTC
Notification    72 hours   2026-09-17 09:30:26 UTC
Final report    14 days    2026-09-28 09:30:26 UTC

What it deliberately doesn't claim

A KEV hit does not mean you must file. KEV evidences exploitation somewhere in the world; Article 14 asks about exploitation in your product. If the vulnerable path isn't reachable in your build, the answer may be no — and the Commission's July 2026 guidance is explicit that reachability matters for third-party components. No scanner can make that call.

Equally, a clean result is not a certificate. KEV lags and isn't exhaustive. Your own telemetry or a customer's incident report can start the clock before CISA lists anything.

Whatever the result: write down what you knew and when you knew it. A documented decision not to report is defensible. An undocumented one isn't.

CLI version

For CI, the full tool walks your whole repo across twelve lockfile formats and exits non-zero on a match — github.com/ntoledo319/cra-watch, MIT, stdlib only:

- uses: ntoledo319/cra-watch@v1.0.0
  with:
    fail-on-match: 'false'

Run it on a schedule, not just on push. The KEV catalogue grows continuously — a repo that was clean yesterday can become a reporting question today with no change to your code.

If you hit a lockfile format it mangles, open an issue. I'd rather fix it than be confidently wrong in public.

Not legal advice; I'm not a lawyer. Verify against Regulation (EU) 2024/2847 and your coordinating national CSIRT before filing.

13 advisories, 0 reporting triggers: severity is not exploitation under the EU CRA

Nicholas Toledo — Mon, 14 Sep 2026 09:22:33 +0000

I spent this morning reading the CISA KEV catalogue against a dozen real repositories, and I want to write down something that surprised me — because I think it's the thing most teams are going to get wrong about the EU Cyber Resilience Act.

The setup

Since 11 September 2026, Article 14 of the CRA has been enforceable. If a vulnerability in a product you've placed on the EU market is being actively exploited, you owe an early warning to your national CSIRT and ENISA within 24 hours.

Everyone reading that sentence hears "vulnerability" and thinks about their scanner output. That's the mistake.

What I actually found

I scanned a real project this morning — 649 distinct components across a package-lock.json and a Cargo.lock. The result:

  Advisories  13 component(s) carry at least one known advisory
  KEV feed    1709 entries, catalogue 2026.09.11

  NO KEV MATCHES.

Thirteen components with published advisories. Zero on the known-exploited list.

Now, thirteen advisories would light up any dependency scanner. If you were treating scanner output as your CRA trigger, you'd have thirteen things that look like they might start a 24-hour clock. In reality, on this evidence, you have none.

The inverse is also true and more dangerous. I built a fixture with log4j-core 2.14.1 in it:

  2 KEV MATCH(ES) - MANUAL DECISION REQUIRED NOW

  CVE-2021-44228  (GHSA-jfh8-c2jp-5v3q)
    component      org.apache.logging.log4j:log4j-core 2.14.1  [Maven]
    known as       Apache Log4j2 Remote Code Execution Vulnerability
    KEV listed     2021-12-10   ransomware use: Known

One component. Two known-exploited CVEs. That's the one that deserves a human in the room, and it would have been item #7 of 13 in a severity-sorted list.

Severity is not exploitation

This is the whole point and it's worth being blunt about it:

CVSS 9.8 describes how bad it would be if exploited.
KEV listing describes that it is being exploited, in the real world, right now.

Article 14 turns on the second one. Most vulnerability tooling optimises for the first. So the list you've been living with — sorted by severity, triaged by "critical/high/medium" — is not the list that answers the regulatory question. It's a different question with a different answer set, and the overlap is smaller than you'd guess.

There's a second-order effect that I think is underrated: treating every critical CVE as a potential reporting trigger doesn't just waste time, it produces over-reporting, and over-reporting to a regulator is its own kind of problem. You want the small true list, not the big cautious one.

The part where I'm honest about the limits

I wrote a tool to do the intersection (cra-watch, MIT, stdlib-only, no account). But I want to be straight about what it can't do, because compliance tooling that overclaims is worse than no tooling:

A KEV listing doesn't mean you must report. KEV says a vulnerability is being exploited somewhere in the world. Article 14 asks whether it's being exploited in your product. If the vulnerable code path isn't reachable in your build, the answer may genuinely be no. The Commission's July 2026 guidance is explicit that reachability matters for third-party components. No scanner can make that call — a person has to.

KEV isn't the legal definition either. It's a US government catalogue. It lags, and it isn't exhaustive. Your own telemetry or a customer's incident report can start the clock before CISA ever lists the CVE.

Clean output isn't a certificate. It means two public sources don't currently intersect for your dependency graph. Useful, dated, reproducible. Not immunity.

What I'd actually do on Monday

Run the intersection, not the severity sort. You want the short list, and it probably is short.
Put it on a schedule, not on push. This is the bit people miss. The KEV catalogue gains entries continuously. A repo that was clean yesterday can become a reporting question today with zero code changes on your side. A one-off audit answers a question about the past.
Decide who presses send, before you need to know. Under a 24-hour clock, the most common failure isn't technical — it's four people each assuming someone else owns the decision.
Write down what you knew and when. Whatever you decide, the contemporaneous record is what defends it later. A documented decision not to report is defensible. An undocumented one is very hard to defend.

The tool is free and I'd rather it were widely used than gated:

curl -fsSL https://raw.githubusercontent.com/ntoledo319/cra-watch/main/cra_watch.py -o cra-watch
chmod +x cra-watch && ./cra-watch scan

Three lines in CI:

- uses: ntoledo319/cra-watch@v1.0.0
  with:
    fail-on-match: 'false'

If you find a case where it gets the intersection wrong, open an issue — I'd rather fix it than be confidently wrong in public.

Not a lawyer, not legal advice. Verify against Regulation (EU) 2024/2847 and your coordinating national CSIRT's guidance before filing anything. I also sell a process kit for the decision-and-filing side; the scanner is free and always will be, and it isn't crippled or time-limited.

The EU's 24-hour vulnerability reporting clock started 3 days ago. Here's a free tool to check if it applies to you.

Nicholas Toledo — Mon, 14 Sep 2026 09:05:11 +0000

On 11 September 2026, the first enforceable deadline under the EU Cyber Resilience Act arrived. Almost nobody I've spoken to noticed, because the headline date everyone has in their calendar is December 2027.

That's the date most of the CRA applies. But Article 14 — the reporting obligation — has been live since the 11th.

Here's the short version:

If a vulnerability in a product you've placed on the EU market is being actively exploited, you owe an early warning to your coordinating national CSIRT and ENISA within 24 hours of becoming aware of it. Then a fuller notification within 72 hours. Then a final report within 14 days of a fix being available.

Penalties top out at €15 million or 2.5% of worldwide annual turnover (Article 64(2)).

One relief that's worth knowing and often gets left out: under Article 64(10)(a), those administrative fines do not apply to microenterprises and small enterprises for missing the 24-hour early-warning deadline specifically. That relief covers the deadline only — not the duty to report, and not the 72-hour or final-report stages. If you're a small team, the headline fine number you keep seeing quoted is probably not the one that applies to you.

And the part that catches people: under Article 69(3), this covers products already on the EU market. Not just things you ship after the deadline. That thing you shipped in 2022 that's still being sold? In scope.

"Products with digital elements" is broader than you think

It's software, hardware, remote data-processing solutions, and components placed on the market separately. If you're outside the EU but sell into it through an importer, distributor, or authorised representative, the obligation can still reach you. Being in Ohio doesn't exempt you.

The word that matters is "exploited"

This is where I think most teams are going to get it wrong, in both directions.

Article 14 is not triggered by:

a critical CVE in your dependency tree
a CVSS 9.8
a proof-of-concept on GitHub
your scanner going red

It's triggered by evidence that the vulnerability is actually being exploited in the real world, in your product. That's a much smaller set. Most CVEs never meet it.

The Commission's July 2026 guidance also clarified something useful about third-party components: if an actively exploited vulnerability comes from a component you integrated, a report is required when that vulnerability is being actively exploited in your product. If the vulnerable code isn't reachable in your build, an Article 14 report isn't required on that basis.

So the question isn't "do I have CVEs." Everyone has CVEs. The question is: is any of what I ship on the list of things being exploited right now?

A free tool for exactly that question

I built cra-watch to answer it. MIT licensed, Python standard library only, no account, no telemetry, no signup.

curl -fsSL https://raw.githubusercontent.com/ntoledo319/cra-watch/main/cra_watch.py -o cra-watch
chmod +x cra-watch
./cra-watch scan

It reads your lockfiles, resolves them against OSV.dev, and intersects the result with the CISA Known Exploited Vulnerabilities catalogue — the closest thing to a public register of what's genuinely being exploited in the wild.

Clean run:

  Advisories  13 component(s) carry at least one known advisory
  KEV feed    1709 entries, catalogue 2026.09.11

  NO KEV MATCHES.

  Nothing in your dependency graph appears on the CISA Known Exploited
  Vulnerabilities catalogue. On this evidence there is no Article 14
  24-hour reporting trigger from a listed component today.

  You do still have advisories on 13 component(s).
  Those are ordinary patching work, not a reporting clock. Article 14
  is about ACTIVE EXPLOITATION, not severity.

Note what it does there: 13 components have advisories, and it explicitly tells you those are not a reporting trigger. That distinction is the whole point. Your scanner's wall of red is patching work. This is a different question.

The other answer:

  2 KEV MATCH(ES) - MANUAL DECISION REQUIRED NOW

  CVE-2021-44228  (GHSA-jfh8-c2jp-5v3q)
    component      org.apache.logging.log4j:log4j-core 2.14.1  [Maven]
    known as       Apache Log4j2 Remote Code Execution Vulnerability
    KEV listed     2021-12-10   ransomware use: Known

  If you confirm exploitation in your product, the clock is:

    Early warning     within 24h    2026-09-15 08:40:10 UTC
    Notification      within 72h    2026-09-17 08:40:10 UTC
    Final report      within 14d    2026-09-28 08:40:10 UTC

Supports 12 lockfile formats (npm, yarn, pnpm, pip, poetry, Pipfile, go.sum, Cargo, Gemfile, composer, NuGet, gradle) plus CycloneDX and SPDX SBOMs.

Exit codes are CI-friendly: 0 clean, 1 KEV match, 2 nothing scannable.

Run it on a schedule, not on push

This is the bit I'd emphasise. The KEV catalogue gains entries continuously. A repo that was clean yesterday can become a reporting question today without a single line of your code changing.

name: cra-watch
on:
  schedule: [{ cron: "0 6 * * *" }]
jobs:
  kev:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: curl -fsSL https://raw.githubusercontent.com/ntoledo319/cra-watch/main/cra_watch.py -o cra-watch.py
      - run: python3 cra-watch.py scan

A one-off audit answers a question about yesterday.

What the tool deliberately does not do

I want to be straight about the limits, because compliance tooling that overclaims is worse than no tooling.

A KEV listing is not proof of exploitation in your product. KEV says a vulnerability is being exploited somewhere in the world. Article 14 asks whether it's being exploited in the thing you shipped. If the vulnerable code path is unreachable in your build, the answer may genuinely be no. The tool can't assess reachability. A person has to.

KEV is not the legal definition of "actively exploited." It's a US government catalogue. It lags, and it isn't exhaustive. Your own telemetry or a customer's incident report can start the clock before CISA lists anything.

Clean output is not a compliance certificate. It means two public data sources don't currently intersect for your dependency graph. That's useful and reproducible. It isn't immunity.

It only sees declared dependencies. No vendored code, no static linking, no container base images, no your-own-source analysis.

Whatever the output, the thing to actually do is write down what you knew, when you knew it, and why you decided as you did. That contemporaneous record is what defends the decision later — far more than any scanner output.

The harder half

Finding the shortlist is the easy part, and it's the part software can do.

The hard part is the decision under a 24-hour clock: who's accountable for pressing send, what an early warning says when you still know almost nothing (answer: very little — it's designed to be thin, and you file it anyway), and what evidence defends a decision not to report when someone asks eight months later.

I also put together a CRA 24-Hour Reporting Kit covering that process side — decision tree, the three clocks worked in UTC, fill-in templates for all three filings, an evidence log, and a 30-minute tabletop exercise. That one's paid ($149), and it's the only thing I'm selling here. The scanner is free and always will be; it's not crippled, time-limited, or a trial.

If you only take one thing from this post, take the scanner and the cron job. The deadline is real, it's already passed, and most teams haven't checked.

I'm not a lawyer and none of this is legal advice. Verify against Regulation (EU) 2024/2847 and guidance from your coordinating national CSIRT before filing anything. If I've got something wrong, tell me in the comments — I'd rather fix it than be confidently wrong in public.

Turn Any Web Page into Markdown with NoHustle API

Nicholas Toledo — Fri, 22 Aug 2025 04:57:01 +0000

Scraping web content is tedious. NoHustle API converts any URL to clean Markdown in one GET request.

🚀 Zero Setup Required

curl "https://nohustle-api.onrender.com/url2md?url=https://example.com/article"

💪 What It Handles

JavaScript-rendered pages - Waits for content to load
Clean text extraction - Removes ads, navigation, footers
Proper formatting - Headers, links, lists preserved
Large articles - Handles long-form content reliably

🔧 Integration Examples

Python:

import requests

response = requests.get("https://nohustle-api.onrender.com/url2md", params={"url": "https://news.ycombinator.com"})
markdown = response.text
print(markdown[:500])

cURL in CI/CD:

# Archive article as Markdown
curl "https://nohustle-api.onrender.com/url2md?url=$ARTICLE_URL" > archive/$(date +%Y%m%d).md

Great for content archiving, research tools, or feeding LLMs clean text.

🚀 Try it Now

🌐 Try in Browser → (Hugging Face Space)

📫 Run in Postman → (One-click collection)

⚡ RapidAPI → (Managed hosting)

More NoHustle endpoints: https://nohustle-api.onrender.com

Remove Image Background via API (Free tier, no paid upstreams)

Nicholas Toledo — Fri, 22 Aug 2025 04:57:01 +0000

Need to remove backgrounds from images without paying for expensive APIs? NoHustle API does it for free.

🎯 One POST, Clean Results

curl -X POST -F image=@sample.jpg https://nohustle-api.onrender.com/remove-bg -o clean.png

✨ What You Get

PNG with transparency - Perfect for overlays, logos, product shots
No subscriptions - Free tier covers most use cases
Fast processing - Usually under 3 seconds
No watermarks - Clean output, ready to use

🔧 Code Examples