SBOMs, Scan Reports and the CVE We Have Never Filed

Illustration for: SBOMs, Scan Reports and the CVE We Have Never Filed

The sixth goal of CISA’s Secure by Design pledge asks a signer to demonstrate transparency in vulnerability reporting, by including accurate Common Weakness Enumeration and Common Platform Enumeration fields in every CVE record for its products, and by issuing CVEs in a timely manner for at least all critical and high impact vulnerabilities that either require customer action or show evidence of active exploitation.

I will start with the part most pledge write-ups bury. RaptorGRC has no CVE records. We have never been assigned one and we have never issued one. On the literal text of goal six, we have nothing to show.

That is not a boast. A product with no CVEs is either very small, very young, or unexamined, and RaptorGRC is the first two. CISA says as much in its own wording for this goal, cautioning against reading the presence of CVEs as a negative sign and noting that the count often rises as a manufacturer takes security seriously. A rising CVE count would be a sign of health here, not of decay.

So this article covers what we publish in the meantime, and what we would do on the day a vulnerability in our own code needs a customer to act.

What ships with every release

Two bills of materials, generated from the built image

The pipeline generates a software bill of materials from the container image itself rather than from the project files, in both CycloneDX and SPDX formats. Generating from the built artefact matters, because it captures what is actually in the image, including operating-system packages, and not merely what the solution intended to reference.

The image is then rebuilt with its own bill of materials embedded inside it, at a fixed path. An air-gapped operator can read the manifest of the thing they are running without downloading anything, which is the only version of SBOM delivery that works in a facility with no route out.

The full vulnerability scan for that exact build

Every release carries the Trivy report for the image it was built from, in machine-readable and human-readable forms, plus a short summary.

The scan policy is committed in the repository alongside the pipeline, so the rule is public. A release fails on any critical or high finding that has a fix available. A finding with no upstream fix does not block the release, and it appears in the report you receive.

Signatures over the artefacts, not over a registry entry

The pipeline signs blobs directly with cosign rather than signing a registry reference. Four things carry their own detached signature, which are the image tarball, the release metadata, the CycloneDX bill of materials and the provenance document.

Signing deliberately skips upload to a public transparency log, and verification uses a public key committed to the repository and shipped in the bundle. A verification step that needs internet access is useless to the people this product is for, so the whole chain is designed to work on a machine that has never seen a network.

Be precise about the gap in that. The SPDX bill of materials is not individually signed. It is in the bundle and it is covered by the checksum file, which is covered in turn by nothing, so a reader following the letter of the verification steps authenticates the CycloneDX document and takes the SPDX one on the strength of a checksum. That is a small inconsistency and it should be closed by signing both.

Provenance, and an honest SLSA line

Build provenance is generated in the in-toto style and signed alongside everything else.

The pipeline documentation includes a self-assessment against the SLSA levels which reads, in summary, level one met, level two met with a stated caveat, level three not met. I mention it because publishing an honest “not met” alongside two “met” lines is more useful to somebody assessing us than a badge would be.

A bundle a customer can verify without us

All of that arrives as one tarball designed to be carried onto approved media. It contains the image, both bills of materials, the signatures, the provenance, the Trivy report in machine-readable and human-readable forms, the scan summary, the published scan policy, a SonarQube summary, a NuGet audit, the cosign public key, a checksum file over everything, and a verification document.

The last of those is the one I would point a security team at first. It walks an operator through checking the checksums and then verifying each signature with the bundled key, command by command, and it states plainly that none of those commands makes a network connection.

The assembly script hard-fails if any of those inputs is missing. A bundle either carries its complete evidence pack or it is not produced at all, which also means a high or critical dependency advisory blocks the bundle rather than producing a quieter one.

What the portal does with it

In the customer portal, the bill of materials and the scan report attach to a release and are downloadable, each with its own SHA-256 so you can verify what you carried across.

The scan is also rendered rather than merely offered. The downloads page reads the report and shows severity counts, then splits the findings into two groups, which are the RaptorGRC application and the container operating system. That split is the distinction that decides what a finding means to you. A Debian package finding is usually resolved by us rebasing the image. A finding in our own dependencies is a patch we have to write. Presenting one undifferentiated list of forty findings tells a customer nothing about which ones are ours.

If a report cannot be parsed, the page falls back to offering the raw file rather than displaying an empty table, because a scan report that renders as “no vulnerabilities” when it actually failed to load is worse than no display at all.

Three honest qualifications

Generating the evidence is automatic, publishing it is not

The pipeline produces all of the above for every build it makes, and the assembly step refuses to produce an incomplete bundle. That part is a gate.

Getting two of those artefacts into the customer portal is not. The bill of materials and the scan report are attached to a release after it has been uploaded, by a person, through a separate step. All six artefact columns on the release record are optional, the create-release request does not carry them at all, and nothing refuses a release that has neither. A tired administrator at eleven at night can publish a release, forget the attachments and be told nothing.

Our pledge page now says exactly this, that generating the evidence is automatic and publishing it is our practice rather than a gate. I would rather it were a gate, and making the upload flow demand both artefacts is a small change with a good return.

The portal carries a fraction of the bundle

The bundle holds the whole evidence pack listed above. The portal stores two files out of it.

The signatures, the provenance and the verification document are the artefacts a serious customer uses to prove that the tarball they downloaded is the one our pipeline built. They exist, they are good, and they are not currently in the place a customer goes to get the software. That is a gap in exactly the wrong place, and it is more valuable to close than the enforcement point above.

The attach mechanism is young

The ability to attach these artefacts to a release in the portal only reached production on 1 September 2026. Any claim about what “every release” carries has to be read against that date rather than against the life of the product, and this article should be updated rather than quietly aged when there are enough releases behind it to say something stronger.

A bill of materials for our image is not a bill of materials for your deployment

The SBOM describes the container we built. It does not describe the database server you pointed it at, the reverse proxy in front of it or the base operating system of the host.

Vendors quietly let customers believe otherwise, and it is worth being clear about the boundary of what we are handing you.

What we would do the day we have a real vulnerability

Since we have no record to show, the useful thing is to state the policy in advance, so that it can be held against us later.

If a vulnerability in RaptorGRC requires a customer to act, or shows evidence of active exploitation, we will request a CVE identifier. We are not a CVE Numbering Authority, so that means going through a CNA of last resort, which for a product like ours means MITRE. We will populate the Common Weakness Enumeration and Common Platform Enumeration fields, because a CVE record without them makes a customer’s automated triage useless and CISA’s goal names both explicitly.

We will publish it alongside the release notes for the version that fixes it, and the finding will appear in that release’s scan report like any other.

Becoming a CNA ourselves is under consideration and nothing more than that. It would mean issuing and publishing identifiers directly, with tighter timelines and a documented process behind them. For a company of our size, the honest question is whether we could sustain the obligations, and I would rather not sign up to a responsibility we would then discharge badly.

The argument that this is all ceremony, taken seriously

There is a real case that bills of materials have become a compliance artefact that nobody reads. A CycloneDX file with nine hundred components, most of them transitive, is not something a two-person security team is going to work through. Producing one satisfies a procurement question and changes no behaviour.

That case has force, and the answer to it is not to produce the document more enthusiastically. The answer is that an SBOM earns its keep only when something consumes it. The scan report is the consumption. It is the SBOM matched against a vulnerability database, sorted by severity and split by whose problem each finding is, which is a thing a person can act on in ten minutes.

The manifest on its own is ceremony. The manifest plus the scan, published together for the exact build you are running, is not.

The full tracker is at /secure-by-design. What does and does not leave your network is set out at /transparency.