← Back to all projects

LEARN SOFTWARE SUPPLY CHAIN SECURITY MASTERY

In the past, security focused on the perimeter—keeping hackers out of the network. Today, the biggest threat is the **Supply Chain Attack**.

Learn Software Supply Chain Security: From Zero to Supply Chain Master

Goal: Deeply understand the integrity and provenance of software—how to prove that the code running in production is exactly what was written by a specific developer, built in a trusted environment, and hasn’t been tampered with at any point in the lifecycle. You will master the “Chain of Trust” using SLSA, Sigstore, and Attestations.

Why Software Supply Chain Security Matters

In the past, security focused on the “perimeter”—keeping hackers out of the network. Today, the biggest threat is the Supply Chain Attack.

Consider the SolarWinds attack (2020) or the XZ Utils backdoor (2024). In these cases, the “source” was compromised or the “build process” was hijacked to insert malicious code into legitimate updates. Organizations downloaded signed, “trusted” software that contained hidden backdoors.

Understanding this topic unlocks the ability to:

Prevent Tampering: Ensure a hacker can’t swap your binary with a malicious one.
Enforce Provenance: Prove exactly which CI/CD pipeline built a container.
Automate Trust: Replace manual security reviews with cryptographic proofs.
Meet Compliance: Satisfy rigorous standards like SLSA and SSDF.

The Attack Surface: From Code to Cloud

[ Developer ] --(1)--> [ Source Control ] --(2)--> [ Build System ] --(3)--> [ Artifact Registry ] --(4)--> [ Production ]
      ^                      |                        |                          |                        |
      |                      v                        v                          v                        v
   Compromised          Malicious               Build Script              Registry Poisoning         Deployment
   Account              Commits                 Injected                  (Image Swapping)           Override

Core Concept Analysis

1. The Immutable Identity (Hashing)

At the heart of everything is the Cryptographic Hash. If one bit changes in a 1GB file, the hash changes completely. This is our “Fingerprint.”

File A (v1.0) -> [ SHA-256 ] -> b94d27...
File A (v1.1) -> [ SHA-256 ] -> f3a10c...

2. The Digital Notary (Signing)

A hash proves integrity (it hasn’t changed), but not origin (who sent it). Digital Signatures (Asymmetric Cryptography) allow a producer to sign a hash with a Private Key. Anyone with the Public Key can verify that only the owner of the Private Key could have generated that signature.

[ Hash ] + [ Private Key ] -> [ Digital Signature ]
[ Signature ] + [ Public Key ] -> [ Verified/Rejected ]

3. Supply-chain Levels for Software Artifacts (SLSA)

SLSA (pronounced “salsa”) is a security framework. It’s a checklist of standards that increase in difficulty.

Level 1: Documentation of the build process (Provenance).
Level 2: Build happens on a hosted service; provenance is signed.
Level 3: The build platform is hardened against tampering.

4. Sigstore: The New Standard

Sigstore simplifies signing. It introduces three critical components:

Cosign: The tool for signing containers and blobs.
Rekor: A “Transparency Log” (like a blockchain for signatures) where all signatures are publicly recorded and immutable.
Fulcio: A Certificate Authority that issues temporary certificates based on OIDC (your GitHub/Google identity), removing the need to manage long-lived private keys.

5. SBOM (Software Bill of Materials)

Think of this as the “Ingredients List” for your software. It lists every library, version, and license used in your project, allowing you to quickly check if you are vulnerable to a new CVE.

PRODUCT: MyWebApp
INGREDIENTS:
  - openssl v1.1.1
  - react v18.2.0
  - log4j v2.14.1 (WARNING: VULNERABLE!)

Project 1: The Integrity Guardian (Hashing & Checksums)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: C
Alternative Programming Languages: Go, Rust, Python
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 1. The “Resume Gold”
Difficulty: Level 1: Beginner
Knowledge Area: Filesystem / Cryptography
Software or Tool: OpenSSL / Libcrypto
Main Book: “The Linux Programming Interface” by Michael Kerrisk

