Cheat notes · Pipeline surfaces
Pipeline surfaces: cheat notes
Every module on one page, cut to what you need to remember: the idea, the commands, the pitfalls and a few questions to test yourself. Made for review after you have done the course, not instead of it. Back to the course.
00 Orientation
This module only · Full module
The idea
Map the delivery path and name the seven surfaces before changing them. A running local checkout service, a connected public repository, and seven open surface entries.
Remember
- Surface: A surface is a point where data crosses a trust boundary.
- Trust: A capability is permission to change code, publish an artifact, or reach data.
- Evidence: Orientation: a label is not evidence
- Owner: keep one team accountable for the control and the retest.
Pitfalls
- A green workflow does not prove the artifact or its inputs are trustworthy.
- A policy file does not prove that the same attack path is stopped.
Commands
./scripts/validate.sh | Check the evidence files are present without running learner code. |
git log --oneline -5 | Trace recent changes that may affect the path. |
Test yourself
Answer in your head first, then open the answer.
What is the objective?
A surface is a point where data crosses a trust boundary.
What do you test?
Create the learner repo, inspect the seeded app and workflows, and open docs/attack-surface.yaml.
What proves the control holds?
A running local checkout service, a connected public repository, and seven open surface entries.
Where module 00 leaves you: A running local checkout service, a connected public repository, and seven open surface entries.
01 Secrets in Git
This module only · Full module
The idea
Trace how a secret enters Git history and how rotation limits its value. S01 has a test, prevention and detection evidence, and a rotation record.
Remember
- Surface: History keeps earlier file contents even after a later deletion.
- Trust: A scanner finding does not revoke a credential.
- Evidence: Break it: a secret-shaped value returns in history
- Owner: keep one team accountable for the control and the retest.
Pitfalls
- A green workflow does not prove the artifact or its inputs are trustworthy.
- A policy file does not prove that the same attack path is stopped.
Commands
./scripts/validate.sh | Check the evidence files are present without running learner code. |
git log --oneline -5 | Trace recent changes that may affect the path. |
Test yourself
Answer in your head first, then open the answer.
What is the objective?
History keeps earlier file contents even after a later deletion.
What do you test?
Run the repository scan, inspect the seeded canary rule and hook, remove the canary from history, rotate the lab value, and record S01.
What proves the control holds?
S01 has a test, prevention and detection evidence, and a rotation record.
Where module 01 leaves you: S01 has a test, prevention and detection evidence, and a rotation record.
02 Workflows and artifacts
This module only · Full module
The idea
Follow untrusted text and artifacts across low and high privilege jobs. S02 is covered, jobs start read-only, and the privileged report job never runs downloaded files.
Remember
- Surface: The Actions cache is shared by runs on the same branch scope; untrusted pull request caches are scoped to their merge ref.
- Trust: A read-only token does not make an artifact trustworthy.
- Evidence: Break it: a main-branch cache carries an unreviewed marker
- Owner: keep one team accountable for the control and the retest.
Pitfalls
- A green workflow does not prove the artifact or its inputs are trustworthy.
- A policy file does not prove that the same attack path is stopped.
Commands
./scripts/validate.sh | Check the evidence files are present without running learner code. |
git log --oneline -5 | Trace recent changes that may affect the path. |
Test yourself
Answer in your head first, then open the answer.
What is the objective?
The Actions cache is shared by runs on the same branch scope; untrusted pull request caches are scoped to their merge ref.
What do you test?
Test issue-title interpolation and the workflow_run report consumer, restrict permissions, treat artifacts as JSON data, and audit workflows with zizmor.
What proves the control holds?
S02 is covered, jobs start read-only, and the privileged report job never runs downloaded files.
Where module 02 leaves you: S02 is covered, jobs start read-only, and the privileged report job never runs downloaded files.
03 AI agents in CI
This module only · Full module
The idea
Separate untrusted instructions from the tools and rights an agent can reach. The agent has read-only access and an allowlisted tool belt; a separate job applies only validated output.
Remember
- Surface: The stand-in follows ACTION lines deterministically. It runs only in the learner repository.
- Trust: Model output is input from whoever controls the prompt.
- Evidence: Break it: an issue asks for an unapproved label
- Owner: keep one team accountable for the control and the retest.
Pitfalls
- A green workflow does not prove the artifact or its inputs are trustworthy.
- A policy file does not prove that the same attack path is stopped.
Commands
./scripts/validate.sh | Check the evidence files are present without running learner code. |
git log --oneline -5 | Trace recent changes that may affect the path. |
Test yourself
Answer in your head first, then open the answer.
What is the objective?
The stand-in follows ACTION lines deterministically. It runs only in the learner repository.
What do you test?
Use the deterministic local stand-in against a harmless issue fixture, then remove its write access and secret, and validate its output in a model-free job.
What proves the control holds?
The agent has read-only access and an allowlisted tool belt; a separate job applies only validated output.
Where module 03 leaves you: The agent has read-only access and an allowlisted tool belt; a separate job applies only validated output.
04 Borrowed code
This module only · Full module
The idea
Treat actions, packages, scanners and build tools as code you inherit. S04 records pinned workflow dependencies, a lockfile and a consumer policy that rejects a fresh package.
Remember
- Surface: The sample package registry is local and uses disposable lab data.
- Trust: A lockfile fixes resolution but does not prove the publisher is safe.
- Evidence: Break it: a tag moves to a different commit
- Owner: keep one team accountable for the control and the retest.
Pitfalls
- A green workflow does not prove the artifact or its inputs are trustworthy.
- A policy file does not prove that the same attack path is stopped.
Commands
./scripts/validate.sh | Check the evidence files are present without running learner code. |
git log --oneline -5 | Trace recent changes that may affect the path. |
Test yourself
Answer in your head first, then open the answer.
What is the objective?
The sample package registry is local and uses disposable lab data.
What do you test?
Inspect the local Verdaccio exercise, observe the seeded dependency and token, pin actions by full commit, verify package signatures and set a release cooldown.
What proves the control holds?
S04 records pinned workflow dependencies, a lockfile and a consumer policy that rejects a fresh package.
Where module 04 leaves you: S04 records pinned workflow dependencies, a lockfile and a consumer policy that rejects a fresh package.
05 Build a verifiable image
This module only · Full module
The idea
Connect source, build inputs, vulnerability findings and image identity. S05 is recorded as covered with the image digest and provenance evidence.
Remember
- Surface: A digest names image bytes; a tag is a movable label.
- Trust: Provenance explains how an artifact was built but does not make untrusted source safe.
- Evidence: Break it: the tag points to a different image
- Owner: keep one team accountable for the control and the retest.
Pitfalls
- A green workflow does not prove the artifact or its inputs are trustworthy.
- A policy file does not prove that the same attack path is stopped.
Commands
./scripts/validate.sh | Check the evidence files are present without running learner code. |
git log --oneline -5 | Trace recent changes that may affect the path. |
Test yourself
Answer in your head first, then open the answer.
What is the objective?
A digest names image bytes; a tag is a movable label.
What do you test?
Build checkout, scan its filesystem and image, publish a digest from a tagged release, and attach provenance to that digest.
What proves the control holds?
S05 is recorded as covered with the image digest and provenance evidence.
Where module 05 leaves you: S05 is recorded as covered with the image digest and provenance evidence.
06 Verify at admission
This module only · Full module
The idea
Check signatures and signer identity when an image enters the cluster. Admission accepts the exact release identity and refuses the same image signed by another workflow.
Remember
- Surface: A valid signature from the wrong workflow is still the wrong signer.
- Trust: A broad identity pattern grants trust to future repositories too.
- Evidence: Break it: one wildcard admits another signer
- Owner: keep one team accountable for the control and the retest.
Pitfalls
- A green workflow does not prove the artifact or its inputs are trustworthy.
- A policy file does not prove that the same attack path is stopped.
Commands
./scripts/validate.sh | Check the evidence files are present without running learner code. |
git log --oneline -5 | Trace recent changes that may affect the path. |
Test yourself
Answer in your head first, then open the answer.
What is the objective?
A valid signature from the wrong workflow is still the wrong signer.
What do you test?
Sign the release digest with keyless identity, install the image policy, try a mismatched signer, and record S06.
What proves the control holds?
Admission accepts the exact release identity and refuses the same image signed by another workflow.
Where module 06 leaves you: Admission accepts the exact release identity and refuses the same image signed by another workflow.