Skip to main content

Artifact security

Many prominent cyberattacks have involved tampering with the software supply chain. Attackers may alter software artifacts (whether they are container images, software dependency packages, binaries, etc.) distributed by open source project or commercial vendors to contain malicious code to steal data or carry out a denial of service. Stacklok's Minder can help you incorporate various Artifact Security best practices into your supply chain to reduce the possibility of a successful supply chain attack being carried out against the software you produce, or the software you consume.

Aspects of Artifact Security​

Artifact security is a broad concept. Minder focuses on provenance of container images, that is, whether a link exists between a container image and the repository that built the container. In addition, the link must be cryptographically verifiable - that is to say that it it not possible to alter the image after it has been signed without breaking the signature.

Having this link gives you a strong guarantee about where the code that was used to built a container image comes from and who or where built it.

How Does Minder Help With Artifact Security?​

Minder's artifact policies can be divided into two checks:

  • Determining whether there exists any provenance statement about the artifact at all and if yes, whether that provenance statement indeed represents that artifact.
  • Extended provenance checks - these let you assert that the artifact tracked by the Minder profile comes from a specific repository and/or was built by a specific GitHub workflow or even a specific GitHub runner.

Deploying these checks helps to detect attacks such as a malicious user building a container image using a non-approved workflow which might inject code into the resulting image or even pushing an image to a container registry from outside the repository.

Minder's Artifact Rule Options in Detail​

Minder's Artifact provenance rule has option that allow to assert the following about an artifact:

  • Repository specification: Define the exact repository that builds your artifact, such as https://github.com/mindersec/minder, ensuring the artifacts you publish for others to use originate from your expected trusted source.
  • Branch identification: Specify the branch, for instance, main, to narrow down the source of acceptable changes. This ensures that your artifact doesn’t come from a development branch or branch with malicious intent.
  • Signer identity: Define the Identify that builds your artifact. For example, you can specify a GitHub workflow name such as docker-image-build-push.yml to ensure that the artifact your project publishes was produced through approved CI/CD processes. This protects you from potential vulnerability where another person or a workflow gains access to your repository permissions and publishes in parallel a malicious version of your artifact.
  • Certificate issuer: Pinpoint the certificate issuer, e.g., https://token.actions.githubusercontent.com, to ensure artifacts are a result of specific, trusted processes.
  • Runner environment setting: Specify the environment, such as github-hosted, to validate the context in which the artifact was built. This allows you to further strengthen your posture in case you’re building artifacts on private GitHub runners.

Setup​

Through the Minder UI, a profile can be created to verify that images tagged with latest in your project are signed and verified:

  • Select "Profiles" from the menu on the left.
  • Select "New Profile" from the top right hand corner of the screen.
  • From the list of profiles, select "Artifact Security".
  • Click "Apply" to create the profile.

To customize the behavior of these checks, see the Artifact signing how-to guide.