01 · The record

When someone asks, show the date.

Under the Cyber Resilience Act, an actively exploited vulnerability has to be reported within 24 hours of becoming aware of it. The hard question afterwards is rarely “what is wrong”. It is “what did you ship, and when did you know?”

Whenproof answers it as you go. Every push and every daily rescan is stored with its date, the SBOM it produced and the advisories known at that moment. When someone confirms that a vulnerability is exploited, their name and the time are written down and never silently changed.

Documents and drafts are included. The record is the point.

what one repository's record holdsschema

scan: one per push, install and daily rescan
commit: {{sha}}
scanned at: {{time, UTC}}
trigger: push · install · rescan
SBOM: CycloneDX 1.6 and SPDX 2.3, stored with the scan
findings: OSV.dev advisories known at that moment
signals: listed in CISA KEV, or EPSS ≥ 0.1
confirmation: one per exploited vulnerability, never reset
confirmed by: {{person with write access}}
confirmed at: {{time, UTC}}
aware since: {{time, UTC}} the 24 h clock starts here
evidence: the signals at confirmation, or your note
audit log: who did what, and when

Fields from the app's database (scans, signals, exploitation, audit_log). Values in amber are placeholders, not sample data.

02 · Every push

Your lockfiles in. A dated SBOM out.

On every push to your default branch, Whenproof reads your lockfiles through GitHub's API, without cloning the repository, and writes a CycloneDX 1.6 and an SPDX 2.3 SBOM. Both are stored with the scan, so the SBOM for any past push is still there.

Reads package-lock.json, npm-shrinkwrap.json, Cargo.lock, poetry.lock and go.sum. The CLI also uses Syft when it is installed.

sbom.cdx.jsonCycloneDX 1.6 SBOM
sbom.spdx.jsonSPDX 2.3 SBOM
vulnerability-report.mdKnown vulnerabilities from OSV.dev
vulnerability-handling.mdPolicy draft, CRA Annex I Part II
technical-documentation.mdSkeleton, CRA Annex VII

.cra-kit/sbom.cdx.json4 components

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:urn:uuid:00000000-0000-4000-8000-000000000000",
  "version": 1,
  "metadata": { … },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:npm/%40scope/util@1.2.3",
      "name": "@scope/util",
      "version": "1.2.3",
      "purl": "pkg:npm/%40scope/util@1.2.3",
      "properties": [
        {
          "name": "cra-kit:source",
          "value": "package-lock.json"
        }
      ]
    },
    {
      "type": "library",
      "bom-ref": "pkg:npm/lodash@4.17.20",
      "name": "lodash",
      "version": "4.17.20",
      "purl": "pkg:npm/lodash@4.17.20",
      "properties": [
        {
          "name": "cra-kit:source",
          "value": "package-lock.json"
        }
      ]
    },    …
  ]
}

Output of npm run scan -- test/fixtures/npm-app --offline on the sample project in the Whenproof repository. Excerpt: metadata folded, two of four components shown; the marked one is the package the check run below flags.

03 · Every day

New advisories find you without a new push.

Each scan posts a check run on the commit: counts, the vulnerability table from OSV.dev, and expiring signed download links for the SBOMs and drafts. Stored SBOMs are rescanned every day, and each rescan is kept as its own dated entry, so the record shows what was known on which day. It never blocks a merge.

Whenproof neutral

1 known vulnerability in 4 components (1 new)

1 known vulnerability found (1 new since the last scan). Nothing is blocked; the findings are below.

Components	Affected	Known vulnerabilities	New	Needs review
4	1	1	1	0

Lockfiles scanned: package-lock.json

Download

File	Contents
sbom.cdx.json	SBOM, CycloneDX 1.6
sbom.spdx.json	SBOM, SPDX 2.3
vulnerability-report.md	Known vulnerabilities from OSV.dev
vulnerability-handling.md	Draft policy, CRA Annex I Part II
technical-documentation.md	Draft skeleton, CRA Annex VII

Links are signed and expire; re-open the latest check run for fresh ones.

Vulnerability report: npm-app

1 known vulnerability in 1 component of 4 scanned. Checked against OSV.dev by cra-kit on 2026-10-06 08:00 UTC.

Components scanned	Affected	Known vulnerabilities	Exploitation signals
4	1	1	not checked

Known is not exploited. CRA Article 14 reporting to ENISA applies to actively exploited vulnerabilities. Confirm exploitation before drafting an early warning.

Findings

Severity	Component	Vulnerability	Fixed in	Lockfile
7.2 High	lodash 4.17.20	GHSA-35jh-r3h4-6jhm (CVE-2021-23337) Command Injection in lodash	4.17.21	`package-lock.json`

Built by the app's check-run code for the same sample project. The OSV response is the recorded one from the test suite; GHSA-35jh-r3h4-6jhm is a real advisory for lodash 4.17.20. KEV and EPSS were not queried for this sample.

04 · The free watch

Exploited is rare. You'll hear when it isn't.

The CRA's 24-hour reporting applies to actively exploited vulnerabilities, not to every advisory. When a dependency you shipped appears in CISA's KEV catalogue or crosses an EPSS score of 0.1, Whenproof flags it on a check run on the commit you shipped. Then it stops: a listing is a prompt, not a verdict.

