StatusNeo

DevSecOps 101 – Securing the Software Supply Chain with SLSA

What is SLSA?

Supply chain Levels for Software Artifacts, or SLSA is a security framework that provides a set of standards and controls to enhance the integrity and protect against tampering in projects, businesses, and enterprises. It ensures that you attain maximum resilience at every point in the chain, moving from a safe state to optimal security.

The complexity of a system increases the risk of vulnerabilities being introduced into the supply chain through software. It’s crucial to have established checks and best practices to ensure artifact integrity and confirm that the source code being used is authentic. Without a solid foundation and a growth plan, it becomes challenging to effectively guard against future hacks, breaches, or compromises.

Supply chain attacks, which use software interference to target weak spots, are a constant concern. In order to protect a system from these dangers and risks, the SLSA framework sets three trust boundaries and encourages the use of the appropriate standards, attestation, and technical controls.

Levels of Assurance

When discussing how secure software, supply chains, and their individual components really are, SLSA levels act as a shared vocabulary. The levels combine industry-recognized best practices from the source to the system to produce four compliance levels of increasing assurance. In these, the builds, sources, and dependencies of open-source or for-profit software are examined. SLSA means targeted, doable steps to stop unauthorized software modifications, as well as a plan to harden that security over time. It starts with simple, fundamental steps at the lower levels to build up and guard against complex threats later.

This entails the capacity to automatically analyze artifacts, ensure the original source code, guard against disruptions that may occur during the development and distribution processes, isolate any hidden vulnerabilities, and know for sure which system components may be impacted.

Threats and Mitigations

The primary focus of the SLSA Framework is Supply Chain Integrity with a secondary focus on Availability.

Integrity means protection against tampering or unauthorized modification at any stage of the software lifecycle. Within SLSA, we divide integrity into source integrity vs build integrity. Integrity refers to defense against unauthorized manipulation or modification at any point in the software lifecycle. Integrity in SLSA is split into source integrity and build integrity.

Source Integrity Threats

(A) Submit unauthorized change

(A1) Submit Code Without Review

• Code in the VCS should not be merged in without a formal review from the maintainers/ peers.
• The author/contributor should not approve his/her own pull request with a sock puppet account
• Robot Accounts should not be allowed to review and approve the pull request – they should be responsible for quality gates and automated validation jobs.
• Review Exceptions should not be abused by anyone, administrators included.

(A2) Evade Code Review Requirements

• Code Modification post-approval on the PR must revoke the approval
• No unreviewable/meaningless changes that pass the diff should be part of the pull request.
• Reviewed Pull Request’s context should not be switched post approval
• Multi-factor authentication must be enforced so that trusted accounts cannot create a malicious PR if they are compromised.
• Only the final version that is actually reviewed is the one that is approved. Any intermediate revisions don’t count as being reviewed.

(A3) Code review bypasses that are out of the scope of SLSA

• The author intentionally submits and merges bad code
• Two trusted peers collude a change
• Bug door changes: PR looks innocent but has malicious changes
• The peer/reviewer “rubber-stamps” the pull request without actually reviewing the changes

(B) Compromise source repo

• The project owner bypasses or disables controls
• Platform administrator abuses their power
• exploiting an SCM weakness

Build Integrity Threats

(C) Build from a modified source

• Build using the unofficial fork of the code: Build from an unauthorized fork of the code that might have unapproved changes, but utilize the usual CI/CD process.
• Create from an unauthorized branch or tag: Check out an “experimental” branch or something comparable that might contain code that isn’t meant for release, but build using the expected CI/CD procedure and source location.
• Build the package using the appropriate CI/CD platform, but with unauthorized build instructions.
• Build from an unauthorized entry point: Build with the typical CI/CD procedure, source location, and branch/tag, but with a target or entry point that is not meant for publication.
• Build using a modified copy of the code that was altered after checkout: Build from a copy of the code that has changed from the checkout.

(D) Compromise build process

• Build parameters can be used to insert behavior: Build with the anticipated branch/tag, source location, CI/CD process, and entry point, but include a build parameter that introduces undesirable behavior into the result.
• Compromise the built environment for a subsequent build by running a “bad” build that leaves a modification in the environment, then using that environment to execute a “good” build.
• Parallel build compromise: Run a “poor” build that changes the way another “good” build behaves.
• Utilize or exfiltrate a cryptographic secret that should only be accessible to the build service, such as the provenance signing key.
• Decide on the provenance’s values: Get the dependable control plane to sign fabricated provenance.
• Add a “bad” artifact to a build cache that is later retrieved by a “good” build process to poison the build cache.
• Project director
• Platform manager

(E) Use compromised dependency

(F) Upload modified package

• Build using an unauthorized CI/CD pipeline that does not follow the proper building procedures.
• Upload a package without a provenance: Upload an unprovenanced package.
• After CI/CD, you can tamper with an artifact by taking a good version, making some changes to it, and then re-uploading it with the original provenance.
• Change provenance: Complete a build that would not ordinarily pass the policy tests, then change the provenance to enable the build.

(G) Compromise package repo

(H) Use compromised package

• Typosquatting: To trick consumers into using your malicious package instead of the good one, register a package name that seems suspiciously close to the name of a well-known package.

DevSecOps is a critical aspect of modern software development and delivery. It integrates security into the entire software development process, from design to deployment. This approach not only helps to minimize the risk of vulnerabilities but also enables organizations to quickly respond to security threats. By adopting DevSecOps, organizations can ensure that their software is secure, resilient, and meets the high standards of their customers and stakeholders. Overall, DevSecOps represents a cultural shift in the way organizations think about security and provides a framework for delivering secure and reliable software at scale.