Where to start with software supply chain security

To start securing the software supply chain, spot your main problem among four (visibility, pipeline, artifact integrity, adoption decision), then apply the five actions of the week. This lesson is for developers, DevOps engineers, architects and security managers (CISOs) who do not know which section to enter by. It does not try to secure everything at once: it helps you start with the controls that really reduce risk, with a diagnosis in six questions, a prioritized checklist and a reference for the deadlines of the Cyber Resilience Act (CRA, the European regulation on the security of digital products).

Recent attacks explain this approach. XZ Utils, Polyfill.io and tj-actions showed that the software supply chain (all the components, tools and people that contribute to producing your software) is no longer limited to open source dependencies: it includes CI/CD pipelines (the automation that builds and ships your code), registries, third-party actions and published artifacts. For the full panorama of attack families, see the software supply chain threats. If an incident is already under way, go straight to responding to a supply chain incident.

Reminder from March 2025

The compromise of the tj-actions/changed-files action (March 2025) made pinning to a SHA and reducing CI/CD permissions baseline measures: secrets of repositories using the action ended up exposed in the logs of their pipelines.

What you will learn

• Identify your main problem among the four entry points.
• Measure your gaps with a self-assessment in six questions.
• Apply the five actions that reduce the attack surface in a week.
• Choose your priority reading according to your role.
• Place the CRA deadlines to plan your compliance.

What are the four entry points?

There are four entry points, one per symptom: lack of visibility on components, a fragile pipeline, artifact integrity not proven, adoption of dependencies without criteria. Choose the one whose symptom looks most like yours and read the cited guides first, in the order they appear.

You lack visibility on your components

Symptom: you do not know exactly what your artifacts are made of, nor what really runs in production. Start with the SBOM, the list of all the components of a piece of software, which Syft (in French) generates on the command line. Continue with VEX to qualify the vulnerabilities that are really exploitable, then with the xBOM, which extends the inventory to the build, the runtime, services, cryptography and AI.

Your pipeline is your weak point

Symptom: your CI/CD workflows use tagged actions, have overly broad permissions, or handle secrets without strict control. The starting point is the OWASP Top 10 CI/CD, which lists the ten major risks of pipelines. Add build environment hardening, source code governance to control who changes what, and Gitleaks to detect secrets in the code.

You want to guarantee the integrity of your artifacts

Symptom: impossible to prove that your container images really come from you, nor that they were built by your legitimate pipeline. Start with the signing ecosystem Sigstore and its tool Cosign, which signs and verifies images. Provenance attestations (signed statements of how an artifact was built) are the domain of in-toto and of the levels of the SLSA (in French) framework.

You must assess, decide and comply

Symptom: you adopt dependencies without clear criteria, you do not know how to assess your suppliers, or you must prepare for the CRA and NIS2 (the European directive on the security of networks and information systems). The OpenSSF Scorecard assesses the posture of a project, securing dependencies sets adoption criteria, Kusari (in French) automates go/no-go decisions, and the technical TPRM assesses your third-party suppliers.

How do you spot your gaps in six questions?

Answer each question of the table honestly: a "no" points to the section to consult in priority. The table follows the four entry points: visibility and decision each take two questions (build and production on one side, assessment of third parties and regulatory compliance on the other).

Question	If no, go to
Do you know what your artifacts are made of (SBOM)?	Inventories and BOMs
Do you know what really runs in production?	xBOM / OBOM
Can your pipelines be modified or have their secrets hijacked?	OWASP Top 10 CI/CD
Do you verify the integrity and provenance of your artifacts?	Sign, attest, verify
Do you assess your dependencies and suppliers before adopting them?	Assess and decide
Have you identified your CRA / NIS2 obligations?	CRA guide (in French)

Swipe to see more

What are the five actions to take this week?

These five actions immediately reduce the attack surface, with no overhaul: an SBOM, a vulnerability scan, pinned actions, a secret scan and a signing target. Each one produces a verifiable result, shown after the command.

1. Generate an SBOM on a critical project

   syft . -o cyclonedx-json > sbom.json && syft . -o table

   The table lists each package and its version: you will discover the transitive dependencies you did not know about.

2. Scan this SBOM for critical CVEs

   grype sbom:sbom.json --fail-on critical

   The command exits with an error if a Critical vulnerability is found, that is, a CVE (the public identifier of a known flaw) of maximum severity (tool: Grype, in French). Fix the Critical and High ones first.

