4 ways to secure your software artifacts with Minder

In the world of software development, maintaining the integrity and security of repository artifacts has become more crucial than ever. Minder makes it easier to fortify your software supply chain against tampering and unauthorized modifications. In this post, we'll walk you through the latest enhancements in Minder that support artifact security, extending beyond the existing artifact provenance checks.

What is Minder?

Minder is an open source software supply chain security platform. It can help you put in place and execute a robust security strategy to protect your project artifacts at every stage of your development lifecycle.

With Minder, you can ensure that:

• Every aspect of artifact creation, from project settings and code commit to build and release, is secured and verifiable.

• Policies are aligned with your organization's specific security requirements and compliance obligations.

• You're taking a proactive stance against security vulnerabilities in the software supply chain.

Minder's key concepts are Providers, Profiles, and Rule Types. (Today, we're limited to a single provider—GitHub—but plan to expand this in the future.) Once you've enrolled GitHub as a provider, you can create profiles. Profiles allow you to group and manage rule types for entities like repos and artifacts, and apply those rule types across a set of registered GitHub repos.

Minder includes pre-built rule types to make it easy to get started with applying and continuously enforcing security best practices, like secret scanning, code scanning, and branch protections. But you can also write your own custom rule types.

Next, let's take a look at four ways you can use Minder specifically to strengthen artifact security.

Securing your software artifacts with Minder

1. Ensure artifacts have verifiable cryptographic provenance statements

It's essential to have a verifiable cryptographic provenance statement for your artifacts; this provides proof that the artifacts you produce have been not been altered or tampered with after they've been signed. This step is divided into two critical checks:

• First, determining if Minder can link any provenance statement to the artifact. Without this provenance statement, further checks are not possible due to a lack of data to verify.

• Second, the focus shifts to validating the integrity of the provenance statement, ensuring it accurately represents the artifact in question. The majority of this verification process is handled by the sigstore-go library, which itself follows a well-documented verification process.

An example of one such policy is below:

---
version: v1
type: profile
name: simple-artifact-profile
context:
  provider: github
artifact:
  - type: artifact_signature
    params:
      tags: [latest]
      name: 
    def:
      is_signed: true
      is_verified: true

There are two parameters in this profile:

• is_signed - Checks to see if there is provenance information present for that artifact version. Note that this doesn’t mean it’s verified or that it can be trusted; it means just that it’s there.

• is_verified - Takes this further and gets Minder to cryptographically verify that the provenance information is indeed representing this artifact; that it's verified by sigstore’s Public Good Instance (PGI); and that whatever metadata is in it can be trusted. In the next step, you’ll see how we start leveraging this.

2. Utilize extended policy parameters for more expressive provenance checks

Minder's recent update has significantly broadened the scope of available policy parameters, allowing for more expressive provenance checks. These added parameters include:

• Repository specification: Define the exact repository that builds your artifact, such as https://github.com/stacklok/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. It could be a workflow or your email address that Sigstore used to generate short-lived Fulcio certificate. For example, you can specify your docker-image-build-push.yml workflow name 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.

These parameters enable developers to craft policies that ensure the artifacts you produce and are available for others to use do come from your trusted sources and are produced through verified processes, significantly reducing the risk of incorporating compromised components into your projects. In the event of someone publishing a malicious image that doesn’t reflect your desired repository posture, Minder will notify you using a GHSA alert so you can resolve the issue as quickly as possible.

Here’s an example of what a profile that utilizes these values looks like:

---
version: v1
type: profile
name: artifact-profile-hardened
context:
  provider: github
artifact:
  - type: artifact_signature
    params:
      tags: [latest]
      name: 
      sigstore: tuf-repo-cdn.sigstore.dev # Sigstore's Public Good Instance
    def:
      is_signed: true
      is_verified: true
      branch: main
      signer_identity: docker-image-build-push.yml
      runner_environment: github-hosted
      repository: https://github.com//
      cert_issuer: https://token.actions.githubusercontent.com

3. Configure private sigstore instances

Minder defaults to using sigstore’s Public Good Instance (PGI), i.e. “tuf-repo-cdn.sigstore.dev” for verifying whether artifacts are signed. For organizations with stringent security requirements, or those that prefer using internal systems such as running their own sigstore instances for artifact signing, Minder now supports the configuration of custom sigstore instances. This flexibility allows companies to:

• Maintain internal control over the signing process.

• Ensure that all artifacts are signed in accordance with corporate policies and compliance standards.

• Utilize private, internal sigstore instances for enhanced security and privacy.

This feature is invaluable for companies that run their own Sigstore instances, offering a tailored approach to artifact provenance and integrity checks.

4. Implement workflow-specific policies

We can take a step back from artifacts and focus on the workflows that build them. With the ability to specify additional workflow policies, Minder allows you to ensure that the GitHub Actions workflows that build your software are secure as well. Here are some examples of what you can do:

• Specify the workflows that are allowed to run in your repository's CI/CD pipeline. By taking the allowed_selected_actions rule type into use, you can restrict the GitHub actions that are executed in your CI/CD pipeline to a set of approved actions. (Read our earlier blog post on automating GitHub Actions security to learn more about this.)

• Restrict workflow permissions. Minder lets you enforce the default permissions for workflows with its default_workflow_permissions rule, but on top of that it, is advisable to explicitly set the lowest possible set of permissions explicitly for each workflow or, even more granularly, on the job level.

• Ensure all Actions within your workflows are pinned by their digests, instead of using floating tags. This is a hardening technique recommended by GitHub. Pinning your actions manually to their SHAs is not easy— luckily, Minder has a rule that lets you do that, and even exclude actions that can’t be pinned. (Read more about this here, or refer to the rule type or its use in a profile we use internally at Stacklok.)

This granular control over the artifact creation and acceptance process is crucial for maintaining a secure and reliable software supply chain.

Conclusion

Minder's latest updates align with the goal of providing useful tools to help you improve your security posture, whether you're the maintainer of a growing open source project, or an engineering lead for an organization with hundreds of repos. By using the strategies outlined above, you can make sure that your project artifacts are secure, trustworthy, and compliant with the highest standards of integrity.