Responsibility Model
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.
Takumi Images reduces the work required to operate secure base images, but it does not move every responsibility to us. The supply chain of a base image involves three parties: the upstream projects that develop the software itself, GMO Flatt Security that verifies it and provides it as images, and the users who put their applications on top of the images and run them. The responsibility boundaries run between these three parties.
Overview
The following table summarizes the split between the three parties.
| Area | Upstream projects | Takumi Images (us) | Users |
|---|---|---|---|
| The software itself | Development and vulnerability fixes | Monitoring and incorporating fixes | None |
| The base image artifact | None | Build, patch, test, sign, and publish | Choose and verify images |
| Additional layers | None | None | Maintain application code and dependencies |
| Runtime environment | None | None | Configure secrets, network, volumes, and privileges |
| Updates | Release fixes | Publish updated builds and evidence | Update, verify, and roll out digests |
| Lifecycle | Decide support end (EOL) | Patch supported versions | Migrate before EOL |
Upstream project responsibilities
Upstream projects develop the software itself and provide its fixes. Software included in the images, such as curl or OpenSSL, is not developed by us. The primary source of vulnerability fixes is upstream, and the patches we apply are also based on upstream fixes.
This structure has two consequences.
First, the upstream support period is the limit of the image. When an upstream version reaches EOL, the fixes that patching depends on stop, so we generally stop publishing new patched builds for that version. See Upstream EOL Handling for details.
Second, bugs in the behavior of the software itself are upstream's responsibility. Image Bugs explains how to separate them from problems caused by the image packaging.
However, we do not trust upstream artifacts unconditionally. Monitoring and verifying sources before incorporating them is our responsibility, described next.
Takumi Images (our) responsibilities
We are responsible for the process of verifying and incorporating upstream artifacts into the digest artifacts published at images.flatt.tech.
This includes:
- continuously monitoring the upstream sources that enter images, inspecting them for signs of malicious changes and undisclosed fixes,
- incorporating upstream fixes into images by advancing the pin or applying package-level patches,
- building images from pinned inputs,
- keeping production images distroless,
- testing images before publication,
- attaching signatures, SBOM, SLSA Provenance, and VEX, and
- rebuilding, rescanning, and publishing updated builds on every update.
This scope has two boundaries: one toward upstream and one toward users.
The upstream-side boundary is the availability of upstream fixes. We cannot permanently fix a vulnerability on our own when upstream provides no fix. For severe vulnerabilities, we may apply an early patch before the upstream release, but this is a case-by-case decision, not a blanket promise for every vulnerability.
The user-side boundary is the published digest artifact. The SBOM, provenance, and VEX are evidence about that artifact. They do not describe files or packages that users add later.
What users add on top
If you use a Takumi image as a base image in a Dockerfile, the additional layers are outside Takumi's control. Users are responsible for the application code, packages, language dependencies, configuration files, and generated artifacts added in those layers.
| Usage pattern | User responsibility |
|---|---|
| Extend the image in a Dockerfile | Patch and verify the added application and dependencies |
| Run the image without adding layers | Manage runtime configuration, secrets, and deployment settings |
The difference matters for scan results. A finding in a component included in the Takumi base image is handled through Takumi's rebuild, patching, or VEX process. A finding in a dependency added by your application is part of your application supply chain.
Runtime environment and deployment settings
Takumi Images does not control the environment where the container runs. Users remain responsible for deployment settings such as Kubernetes manifests, seccomp and AppArmor profiles, Linux capabilities, mounted volumes, secrets, network policy, and resource limits.
A distroless image narrows what is available inside the container, but it does not replace runtime hardening. For example, if a workload mounts sensitive host paths or runs with unnecessary privileges, that risk comes from the deployment environment rather than from the image artifact.
Update operations
Takumi publishes updated images, but users choose when deployments move to those images. For production use, pin deployments by digest and use an update tool such as Renovate or Dependabot to propose digest updates. Run those updates through CI and a staged rollout before promotion.
Leaving an old digest pinned for a long time means you do not receive fixes in newer builds.
Following :latest without verification can introduce regressions into your environment.
The recommended operation is to pin by digest, update that digest regularly, and test each proposed update before rollout.
Beyond digest updates, version migration is also the user's decision. If you are using a version approaching upstream EOL, migrate to a supported version before EOL is reached.