If it's real, someone with write access confirms with a button on the check run (or the CLI). Whenproof records who and when, counts the deadlines from the moment you became aware, and writes the ENISA early-warning draft for you to complete and file. Nothing is submitted for you.

The watch is in the free plan. Email alerts are planned; today the flag arrives as a check run. What “actively exploited” means

0 hYou become aware and confirm. Name and time are recorded.
24 hEarly warning to ENISA's Single Reporting Platform. Art. 14(2)(a)
72 hVulnerability notification. Art. 14(2)(b)
14 dFinal report, at the latest 14 days after a fix or mitigation is available. Art. 14(2)(c)

enisa-early-warning-<id>.mdtemplate

## Deadlines
- Became aware at (UTC): {{awareAt}}
- Early warning due (24 h): {{earlyWarningDue}}
- Vulnerability notification due (72 h): {{notificationDue}}

## Product and vulnerability
- Manufacturer: {{manufacturer}}
- Product with digital elements: {{product}}
- Vulnerability: {{vulnId}} ({{aliases}})
- Affected component: `{{component}}`
- Fixed in: {{fixedIn}}
- Member States where the product is made available: {{memberStates}}

## Confirmation
- Exploitation confirmed by: {{confirmedBy}} at {{confirmedAt}} (via {{confirmedVia}})

Fields from the draft template. The deadlines are filled in from the recorded confirmation; {{…}} fields stay visible until a person fills them.

05 · Access

Three permissions. Nothing written to your repository.

Whenproof asks GitHub for the least it needs. SBOMs and drafts are stored by the app and reached through links that expire; nothing is committed to your code.

Not requested: contents: write, pull requests, issues, security events.

GitHub App permissions
Permission	Access	Why
Metadata	`read`	Required by GitHub for every app.
Contents	`read`	Read lockfiles through the trees and blobs API.
Checks	`write`	Post the result on your commit.

Vulnerability data: OSV.dev. Exploitation prompts: CISA KEV and FIRST EPSS.

06 · Pricing

Per product, not per repository.

Planned prices, ex. VAT, in euros per product per month. Nothing is billed yet: these are the prices we plan to launch with. A product is what you sell; it can span several repositories.

Watch

€0

For one product or one public repository.

CycloneDX and SPDX SBOMs on every push
Daily rescans against OSV.dev, CISA KEV and EPSS
A dated record of every scan and confirmation
ENISA early-warning draft once you confirm

Track

€19 per product / month

The evidence trail for every product you sell.

Everything in Watch, for each product
Several repositories as one product planned
An SBOM per release, kept 10 years planned

Report

€49 per product / month

Everything in Track, plus the paperwork.

Vulnerability-handling policy draft (Annex I Part II)
Technical-documentation skeleton (Annex VII)
72-hour and final report drafts planned
Record export for an authority planned

07 · Questions

The CRA, briefly.

Dates from the regulation and the Commission's and ENISA's pages. Not legal advice. Longer answers, with sources:

What does the CRA require, and when?

The Cyber Resilience Act, Regulation (EU) 2024/2847, entered into force on 10 December 2024. Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents in their products, including products already on the market (Article 14). From 11 December 2027 the rest applies: the essential requirements in Annex I (including an SBOM and vulnerability handling), technical documentation (Annex VII), conformity assessment and CE marking. The full timeline

Why early access, and not an install button?

The GitHub App isn't open for installs yet. What this page describes as working is built and tested; anything marked planned is not built yet. Leave your email and we'll write when you can install it.

What counts as a product?

What you place on the market: an app, a library, a device's firmware. It can live in one repository or several. Today Whenproof records per repository; grouping repositories into one product is planned, and pricing will follow the product, not the repository count.

Does Whenproof make my product compliant?

No. It keeps records, produces SBOMs, tracks known vulnerabilities and drafts documents with the structure the CRA describes. You review, complete and sign off on them. Compliance depends on how your product is built, supported and documented, which a tool cannot decide for you.

Does it file reports with ENISA?

No. Reports go through ENISA's Single Reporting Platform, live since 11 September 2026. According to ENISA's FAQ it has no API at launch, so filing is done by hand. Whenproof gives you the draft and the deadlines, counted from when you became aware.

Will it tell me to report every vulnerability it finds?

No. Most known vulnerabilities in dependencies are not actively exploited, and only those trigger Article 14 reporting. KEV listings and high EPSS scores only prompt a person to look. A draft is written only after someone with write access confirms exploitation.

Do the SBOMs meet BSI TR-03183-2?

Not yet. Version 2.1.0 asks for SHA-512 component hashes, SPDX 3.0.1 or CycloneDX 1.6 or newer, and one SBOM per version. Whenproof writes CycloneDX 1.6 and SPDX 2.3 without hashes, per push rather than per release. Hashes and per-release SBOMs are planned. SBOM requirements

Which ecosystems are supported?

npm (package-lock.json, npm-shrinkwrap.json), Rust (Cargo.lock), Python with Poetry (poetry.lock) and Go (go.sum). pnpm, Yarn, uv and Maven/Gradle are planned; tell us yours when you sign up.

Prove what you knew, and when.