Your Code, Their Target: Defending the Software Supply Chain with SLSA

• June 5, 2025
• By SECNORA

Software is everywhere. Whether it’s powering a healthcare system, running a financial institution, or supporting a small online business, software is now central to how we operate. But with this reliance comes a growing risk, one that most organisations aren’t fully prepared for. At SECNORA, we believe that strong cybersecurity begins with clarity and informed decision-making. Understanding the risks, and adopting proven strategies and frameworks like SLSA (Supply-chain Levels for Software Artifacts), is key to securing today’s software-driven systems. SLSA helps organisations strengthen the integrity of their software supply chain through structured, progressive levels of assurance.

In this blog, we’ll explore what a software supply chain attack really is, introduce the SLSA framework, explain its four security levels, outline the implementation process, and highlight how SLSA can enhance your organisation’s ability to resist and recover from supply chain threats.

What is a Supply Chain Attack?

A supply chain attack is when cybercriminals target software at the point of creation not at the end-user. Rather than trying to breach a system after it’s been installed, attackers go after the systems and people that build the software in the first place. Their goal? To sneak malicious code or vulnerabilities into a trusted product before it ever reaches the market. Once the compromised software is released and integrated, it can give attackers access to networks, sensitive data, or internal systems without any immediate signs of intrusion. This makes such attacks extremely difficult to detect and even harder to trace. Supply chain threats take advantage of the trust placed in software providers, third-party tools, and update mechanisms. When an organisation installs a trusted application, they often assume it’s safe. Attackers exploit that assumption by inserting themselves quietly into the development process long before the product is in use.

Unfortunately, supply chain attacks are no longer rare. Over the past few years, they’ve affected both private companies and public institutions worldwide. These incidents have shown how a single breach in a software pipeline can create ripple effects across thousands of organisations. Governments and security experts are now treating this issue as a top priority. At SECNORA, we’ve responded by helping our clients gain visibility into their development pipelines, secure their software sources, and adopt frameworks like SLSA (Supply-chain Levels for Software Artifacts) to protect against tampering and maintain code integrity.

What is SLSA?

SLSA (pronounced “salsa”) stands for Supply-chain Levels for Software Artifacts. It’s a security framework designed to help businesses of all sizes strengthen their software development and delivery process. Developed by leading minds in the tech and security industries, SLSA lays out a clear, step-by-step path for improving software integrity. Simply put, it helps ensure that the software you build or use hasn’t been changed or compromised by someone else along the way.

Every piece of software goes through a journey from source code to build systems, and finally to the product you deploy or install. Along that path, there are multiple points where things can go wrong: unauthorised access, human error, or deliberate tampering. SLSA focuses on protecting that entire journey. It introduces clear controls to make sure that what ends up in your hands is exactly what was intended with a full record of where it came from and how it was built. For businesses, this means reliability, trust, and control over your software environment. SLSA is made up of four levels, each building on the previous one:

Each level helps you reduce risk and prove to stakeholders; clients, partners, and regulators that your software is trustworthy. SECNORA sees SLSA as a vital part of any modern defence strategy. Any organisation that builds, uses, or distributes software can benefit. By adopting SLSA, our clients are better protected and also able to meet increasing demands from regulators and customers for transparency and accountability in digital operations.

How SLSA Strengthens Supply-Chain Security?

At its core, SLSA protects against tampering and misconfiguration. By design, it makes the build process auditable and cryptographically verifiable. For each build, SLSA requires generating a provenance record, essentially a signed “receipt” that logs where, when and how an artifact was produced. In practice this uses in-toto attestations (an open framework for supply-chain metadata): build tools produce a signed statement of the exact source inputs, steps and environment used. As one security guide notes, “in-toto is an unopinionated layer to express supply chain info, and SLSA is the opinionated layer specifying exactly what information must be captured”. Encapsulating provenance in a signed in-toto attestation gives it strong integrity and authenticity guarantees. Downstream users, developers and DevOps teams can then verify that any component came from an approved source and build process, not from a malicious fork or tampered binary.

