Skip to main content
View as Markdown

Known Vulnerability Response

info

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.

In this page, "known vulnerability" does not mean only CVE. Vulnerability identifiers can be CVEs, GHSAs, OSV IDs, vendor advisory IDs, or other formats. Takumi Images does not depend on a single identifier scheme; it compares vulnerability IDs reported by scanners and upstream advisories with the actual impact on the image.

There are three paths by which a known vulnerability leaves a Takumi image: following a new upstream release, applying an upstream fix as a package-level patch, and recording a not_affected decision in VEX when the image is not actually affected or the finding is a false positive.

PathUsed whenScope
Pin advanceUpstream has released a fixed versionDelivered at once to every image using that package
Package-level patchThe fix exists upstream but is not yet in the pinApplied everywhere the package appears, directly or transitively
VEX not_affectedThe image is not actually affected, or the finding is a false positiveApplies only to the reviewed finding, with rationale

Following upstream releases​

The main path for fixes is advancing the single pinned source revision used as the build base. Because the pin is shared across the catalog, advancing it once delivers the fixed package to every image that uses it. For example, if a widely used shared library releases a fix, advancing the pin updates every image that contains that library.

This path is repeated frequently. Every pin advance rebuilds affected images, reruns tests, and rescans the results. The time at which a fix reaches an image therefore depends on both upstream release timing and the Takumi Images rebuild cadence.

Package-level early patches​

Sometimes the fix exists upstream but has not yet entered the pin. The upstream release may not exist yet, or the release may exist before the shared pin has advanced. In that case, Takumi Images can apply a small package-level patch, called an overlay, without waiting for the next pin update. An overlay is a short Nix expression that layers the upstream patch onto the target package definition.

final: prev: {
  curl = prev.curl.overrideAttrs (old: {
    patches = (old.patches or []) ++ [ ./patches/fix-header-injection.patch ];
  });
}

The patch file uses the upstream fix. Because the overlay is also an expression, which package was patched and which patch was applied are recorded as build inputs.

The applied patch is also recorded in the image SBOM as pedigree.patches, including the diff. For example, the published busybox SBOM records early fixes applied to busybox 1.37.0 for CVE-2025-60876 and CVE-2024-58251. You can verify the patched build state through the signed SBOM, not only through provider statements.

The overlay applies everywhere the package appears. It applies whether the package is directly included in an image or appears transitively through another dependency.

For severe vulnerabilities whose fixed version has not yet been released by upstream, Takumi Images may consider this path according to internal criteria. This is a case-by-case decision, not a blanket promise for every known vulnerability.

VEX not_affected decisions​

The scan pipeline reports suspicious findings broadly to avoid missing issues. Some reported findings therefore do not actually apply. Examples include disputed vulnerability records, code that is fixed even though the version string did not change, or a vulnerable code path that is not included in the image.

Takumi Images records these decisions as machine-readable VEX statements with not_affected. The statement includes an impact statement explaining the decision. This preserves which finding was reviewed and why it was judged not applicable. The record is operated append-only: if the situation changes, a new statement is added rather than rewriting the previous one. Findings that are actually unfixed remain affected, so VEX is not used to make the count look smaller.

See VEX for the format and signed attestation verification.

Scan freshness​

Scans rerun whenever the pin advances and images are rebuilt. A clean scan result is therefore not a permanent property of an image digest; it is a property of the most recent build and scan. New vulnerabilities are disclosed every day, so if you keep using the same pinned digest for a long time, findings can accumulate over time.

The model assumes you regularly pull a tag such as :latest. You should pin deployments by digest while also avoiding long-term use of stale digests.

See Build Pipeline Overview for where pin advances and overlays are applied before publication. See Reduced Vulnerability Response Work for how this reduces user-side work.

Last updated on