A security review at the end of a release can discover problems after they are expensive to fix. DevSecOps brings security work into ordinary development and operations: review access, check dependencies and configuration, protect the build, and decide what may be deployed.
Start with the route your software takes from source code to a running application. Who can change each step, and what would show that an image came from the intended build? A vulnerability scan is one useful check. It does not prove the entire application is safe or that the build system was trusted.
Try it in a lab
Map a small delivery workflow and identify who can change source, modify the build and promote an artifact. Add one relevant check and define what happens when it fails.
Check your understanding
Trace a deployed artifact back to its source revision and build identity. Explain how an exception is recorded and revisited rather than silently bypassed.
Before you start
Do not make a pipeline depend on publishing sensitive scan output. Distinguish a fixable finding from a false positive with documented evidence.
Read the official guide
Use the SLSA specification for source and build security requirements, provenance formats and artifact-verification guidance. Record the versions and results of your own exercise. This page proposes a learning activity; it does not report a Kubedex test.
This is a newly written study reference at an address from the original Kubedex course outline. The original lesson was not recovered. It does not include course enrolment, progress tracking or a certificate.
Sources & further reading
Spotted something that needs another look?
Help improve this page →