What you’ll build: A CLI tool that generates a “Manifest” for a directory (recursively), storing the SHA-256 hash of every file, and can later “Verify” the directory to detect any modified, added, or deleted files.

Why it teaches Supply Chain: This is the atomic unit of the supply chain. Before you sign anything, you must be able to uniquely identify it. You’ll learn that a “release” is just a collection of hashes.

Core challenges you’ll face:

Handling Large Files → Mapping to streaming data vs loading into memory
Recursive Directory Walking → Mapping to managing file descriptors and paths
Canonicalization → Mapping to why file paths/ordering matter for stable hashes

Key Concepts:

SHA-256: “Foundations of Information Security” Ch. 4
File I/O: “The Linux Programming Interface” Ch. 4 & 5

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic C (pointers, file I/O)

Real World Outcome

You will have a tool similar to sha256sum --check but recursive. You can run it on a source folder, generate a .manifest file, then change one character in a file and watch the tool flag it.

Example Output:

$ ./guardian manifest ./my_project > project.manifest
Generated hashes for 42 files.

$ echo "hacked" >> ./my_project/src/main.c

$ ./guardian verify project.manifest
[!] TAMPERED: ./my_project/src/main.c (Expected: a1b2..., Got: f9e8...)
[!] MISSING:  ./my_project/README.md
[!] UNKNOWN:  ./my_project/backdoor.py
Verification Failed.

The Core Question You’re Answering

“How can I prove that the 1GB zip file I just downloaded is exactly what the developer uploaded, bit-for-bit?”

Before you write any code, sit with this. If I change a single ‘0’ to a ‘1’ in a binary, the functionality could change from “Hello World” to “Delete All Files.” A hash is the only way to catch this without re-reading the whole code.

Concepts You Must Understand First

Cryptographic vs. Non-Cryptographic Hashes
- Why can’t we use CRC32 or Adler32 for security?
- What is a “Collision Attack”?
- Book Reference: “Foundations of Information Security” Ch. 4
File Buffering
- How do you hash a 10GB file without using 10GB of RAM?
- Book Reference: “The Linux Programming Interface” Ch. 13

Project 2: The Digital Notary (PKI Signing)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Go
Alternative Programming Languages: Rust, C++, Python
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold”
Difficulty: Level 2: Intermediate
Knowledge Area: PKI (Public Key Infrastructure)
Software or Tool: Cosign / OpenSSL
Main Book: “Foundations of Information Security” by Jason Andress

What you’ll build: A tool that generates an RSA or ECDSA key pair, signs the manifest from Project 1 with the private key, and verifies the signature using the public key.

Why it teaches Supply Chain: This introduces the “Identity” aspect. A hash proves the file is the same, but the signature proves who says it’s the same. This is the foundation of cosign.

Core challenges you’ll face:

Serialization → How do you store a signature? (Base64 vs Binary)
Key Formats → Understanding PEM, DER, and JWK formats.
Asymmetric Math → Why the public key can verify what the private key signed.

Key Concepts:

Asymmetric Encryption: “Foundations of Information Security” Ch. 4
Digital Signature Algorithm (DSA): “Computer Networks” Ch. 8

Real World Outcome

You’ll be able to distribute your software with a .sig file. Even if an attacker compromises your website and swaps the binary, they can’t swap the signature without your private key.

Example Output:

$ ./notary sign --key private.pem --file project.manifest --out project.sig
Signature generated and saved to project.sig

$ ./notary verify --public public.pem --file project.manifest --sig project.sig
[✓] Signature Verified: Source is Authentic.

The Core Question You’re Answering

“I have the hash, but how do I know the hash itself wasn’t replaced by an attacker?”

This is the “Who” question. Integrity (Project 1) is useless without Authentication (Project 2).

Project 3: The Transparency Inspector (Rekor Log)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Python
Alternative Programming Languages: Go, JavaScript
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Distributed Systems / Logs
Software or Tool: Sigstore Rekor
Main Book: “Designing Data-Intensive Applications” by Martin Kleppmann

