Memory hook: Inventory tells what; provenance tells how; signatures tell who; scanning finds known risk.
Must remember
An image is a packaged filesystem and execution configuration. A tag is a movable name; a digest identifies particular content. Pin reviewed production artifacts by digest to prevent an unchanged tag from silently referring to another image. Digest pinning gives stable identity, not proof that the image is safe.
Protect each supply-chain step: source repository, dependency resolution, build runner, registry and deployment. Require reviewed source changes, limited build credentials and separation between untrusted pull requests and privileged release jobs. Rebuild and redeploy patched images through a controlled pipeline instead of repairing containers manually and losing the change on restart.
| Evidence | Question it answers | Limit |
|---|---|---|
| Vulnerability scan | Which known weaknesses match this artifact? | Database freshness, exploitability and configuration affect findings |
| SBOM | Which components and versions are included? | Inventory alone does not prove safety or integrity |
| Signature | Was this digest signed by an accepted identity/key? | An authorized signer can still sign vulnerable code |
| Provenance | Which source, builder and process produced the artifact? | Verify the attestation and trust the builder; a claim alone is insufficient |
SLSA provides supply-chain assurance requirements with increasing guarantees. Understand the purpose of trustworthy builds and provenance rather than memorizing a tool as a universal compliance solution. Sigstore/Cosign can sign and verify artifacts; verification must constrain the expected signing identity or trusted key, including the issuer when identity-based verification is used.
A registry stores and distributes images; make private artifacts available only to authorized readers. Separate push from pull permissions, limit retention and protect robot credentials. Use TLS for registry connections. imagePullSecrets support authenticated pulls in their namespace; they do not authorize application requests or prove image provenance. Approved registry policies and signature verification can be enforced during admission.
Prefer maintained minimal base images, a non-root application user and only required packages. Multi-stage builds can leave compilers and build tools out of the final image. Secrets copied into an image layer may remain recoverable even if a later layer deletes the file; use an appropriate build secret mechanism and never publish credentials in the image.
A vulnerability needs triage: affected version, exposure, exploitability, business impact and compensating controls. Record approved exceptions with an owner and expiry. Continue scanning stored and running artifacts as new vulnerabilities become known. Keep dependency licensing and provenance evidence where supply-chain policy requires them.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Stop mutable tags changing reviewed deployments | Pin the approved digest and verify it against release policy. |
| Identify packages affected by a new advisory | Query SBOM and vulnerability evidence, then assess actual exposure. |
| Accept artifacts only from a trusted release pipeline | Verify signatures and provenance against the expected identity and builder. |
| Allow a workload to pull a private image | Grant minimal registry pull access and configure the appropriate pull credentials. |
Traps
- A private registry can contain malicious or outdated artifacts.
- ImagePullPolicy Always does not establish that the selected image is trusted.
- A clean scan is a point-in-time result, not a guarantee against future disclosures or malicious logic.
Active recall
1. Which prevents a tag from silently selecting different bytes?
Referencing the reviewed image digest. The digest must still be checked against a trusted release decision.
2. Does an SBOM certify that an image has no vulnerabilities?
No. It inventories components that can be assessed against vulnerabilities and other policies.
3. An image is signed by an unknown identity. Should signature validity alone authorize it?
No. Verification must match the trusted signer or identity/issuer and the approved artifact policy.
4. Why can deleting a secret in a later Dockerfile instruction be inadequate?
The secret may remain in an earlier image layer. Avoid introducing it into the artifact and rotate an exposed credential.
5. A vulnerability is disclosed after deployment. What evidence helps locate affected workloads?
Component inventory/SBOM, deployed image digests, scan results and workload inventory connect the advisory to the running release.