Implementing SLSA Source Requirements to Improve Software Supply Chain Security

user profile
Developer Advocate

Today, attackers can target every link in a typical software supply chain. These kinds of attacks are increasingly public, disruptive, and costly in today’s interconnected environment. SLSA source requirements help mitigate threats originating from source control management. 

The Cycode platform is helpful for many purposes–among them, it can verify SLSA source requirements. The policies and knowledge graph can validate each condition, helping developers ensure conformity to these standards.

Fulfilling SLSA Source Requirements

As previously mentioned in our overview of SLSA, this framework contains four (4) levels, with SLSA 4 representing the highest degree of security rigor.

Version Controlled

Implementing version control is recommended even at the lowest SLSA level; at SLSA level 2, this recommendation becomes a requirement. The version control system must meet several needs to fulfill this prescribed baseline level.

The first requirement is to include a change history. A changelog must be maintained to retain a record of changes. Each change must consist of the following elements:

  • Identities of the uploader and reviewers (if applicable)
  • Timestamps of the submission and the reviews (if any)
  • A change description or other justification
  • The content of the change
  • Any parent revisions

These elements should all be present at the SLSA level 4, particularly since higher SLSA levels necessitate greater oversight, including two-person reviews. Though the changelog does not have to be public, organizations should implement some form of proof for the sake of their consumers.

The second requirement is to include an immutable reference to the revision. In systems such as git, this is stored semantically with the format {repo URL + branch + commit ID}. 

Most popular version control systems already meet these requirements, such as git, Perforce, Mercurial, and Subversion. 

We may verify this within the Cycode platform by verifying the presence of this item within the Assets section. Repository information, including the source information, is displayed in a list format.

The repositories are listed here, and the source control management utilized tautologically proves that the repo is version controlled. If you can locate the repository within the Cycode platform, then voila: your organization’s repository has already achieved SLSA level 2!

Verified History

Achieving SLSA level 3 and above necessitates a verified history. This source requirement requires each change to have at least one strongly authenticated actor identity and timestamp. These identities contain author, uploader, and reviewer data. Identities must use two-step verification.

The Cycode platform contains several access policies that help protect the source by enforcing two-factor authentication:

These policies help ensure robust verification of users who make changes within a source control system, thus reducing the probability of successful tampering. 

We may use Cycode’s knowledge graph to confirm that the repository has branch protections:

Users may save this custom query to alert organizations when repositories are not using the necessary branch protections on the main (or master) branch. This allows users to validate that SCM branch protections include status checks, reviews from code owners, linear history, and signed commits:

Retained Indefinitely

Immutable history

To verify immutable history as part of ascertaining indefinite retention, we must confirm that force pushes are disabled. Cycode includes built-in policies for verifying this information. Within the “Insecure Configuration” subsection, there exists a policy that creates an alert if force-pushes on the default branch are permitted: Enabling this policy provides an easy way of verifying an immutable history that is not susceptible to being overwritten.

Time of retention

Verifying that the main branch is not prone to deletion helps validate the retention time and helps verify immutable history as part of SLSA source requirements. Similarly to the prior policy, this may be toggled for use within the insecure configurations setting:

Enabling this policy helps prove indefinite retention, thus allowing organizations to adhere to SLSA requirements. 

Once these policies are employed, along with common requirements to control access, the Cycode platform has effectively helped an organization partially achieve SLSA level 4, the highest level of SLSA source requirement. The last piece of this puzzle entails a two-person review.

Two-Person Reviewed

Achieving SLSA level 4 within this framework’s source requirements requires a two-person review of each merged PR. The Cycode platform contains several policies that may be used for this purpose. 

Part of this two-person review requirement includes receiving an approving review from a different person than the review requester. Each merge to the default branch requires a review and approval from a code owner. We can utilize the following policy to set this secure configuration:

Enabling this policy prevents code from being merged without an approving review. This catalyzes visibility and oversight into the development process, thus helping protect the source from departures from a known safe state.  

In addition, we may check to confirm that MFA is enabled:

Multi-factor authentication provides a means of further validating that each reviewer is who they say they are, hardening authentication. 

Cycode and SLSA Source Requirements

Adhering to the highest level of SLSA source requirements or other SLSA requirements requires a comprehensive solution enabling strong governance. Cycode’s platform enables inventorying of assets, protects source code by mandating best IaC security practices, and serves as an answer to AppSec’s challenge of development visibility. Ultimately, Cycode helps install security at the beginning of the SDLC to protect against risks, including software supply chain attacks.

Cycode’s knowledge graph is a powerful tool to help security teams validate adherence to SLSA source requirements. Many necessary pieces of information are aggregated from across the SDLC to deliver unique, concise insights.

These insights are generated quickly and help organizations save time between diagnosis and remediation, thus shrinking the attack window and further strengthening an organization’s security posture.

About Cycode

Adhering to any compliance framework, be it SLSA, the NIST SSDF, or any other framework requires guidance. Cycode is a complete solution to ensuring software supply chain security. The platform provides visibility, safety, and integrity across all phases of the SDLC. Cycode integrates with DevOps tools and infrastructure providers, hardens their security postures by implementing consistent governance, and reduces the risk of breaches with a series of scanning engines that look for issues like hardcoded secrets, infrastructure as code misconfigurations, code leaks, and more. Cycode’s knowledge graph tracks code integrity, user activity, and events across the SDLC to prioritize risk, detect anomalies, and prevent code tampering.

Want to learn more?

Schedule a demo to learn more about how Cycode can help secure your software supply chains.

Further Reading

https://slsa.dev/spec/v0.1/requirements

https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html

https://github.com/slsa-framework/slsa