Reduced Vulnerability Response Work
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.
When a vulnerability fix becomes available for a base image component, the user-side action is to pull the image again. Takumi Images rebuilds and rescans affected images whenever upstream dependencies are updated. Therefore, when you pull the latest tag again, available patches at that point have already been applied to the image.
You can see this behavior by checking the digest pointed to by :latest.
:latest is a tag, and its target changes with rebuilds.
For example, the digest currently pointed to by the curl image tag can be checked as follows.
$ crane digest images.flatt.tech/takumi/curl:latest
sha256:<digest>
If curl or one of its dependencies is fixed and rebuilt, the same command returns a different digest.
To make deployment behavior fixed, record the digest and refer to the image as @sha256:....
To continue following fixes, use :latest and pull it again on a regular cadence.
See the digest section in the Quickstart for how to combine digest pinning and following :latest.
Two paths for fixes
Fixes reach images through two paths.
The first path is advancing the pinned source revision used as the build base. Because the pin is shared across the catalog, advancing it once delivers the fix to every image that uses the package.
The second path is applying a package-level patch, called an overlay, when the fix exists upstream but has not yet been incorporated into the pin.
The overlay applies everywhere that package appears, so there is no need to wait for the next pin update.
The applied patch is recorded as a diff in the image SBOM's pedigree.patches.
Neither path requires users to patch individual base images themselves. See Known Vulnerability Response for implementation details.
Judgments users usually have to make
When operating container images yourself, you usually need to answer several questions about the base image. Takumi Images handles those decisions as part of the provider's operation.
| Question | Typical distribution | Takumi Images |
|---|---|---|
| How quickly are fixes reflected? | Official images can lag behind fixes in the underlying packages. | Images are rebuilt as dependencies are updated, so pulling again gives you the fixed build. |
| Who maintains the image? | When no official image exists, users must evaluate unofficial image maintainers themselves. | The catalog is managed consistently by GMO Flatt Security. |
| What is in the base image? | Users must check whether unnecessary packages or tools are present. | Images are distroless and exclude runtime-unnecessary components. |
| When was the image built? | Users must check build time themselves. | Build and scan times are recorded in the catalog. |
The right column is not per-image research users must perform. It is provider-side operation applied to the catalog.
Note: triage transparency
Findings that remain until a fix is published are kept with the basis for the decision, instead of forcing an unrealistic zero-vulnerability appearance. These decisions are published as VEX, so users can confirm which findings actually require action.