SBOM
The English user guide is currently in beta preview. Most of the documents have been automatically translated from the Japanese version. Should you find any inaccuracies, please reach out to Flatt Security.
Each image includes a CycloneDX SBOM listing the components it contains. Because Takumi Images do not include a package database inside the image, the SBOM is generated from the image's runtime dependency closure. The closure is the set of store paths the container actually carries, including shared libraries required by the binaries. Therefore the SBOM accurately represents what is present in the runtime container.
Takumi Images is currently in beta. Specifications and behavior may change without prior notice.
The SBOM is a list of components. The following is an excerpt of the busybox component from a busybox image SBOM.
{
"bom-ref": "xpp0j7j90g2nbr382bi2ym0ln9ykli6l-busybox-1.37.0",
"type": "application",
"name": "busybox",
"version": "1.37.0",
"purl": "pkg:nix/busybox@1.37.0",
"cpe": "cpe:2.3:a:busybox:busybox:1.37.0:*:*:*:*:*:*:*",
"externalReferences": [
{
"type": "vcs",
"url": "https://busybox.net/downloads/busybox-1.37.0.tar.bz2",
"hashes": [
{
"alg": "SHA-256",
"content": "3311dff32e746499f4df0d5df04d7eb396382d7e108bb9250e7b519b837043a4"
}
]
}
],
"pedigree": {
"patches": [
{
"type": "unofficial",
"diff": { "text": { "content": "<applied patch diff>" } }
}
]
}
}
There are four important fields.
bom-ref corresponds to the Nix store path, so it uniquely identifies the input from which the component was built.
externalReferences records the upstream source URL and hash exactly as fetched.
cpe is used to match vulnerability databases such as NVD, and is attached based on a mapping managed by GMO Flatt Security.
pedigree.patches records the diff of patches applied by Takumi Images, so the SBOM contains both the explanation and the actual patch content.
SBOM scope
The SBOM covers the runtime closure. For compiled programs such as Go or Rust programs, language-level modules linked at build time may not appear as separate files in the distributed image, so they do not appear as SBOM components. This boundary is one of the lines between what Takumi covers and what users own. See Responsibility Model for that boundary.
Per-architecture contents
The SBOM differs between amd64 and arm64. Even for the same package, the Nix store path changes depending on the build architecture, so component identifiers in the SBOM also differ. Therefore SBOMs are attached to architecture-specific child images, not to the multi-arch index.
Retrieval
Extract the child digest for the target architecture from the index, then verify the SBOM with --type cyclonedx.
CHILD_DIGEST=$(crane manifest images.flatt.tech/takumi/busybox:latest \
| jq -r '.manifests[] | select(.platform.architecture=="amd64").digest')
cosign verify-attestation \
--certificate-oidc-issuer=https://token.actions.githubusercontent.com \
--certificate-identity-regexp 'https://github.com/flatt-security/takumi-images/.github/workflows/release.yml@.*' \
--type cyclonedx \
"images.flatt.tech/takumi/busybox@${CHILD_DIGEST}" \
| jq -r '.payload' | base64 -d | jq '.predicate'
See Attestation for the signing model that makes this attestation trustworthy.