What you’ll build: A tool that interacts with the Public Rekor server. It will take a hash of a file and search the global transparency log to find when it was signed and by whom.

Why it teaches Supply Chain: Key theft is common. If your key is stolen, the attacker can sign malicious code. A Transparency Log makes this visible. If you see a signature in the log that you didn’t create, you know you’re compromised.

Core challenges you’ll face:

Merkle Trees → Understanding how Rekor proves an entry exists without sending the whole log.
REST API Consumption → Interacting with complex, nested JSON responses from Sigstore.
Timestamping → Understanding the importance of an “Integrated Time” in a log.

Key Concepts:

Merkle Trees: “Grokking Algorithms” (Binary Trees section) or Rekor Documentation.
Log Transparency: “Designing Data-Intensive Applications” (Log-Structured storage).

Real World Outcome

You will verify that a container image (like nginx) was actually signed and is recorded in the public ledger.

Example Output:

$ ./inspector check-hash d3b07384...
[✓] Found in Rekor!
    Entry ID: 24296fb2...
    Timestamp: 2024-10-12 14:00:00 UTC
    Integrated Time: Yes
    Signer: dev-team@company.com
    Verification: Merkle Proof Valid

Project 5: The Ingredient List (SBOM Generator)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Python
Alternative Programming Languages: Go, Rust, Ruby
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Parsing / Dependency Management
Software or Tool: CycloneDX / SPDX
Main Book: “Code Complete” by Steve McConnell

What you’ll build: A tool that scans a project’s package.json, requirements.txt, or go.mod and generates a standard SBOM in CycloneDX JSON format. It should include licenses and hashes for every dependency.

Why it teaches Supply Chain: You can’t secure what you don’t know you have. An SBOM allows you to track transitive dependencies (the library your library uses). This is the key to solving “Log4Shell” style crises.

Core challenges you’ll face:

Transitive Dependencies → Following the tree to the bottom.
Standards Compliance → Ensuring your JSON matches the complex CycloneDX schema.
License Identification → Normalizing license names (MIT vs. MIT-License).

Key Concepts:

Dependency Graphs: “Algorithms, Fourth Edition” (Graph section).
SBOM Standards: official cyclonedx.org documentation.

Real World Outcome

You’ll generate a file that security teams can upload to vulnerability scanners to instantly see if your project is at risk.

Example Output:

$ ./bom_gen --dir ./my_app --format cyclonedx
[✓] Scanned 12 direct dependencies
[✓] Found 142 transitive dependencies
[✓] Generated bom.json (CycloneDX 1.5)

# Verify with an external tool
$ cyclonedx-cli validate --input-file bom.json
Success: File is a valid CycloneDX document.

The Core Question You’re Answering

“How do I know if I’m using a library that has a known critical vulnerability (CVE)?”

Most security breaches happen through unpatched third-party code. The SBOM is your early warning system.

Project 6: The Provenance Builder (SLSA Attestations)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Go
Alternative Programming Languages: Rust, Python
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 3: Advanced
Knowledge Area: Metadata / In-toto
Software or Tool: In-toto / GitHub Actions
Main Book: “The Linux Programming Interface” by Michael Kerrisk

What you’ll build: A tool that runs inside a CI/CD pipeline and generates a SLSA Provenance Attestation. This is a signed document that says: “This binary was built from Commit X, on Runner Y, using Command Z.”

Why it teaches Supply Chain: This is the heart of SLSA. It’s not enough to have a signed binary; you need to prove how it was built. An attacker might sign a binary they built on their own hacked laptop. Provenance proves it came from a trusted CI runner.

Core challenges you’ll face:

Environment Isolation → How to gather metadata without allowing the build process to fake it?
In-toto Statement Format → Learning the “Subject-Predicate” structure of attestations.
Signing Attestations → Using cosign to sign the metadata and attach it to an image.

Key Concepts:

In-toto Attestations: in-toto.io specs.
CI/CD Security: “How Linux Works” (Process isolation/Namespace sections).

Real World Outcome

