KCSA — Software Supply Chain Security
What Is a Software Supply Chain?
A software supply chain is everything that goes into building and deploying your application — from the source code you write, to the libraries you pull in, to the build tools that compile it, to the pipeline that deploys it.
Source Code → Dependencies → Build System → Container Image → Registry → Deployment
An attack on any link in this chain can compromise your production environment. And unlike a direct attack on your cluster, supply chain attacks are insidious — they often come from trusted sources.
If an attacker can inject malicious code into a popular library you depend on, your build pipeline will happily compile it, package it into an image, push it to your registry, and deploy it to production — all without any alarms.
Why Supply Chain Security Matters for KCSA
Supply chain security has become one of the most important topics in cloud native security. High-profile attacks have shown that:
- Trusting dependencies blindly is dangerous
- Build systems are high-value targets
- Verification and transparency are essential
The KCSA exam tests your understanding of supply chain concepts, frameworks, and tools — not just Kubernetes-specific configurations.
Real-World Supply Chain Attacks
Understanding past attacks helps you grasp why these security practices exist.
Notable Attacks
| Attack | Year | What Happened | Impact |
|---|---|---|---|
| SolarWinds (Sunburst) | 2020 | Attackers compromised SolarWinds’ build system and injected malicious code into the Orion software update | 18,000+ organizations affected, including US government agencies |
| Codecov | 2021 | Attackers modified Codecov’s Bash Uploader script to exfiltrate CI/CD environment variables (secrets, tokens) | Affected thousands of CI/CD pipelines; secrets leaked |
| Log4Shell (CVE-2021-44228) | 2021 | Critical RCE vulnerability in Log4j, a ubiquitous Java logging library | Virtually every Java application was affected; exploited within hours |
| ua-parser-js | 2021 | Popular npm package compromised — malicious version installed crypto miners and password stealers | Millions of weekly downloads affected |
| event-stream | 2018 | A new maintainer of a popular npm package injected code targeting cryptocurrency wallets | Users of the package unknowingly ran malicious code |
| 3CX | 2023 | Desktop VoIP app compromised through a supply chain attack on a traded dependency | Supply chain attack on a supply chain — a cascading compromise |
Patterns to Notice
- ✅ Attacks target trusted sources — libraries, build tools, update mechanisms
- ✅ One compromised dependency can affect millions of users
- ✅ Detection is difficult — the malicious code comes from a “trusted” source
- ✅ Build systems are high-value targets — if you compromise the build, you compromise everything downstream
SBOM — Software Bill of Materials
An SBOM is a formal, machine-readable list of all components (libraries, packages, modules) that make up a piece of software.
Think of it like the ingredient list on food packaging — it tells you exactly what’s inside, so you can check for allergens (vulnerabilities).
Why SBOMs Matter
- Transparency — know exactly what’s in your software
- Vulnerability response — when a new CVE is published (like Log4Shell), you can instantly check if you’re affected
- Compliance — regulatory frameworks increasingly require SBOMs (e.g., US Executive Order on Cybersecurity)
- Audit trail — prove what was deployed and when
SBOM Formats
| Format | Maintained By | Key Features |
|---|---|---|
| SPDX | Linux Foundation | ISO standard (ISO/IEC 5962:2021); widely adopted; supports licensing and security info |
| CycloneDX | OWASP | Designed for security use cases; lightweight; supports VEX (Vulnerability Exploitability eXchange) |
Both formats are valid and widely used. The KCSA exam may ask you to identify SBOM formats — remember SPDX (Linux Foundation) and CycloneDX (OWASP).
SBOM Generation Tools
| Tool | Description |
|---|---|
| Syft (Anchore) | Generates SBOMs from container images, filesystems, and source code |
| Trivy | Can generate SBOMs in SPDX and CycloneDX formats in addition to vulnerability scanning |
| cdxgen | CycloneDX generator for multiple ecosystems |
| Docker Scout | Generates SBOMs as part of image analysis |
Example: Generating an SBOM with Syft
# Generate an SBOM for a container image in SPDX format
syft nginx:1.25 -o spdx-json > nginx-sbom.spdx.json
# Generate in CycloneDX format
syft nginx:1.25 -o cyclonedx-json > nginx-sbom.cdx.json
SLSA Framework — Supply-chain Levels for Software Artifacts
SLSA (pronounced “salsa”) is a framework that defines increasing levels of supply chain security.
SLSA Levels
| Level | Name | Requirements | What It Prevents |
|---|---|---|---|
| Level 0 | No guarantees | No SLSA compliance | Nothing — you’re on your own |
| Level 1 | Provenance exists | Build process generates provenance metadata documenting how the artifact was built | Lack of transparency |
| Level 2 | Hosted build platform | Build runs on a hosted, authenticated service; provenance is signed | Tampering after build |
| Level 3 | Hardened builds | Build platform provides strong isolation between builds; provenance is non-falsifiable | Compromised build environments |
| Level 4 | Dependencies verified | All dependencies meet SLSA Level 3+ requirements; two-party review of all changes | Compromised dependencies |
Key SLSA Concepts
- Provenance — metadata about how an artifact was built (source repo, build system, commands, inputs)
- Attestation — a signed statement about an artifact (e.g., “this binary was built from commit abc123 on GitHub Actions”)
- Build platform — the system that builds your software (GitHub Actions, Jenkins, Tekton)
- Isolation — build jobs are isolated from each other so one compromised build can’t affect another
For the KCSA exam, understand the general progression of SLSA levels: from “no guarantees” (Level 0) to “fully verified” (Level 4). You don’t need to memorize every detail, but know the key idea: each level adds more trust to the build process.
Dependency Scanning and Management
Most modern software consists of 90%+ third-party code. Managing those dependencies is critical.
Types of Dependencies
| Type | Description | Risk |
|---|---|---|
| Direct | Libraries you explicitly import | You chose them, but they may have vulnerabilities |
| Transitive | Dependencies of your dependencies | You may not even know they exist — hidden risk |
| Build-time | Tools used only during build (compilers, linters) | Can inject malicious code during build |
| Runtime | Libraries loaded at execution time | Directly in the attack path |
Dependency Security Practices
- ✅ Pin dependency versions — don’t use floating ranges (
^,~,*) - ✅ Use lock files (
package-lock.json,go.sum,Pipfile.lock) — ensure reproducible builds - ✅ Scan for vulnerabilities — use tools like
npm audit,pip-audit,govulncheck - ✅ Automate updates — use Dependabot or Renovate to get timely patch PRs
- ✅ Review transitive dependencies — tools like
npm lsorgo mod graphshow the full tree - ✅ Remove unused dependencies — less code = less attack surface
Build Provenance and Attestation
Provenance answers the question: “How was this artifact built, and from what source?”
What Provenance Includes
| Field | Description |
|---|---|
| Source | Git repository, commit hash, branch |
| Builder | Build system (GitHub Actions, Jenkins, Tekton) |
| Build instructions | Dockerfile, build script, Makefile |
| Inputs | Dependencies, base images, build arguments |
| Output | Image digest, artifact hash |
| Timestamp | When the build occurred |
| Identity | Who or what triggered the build |
Attestation
An attestation is a cryptographically signed statement that ties provenance to a specific artifact. It says:
“I, the build system, certify that image sha256:abc123... was built from source repo X, commit Y, at time Z.”
Tools for creating and verifying attestations:
- cosign — can attach attestations to container images
- in-toto — framework for attestation across the entire supply chain
- SLSA GitHub Generator — generates SLSA provenance for GitHub Actions builds
In-toto Framework
in-toto is a framework that secures the entire software supply chain by defining what steps should occur and verifying that they actually did.
How in-toto Works
- Layout — a project owner defines the expected steps in the supply chain (e.g., “code must be reviewed, then built, then tested, then signed”)
- Links — each step produces a signed record (metadata) of what happened
- Verification — a client verifies that all required steps were completed by authorized parties
Example Supply Chain with in-toto
Step 1: Developer writes code → Signed link (by developer)
Step 2: Code reviewed by reviewer → Signed link (by reviewer)
Step 3: CI builds the artifact → Signed link (by CI system)
Step 4: QA tests the artifact → Signed link (by QA system)
Step 5: Artifact is signed → Signed link (by release manager)
If any step is missing or performed by an unauthorized party, in-toto verification fails.
in-toto provides end-to-end verification of the supply chain — it doesn’t just check one step, it ensures the entire pipeline was followed correctly.
CI/CD Pipeline Security Practices
Your CI/CD pipeline is the bridge between source code and production. It’s also a prime target for attackers.
CI/CD Security Practices
| Practice | Description |
|---|---|
| Pin action versions | Use commit SHAs instead of tags for GitHub Actions / pipeline steps |
| Limit secrets access | Only expose secrets to the steps that need them |
| Ephemeral build environments | Use fresh, isolated build environments for every build |
| Scan in the pipeline | Run image scanning, dependency scanning, SAST, and SBOM generation |
| Sign artifacts | Sign images and generate attestations after a successful build |
| Fail on critical findings | Block deployments if scanning finds critical vulnerabilities |
| Audit pipeline changes | Review changes to CI/CD configuration files (they’re code too) |
| Use OIDC for auth | Use OpenID Connect for short-lived credentials instead of long-lived secrets |
| Separate build and deploy | Use different credentials and permissions for build vs. deploy stages |
| Monitor pipeline execution | Alert on unusual build times, unexpected steps, or new dependencies |
Pipeline Security Flow
Source Code
↓
[SAST + Dependency Scan] ← Fail if critical issues found
↓
[Build Image]
↓
[Scan Image (Trivy)] ← Fail if critical CVEs found
↓
[Generate SBOM (Syft)]
↓
[Sign Image (cosign)]
↓
[Push to Private Registry]
↓
[Generate Attestation]
↓
[Deploy to Cluster] ← Admission controller verifies signature
Key Takeaways for the Exam
- A software supply chain includes everything from source code to dependencies to build systems to deployment
- SolarWinds, Codecov, and Log4Shell are key examples of supply chain attacks — know the patterns
- SBOM = Software Bill of Materials — a list of all components; formats are SPDX (Linux Foundation) and CycloneDX (OWASP)
- SLSA = Supply-chain Levels for Software Artifacts — 4 levels of increasing supply chain security
- Provenance = metadata about how an artifact was built; attestation = signed statement tying provenance to an artifact
- in-toto provides end-to-end supply chain verification by defining expected steps and verifying signed links
- Pin dependency versions and use lock files for reproducible, secure builds
- Transitive dependencies are a hidden risk — you may not know they exist, but they’re in your supply chain
- CI/CD pipelines should scan, sign, generate SBOMs, and fail on critical findings
- cosign (Sigstore) is the tooling for image signing; Syft / Trivy for SBOM generation
Next up: Artifact Repository & Registry Security — securing where your built artifacts are stored and distributed from.