These provenance attestations cover key security controls. They ensure source integrity (every code change is accounted for, often with cryptographic signatures) and build integrity (the output genuinely reflects the declared source and build recipe). For example, SLSA forbids any hidden manual steps in the pipeline: builds must be fully automated and reproducible, and the build platform must sign the resulting metada. In this way, SLSA helps “prevent tampering” and “improve integrity” at every link in the chain. When implemented, it means an attacker who tries to slip malicious code into a build would break the attestations or be flagged by the signed provenance. In short, SLSA makes your software supply chain tamper-evident and traceable from origin to release.

How to Implement SLSA?

Adopting SLSA is intended to be incremental. Here are key steps a development team can follow:

• Start with source control and automation. Ensure your build steps are fully scripted and checked into version control (for example, as YAML pipeline files or build scripts). This meets SLSA Level 1 and establishes a clear, repeatable build baseline. Even at this stage, try to sign or timestamp the build outputs if possible, as that “increases trust in the document”.
• Use a trusted build platform. Move your builds onto a hosted CI/CD service (such as GitHub Actions, Google Cloud Build, or Azure DevOps) that can enforce strict controls. SLSA Level 2 requires that the build system itself generates and signs For example, GitHub Actions supports SLSA 3 out of the box by adding a provenance action, while Google Cloud Build and other hosted builders can produce signed attestations. This means developers cannot forge build metadata, and each build’s environment is isolated from the next.
• Generate and publish provenance. Integrate a tool like in-toto or Tekton Chains to emit SLSA-formatted provenance records alongside your artifacts. For instance, Tekton Chains is an extension for Kubernetes-based pipelines that automatically produces signed attestation of container builds. GitHub provides an official SLSA provenance generator action. When a build completes, the provenance (often attached as an OCI attestation or alongside the artifact) lets downstream users verify the artifact’s origin.
• Sign and secure everything. Use strong cryptographic signatures on both your source code (e.g. GPG-signed commits) and on build artifacts or provenance. Tools like Sigstore’s cosign are commonly used to sign container images and attestations. Protect signing keys and credentials carefully, so that only authorized build agents can produce valid attestations. (SLSA guidance emphasises isolating each build run and securing the build environment to prevent insiders or attackers from injecting code.)
• Verify and enforce policies. Make provenance verification part of your release or deployment process. Consumers of your software (including your own QA systems) can run the open-source SLSA Verifier or other checks on the attestations to ensure they are valid and meet the claimed SLSA level. By automating these checks, you catch issues early. In summary, the two core tasks at any SLSA level are to: generate provenance and make it available for verification.

Tools and Workflows Supporting SLSA

Many modern tools and platforms now support SLSA out of the box or via plugins:

• GitHub Actions – GitHub’s workflows can produce SLSA-compliant provenance. There is an official SLSA GitHub generator action that signs build metadata. Using GitHub Actions also qualifies immediately for SLSA Level 3 (with no manual changes needed for SLSA 1–2). Consumers can verify artifacts with the generic SLSA verifier or view signatures via GitHub’s OCI registry integration.
• Tekton and Tekton Chains – For teams using Kubernetes-based pipelines, Tekton Pipelines plus Tekton Chains can enforce SLSA compliance. Chains watches your pipeline runs and generates in-toto attestations for each image or binary produced. This automates provenance capture in cloud-native CI/CD systems.
• Jenkins & Azure DevOps – Traditional CI servers also have SLSA support. For example, Jenkins offers an SLSA Builder plugin and an in-toto integration that output provenance. Azure DevOps has extensions to collect build metadata as SLSA attestations. These let existing on-premise pipelines move toward SLSA levels without a full rewrite.
• Sigstore (cosign) and in-toto – Sigstore’s tooling is often used alongside SLSA for signing and storing attestations. Cosign can sign container images and their attestations (in-toto statements), ensuring provenance is verifiable. In-toto itself (a CNCF project) provides language libraries and frameworks for creating secure attestations. As the SLSA FAQ notes, “in-toto is the unopinionated layer, and SLSA is the opinionated layer specifying exactly what information must be captured”. Many SLSA implementations rely on these open standards under the hood.
• Other CI/CD platforms – Google Cloud Build, GitLab, and others are also adding SLSA capabilities. For example, Google Cloud Build can generate attestations that satisfy SLSA requirements. The SLSA documentation even lists which platforms can achieve each level. Choosing a platform with built-in SLSA support is often the easiest path to higher assurance.

