Declarable and the free Article 14 command-line helpers, compared
Three free open-source projects appeared in the first week of October 2026. Each reads a lockfile or an SBOM, checks it against lists of known vulnerabilities and writes an Article 14 draft, for nothing. If a draft and a deadline are all you need, one of them may be the right tool. This page says what each project’s own README says, with the address and the date we read it, and where our product differs. All three are days old and kept by one person each, so we describe them and do not rank them. A cell that says “Not stated in the README we read” is silence in that README, not a claim that the project lacks the feature.
Newest check: 13 October 2026
When another option is the better choice
Our judgement, not a finding from the sources below.
- cra-clock: Your product is built from lockfiles, you want the check inside your own GitHub pipeline, and an issue with deadlines and drafts is all the record you need.
- cra-report: You want the quickest possible check: one command on an SBOM or a lockfile, with no sign-up, a short list of exploited components, and a Markdown early warning to edit.
- CRA Toolkit (German-first): Your authority contact is German and you want the drafts in German today, kept as plain files you control on your own disk.
- Declarable: Your build is Zephyr, Yocto, ESP-IDF or Buildroot and you need the VEX, the declaration draft and the technical file beside the Article 14 record, and you accept an account and storage on our server.
| Criterion | Declarable | cra-clock | cra-report | CRA Toolkit (German-first) |
|---|---|---|---|---|
| Price and licence — What it costs and the licence its code is shared under | The Article 14 workflow is on every plan including Free, which is free. Documents, alerts and upload from CI are in the Maker plan. The code is not open source. | Free; Apache-2.0source, 13 October 2026 | Free; MITsource, 13 October 2026 | Free; MITsource, 13 October 2026 |
| Needs an account — Whether you have to sign up before you can use it | Yes. The product needs an account. The free Article 14 clock on our tools pages needs none, but it works out dates only: it reads no SBOM and matches nothing. | Not stated in the README we readsource, 13 October 2026 | No: “nothing to sign up for” and no API keysource, 13 October 2026 | Not stated in the README we readsource, 13 October 2026 |
| Where it runs — On your machine or in your own build pipeline, or on our server. That decides where your list of software parts goes | On our server. A release you upload is stored with us, and an uploaded SBOM or config file is deleted 90 days after upload. If you want the list of parts to stay inside your own pipeline, a free helper that runs there is the better fit. | A GitHub Action in your own repository. The README also links a browser page where a lockfile is scanned and says the lockfile never leaves your browsersource, 13 October 2026 | One command on your machine or in your pipeline (npx cra-report)source, 13 October 2026 | A Python command on your machine or in your pipeline. An online scan sends only the package addresses of your components to OSV, and an offline mode makes no network callssource, 13 October 2026 |
| What it reads — The files it turns into a list of software parts: lockfiles of software packages, a generic SBOM, or the files a firmware build writes | The files a Zephyr, Yocto, ESP-IDF or Buildroot build writes, turned into a list of software parts for you to check. | Twelve lockfile formats, among them package-lock.json, yarn.lock, pnpm-lock.yaml, poetry.lock, go.mod and Cargo.lock; it writes a CycloneDX 1.6 SBOMsource, 13 October 2026 | CycloneDX and SPDX JSON SBOMs, package-lock.json, Cargo.lock and pinned lines of requirements.txtsource, 13 October 2026 | Lockfiles and manifests for npm, PyPI, Go, Rust, PHP and Java; it writes a CycloneDX 1.6 SBOMsource, 13 October 2026 |
| Match against known exploited vulnerabilities — Whether it checks your software parts against CISA’s list of vulnerabilities that are known to be used in attacks, which is the usual trigger for an Article 14 report | Yes: matches carry CISA KEV’s dates and exploited findings are listed first, and you can start an Article 14 report from a finding. Alerts and daily monitoring start at the Maker plan. | Yes: OSV, CISA KEV and FIRST EPSS. Only a KEV listing starts the clock; a high EPSS score is a warningsource, 13 October 2026 | Yes: asks OSV about your exact versions and cross-references CISA KEV. It says it narrows the list and does not decide whether the clock startedsource, 13 October 2026 | Matches components against OSV.dev. The README sections we read do not mention CISA KEVsource, 13 October 2026 |
| Article 14 steps it drafts — Article 14 of the Cyber Resilience Act sets reporting steps: an early warning, a notification, a final report, and a notice to your users. A draft is a starting text for you to review | Drafts for your review of the early warning, the notification and the final report, a notice to your users, and a note to the maintainer of the affected component. We do not file anything with ENISA or a CSIRT: you file it yourself. | Opens an issue with the deadlines and pre-filled ENISA drafts for an actively exploited vulnerability. It says severe incidents are outside its scopesource, 13 October 2026 | The early warning, as a Markdown file, with the facts it cannot know marked TO COMPLETE. It says it is a draft, not a submissionsource, 13 October 2026 | Markdown drafts of the early warning, the notification and the final report, for an exploited vulnerability or a severe incident. It says it drafts and does not submitsource, 13 October 2026 |
| How the deadlines are worked out — Whether it counts the 24-hour and 72-hour limits from the moment you became aware, and how it handles the final report, which has a different clock for an exploited vulnerability and for a severe incident | Counted from the moment you say you became aware. The final report is 14 days after a fix or mitigation is available for an exploited vulnerability, and one month after the notification for a severe incident; the two are told apart. | Lists 24 hours, 72 hours, and 14 days after a corrective or mitigating measure is available. The clock starts when it first detects the KEV listing, and the draft asks you to edit the time if you knew earliersource, 13 October 2026 | Both deadlines (24 and 72 hours) counted from now, in the draftsource, 13 October 2026 | You open a case with the time you became aware, and the 24-hour and 72-hour deadlines are counted from it. The final report is shown as 14 days after a fix is available, and for a severe incident one month after the notificationsource, 13 October 2026 |
| VEX — A VEX is a statement of which known vulnerabilities in your software parts actually affect your product, and which do not | Yes: a VEX file for a product, from your findings, for you to review. | Yes: writes a CycloneDX 1.6 VEX file with KEV and EPSS evidencesource, 13 October 2026 | Not stated in the README we readsource, 13 October 2026 | Not stated in the README we readsource, 13 October 2026 |
| Declaration and technical file drafts — The EU declaration of conformity is the signed statement that a product meets the Cyber Resilience Act; the technical file (Annex VII) is the documentation behind it. A draft is a starting text for you to review | Yes: a declaration draft and technical documentation drafts, ready for your review. They are starting texts, not finished documents. Documents start at the Maker plan. | Not stated in the README we readsource, 13 October 2026 | Not stated in the README we readsource, 13 October 2026 | Generates an Annex II user-information skeleton. The README we read lists no declaration or technical-file commandsource, 13 October 2026 |
| What is kept afterwards — What you are left with after a run: a file or an issue you keep yourself, or a record kept for you with its history | A record in your account. Issued declaration PDFs are kept for as long as your organisation exists, and for 30 days after you ask for it to be deleted. The signed scan is kept for at least ten years from signing, or to the end of the support period if that is later. | Files in the output folder (SBOM, VEX, report) that you upload as a build artifact, and one GitHub issue per exploited vulnerability that you close when the final report is filedsource, 13 October 2026 | The Markdown file you ask it to write; the README does not describe a record beyond thatsource, 13 October 2026 | Plain JSON and Markdown files in a folder on your disk: a product register, one file per case, the drafts, and timestamped SBOMs and scan reportssource, 13 October 2026 |
* We have not verified this; it does not mean the product lacks it.
How we checked
- A cell about another product is filled in only from a page we opened and read; it links to that page and shows the date we read it. Cells older than 90 days say so.
- Anything else reads “Not checked”. We have not verified it, and it does not mean the product lacks it.
- Declarable’s current prices are on the pricing page.
- If a cell about your product is wrong, tell us through the About page and we will correct it with a new date.
Want to see what your own SBOM is missing?
Check an SBOMKeep reading
- Firmware components: the identifiers we assign to Zephyr, Yocto and ESP-IDF parts
- Article 14, step by step: from "we became aware" to the final report
- Asking a supplier or an open-source project for CRA evidence: a request you can send
- The CRA and the Radio Equipment Directive side by side: EN 18031, the overlap and the dates
Declarable prepares documentation for you to review. It is not legal advice and not certification. You sign your own declaration of conformity.