Find out if a dependency vulnerability starts your EU CRA reporting clock

The obligation in one paragraph

Under Article 14 of the EU Cyber Resilience Act, a manufacturer that becomes aware of an actively exploited vulnerability in its product must send an early warning within 24 hours, a notification within 72 hours, and a final report 14 days after a corrective or mitigating measure is available. The European Commission page on CRA reporting describes the process, and the Article 14 obligations apply from 11 September 2026.

The practical question for an engineering team is narrow: is any component in our dependency tree known to be exploited right now, and where is it declared? The CRA Readiness Check answers that for a repository in one call. Its output is a technical position, not legal advice; the response says so in a not_legal_advice field.

Run it on a repository

Pass a public GitHub repository as repo. Alternatively send files (manifests and lockfiles) for a private codebase, and use ecosystems, ref, repoLicense and product to describe what you ship.

curl -sS -X POST "https://$RAPIDAPI_HOST/v1/pipelines/cra-readiness" \
  -H "Content-Type: application/json" \
  -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
  -H "X-RapidAPI-Host: $RAPIDAPI_HOST" \
  -d '{"repo": "star7th/htq"}' > cra.json

jq '.data | {readiness, nextStep, deadlines}' cra.json

Read the result

readiness is one of REPORTABLE_CANDIDATES, NO_EXPLOITED_EVIDENCE, INSUFFICIENT_EVIDENCE or NO_RESOLVED_VERSIONS. Our run on a public repository returned NO_EXPLOITED_EVIDENCE with next step MONITOR_FEEDS: no matched advisory had KEV or EUVD exploitation evidence at the feed snapshot times, and the response advises rerunning when the dependency list or the feeds change, because feeds lag disclosure.

Treat NO_EXPLOITED_EVIDENCE as absence of evidence at a point in time, not a clean bill of health. INSUFFICIENT_EVIDENCE and NO_RESOLVED_VERSIONS mean some packages could not be resolved to a locked version; the unresolved and missing fields list them, and a lockfile in files usually fixes it.

When readiness is REPORTABLE_CANDIDATES, each exploited component is joined to the manifest that declares it, with fixed versions, under fixPlan. deadlines holds the 24-hour and 72-hour due times computed from awareness_time (default: now) and the 14-day final-report time once you pass fix_available_at.

Run it on a schedule, alert on change

Exploited-vulnerability lists change daily, so a one-off check ages quickly. A scheduled job that fails only when readiness becomes REPORTABLE_CANDIDATES turns this into a standing control. Record the time the job first saw the result: that is evidence of when you became aware, which is what starts the clock.

name: cra-watch
on:
  schedule:
    - cron: "17 6 * * *"
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    env:
      RAPIDAPI_KEY: ${{ secrets.RAPIDAPI_KEY }}
      RAPIDAPI_HOST: code-review-and-software-supply-chain-security-api.p.rapidapi.com
    steps:
      - run: |
          curl -sS --fail-with-body -X POST "https://$RAPIDAPI_HOST/v1/pipelines/cra-readiness" \
            -H "Content-Type: application/json" \
            -H "X-RapidAPI-Key: $RAPIDAPI_KEY" \
            -H "X-RapidAPI-Host: $RAPIDAPI_HOST" \
            -d '{"repo": "${{ github.repository }}"}' -o cra.json
          jq '.data | {readiness, nextStep, deadlines}' cra.json
          test "$(jq -r '.data.readiness' cra.json)" != "REPORTABLE_CANDIDATES"