You will have a “Birth Certificate” for your artifact. If someone tries to deploy a binary that doesn’t have a valid provenance, your production system will reject it.

Example Output:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [{"name": "my-app", "digest": {"sha256": "..."}}],
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "predicate": {
    "builder": {"id": "https://github.com/actions/runner"},
    "buildType": "https://github.com/actions/workflow@v1",
    "invocation": {"configSource": {"uri": "git+https://github.com/user/repo", "digest": {"sha1": "..."}}}
  }
}

Project 7: The Gatekeeper (Kubernetes Admission Controller)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Go
Alternative Programming Languages: Python (with Flask), Rust
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: Kubernetes / Webhooks
Software or Tool: Kubernetes / Cosign
Main Book: “Operating System Concepts” by Silberschatz

What you’ll build: A Kubernetes Validating Admission Webhook. Every time a new Pod is created, this controller intercepts the request, checks the container image for a Cosign signature, and rejects the deployment if the signature is missing or invalid.

Why it teaches Supply Chain: Security is only as strong as its enforcement. This is the “Verification” step. You’ve signed things (Project 2, 4, 6), now you are actually stopping unsigned code from running in production.

Core challenges you’ll face:

K8s Webhook Protocol → Handling TLS certificates for the webhook itself.
Remote Signature Lookups → Efficiently querying the registry for signatures without slowing down deployments.
Policy Fail-Open/Fail-Closed → Deciding what happens if the signature check fails.

Key Concepts:

Admission Controllers: official kubernetes.io documentation.
TLS/mTLS: “Computer Networks” (Security section).

Real World Outcome

When you try to kubectl apply an unsigned image, it will fail with a clear security error.

Example Output:

$ kubectl apply -f deployment.yaml
Error from server (Forbidden): admission webhook "verify-sig.example.com" denied the request: 
Image "malicious-user/backdoor:latest" is NOT SIGNED by a trusted authority.

Project 9: The Root of Trust (The Update Framework - TUF)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Go
Alternative Programming Languages: Python, Rust
Coolness Level: Level 5: Pure Magic
Business Potential: 5. The “Industry Disruptor”
Difficulty: Level 5: Master
Knowledge Area: Resilience / Cryptography
Software or Tool: TUF (The Update Framework)
Main Book: “Foundations of Information Security” (Security Models section)

What you’ll build: A minimal implementation of TUF. You will create a system with multiple roles (Root, Targets, Snapshot, Timestamp). Each role has its own keys, and the system must handle key rotation and “threshold” signing (e.g., 2 out of 3 admins must sign the root).

Why it teaches Supply Chain: Digital signatures aren’t enough if your key is stolen. TUF is the gold standard for “Compromise Resilience.” It teaches you how to design a system that stays secure even if some of its keys are compromised.

Core challenges you’ll face:

Delegation of Trust → How the Root role delegates authority to the Targets role.
Handling Freshness → Using the “Timestamp” role to prevent “Freeze Attacks” (where an attacker serves old but “valid” signatures).
Key Rotation → Updating the system’s trusted keys without breaking everything.

Key Concepts:

TUF Specification: theupdateframework.io.
Compromise Resilience: “Computer Networks” (Security / Key management).

Real World Outcome

You will have a repository that can survive a hacker stealing a developer’s key. The client will detect that the repository is still valid because the “Root” key (kept offline) hasn’t been compromised.

Example Output:

$ ./tuf client update
[✓] Root metadata verified.
[!] WARNING: 'targets.json' key was rotated. Verifying with new key...
[✓] Successfully updated artifact: 'app-v2.0'
[✓] Protection against: Replay, Freeze, and Mix-and-Match attacks.

Project 10: The Secure Mirror (Registry Proxy)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Go
Alternative Programming Languages: Rust, Python (FastAPI)
Coolness Level: Level 3: Genuinely Clever
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 3: Advanced
Knowledge Area: Networking / Proxies
Software or Tool: Docker Registry API / Cosign
Main Book: “Computer Networks” by Tanenbaum

