DEV Community: Nicholas Toledo

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