Product
One record per product. Five jobs it does for you.
SBOM monitoring, Article 14 reporting, the CRA technical file, vulnerability disclosure and CI upload: one record per product, prepared for your review.
Products / demo-sensor-firmware.cdx.json
Demo sensor firmware 1.0.0
4 components| Severity | Vulnerability | Component | Status |
|---|---|---|---|
| Critical | CVE-2022-37434 | zlib@1.2.11 | Not checked yet |
| High | CVE-2018-25032 | zlib@1.2.11 | Not checked yet |
| High | CVE-2024-28960 | mbedtls@2.28.0 | Not checked yet |
- Annex I Part II (1)Some components cannot be looked up
- Annex I Part II (1)Some components have no version
- Annex I Part II (2)Components have high or critical severity vulnerabilities
01SBOM monitoring
Know when a new vulnerability reaches your firmware.
Embedded SBOMs rarely carry the identifiers vulnerability databases match on. Declarable adds them where its mapping rows know the component, checks every release against the public feeds, and tells you when a new record matches something you ship.
- Identifiers fixed before matchingComponents from west spdx, create-spdx or esp-idf-sbom often arrive without a package URL or CPE. Where the mapping rows know the component, Declarable adds them and shows you what it added.
- Five public feeds, plus exploit scoringEach component is checked against the CVE List, ENISA’s EU Vulnerability Database, GitHub Security Advisories, OSV and CISA’s Known Exploited Vulnerabilities catalogue, with the EPSS score beside it.
- Checked again every dayWe check your components against newly published vulnerabilities every day. Free is checked at least once a month.
- Alerts by email, Slack or webhookA new match sends an email, and can post to a Slack channel or your own webhook. A weekly summary says what opened, what closed and which products near the end of their support period.
02Article 14 reporting
The 24-hour clock, timed and drafted for you.
An actively exploited vulnerability or a severe incident has to be reported in three stages. Declarable times each one from the moment you became aware, drafts the text, and keeps the record. You submit it yourself on ENISA’s platform.
- All three deadlines, in UTC and your time zoneThe early warning at 24 hours, the notification at 72, and the final report: 14 days after a fix is available for an exploited vulnerability, one month after the notification for a severe incident.
- Draft text for every stageEach stage starts from a template that asks only what that stage needs, filled in from what you already recorded.
- Reminders before anything is dueReminder emails go to the people you choose, ahead of each deadline. Add the deadlines to your calendar with one file.
- Start from a findingOpen a report straight from a matched vulnerability. The product, the component and the record carry over; you decide when you became aware.
03CRA documents
The technical file, drafted from what your product already knows.
Five documents the Cyber Resilience Act expects, each started from your SBOM, your findings and the answers you have already given. Every draft records the template and the legal state it was prepared under. You review, edit and sign.
- Five documents, one recordThe essential-requirements checklist, the risk assessment, the technical documentation, the information for users and the EU declaration of conformity, all drawn from the same product record.
- Filled from your SBOM, not typed twiceSections that the record can answer start answered: the component list, the vulnerability handling, the support period. You fill in the rest once.
- Every page says what it was prepared underEach draft records its template version and the legal-state version. When the law or a template changes, the document says it is out of date.
- Due diligence and the conformity routeA due-diligence record for third-party and open-source components, and the conformity-assessment routes open to your product’s category. The choice of route stays yours.
04Vulnerability disclosure
A front door for vulnerability reports, and a place to answer them.
The Cyber Resilience Act asks for a way to receive vulnerability reports and a way to tell users about fixes. Declarable drafts the policy and the security.txt that points to it, hosts your advisories, and puts what you choose to make public on one page.
- A disclosure policy to start fromA draft policy that says how to report a vulnerability to you, what you will do with it and how long it takes. You edit it before publishing.
- security.txt that follows RFC 9116The file is checked against RFC 9116 as you fill it in, and served at a stable address you can redirect your own /.well-known/security.txt to.
- Advisories with CSAF files and feedsPublish an advisory per vulnerability. Each one gets a CSAF 2.0 file, and your advisories appear in an Atom and a JSON feed that buyers’ tools can follow.
- Thanks for the people who reportAn acknowledgements page lists the researchers you choose to thank.
05CI, API and agents
Every release recorded from the build that made it.
Uploading an SBOM by hand works for the first release. After that it belongs in the pipeline. Declarable takes an upload from your CI, answers over an API, posts to your webhooks, and talks to your AI agent over MCP.
- GitHub Actions, GitLab CI or plain shA GitHub Action, a GitLab CI template, and a shell script that needs only sh and curl for anything else.
- Guides for your build systemStep-by-step pipeline guides for Zephyr, Yocto, ESP-IDF, nRF Connect SDK, Buildroot, PlatformIO and Arduino.
- Each upload becomes the current releaseAn upload under a new version becomes the product’s current release, so what Declarable watches and alerts on is what you ship.
- A REST APIList products, read a release’s status and its open findings, and record decisions from your own tools.
Ready to check your first SBOM?
The free check runs in your browser and needs no account. A Free plan keeps 1 product and the Article 14 clock. Paid plans start at €49 a month.
Prefer to ask something first? Questions and answers, and how to reach us