Secure CI/CD and Software Supply-Chain Assurance
Create a continuous integration and delivery pipeline for your Game of Life implementation. The pipeline should provide automated evidence that a submitted version has been built, tested, analysed, and packaged through an identifiable and repeatable process.
Two layers work together: repository controls decide what is allowed to be merged, and the pipeline produces automated evidence about each change. You choose which stages to include; the brief lists a menu.
Each box should answer a question you can state in the report: what threat or failure does this stage address, and what evidence does it leave behind?
Your pipeline should run when changes are proposed or merged and should include an appropriate selection of the following controls:
- compilation and automated testing;
- race, concurrency, or static analysis;
- dependency and known-vulnerability scanning;
- checks for accidentally committed credentials or secrets;
- production of a Software Bill of Materials (SBOM);
- retention of test and scanning results;
- creation of a versioned deployment artefact;
- generation of build provenance; and
- signing and verification of release artefacts.
Define a security policy that determines which findings should:
- fail the pipeline immediately;
- prevent a change from being merged;
- prevent an artefact from being released;
- generate a warning requiring review; or
- be accepted temporarily as a documented exception.
For each controlled problem in the brief, decide what your pipeline should do and why. Click a row to see where in the pipeline it should surface. Your choices appear as a table you can copy into your report. The choices are yours to justify; there is no single right answer.
| Controlled problem | Policy outcome | Why? (and, for exceptions, who approves and when it expires) |
|---|---|---|
| A failing test | ||
| A concurrency error detectable by your selected tools | ||
| A deliberately vulnerable test dependency | ||
| A simulated secret in a designated test file | ||
| An unsigned or modified build artefact | ||
| A change that attempts to bypass the expected review process |
Configure the repository workflow so that important changes are reviewed before integration. Your design should consider:
- protected branches;
- pull-request review;
- restricted workflow permissions;
- automated dependency updates; and
- secure handling of pipeline secrets.
Ask of each arrow: who or what can use this path, with which permissions, and what stops it being abused? The brief's list (protected branches, review, restricted permissions, automated dependency updates, secret handling) maps to the boxes above.
Demonstrate the operation of the pipeline by introducing a controlled set of problems. These may include:
- a failing test;
- a concurrency error detectable by the selected tools;
- a deliberately vulnerable test dependency;
- a simulated secret in a designated test file;
- an unsigned or modified build artefact; and
- a change that attempts to bypass the expected review process.
Do not introduce real credentials or deploy intentionally vulnerable artefacts to a public or production environment.
For each scenario, record:
- whether the pipeline detects the problem;
- where the finding is reported;
- whether the configured policy permits or blocks the change or release; and
- how the issue could be remediated.
Verify that a valid signed artefact can be traced to its source revision, and that modifying the artefact causes signature or integrity verification to fail.
- 1 A malicious change or compromised dependency enters before the build.
- 2 The build service itself is compromised, so it builds something other than the source.
- 3 The artefact is altered after it is built.
- 4 The signing key or an administrator account is compromised.
- 5 Verification is skipped, or checks the wrong thing.
Which of these does your design stop, which does it only make detectable, and which remain residual risks? The brief asks you to discuss residual risks such as compromised dependencies, build services and administrator accounts.
Measure the effect of the security checks on the engineering workflow. You may consider:
- total pipeline duration;
- time added by individual assurance stages;
- number and severity of findings;
- false-positive or unactionable findings;
- time required to diagnose and remediate a controlled issue; and
- reproducibility of artefacts across repeated builds.
Enter the time each stage takes (from your pipeline run logs) and mark which are assurance stages. The chart shows where time goes and how much the assurance stages add. The example numbers below are not measurements; replace them with yours.
| Stage | Seconds | Assurance stage? |
|---|---|---|
| Set-up and checkout | ||
| Build | ||
| Automated tests | ||
| Race detection | ||
| Static analysis | ||
| Dependency scan | ||
| Secret scan | ||
| SBOM generation | ||
| Package artefact | ||
| Provenance and signing | ||
| Verification |
Enter some times to see the chart.
Time is only one cost. The brief also asks about findings, false positives, time to diagnose and fix, and reproducibility. Consider how you will record those too.
In your report:
- describe the pipeline stages and the threat or failure each addresses;
- explain the repository permissions and branching strategy;
- justify the selected enforcement policy;
- provide evidence from successful and unsuccessful pipeline executions;
- trace one controlled vulnerability through discovery, triage, remediation, and verification;
- explain how provenance and signing support artefact integrity;
- discuss residual risks, including compromised dependencies, build services, or administrator accounts; and
- evaluate the balance between assurance, usability, execution time, and developer productivity.
Choose one controlled problem and keep screenshots, logs or run links for all four steps. That single worked example is the evidence the brief asks for.
- Baseline pipelineBuild and test automatically on every proposed change. Get this green first.
- Add analysisRace detection and static analysis. See what they report on your real code.
- Add dependency and secret scanningLearn what is actionable and what is noise before you set any policy.
- Produce and keep evidenceSBOM, test results and scan results retained for each run.
- Create the release artefactVersioned, with provenance, signed, and verified in a separate step.
- Lock down the repositoryProtected branches, review, minimal permissions, secret handling, dependency updates.
- Write the policyUse the findings from steps 2 to 3 to decide what fails, blocks, warns or is excepted.
- Introduce controlled problemsOne at a time, recording detection, location, policy outcome and remediation. Never real secrets, never deploy vulnerable artefacts.
- Measure and write upPipeline cost, findings, reproducibility, residual risks and trade-offs.
| Report bullet | Evidence to bring |
|---|---|
| Pipeline stages and the threat each addresses | A stage-by-threat table, with the pipeline diagram |
| Repository permissions and branching strategy | Your workflow diagram and the settings that implement it |
| Enforcement policy | The policy table with a justification for each decision |
| Successful and unsuccessful pipeline runs | Run links or logs for each controlled problem and for a clean run |
| One vulnerability traced end to end | The four-step trace above |
| Provenance and signing | Verification success, then failure after modifying the artefact |
| Residual risks | The five numbered risks on the chain-of-custody diagram, with your position on each |
| Assurance versus productivity | Cost chart and findings data, with your evaluation |