What you’ll build: A caching proxy for container registries (like Docker Hub). When a client requests an image, the proxy doesn’t just download it; it checks for a signature and a high-quality SBOM. If the image is “untrusted” according to your company’s rules, the proxy blocks the download.

Why it teaches Supply Chain: This is “Security at the Edge.” Instead of checking signatures in Kubernetes (Project 7), you prevent untrusted images from even entering your network.

Core challenges you’ll face:

Streaming Proxying → Passing through large image layers efficiently.
Registry API Authentication → Handling Bearer tokens and credential passthrough.
Metadata Stitching → Associating the signature (which is a separate artifact in the registry) with the image.

Key Concepts:

HTTP Proxying: “Computer Networks” Ch. 7.
OCI Distribution Spec: official opencontainers.org documentation.

Real World Outcome

You can set docker pull my-proxy.internal/nginx and know that it will only succeed if the image is safe.

Example Output:

$ docker pull my-proxy.internal/bad-image:latest
Error response from daemon: 
Proxy Denied: Image 'bad-image' has no valid signature from 'trusted-vendor'.

Project 11: The CI/CD Hardener (GitHub Actions OIDC)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: YAML / Bash
Alternative Programming Languages: N/A (platform specific)
Coolness Level: Level 3: Genuinely Clever
Business Potential: 1. The “Resume Gold”
Difficulty: Level 2: Intermediate
Knowledge Area: DevOps / Identity
Software or Tool: GitHub Actions / Sigstore
Main Book: “How Linux Works” by Brian Ward

What you’ll build: A highly secure GitHub Actions workflow that uses OIDC to sign container images. It must be “Secretless”—meaning no AWS keys or Cosign keys are stored in GitHub Secrets. The workflow will use the GitHub-provided identity token to authenticate with AWS/GCP and Sigstore.

Why it teaches Supply Chain: Storing secrets in CI/CD is a major vulnerability (SolarWinds). By using OIDC, you eliminate the “Static Secret” problem. You’ll learn how cloud providers trust each other through short-lived tokens.

Core challenges you’ll face:

Trust Relationships → Configuring AWS/GCP to trust the GitHub OIDC provider.
Token Claims → Ensuring the token can only be used by a specific repo and branch.
Cosign Integration → Using the COSIGN_EXPERIMENTAL=1 (or modern equivalent) to trigger keyless signing.

Key Concepts:

Identity Federation: “Foundations of Information Security” Ch. 5.
OIDC Claims: official auth0.com/docs or GitHub docs.

Real World Outcome

A hacker steals your GitHub account but cannot find any AWS keys or signing keys in the settings, because they don’t exist!

Example Output:

# In GitHub Actions logs:
Generating ephemeral keys...
Requesting OIDC token from GitHub...
Authenticating with Fulcio using OIDC token...
[✓] Signature uploaded to Rekor.
[✓] Image signed as: https://github.com/my-org/my-repo/.github/workflows/build.yml@refs/heads/main

Project 12: The Forensic Examiner (Artifact Analysis)

File: LEARN_SOFTWARE_SUPPLY_CHAIN_SECURITY_MASTERY.md
Main Programming Language: Python
Alternative Programming Languages: Go, Rust
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 4: Expert
Knowledge Area: Forensics / Security Auditing
Software or Tool: Grype / Syft / Cosign
Main Book: “Practical Malware Analysis” by Michael Sikorski

What you’ll build: A tool that takes a “mystery” container image and performs a full forensic audit. It should:

Extract the SBOM.
Cross-reference every dependency with the CVE database.
Validate all signatures and attestations.
Calculate a “Security Score” based on SLSA levels.

Why it teaches Supply Chain: This is the “Consumer” side of the supply chain. You’ll learn how to analyze artifacts you didn’t build, teaching you what a “good” artifact looks like from the outside.

Core challenges you’ll face:

CVE Database Integration → Interacting with the OSV (Open Source Vulnerability) API.
Static Analysis → Looking for “Suspicious” patterns in the binary or image layers.
Scoring Heuristics → Deciding how much weight to give to a signature vs. an SBOM.

