September 09, 2026
11 min read
By Kokil Thapa | Last reviewed: September 2026
Your application can pass every penetration test and still ship a compromised dependency or a tampered build artifact. Supply-Chain Security with SLSA addresses that gap by defining what trustworthy build provenance looks like and how to verify it before deploy. If you run DevSecOps pipelines that shift security left in CI/CD, SLSA gives you a shared vocabulary for build integrity instead of ad-hoc checklist items. This guide maps SLSA levels to steps you can implement on Laravel 13, PHP 8.5, and GitHub Actions today.
Quick answer: Supply-Chain Security with SLSA means generating and verifying signed build provenance so every release proves who built it, from which source commit, with which steps, and without post-build tampering—starting at SLSA Level 1 and scaling toward isolated, reproducible builds.
What is Supply-Chain Security with SLSA and why does it matter?
SLSA—Supply-chain Levels for Software Artifacts—is an open framework maintained at slsa.dev. It does not replace your existing security stack. It tells you what evidence to collect at build time so downstream systems can trust—or reject—an artifact.
High-profile incidents like SolarWinds and compromised npm packages showed a pattern. Attackers target CI runners, build scripts, or artifact stores rather than production firewalls. On production Laravel applications I maintain, the risk is rarely a clever SQL injection on day one. It is a poisoned Composer package, a modified release tarball, or a runner that builds from the wrong commit.
SLSA organises defences into four levels. Each level adds requirements for provenance, build isolation, and reproducibility. You do not need Level 4 on every internal admin panel. You do need a conscious target level per asset class.
SLSA complements—not replaces—dependency scanning, SAST versus DAST testing, and runtime hardening. Think of it as answering a different question. Scanning asks whether code contains known flaws. SLSA asks whether the binary you deploy is the binary your pipeline actually built.
How do SLSA levels compare and which should you target?
SLSA v1.1 defines Build Track levels from 0 to 3 in the current spec. Level 4 remains aspirational for many teams. Pick a target based on asset criticality, not vanity.
| Level | Provenance | Build environment | Typical fit |
|---|---|---|---|
| 0 | None or informal | Any | Local experiments, throwaway branches |
| 1 | Script-generated, unsigned | Shared CI | Internal tools, staging apps |
| 2 | Signed, service-generated | Hosted platform controls | Client-facing Laravel APIs, WooCommerce stores |
| 3 | Non-falsifiable, platform-enforced | Isolated, ephemeral builders | Payment flows, legal portals, regulated data |
For a law-firm client portal with document uploads and payments—similar to platforms in my Mijar Law Associates portfolio work—Level 2 is a sensible minimum. Level 3 is worth the effort when a compromised build could expose client documents or payment callbacks.
Level 1 is where most teams should start if they ship manually today. You already have CI. Add a provenance file on every tagged release. That alone beats a tarball copied over SFTP with no audit trail.
How do you implement SLSA Level 1 provenance in GitHub Actions?
Level 1 requires documented build steps and provenance that lists the source repository, commit, builder, and build type. GitHub's official generator handles most of this if you structure the workflow correctly.
Step 1: Pin actions and lock dependencies
Start with immutable references. Pin third-party GitHub Actions to commit SHAs. Commit your composer.lock and run composer install --no-dev --prefer-dist in CI. On PHP 8.5 with Laravel 13, never run composer update during a release build.
Step 2: Add the SLSA GitHub generator
The slsa-framework/slsa-github-generator project emits provenance compatible with SLSA Level 3 when used on GitHub-hosted runners with the recommended workflow pattern. Even at Level 1, adopting its output format future-proofs your pipeline.
# .github/workflows/release.yml
name: Release with Provenance
on:
push:
tags:
- 'v*'
permissions:
contents: write
id-token: write
attestations: write
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: shivammathur/setup-php@v2
with:
php-version: '8.5'
tools: composer:v2.10
- run: composer install --no-dev --prefer-dist --no-interaction
- run: php artisan config:cache && php artisan route:cache
- run: tar -czf release.tar.gz --exclude=.git .
- uses: actions/upload-artifact@v4
with:
name: release-bundle
path: release.tar.gz
provenance:
needs: build
permissions:
actions: read
id-token: write
attestations: write
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
with:
base64-subjects: ${{ needs.build.outputs.digest }}
upload-assets: true
Adjust the generator version to a current release tag from the upstream repository. Never track @main on security-sensitive workflows.
Step 3: Store artifacts and provenance together
Upload the tarball and its provenance to the same GitHub Release or object store prefix. Your deploy script should fetch both and verify the signature before extraction. This mirrors the zero-downtime Deployer 7 flow I use on shared EC2 hosts: build in CI, verify at deploy, symlink swap only after checks pass.
How do you verify SLSA provenance before deployment?
Generating provenance without verification is paperwork. Verification closes the loop. Before you run dep deploy production or restart PHP-FPM, confirm the artifact matches signed metadata.
Use slsa-verifier at deploy time
The SLSA project ships slsa-verifier, a CLI that checks provenance signatures against expected builder identity and source repository. Run it from your deploy hook or a GitLab CI deploy stage.
# Install slsa-verifier (check latest release on GitHub)
curl -Lo slsa-verifier https://github.com/slsa-framework/slsa-verifier/releases/download/v2.6.0/slsa-verifier-linux-amd64
chmod +x slsa-verifier
# Verify artifact against expected source repo and tag
./slsa-verifier verify-artifact release.tar.gz \
--provenance-path provenance.intoto.jsonl \
--source-uri github.com/myorg/myapp \
--source-tag v1.4.2
If verification fails, abort the deploy. Do not override with a force flag unless you enjoy incident response on a Friday evening.
Integrate with container and package registries
For Docker-based Laravel queues or Horizon workers, publish images to a registry that supports OCI artifact attestations. Verify digest plus attestation before docker pull on production nodes. Pair this with distroless base images to shrink runtime attack surface after you trust the build.
On shared hosting without containers, tarball verification still works. Hash the artifact in provenance and compare locally with sha256sum. Simple beats nothing.
How does SLSA fit with SBOMs, dependency scanning, and PHP/Laravel workflows?
SLSA provenance proves build integrity. An SBOM lists what is inside the build. You need both for defensible supply-chain security.
Generate a CycloneDX or SPDX SBOM from Composer during CI:
composer require --dev cyclonedx/cyclonedx-php-composer
vendor/bin/cyclonedx-php-composer make-bom --output-file sbom.json
Feed the SBOM into your vulnerability scanner or store it alongside provenance on each release. When applying Magento 2 security patches safely, the same pattern applies: provenance confirms the patch build is authentic; the SBOM tells you which vendor modules changed.
For Laravel apps, common gaps I see on client projects include:
- Building on a developer laptop and uploading via FTP—no provenance at all
- Self-hosted runners with shared credentials and no isolation—see self-hosted CI runner hardening
- Skipping lock file commits, so CI cannot reproduce production dependencies
- Treating Composer audit as sufficient while ignoring build tampering
Run composer audit in CI. Also pin GitHub Actions, restrict permissions to least privilege, and use OIDC federation instead of long-lived cloud keys where possible.
Add SonarQube quality and security gates for static analysis on application code. Scan IaC with tools covered in our tfsec, Checkov, and Terrascan guide if Terraform defines your infra. SLSA does not scan Terraform—it ensures the plan artifact you apply came from the expected pipeline.
What are common SLSA mistakes on small teams and Nepal-based projects?
Budget and staff size do not excuse Level 0 forever. They do mean you prioritise ruthlessly.
- Chasing Level 4 first. Reproducible builds are hard on PHP with extension variance. Nail Level 2, then iterate.
- Ignoring runner hygiene. A signed provenance from a compromised self-hosted runner is theatre. Harden the builder before you sign.
- Skipping verification in deploy scripts. Provenance in GitHub Releases helps auditors, not production, unless deploy enforces it.
- Confusing SLSA with compliance checkboxes. SLSA is technical evidence. It supports ISO or SOC narratives but does not replace them.
- Neglecting WordPress and WooCommerce paths. For WooCommerce 11.1 on WordPress 7.1, plugin zip integrity matters as much as container provenance. Use official update channels and hash verification on custom bundles.
Nepal-based agencies often deploy to a single VPS with Rs 3,000–8,000/month hosting (~USD 22–60). That setup can still reach Level 1–2 by building on GitHub Actions and deploying verified tarballs. The server never compiles releases—it only verifies and extracts. This reduces server load and improves security at once.
For password and secret handling in pipelines, rotate tokens quarterly. Use a strong password generator for service accounts, store secrets in GitHub Environments with approval gates, and never echo credentials in workflow logs. Pair pipeline work with Ubuntu server security baselines on the target host.
If you lack in-house DevOps capacity, treating supply-chain controls as part of ongoing support and maintenance or Linux system administration is cheaper than recovering from a poisoned deploy.
Key Takeaways
- Start Supply-Chain Security with SLSA at Level 1: document builds and emit provenance on every release tag.
- Verify provenance with
slsa-verifierbefore deploy—not after users report odd behaviour. - Combine SLSA attestations with Composer SBOMs and
composer auditfor dependency visibility. - Pin GitHub Actions to SHAs, commit lock files, and harden CI runners before pursuing higher levels.
- Target Level 2 for client-facing apps; Level 3 for payment, document, or PII-heavy systems.
- Build in CI, verify on the server—never compile production releases directly on the VPS.
People Also Ask
Is SLSA the same as an SBOM?
No. An SBOM inventories components inside an artifact. SLSA provenance describes how that artifact was built and whether the build process is trustworthy. Use both together for complete supply-chain visibility.
What SLSA level do most companies achieve?
Most organisations sit between Level 1 and Level 2 in 2026. Level 3 is common among cloud-native vendors and security-mature product teams. Level 4 remains rare outside specialised security and open-source projects with reproducible build tooling.
Does SLSA work with GitLab CI instead of GitHub Actions?
Yes. GitLab supports OIDC tokens and artifact metadata you can adapt to SLSA provenance formats. The official generators focus on GitHub, but the spec is platform-neutral. You may need custom attestation steps on GitLab until native generators mature.
Do PHP and Laravel projects benefit from SLSA?
Absolutely. Composer dependencies, shared hosting deploys, and manual SFTP uploads are classic weak points. SLSA gives PHP teams the same build-integrity guarantees that container-native stacks advertise—without requiring Kubernetes.
Next steps for your pipeline
Pick one production app this week. Add a tagged release workflow that emits provenance, store the SBOM beside it, and wire verification into your deploy script before PHP-FPM reload. Read the official SLSA v1.1 specification for terminology, then align your internal runbook.
If you want help auditing an existing Laravel, WordPress, or eCommerce pipeline, review our custom software development services or explore related guides on API security checklists, Content Security Policy for Laravel, and WordPress hardening for 2026. Strong Supply-Chain Security with SLSA is incremental work—not a single tool install—and it pays off the first time it blocks an unexpected artifact.
Contact us to review your CI/CD pipeline, provenance gaps, and deploy verification hooks before your next release.
Frequently Asked Questions
SLSA means generating and verifying signed build provenance so every release proves who built it, from which source commit, with which steps, and without post-build tampering.
No. An SBOM inventories components inside an artifact. SLSA provenance describes how that artifact was built and whether the build process is trustworthy.
Most organisations sit between Level 1 and Level 2. Level 3 is common among cloud-native vendors and security-mature teams. Level 4 remains rare outside specialised projects.
Penetration tests and runtime hardening do not stop a poisoned Composer package, a modified release tarball, or a CI runner building from the wrong commit. High-profile incidents like SolarWinds and compromised npm packages targeted build pipelines and artifact stores, not production firewalls. SLSA collects evidence at build time so deploy systems can trust or reject an artifact. Scanning asks whether code contains known flaws; SLSA asks whether the binary you deploy is the binary your pipeline actually built. On production Laravel applications, that build-integrity gap is often the realistic first attack path.
SLSA v1.1 defines levels 0 through 3; Level 4 remains aspirational for many teams. Level 0 has no or informal provenance and fits local experiments. Level 1 adds script-generated, unsigned provenance on shared CI—typical for internal tools and staging. Level 2 requires signed, service-generated provenance with hosted platform controls—suitable for client-facing Laravel APIs and WooCommerce stores. Level 3 demands non-falsifiable, platform-enforced provenance from isolated, ephemeral builders—appropriate for payment flows, legal portals, and regulated data. Each level adds requirements for provenance, build isolation, and reproducibility. Pick a target based on asset criticality, not vanity.
Level 1 is where most teams should start if they ship manually today: document builds and emit provenance on every tagged release. For client-facing Laravel APIs and WooCommerce stores, Level 2 is a sensible minimum because provenance is signed and service-generated on a hosted platform. For a law-firm client portal with document uploads and payments—similar to platforms like Mijar Law Associates—Level 2 is the baseline. Level 3 is worth the effort when a compromised build could expose client documents or payment callbacks. You do not need Level 4 on every internal admin panel; nail Level 2 first, then iterate.
Start by pinning third-party GitHub Actions to commit SHAs, committing composer.lock, and running composer install --no-dev --prefer-dist on PHP 8.5 with Laravel 13—never composer update during a release build. Add a tagged release workflow that checks out the repo, caches config and routes, builds a release tarball, and uploads it as an artifact. Attach the slsa-framework/slsa-github-generator using generator_generic_slsa3.yml at a pinned release tag—not @main. Grant id-token and attestations write permissions. Store the tarball and its provenance together on the same GitHub Release or object store prefix so deploy scripts can fetch and verify both before extraction.
Generating provenance without verification is paperwork. Before running dep deploy production or restarting PHP-FPM, use slsa-verifier to check the artifact signature against expected builder identity and source repository. Install the CLI from the official GitHub release, then verify the tarball against provenance.intoto.jsonl with your expected source URI and tag. If verification fails, abort the deploy—do not override unless you want incident response on a Friday evening. On shared hosting without containers, hash the artifact in provenance and compare locally with sha256sum. This mirrors a zero-downtime Deployer 7 flow: build in CI, verify at deploy, symlink swap only after checks pass.
SLSA provenance proves build integrity; an SBOM lists what is inside the build. You need both for defensible supply-chain security. Generate a CycloneDX or SPDX SBOM during CI with cyclonedx/cyclonedx-php-composer and store sbom.json alongside provenance on each release. Feed the SBOM into your vulnerability scanner. Run composer audit in CI, but do not treat it as sufficient while ignoring build tampering. SLSA complements dependency scanning, SAST versus DAST testing, and runtime hardening—it does not replace them. Pair attestations with pinned GitHub Actions, least-privilege permissions, and OIDC federation instead of long-lived cloud keys where possible.
Chasing Level 4 first is a frequent error—reproducible builds are hard on PHP with extension variance, so nail Level 2 before iterating. Signed provenance from a compromised self-hosted runner is theatre; harden the builder before you sign. Skipping verification in deploy scripts means provenance in GitHub Releases helps auditors, not production. Confusing SLSA with compliance checkboxes is another trap—SLSA is technical evidence supporting ISO or SOC narratives, not a replacement. Neglecting WordPress and WooCommerce paths matters too: for WooCommerce 11.1 on WordPress 7.1, plugin zip integrity counts as much as container provenance. Rotate pipeline tokens quarterly and never echo credentials in workflow logs.
Yes. Nepal-based agencies often deploy to a single VPS with Rs 3,000–8,000 per month hosting (~USD 22–60). That setup can still reach Level 1–2 by building on GitHub Actions and deploying verified tarballs. The server never compiles releases—it only verifies and extracts. This reduces server load and improves security at once. Budget and staff size do not excuse Level 0 forever; they mean you prioritise ruthlessly. If you lack in-house DevOps capacity, treating supply-chain controls as part of ongoing support and Linux system administration is cheaper than recovering from a poisoned deploy. Pair pipeline work with Ubuntu server security baselines on the target host.
Yes. GitLab supports OIDC tokens and artifact metadata you can adapt to SLSA provenance formats. The official generators focus on GitHub, but the SLSA spec at slsa.dev is platform-neutral. You may need custom attestation steps on GitLab until native generators mature. Run slsa-verifier from a GitLab CI deploy stage the same way you would from a deploy hook. The enforcement point remains deploy-time verification—whether your pipeline runs on GitHub Actions or GitLab, abort the release if provenance does not match the expected source repo, tag, and builder identity.
On client projects I regularly see four weak points. Building on a developer laptop and uploading via FTP leaves no provenance at all. Self-hosted runners with shared credentials and no isolation undermine any signed attestation. Skipping lock file commits means CI cannot reproduce production dependencies. Treating Composer audit as sufficient while ignoring build tampering misses the core SLSA question—whether the deployed artifact matches what the pipeline built. Fix these before pursuing higher SLSA levels: pin GitHub Actions to SHAs, commit composer.lock, run composer install --no-dev --prefer-dist in CI, and restrict workflow permissions to least privilege.
For Docker-based Laravel queues or Horizon workers, publish images to a registry that supports OCI artifact attestations. Verify digest plus attestation before docker pull on production nodes. Pair this with distroless base images to shrink runtime attack surface after you trust the build. SLSA provenance confirms the image came from the expected pipeline; the SBOM tells you which packages changed inside it. On shared hosting without containers, tarball verification with slsa-verifier and sha256sum still works—simple beats nothing. The pattern is identical: generate provenance in CI, store it beside the artifact, and enforce verification before any production pull or extraction.
Pick one production app. Add a tagged release workflow on push to v* tags that emits provenance using the official SLSA GitHub generator at a pinned version. Commit composer.lock, pin actions to SHAs, build the release tarball in CI, and upload the SBOM beside provenance on each GitHub Release. Wire slsa-verifier into your deploy script so verification runs before PHP-FPM reload—matching a Deployer 7 zero-downtime flow where symlink swap happens only after checks pass. Read the SLSA v1.1 specification for terminology, align your internal runbook, and target Level 2 for client-facing apps. Strong supply-chain security with SLSA is incremental work, not a single tool install.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
