Securing our security platform: Findings from Minder's independent security audit
The Minder team paired with Ada Logics, an independent security company, to perform a security audit analyzing Minder's threat model and vulnerable code patterns.
Stacklok is a software security company, so we need to make sure that the software we provide is as secure as possible for our end users. For that reason, we recently worked with the London-based security company Ada Logics to perform an independent security audit of Minder.
While we use Minder internally here at Stacklok to secure our source code repositories, build artifacts, CI/CD workflows, and open source dependencies, we wanted to make sure that the code itself that implements Minder is secure, particularly as a shared platform used by multiple organizations at once. Ada Logics is an expert here. They regularly perform manual audits of open source software to identify vulnerable code patterns and analyze the threat model, and have worked with large OSS projects including Istio, Argo, and Fluent Bit.
We also admire Ada Logics’ commitment to open source. In addition to performing security audits for OSS projects, they regularly contribute to open source security projects including OSS-Fuzz and Fuzz Introspector.
Overview of Minder’s security audit
Minder is an open source platform: the codebase is available on GitHub, so any users or companies can choose to spin up their own Minder instances. At Stacklok, we’ve built a SaaS platform on top of Minder OSS that we call Minder Cloud, available at cloud.stacklok.com. Ada Logics’ security audit therefore covered both Minder and Minder Cloud.
Ada Logics conducted Minder’s security audit with the following goals:
To formalize a threat model of Minder Cloud and identify potential attack vectors
To manually audit Minder Cloud’s codebase, including its frontend, backend, and infrastructure
To set up fuzzing infrastructure and write fuzz tests
As part of this work, AdaLogics found a total of seven issues, all in Minder’s backend server (all of these issues have since been fixed, or the fix is in progress—see the chart below). Read on for more details about our security audit, or read the full report.
Threat Modeling and Identifying Attack Vectors
Minder Cloud's architecture
Based on Minder Cloud’s architecture (shown above), Ada Logics outlined its attack surface and ways that these surfaces could be compromised. We thought it would be useful to outline this here, to help others understand their own possible attack surface. Our includes:
Data sources, including GitHub repositories and OCI registries
Requests to Minder’s gRPC server and HTTP endpoints
Attacker-controlled REST endpoints called by Minder
The chart below provides more details on how these attack surfaces could be compromised, and how we use the Minder project itself to keep Minder Cloud’s attack surfaces secure.
Attack surface
Possible method(s) of compromise
How we keep Minder users safe
GitHub repositories
Because Minder accepts input via users’ GitHub repositories, Minder could end up cloning an attacker-controlled repository, and poison the Minder process while attempting to analyze the repository.
We implemented limits on the size of repos and clones, and repos are accessed using a sandboxed implementation of Rego. Clones are held in-memory and are not written to disk, reducing the ability to perform filesystem attacks.
OCI registries
Minder Cloud pulls artifacts from OCI registries, including Dockerhub. These artifacts can be controlled by users and should be treated as untrusted.
We use the go-containterregistry library, which implements size limits and conservative parsing of manifests.
Requests to gRPC server
Minder’s gRPC server receives raw requests, which could come from both authenticated and unauthenticated users.
Minder implements authentication and authorization using consistent middleware using OpenFGA and OpenId with Keycloak.
Attacker-controlled REST endpoints
Minder could be configured by untrusted users to make requests to malicious REST endpoints, and process the data from the response.
Minder implements size limits on api responses, and limits the allowed API endpoints to GitHub’s API.
Implementing fuzz tests
“Fuzzing” refers to a testing method that injects unexpected inputs into a system in order to find bugs, performance issues, or vulnerabilities. It’s included in OpenSSF Scorecard as a security best practice.
As part of Minder Cloud’s audit, AdaLogics wrote seven fuzz tests and committed them to the upstream Minder repository. They targeted APIs that carry out more complex processing and parsing of user data, and set up a fuzzing infrastructure using ClusterfuzzLite, which manages continuous fuzzing on top of GitHub Actions. (ClusterfuzzLite is built on the same infrastructure that supports OSS-Fuzz, an open source project which has found tens of thousands of bugs in critical OSS software.)
Ada Logics uncovered a total of seven security issues, detailed below. Since the audit, we’ve taken action to fix all of these issues to keep Minder Cloud users secure.
In addition to the security protections outlined above, we also use Minder to keep Minder Cloud’s source code repo and build artifacts secure. Here’s a blog post that outlines more details about how we use Minder internally at Stacklok.