Key Concepts:

Vulnerability Management: “Foundations of Information Security” Ch. 10.
Static Analysis: “Practical Binary Analysis” Ch. 5.

Real World Outcome

You’ll be able to point your tool at any image on Docker Hub and get a “Nutrition Label” of its security.

Example Output:

$ ./examiner audit library/nginx:latest
[!] SECURITY AUDIT: nginx:latest
--------------------------------
- Signed: YES (Verified by Docker Inc.)
- SBOM:   PRESENT (CycloneDX)
- Vulnerabilities: 12 (2 Critical, 4 High)
- SLSA Level: Level 2 (Inferred)
- Trust Score: 68/100
- RECOMMENDATION: Block - Contains critical unpatched CVEs.

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor
1. Integrity Guardian	Level 1	Weekend	★★☆☆☆	★★★☆☆
2. Digital Notary	Level 2	1 Week	★★★☆☆	★★★☆☆
3. Transparency Inspector	Level 3	1 Week	★★★★☆	★★★★☆
4. Keyless Architect	Level 4	2 Weeks	★★★★★	★★★★★
5. Ingredient List	Level 2	1 Week	★★★☆☆	★★☆☆☆
6. Provenance Builder	Level 3	2 Weeks	★★★★☆	★★★☆☆
7. The Gatekeeper	Level 4	2 Weeks	★★★★★	★★★★☆
8. Policy Enforcer	Level 2	Weekend	★★★☆☆	★★★☆☆
9. Root of Trust (TUF)	Level 5	1 Month	★★★★★	★★★★★
10. Secure Mirror	Level 3	2 Weeks	★★★★☆	★★★★☆
11. CI/CD Hardener	Level 2	1 Week	★★★☆☆	★★★☆☆
12. Forensic Examiner	Level 4	2 Weeks	★★★★☆	★★★★☆

Recommendation

Where to start?

If you are new to security: Start with Project 1 (Integrity Guardian). It builds the mental model of “files as hashes” which is essential for everything else.
If you are a DevOps/Platform Engineer: Start with Project 11 (CI/CD Hardener). It provides the most immediate “real world” value and introduces OIDC, which is the future of the industry.
If you are a Cryptography/Systems fan: Dive straight into Project 9 (TUF). It is the most conceptually difficult but the most rewarding to get right.

Summary

This learning path covers Software Supply Chain Security through 12 hands-on projects. Here’s the complete list:

#	Project Name	Main Language	Difficulty	Time Estimate
1	The Integrity Guardian	C	Beginner	Weekend
2	The Digital Notary	Go	Intermediate	1 Week
3	Transparency Inspector	Python	Advanced	1 Week
4	Keyless Architect	Go	Expert	2 Weeks
5	Ingredient List (SBOM)	Python	Intermediate	1 Week
6	Provenance Builder	Go	Advanced	2 Weeks
7	The Gatekeeper (K8s)	Go	Expert	2 Weeks
8	Policy Enforcer	YAML	Intermediate	Weekend
9	Root of Trust (TUF)	Go	Master	1 Month
10	The Secure Mirror	Go	Advanced	2 Weeks
11	CI/CD Hardener	YAML/Bash	Intermediate	1 Week
12	Forensic Examiner	Python	Expert	2 Weeks

Recommended Learning Path

For beginners: Start with projects #1, #2, #5, #11 For intermediate: Jump to projects #3, #6, #8, #10 For advanced: Focus on projects #4, #7, #9, #12

Expected Outcomes

After completing these projects, you will:

Understand the mathematical foundation of hashing and digital signatures.
Be able to implement the Sigstore/SLSA stack in a professional environment.
Know how to automate the generation and verification of SBOMs and Attestations.
Understand the role of Transparency Logs (Rekor) in detecting key compromise.
Be capable of designing an end-to-end “Zero Trust” software delivery pipeline.

You’ll have built 12 working projects that demonstrate deep understanding of Software Supply Chain Security from first principles.