Introducing StepSecurity Release Monitor
We are super excited to announce the preview of StepSecurity Release Monitor. Release Monitor allows you to define your release policy as code and notifies you if a new version of your software is released without following the expected release process.
Release Monitor monitors your software artifact location e.g., a GitHub Release, a Docker image in a registry, or a storage account. If there is a change to an existing artifact or if a new version is released, it re-traces the path from artifact to CI/ CD pipeline to the source code and verifies if the required or expected release process has been followed.
The major highlight is that you can use Release Monitor with minimal effort without having to change your release process or CI/CD pipeline.
Why do I need Release Monitor?
Release Monitor helps you setup governance for your release process. This will enable consumers of your software to use it with confidence.
More importantly, it can help you detect if an attacker updates your software artifact to inject a backdoor. Such software supply chain attacks have become a lot more common.
As an example, in the Codecov breach, the storage account where the software artifact was located was compromised, and the artifact was tampered. With Release Monitor, it would have detected the change to the artifact, re-traced the path that the artifact should have taken, and realized that the expected release process was not followed, since no CI/ CD pipeline was run to update the artifact. The attack would have been detected and alerted in a matter of minutes rather than months.
In another case, the GITHUB_TOKEN for Visual Studio Code’s GitHub repository was compromised by a security researcher, and this token was used to update a release branch. It could have as well been used to modify a release artifact or create a new release with a backdoor. In this scenario, Release Monitor would have detected that the release has not been published from the expected workflow and notified the maintainers.
How do I define my release policy as code?
It is common for software artifacts to be released using a CI/ CD pipeline. Each developer or team has a software release process. This process is sometimes documented and sometimes just known within the team.
With Release Monitor, we are introducing a way to document the release policy as code. You can think of this as a way to group together:
1. An artifact location,
2. A CI/ CD pipeline that is expected to produce the artifact, and
3. A branch where the released code should exist, and
4. Optionally, a prefix for the allowed tag names.
This information is stored in a release-monitor.yml YAML file. As an example, this is the release policy as code YAML file for Fleet:
It shows that
- The artifact location is GitHub Release,
- The release should come from a GitHub Action workflow called
goreleaser-fleet.yamlwhich is in the same repository, - The commit for the release should either be in the main branch or a branch starting with the prefix
patch-fleet-v, and - The tag for the release should start with
fleet-v.
How does Release Monitor work?
In this preview version, Release Monitor can monitor GitHub Releases that are published using a GitHub Actions workflow.
To use Release Monitor to monitor GitHub Releases, you need to install the StepSecurity App. Whenever a new release is published, it looks for the release policy as code file, either in the same repository, or in the step-security/secure-workflows repository. It then verifies if the GitHub Release followed the expected release process.
If not, an issue is created in the repository. Here is an example of an issue when the release commit did not belong to an expected branch.
What’s next?
We will be adding more software artifact types, CI/ CD providers, and notification methods in the future. To get updates, follow StepSecurity on LinkedIn and Twitter.
If you face any issues using StepSecurity App, please create an issue at https://github.com/step-security/secure-workflows/issues
