Scenario: Pusula Software’s compromised build pipeline
A backdoor turns up in a release the fictional Pusula Software shipped to customers; you investigate the pipeline, scope the impact, inform customers and rebuild the chain securely.
Level 401 · 13 lessons · 12 practice labs
Lessons
The alarm
- The first report: odd traffic from a customer
- Examining the release: different hash, different behaviour
- Forming the incident team and a communication plan
- Short task: build the timeline of the first six hours
Investigation
- Finding the change in the pipeline logs
- Tracing activity on the runner host
- Tracking the stolen token
- Blast radius: which releases, which customers
- Short task: list the affected releases with evidence
Recovery
- Revoking tokens and rebuilding in a clean environment
- Customer notification and security advisory
- Rebuilding the chain with signing and provenance
- Capstone: Pusula Software’s incident report and lasting remediation plan
Practice labs
- Extract the indicators from the customer’s report: Note the release number and the destination and time of the odd traffic from the report.
- Compare the published release with one built from source: Compare the digest of the image in the registry with a clean build and find the differing layer and file.
- Build the first six hours’ timeline and communication plan: Order the report, verification and decision moments with evidence, assign the incident team’s roles and write what customers are told and when.
- Find the suspicious run in the pipeline logs: Identify the run that produced the affected release, who triggered it and the runner used.
- Trace activity on the runner host: Find from process, file and session records on the runner the file added during the build and when it arrived.
- Track the stolen token and establish the blast radius: Extract where the token was used from audit logs and list the affected releases and customers with evidence.
- List the tokens and keys to revoke: Extract every credential the runner and pipeline could reach with owner and scope.
- Revoke the tokens and rebuild in a clean environment: Rotate every credential, rebuild the release on a fresh ephemeral runner and confirm the digest is consistent with source.
- Rebuild the chain with signing and provenance: Sign the new release, add a provenance attestation, make verification mandatory at deploy and show a fake artefact of the old kind is now refused.
- List what the customer notification must contain: Fill in affected releases, action to take and point of contact.
- Write the security advisory: Explain in plain language what happened, who is affected, how to check and which release is fixed.
- Prepare the incident report and lasting remediation plan: Report the timeline, root cause, impact and measures taken, and write five lasting improvements for six months with owner and date.
About this course
A backdoor turns up in a release the fictional Pusula Software shipped to customers; you investigate the pipeline, scope the impact, inform customers and rebuild the chain securely.
What you will learn
- The alarm
- Investigation
- Recovery
Prerequisites
You should have practised the topics of the same path up to level 301.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 401; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.