Conformance check report

"metadata": {
  "authors": [ { "name": "Example Manufacturing Co., Ltd." } ]
}

Reference: cyclonedx.org

A signature carried inside the document, or a detached one sitting next to the SBOM as <sbom-filename>.sig (cosign's own convention, e.g. from --sign), is detected automatically and this row will say so. A detached signature under a different name or location is not visible here, because this report only looks for that one convention. Verify it against the sender's key before treating the contents as theirs, and record that you did.

Reference: www.cisa.gov

"components": [ {
  "name": "libexample",
  "hashes": [ { "alg": "SHA-256", "content": "3b7c…" } ]
} ]

Reference: cyclonedx.org

Establish that the SBOM lists every component making up the software, transitive dependencies included. No tool can confirm this from the document alone — the document cannot show what was left out of it. Compare it against the build's own dependency resolution, or against the manifests the software is built from.

Reference: www.cisa.gov

Establish that there is a way to correct SBOM data after it has been published, and that corrections go out promptly. This is a practice of the organisation issuing the SBOM, not a field in it.

Reference: www.cisa.gov

Establish that whoever needs the SBOM can get it promptly, and that any access control keeps unauthorized parties out without blocking authorized ones or preventing the data from being loaded into their security tools.

Reference: www.cisa.gov

Establish that each software version or update has an SBOM of its own, and that a revised SBOM is issued when the component data changes or an error in it is found.

Reference: www.cisa.gov

"signature": {
  "algorithm": "ES256",
  "value": "MEUCIQD…"
}

Reference: cyclonedx.org

Describe how data moves through the system: where an input comes from, what the model receives, and where its output goes. In BomLens, declare it with the service in the AI declaration (service.dataFlows: the direction, a classification, and the source and destination addresses); the next scan writes it to the SBOM as CycloneDX services[].data, marked as the publisher's declaration. An SBOM from another tool counts when its services carry serviceData. Confirm the description matches how the system is actually deployed.

Reference: www.bsi.bund.de

State what the system does with the data it receives: whether it is stored, passed to another component, or used for further training. In BomLens, write it as the description of each data flow of the declared service (service.dataFlows[].description); the next scan writes it to the SBOM, marked as the publisher's declaration. Check this against the privacy notice you publish.

Reference: www.bsi.bund.de

Describe the input and output the system accepts and produces: formats, size limits, and anything it refuses. In BomLens, declare the service's input and output kinds (service.inputModality, service.outputModality); the next scan records them on the service, marked as the publisher's declaration. A person confirms the rest, because a model card lists modalities, not the system's actual interface.

Reference: www.bsi.bund.de

State the field the system is intended for and the uses that are out of scope. This is a decision, not a fact a tool can read, and regulators ask for it directly. In BomLens, declare the service's field and what it is for (service.domain, service.informationAboutApplication); the next scan records them on the service, marked as the publisher's declaration.

Reference: www.bsi.bund.de

{
  "type": "machine-learning-model",
  "description": "0.5B-parameter causal language model."
}

Reference: huggingface.co

"modelCard": {
  "modelParameters": {
    "inputs": [ { "format": "text" } ],
    "outputs": [ { "format": "text" } ]
  }
}

Reference: cyclonedx.org

Give the size and shape of the training data — record counts, class balance, and any known skew. These numbers explain the model's limits, so state them even when they are unflattering.

Reference: huggingface.co

Judge whether the training data holds personal information or third-party copyrighted work, and record what you filtered out and how. Where the answer is unclear, take it to your privacy and legal contacts before release.

Reference: www.bsi.bund.de

"externalReferences": [
  { "type": "bom", "url": "https://example.com/hbom.json" }
]

Reference: cyclonedx.org

List the controls that protect the model and its data — who can reach the weights, how the training environment is isolated, how artefacts are signed. These live in your operations, not in the SBOM.

Reference: www.bsi.bund.de

Name the security standard or internal policy this model was built under, and who signed off. Point at the assessment record rather than restating it here.

Reference: www.bsi.bund.de

Give the route for reporting a vulnerability in this model and who answers it. A published model needs a contact that outlives the person who trained it.

Reference: www.bsi.bund.de

Record what you measured on the security side — adversarial or jailbreak testing, refusal rates, red-team results — with the method and the date. If nothing was measured, say so plainly.

Reference: www.bsi.bund.de