3. Audit your CI/CD workflows

   Replace tagged actions with immutable SHAs, the one of the commit, with the version in a comment:

   # ❌ Dangerous: the v4 tag can be moved
   - uses: actions/checkout@v4
   
   # ✅ Safe: the commit SHA cannot be rewritten
   - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4.2.2

4. Enable secret scanning

   gitleaks detect --source . -v

   The command prints each secret found with its file and its commit. Plug it into a pre-commit hook (a script that runs before each commit) or into CI to block PRs containing secrets.

5. Define a simple rule

   "No unsigned production image will be deployed within 6 months."

   It is a clear objective that guides what comes next, notably signing with Cosign.

Which reading fits your role?

Each role acts on a different link of the chain, so priorities change. Open the tab that matches your job: it lists what falls within your scope this week and the guides to read first.

Developer

Your impact: you are on the front line to build good practices in from the moment you write code, with lockfiles (files recording the exact version of each dependency) and secrets kept out of the repository.

This week:

1. Pin your dependencies (exact versions in the lockfiles)
2. Install a Gitleaks pre-commit hook
3. Run syft . -o table to view your SBOM
4. Sign your commits with gitsign

Priority reading: SBOM, Gitleaks, gitsign (in French)

DevOps / SRE

Your impact: you control the pipelines and the infrastructure, the favorite targets of attackers, hence the permissions and the secrets of CI.

This week:

1. Audit and harden your CI/CD workflows (permissions, SHA, secrets)
2. Integrate SBOM + vulnerability scanning into CI
3. Plan image signing with Cosign
4. Evaluate Kyverno for verification in Kubernetes

Priority reading: OWASP Top 10 CI/CD, Hardening build, Cosign

Architect / CISO

Your impact: you define the standards and prepare compliance, hence the SBOM policy, the target SLSA level and the regulatory roadmap.

This week:

1. Define the SBOM policy: format (CycloneDX, a standard SBOM format), frequency, storage
2. Choose the target SLSA level per type of artifact
3. Evaluate GUAC (in French) vs Dependency-Track (in French) for centralization
4. Start the CRA roadmap (see the deadlines below)

Priority reading: xBOM, SLSA (in French), technical TPRM

What minimal checklist should you apply?

The checklist ranks actions by priority: handle the "Critical" rows before the "High" ones, and only move on to the "Medium" and "Advanced" levels once the first ones are ticked. The order follows the ratio between the effort required and the risk removed.

Action	Priority	Done
Generate an SBOM on a critical project	Critical	☐
Scan for vulnerabilities (Grype, Trivy)	Critical	☐
Enable Dependabot (in French) or GitLab Security	Critical	☐
Pin dependency versions	Critical	☐
Audit CI/CD permissions	High	☐
Pin GitHub Actions to a SHA	High	☐
Scan for secrets (Gitleaks)	High	☐
Sign images (Cosign)	Medium	☐
Generate SLSA attestations	Medium	☐
Deploy GUAC or Dependency-Track	Advanced	☐

Swipe to see more

Which CRA regulatory deadlines should you know?

The European Cyber Resilience Act (CRA) formalizes the importance of the SBOM and of documenting the software chain, with two dates to remember:

• 11 September 2026: the obligations to report actively exploited vulnerabilities and serious incidents have applied since this date;
• 11 December 2027: the main obligations apply, including the technical documentation and the SBOM.

Starting now leaves you until 11 December 2027 to structure your processes without rushing. The detail is in the CRA guide (in French).

NIS2 and beyond

The NIS2 directive requires risk management of the supply chain without prescribing a specific format. Having an SBOM and an assessment of third parties (TPRM, third-party risk management) puts you in a favorable position.

Key points

• Four starting problems: visibility, pipeline, artifact integrity, adoption decision. Choose yours, not all of them at once.
• The five actions of the week: SBOM, CVE scan, actions pinned to a SHA, secret scan, signing rule.
• A GitHub Action is pinned to the commit SHA, with the version in a comment.
• Work through the checklist by priority: Critical, then High, then Medium.
• The main obligations of the CRA, including the technical documentation and the SBOM, apply from 11 December 2027.

Knowledge check

Check that the essentials of this lesson are in place. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

6 questions

6 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

×

See in the glossary →