Written by Maxime Ragionieri, founder of Clearlane, the publisher of Clearlane CRA.
Teams use our apps to keep quality and security records in Jira and Confluence. If an app isn't reliable, the work done with it isn't either. So for us, reliability comes first, and every vulnerability we detect in one of our apps automatically starts a fix on our side. Every time.
To do that, we keep a software bill of materials (SBOM) for every release we put in production. When a vulnerability is published in a component, we don't have to guess whether we ship it: we search our SBOMs and see which apps and versions are affected. This article is about that habit, what the Cyber Resilience Act now asks for, and how to run the same check in Jira.
What the Cyber Resilience Act asks for
- Annex I, Part II, point 1 of Regulation (EU) 2024/2847: identify and document the components in your product, including an SBOM in a commonly used, machine-readable format, covering at least the top-level dependencies.
- When: this requirement applies from 11 December 2027. The Article 14 reporting obligations for actively exploited vulnerabilities have applied since 11 September 2026.
- Who sees it: you don't have to publish your SBOM, but market surveillance authorities can ask for it.
An SBOM is only useful on the day you search it
Producing the file is the easy part: most build tools do it in one command. What matters is the morning a CVE comes out. Here's what we check in our own process, and what we'd suggest to any team:
- One SBOM per version you actually shipped. Not just the main branch: customers run older versions too.
- A standard format. CycloneDX or SPDX, so any tool can read it.
- Kept with the version, for as long as you support it.
- Searchable by name and version range. "Do we ship lodash below 4.17.21?" should take one search, not an afternoon of opening files.
- Linked to the case. Once you know which versions are affected, the fix, the decision and the dates belong in the same record.
How Clearlane CRA does it in Jira
- Register your products and versions, with their support period.
- Import the CycloneDX or SPDX SBOM of each version.
- When a CVE is published, search every SBOM at once: a component name, "name < version" or a package URL. The screenshot above shows two versions of the same product shipping an affected lodash.
- Open one case for the affected versions. If the vulnerability is actively exploited, the case runs the Article 14 clocks (24 hours, 72 hours, and the final report within 14 days of a fix) and prepares the fields for the ENISA platform.
What it doesn't do
Clearlane CRA doesn't generate SBOMs: it imports the one your build already produces. It isn't a vulnerability scanner either: you search when a CVE is published. And it helps you meet the CRA requirements; it doesn't make a product compliant on its own.
It runs on Atlassian, so your data stays in your Atlassian site. You'll find it as Clearlane CRA on the Atlassian Marketplace.
How does your team answer "are we affected?" today? We'd be glad to hear how others handle it.
