CI/CD provider
Container image is not pinned by digest
Control:CTRL-102Container images must be pinned by digest
📋 What is this?
When digest pinning is enabled in your configuration, every container image must be referenced by its SHA256 digest (image@sha256:...). This image is using a tag reference instead.
⚠️ Impact
Even specific version tags (e.g., python:3.12.1) can be reassigned to a different image. Digest pinning is the only way to guarantee the exact image content used in your pipeline, providing the strongest supply chain security.
🔧 How to fix
Replace the tag reference with a digest reference. You can find the digest using docker inspect or crane digest.
# .gitlab-ci.yml: ❌ Uses tag reference (not pinned by digest)build: image: python:3.12.1 script: - python setup.py build# .gitlab-ci.yml: ✅ Pinned by SHA256 digestbuild: image: python@sha256:1c5313e4a18...f4b8e script: - python setup.py build
# Find the digest with:# docker pull python:3.12.1# docker inspect --format='{{index .RepoDigests 0}}' python:3.12.1# Or:# crane digest python:3.12.1💡 Tips
- Digest pinning is a sub-option of the
containerImageMustNotUseForbiddenTagscontrol, not a control of its own:containerImagesMustBePinnedByDigestdefaults totruein the shipped config. - Use
crane digest <image>:<tag>(fromgo-containerregistry) for a quick digest lookup. - Consider automating digest updates with tools like Renovate or Dependabot.
⚙️ Configure this control
With the CLI alone: set it in your configuration file. Every field and default is in the controls configuration reference, CTRL-102.
Container image is not pinned by digest
Control:CTRL-102Container images must be pinned by digest
📋 What is this?
When digest pinning is enabled in your configuration, every container image a workflow runs against (container: and services:) must be referenced by its SHA256 digest (image@sha256:...). This image is using a tag reference instead.
⚠️ Impact
Even specific version tags (e.g., node:20.18.1) can be reassigned to a different image. Digest pinning is the only way to guarantee the exact image content used in your workflow, providing the strongest supply chain security.
🔧 How to fix
Replace the tag reference with a digest reference. You can find the digest using docker inspect or crane digest.
# .github/workflows/build.yml: ❌ Uses tag reference (not pinned by digest)jobs: build: runs-on: ubuntu-latest container: image: node:20.18.1 steps: - run: npm ci && npm test# .github/workflows/build.yml: ✅ Pinned by SHA256 digestjobs: build: runs-on: ubuntu-latest container: image: node@sha256:bd3b3b7...9a1c4 steps: - run: npm ci && npm test💡 Tips
- Digest pinning is a sub-option of the
containerImageMustNotUseForbiddenTagscontrol, not a control of its own:containerImagesMustBePinnedByDigestdefaults totruein the shipped config. - This control reads job
container:andservices:images. Pinning third-party actions by SHA is a separate check, ISSUE-701. - Use
crane digest <image>:<tag>(fromgo-containerregistry) for a quick digest lookup.
⚙️ Configure this control
With the CLI alone: set it in your configuration file. Every field and default is in the controls configuration reference, CTRL-102.