Adopting SLSA in Canada means treating your build pipeline as the security perimeter, generating signed provenance for every artifact, and mapping those attestations to the procurement and privacy obligations Canadian organizations already carry. SLSA (Supply-chain Levels for Software Artifacts) is a vendor-neutral framework maintained under the Open Source Security Foundation, and nothing about it is jurisdiction-specific. What is specific to Canada is the regulatory context you plug it into: federal procurement, PIPEDA, provincial health and public-sector rules, and the growing expectation that suppliers can show where their software came from.
This guide walks through what SLSA actually asks for, how Canadian teams tend to sequence adoption, and where the framework lines up with obligations you may already be meeting.
What SLSA Actually Requires
SLSA is organized into build levels. Each level raises the bar on two things: the integrity of the build process and the trustworthiness of the provenance you can produce.
- Build L1 asks that you produce provenance at all: a machine-readable record of how an artifact was built, what source it came from, and which builder produced it.
- Build L2 requires that the build run on a hosted, managed service and that provenance be signed, so a consumer can verify it was not forged after the fact.
- Build L3 requires hardened, isolated builds where the provenance cannot be tampered with even by the person who triggered the build.
The framework deliberately does not tell you which CI system to use. A GitHub Actions pipeline with the SLSA GitHub Generator, a GitLab pipeline with signed artifacts, or a Tekton chain can each satisfy the same level. What matters is that the provenance is unforgeable and verifiable.
Why Canadian Teams Are Looking at SLSA Now
Two pressures are converging. The first is federal: agencies procuring software increasingly reference secure-development expectations that echo the U.S. NIST Secure Software Development Framework (SSDF), and SLSA provenance is one of the cleanest ways to evidence build integrity against those expectations. The second is commercial: Canadian software vendors selling into U.S. federal or regulated buyers are being asked for SBOMs and provenance regardless of where they operate.
If you are a Canadian SaaS company selling into healthcare, finance, or government, the practical reality is that your customers' security questionnaires now ask how you protect your build pipeline. SLSA gives you a structured answer rather than a paragraph of prose.
Mapping SLSA to Canadian Obligations
SLSA is not a privacy framework and does not replace PIPEDA compliance. But there is useful overlap worth naming honestly:
- Accountability under PIPEDA expects you to demonstrate control over how software handling personal data is produced. Signed provenance is concrete evidence of that control.
- Public-sector procurement in several provinces references supply chain integrity. Build provenance and an SBOM together answer "what is in this, and how do we know."
- Breach response obligations are easier to meet when you can reconstruct exactly which dependencies shipped in a given release from its provenance and SBOM.
Treat SLSA as the build-integrity leg of a broader program that also includes dependency scanning and vulnerability management. It does not, on its own, tell you whether a dependency is vulnerable.
A Realistic Adoption Sequence
Most teams do not jump to Build L3. A sequence that works:
- Generate an SBOM on every build. Use Syft,
cdxgen, or your build tool's native export. This is your inventory. - Emit provenance (L1). Add the SLSA generator to your pipeline so each release artifact carries a provenance document.
- Move builds onto a hosted runner and sign provenance (L2). Use OIDC-based keyless signing with Sigstore/cosign so you are not managing long-lived keys.
- Isolate and harden (L3). Enforce that build steps cannot access signing material and that provenance is generated by the platform, not user-controlled scripts.
Here is a minimal cosign verification step a consumer might run to check a signed artifact before deploying it:
cosign verify-attestation \
--type slsaprovenance \
--certificate-identity-regexp '^https://github.com/your-org/' \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
ghcr.io/your-org/service:1.4.2
Where Dependency Scanning Fits
Provenance tells you a build is authentic. It does not tell you the code inside is safe. A known-vulnerable version of a transitive dependency will happily ship with perfectly valid SLSA provenance. That is why build integrity and software composition analysis are complementary rather than interchangeable. An SCA tool such as Safeguard can flag a vulnerable transitive package that your provenance would otherwise wave through untouched.
Pairing the two gives you the full picture: SLSA answers "did this come from where I think," and SCA answers "is what came through actually safe to run."
Common Mistakes
- Signing with long-lived keys. Keyless, OIDC-based signing removes an entire class of key-management risk. Use it.
- Provenance no one verifies. Generating attestations is pointless if nothing downstream checks them. Wire verification into your deploy gate.
- Confusing SLSA with an SBOM. They are different documents solving different problems. You want both.
- Assuming a Canadian-specific SLSA exists. It does not. The framework is global; only your compliance context is local.
If you are formalizing a program, our security academy has deeper material on provenance and pipeline hardening.
FAQ
Is there a Canadian version of SLSA?
No. SLSA is a single global framework maintained by the OpenSSF. Canadian teams adopt the same specification; what differs is the regulatory context (PIPEDA, procurement rules) you map it into.
Does SLSA make my software compliant with PIPEDA?
Not by itself. PIPEDA is a privacy law covering how you handle personal information. SLSA strengthens build integrity, which supports the accountability principle, but it does not address consent, retention, or disclosure requirements.
What SLSA level should a Canadian startup aim for?
Start at Build L1 (produce provenance) and move to L2 (hosted builds with signed provenance) as soon as your CI supports keyless signing. L2 answers most customer security questionnaires. Pursue L3 when a specific buyer requires it.
Does SLSA replace vulnerability scanning?
No. SLSA verifies where an artifact came from, not whether its contents are vulnerable. You still need software composition analysis to catch known-vulnerable dependencies.