ILLUSTRATIVE TEACHING EXAMPLE / NOT AN EXAM SOLUTION

A safer release.
Evidence you can explain.

Imagine your practice company is about to release an application. A security check finds a known vulnerable dependency. Your task: stop that release, update the dependency and show what changed.

This is a simplified fictional example created to explain the work. All results below are simulated, not measured scan results or a student submission.

01 · Understand the risk

The problem

The delivery pipeline can publish an application even when its dependency check reports a high-severity finding. A green build alone doesn’t tell us whether that risk was resolved.

Your decision: make the security check a required step before the release job can run.

02 · Apply a defence

Make the release depend on the check

The security job must fail when a finding meets the agreed threshold. The release job depends on that job passing. Protect the workflow so changes are reviewed.

security_check:
  - inspect dependencies
  - fail if the agreed threshold is exceeded

release:
  requires: security_check passes
  - publish the application

This is explanatory pseudocode, not a ready-to-run GitHub Actions file. The actual tool, threshold and exception process need to fit the project.

03 · Test both outcomes

Show that the control works

Simulated evidence for this teaching example
Test	Expected behaviour	Illustrative result
Keep the known vulnerable dependency	Check fails; release does not run	Release blocked
Update the dependency; rerun checks	Check passes; release may proceed	Release allowed
Security check cannot complete	Release stays blocked	Release blocked

A complete project would attach actual run links, commit identifiers and test output. None are invented here.

04 · Read the example findings report

Finding: release not gated on security checks

Scope: the fictional training application’s delivery workflow.

Risk: a known vulnerable dependency could reach the published application despite a detected finding.

Change: require a successful security job before publishing. Update the example dependency and retain review requirements.

Validation: test a blocked release, an allowed release and an unavailable check. The table above illustrates the evidence to collect.

Limits: passing a dependency check does not establish that the application is secure. Application behaviour, access controls and AI features need their own testing.

What you can explain: why the check matters, how it affects a release, what your tests prove and what they do not prove.

Download the example report (.md) ↓

Build your own evidence during the bootcamp.

The programme includes four portfolio projects across cloud, delivery pipelines, threat modelling and AI security. This example shows the style of reasoning; the full tasks and assessment use their own requirements.

Review enrolment →Explore the programme →

A safer release.Evidence you can explain.