In practice, teams mix and match these tools in their development workflows. The key is to ensure the pipeline automatically records and signs every step, and that no critical step (like compilation or packaging) happens outside this secure process.

Key Benefits for Development and DevOps Teams

Adopting SLSA brings clear benefits to developers and operators:

• Stronger assurance and trust. Every build and release comes with cryptographic proof of its origin. Teams can “trace each software artifact back to its source, ensuring only trusted, verified components are used”. This builds confidence that nobody slipped malware or unreviewed code into the product.
• Tamper resistance. SLSA ensures controls are in place at every stage to detect and stop malicious changes. Unauthorized modifications to code or dependencies are caught by signature mismatches or missing attestations. In other words, the entire pipeline is hardened so that if an attacker tries to insert a bad component, it will break the chain of trust.
• Integrated security without slowdowns. Because SLSA encourages automation, teams often find that “security gets baked into every step, making it easier to stay ahead of threats without slowing you down”. Checks like static analysis or dependency scanning can run alongside normal builds. By codifying processes, SLSA actually streamlines workflows: everyone follows the same secure build steps, reducing ad-hoc errors.
• Simplified compliance and audits. The signed provenance and logs created by SLSA provide a ready audit trail. As one industry analysis notes, the framework “takes the heavy lifting out of securing your supply chain” by automating attestations. For regulated sectors, this means showing auditors a clear chain of custody for software artifacts (often a tricky requirement).
• Greater release confidence. In the end, SLSA helps reduce risk of post-release failures or breaches. Transparent, verifiable processes “keep software releases secure, reducing the risk of tampering or hidden vulnerabilities and providing confidence in the reliability of the final product”. Developers and DevOps teams can ship code knowing it passed a well-defined security gate.

By following SLSA’s guidelines, organisations achieve an industry-recognised baseline of supply chain security. And because the levels are incremental, teams can start small (Level 1 or 2) and grow security as they mature.

SECNORA’s Role as Your Security Partner

At SECNORA, we emphasise that supply-chain security must be strategic and scalable. The SLSA framework fits this approach perfectly, it provides clear, practical steps from basic to advanced security. By adopting SLSA best practices, technical teams can systematically protect their build pipelines and software artifacts. SECNORA supports clients in implementing these controls, from setting up signed CI/CD pipelines to choosing the right tools and verifying compliance. In doing so, we help ensure that every component of your software is trusted, tamper-proof and ready for production use.

Frequently Asked Questions [FAQs]

1. What is SLSA security?
   SLSA (Supply-chain Levels for Software Artifacts) is a security framework to protect software supply chains by ensuring the integrity, authenticity, and traceability of software artifacts through automated, auditable, and cryptographically verified processes.
2. What is the purpose of the supply chain level for Software Artifacts in the SLSA framework?
   The SLSA framework’s levels (1–4) provide a structured, incremental approach to improve software supply chain security by documenting builds, generating signed provenance, isolating build environments, and enforcing strict controls to prevent tampering and ensure trust.
3. How do you ensure security of supply?
   Ensure supply chain security by adopting SLSA, automating builds, generating and verifying signed provenance, using trusted CI/CD platforms, and enforcing cryptographic signatures and verification policies to detect and prevent tampering.
4. How do you secure supply chain?
   Secure the software supply chain by implementing SLSA’s guidelines: use version-controlled builds, trusted platforms like GitHub Actions or Tekton, sign artifacts with tools like Sigstore, generate in-toto attestations, and verify provenance before deployment.

References:

• https://slsa.dev/
• https://www.jit.io/resources/security-standards/7-ways-to-use-the-slsa-framework-to-secure-the-sdlc
• https://www.legitsecurity.com/blog/slsa-provenance-blog-series-part-2-deeper-dive-into-slsa-provenance#:~:text=What%20is%20SLSA%20Provenance
• https://opensource.googleblog.com/2023/03/getting-to-slsa-level-2-with-tekton-and-tekton-chains