How Stacklok uses Minder internally to build more secure software

Yesterday, we announced the launch of Minder, an open source platform that helps development teams and open source communities build more secure software and prove to others that what they’ve built is secure. In this post, we’ll help you understand how to use Minder by showing you how we use it internally to apply security policies and practices across Stacklok’s repos. 

Stacklok’s setup and needs

While there are a lot of useful security tools and frameworks out there—like Sigstore, SLSA, and OpenSSF Scorecard—it’s hard to always keep up with best practices and ensure they’re properly implemented, especially if you have multiple repos like we do. We built Minder to be like a security assistant: it points out best practices, implements them, and continuously checks to ensure they’re in place. 

Here’s a little background on Stacklok’s setup and why Minder is useful for us. We currently have several dozen repositories in our organization. Some are private, like the Stacklok infrastructure repository, and some are public, like Minder itself. The number of repos continues to grow, and our settings often diverge from our ideal standard. 

Even though different repos might have legitimately different needs, we do require some standards across the board. We have to ensure that secret scanning and secret push protection is enabled, that the “main” branch uses pull requests that are peer-reviewed, and that dependencies are automatically updated, safe, and free from known vulnerabilities. Lastly, we need to ensure that all artifacts we build are signed using Sigstore. 

To achieve these goals, we use Minder to programmatically enforce these standards across our repos, and either alert us or auto-remediate any deviations. The profile we use to secure our own repositories is open source, and available on GitHub. Below, we’ll walk through the steps we took to make this happen. 

Step 1: Configuring our security stance across GitHub repos

We started by using Minder to enroll all of our project repos and set a policy to ensure that branch protections are configured for every repo. We set the policy to auto-remediate and automatically turn on branch protections when they’re missing. This helps us ensure we don’t have to do this manually for every repo going forward. 

As an example, when we first created the minder-rules-and-profiles repository, it didn’t have any branch protection rules in place:  

But after we enrolled that project repo in Minder, we could see that the branch protections policy was automatically applied: 

In addition, we can view the policy status for the whole organization using a single command:

Beyond branch protections, Minder’s policy engine can ensure secret scanning and secret push protection are enabled and that tools like Dependabot, CodeQL, and Trivy are configured correctly. For example, one of our template repos didn’t have a Dependabot configuration present. Minder picked this up and opened a PR with the correct configuration:

Like many organizations, we use GitHub Actions (GHA), and we need to be able to control what GHA can do in our repos. We use Minder to set policies to ensure GHA can only read data in the repos or that only explicitly enumerated actions are allowed. Policies can be set in alert-only mode, opening a GitHub Security Advisory when the repository is not compliant, or set to auto-remediate. 

Beyond the built-in rules included with Minder, you can also create and apply custom rules. See the list of supported rules in the minder-rules-and-profiles repository (this will expand over time). 

Step 2: Setting a policy to verify that all artifacts are signed

We need to ensure that all Minder artifacts are signed on an ongoing basis to keep them safe and tamper-proof. To do this, we created a Minder policy to continuously check that artifacts are signed using Sigstore; this allows us to be notified of artifacts that were produced by a given repo and display the signature and verification status for those artifacts. 

Below is the list of artifacts that Minder pulls from our enrolled repositories and the policy output for a rule that checks for artifact signatures:

We applied this policy to all tagged artifacts in the Minder repo, but we also could have just checked for artifacts with a specific tag.

Step 3: Managing our dependency security posture

For Minder, making sure that we’re using dependencies that are actively maintained and non-malicious is absolutely critical for keeping our software and our users’ software safe. We’re also a startup with a lean team, so we don’t want our developers to spend time dealing with dependency security issues.

To solve for this, we’ve set a policy in Minder to comment on pull requests that bring in dependencies that either have low Trusty scores or known vulnerabilities.  The Minder reply is visible on any PR that brings in a new dependency, including this PR with a Dependabot update:

Next on our roadmap

We’re working hard to build more features to make Minder more helpful for us and our users. Here are a few features you can expect to see soon:

• Repo grouping: Group sets of repos into “Projects” for more granular policy control, and enroll repos automatically within a GitHub org for programmatic policy enforcement

• Expanded repo support: Enroll GitLab and Bitbucket repos 

• Dependency management improvements: Block pull requests based on Trusty scores, capture dependency risk in a given repo or SBOM, and track changes over time; create pull requests for dependency updates

• Attestation and signing: Generate signatures directly from Minder and create and sign SBOMs and SLSA provenance statements
  

You can view our full public roadmap here.