DevSecOps Trainer

The problem statement before the toolchain. Why security-at-the-end fails against a daily release cadence, what a security gate is, and the vocabulary the rest of the course depends on — analysis types, defect classification and the standards findings are mapped to.

Topics: What DevSecOps is, and what it is not · DevSecOps as a property of the delivery pipeline · Static, dynamic and interactive analysis compared · Secure code review and where humans still matter · Defect classification and severity models · OWASP Top 10 and the OWASP project landscape · CWE and mapping findings to weaknesses

• Assignments: (1) Classify twenty sample findings by analysis type and CWE; (2) Map an existing release process and mark every point where a security decision is made implicitly
• Capstone: Write a one-page assessment of a real delivery process identifying the three highest-value places to insert a control

A working refresher on the delivery machinery, because you cannot instrument a pipeline you do not understand. Continuous integration, delivery and deployment as distinct things, the shape of a typical build graph, and the deployment strategies that determine how quickly a bad release can be pulled back.

Topics: DevOps principles and the delivery value stream · Continuous integration, delivery and deployment distinguished · Anatomy of a typical CI/CD pipeline · Build, test, package, promote and deploy stages · Deployment strategies: rolling, blue-green, canary · Artifact repositories and promotion between environments · Where each security control attaches to the build graph

• Assignments: (1) Build a baseline pipeline for a sample application with no security controls in it; (2) Draw the build graph and annotate every stage with the controls that could attach there
• Capstone: Deliver a reference pipeline diagram with control attachment points and expected runtime cost per stage

Turning the SDLC into something with defined security activities and exit criteria. What happens at requirements, design, implementation, testing, deployment and maintenance, and how to define a gate that is enforceable rather than aspirational.

Topics: What a secure SDLC is and how it differs from a checklist · Security activities per SDLC phase · Defining exit criteria for a gate · Threat modelling as a design-phase activity · Embedding security stages in CI/CD · Blocking versus advisory controls · Handling exceptions and risk acceptance

• Assignments: (1) Define exit criteria for three gates including the exact failure condition; (2) Write an exception process that does not become a permanent bypass
• Capstone: Produce a secure SDLC definition for one application team with named owners for each gate

Most of your code is other people's code. Building a dependency inventory, understanding transitive resolution, and turning vulnerability and licence data into a policy that a build can enforce without stopping every merge.

Topics: What software composition analysis does and where it is blind · Direct versus transitive dependencies and lockfiles · Vulnerability data sources: NVD, CVE, advisory databases · Licence obligations and why legal risk is not the same as security risk · SBOM formats — SPDX and CycloneDX · Embedding SCA in the build and in the registry · Policy design: what fails a build versus what raises a ticket

• Assignments: (1) Generate an SBOM for a real application and reconcile it against the declared dependency list; (2) Write an SCA policy with a documented rationale for each blocking rule
• Capstone: Add SCA to the reference pipeline with a policy that blocks critical, reachable vulnerabilities and only those

Running SAST at build time without drowning the team. Rule set selection and tuning, incremental analysis on changed code, baselining an existing codebase, and the separate discipline of stopping credentials from reaching version control in the first place.

Topics: How static application security testing works and its limits · Rule sets, checkers and language coverage · Baselining a legacy codebase so only new findings block · Incremental and pull-request scanning · False positives, suppression and audit trails · Secrets detection in commits and in history · Pre-commit hooks versus server-side enforcement

• Assignments: (1) Baseline a codebase and configure the build to fail only on newly introduced findings; (2) Plant and then detect a credential in a branch, then purge it from history
• Capstone: Integrate SAST and secrets scanning into the reference pipeline with a defensible suppression workflow

Testing the deployed thing rather than the source. Proxy-based scanning, getting past authentication and session handling, crawling single-page applications, and building a baseline scan that runs on every deploy without taking an hour.

Topics: What dynamic application security testing catches that SAST cannot · Proxy interception and the request/response model · Authenticated scanning and session management · Crawling AJAX and single-page applications · TLS and certificate misconfiguration testing · Baseline scans versus full active scans · Scan frequency, scan duration and where DAST fits in the pipeline

• Assignments: (1) Configure an authenticated dynamic scan against a deliberately vulnerable application; (2) Create a baseline scan that completes inside a pipeline stage budget
• Capstone: Add a DAST stage that runs against an ephemeral deployed environment and reports diffs against a baseline

The build no longer produces only application code. Scanning Terraform and Kubernetes manifests for insecure configuration, scanning container images and base layers, and expressing compliance requirements as tests that run rather than documents that are read.

Topics: Infrastructure as code and the configuration attack surface · Scanning Terraform, CloudFormation and Kubernetes manifests · Container image and base-layer scanning · Configuration management as an enforcement mechanism · Compliance as code and executable controls · Writing and running compliance profiles · Handling regulated requirements without manual evidence collection

• Assignments: (1) Scan a Terraform module and fix every high-severity misconfiguration; (2) Write a compliance profile that asserts five real hardening controls on a host
• Capstone: Gate infrastructure changes on policy checks and produce machine-generated compliance evidence for one control set

Scanners are cheap; closure is expensive. Aggregating findings from multiple tools, deduplicating across scans, deciding severity in context rather than by CVSS alone, and routing each finding to an owner with an SLA that is actually met.

Topics: Aggregating findings from SCA, SAST, DAST and infrastructure scans · Deduplication and fingerprinting across tools and runs · Contextual severity: reachability, exposure and exploitability · Triage workflow, states and ownership · SLAs by severity and how to make them survive contact with delivery · Ticketing integration and closing the loop · Metrics that indicate a healthy programme rather than a busy one

• Assignments: (1) Load findings from three tools into an aggregator and deduplicate them; (2) Triage a backlog of fifty findings and defend every deferral
• Capstone: Stand up a vulnerability management flow with ingestion, deduplication, ownership and reporting

A structured way to answer 'what next'. The DSOMM axes, what each maturity level actually requires in evidence, honest self-assessment of an existing programme, and building a roadmap that moves one level rather than everything at once.

Topics: What DSOMM measures and why axes beat a single score · The four axes and their sub-dimensions · Level one to level four: concrete requirements · Self-assessing an existing programme honestly · Sequencing improvements by cost and blast radius · Practices and challenges specific to each level · Reporting maturity to management without inflating it

• Assignments: (1) Score a real or sample programme against all four axes; (2) Build a six-month roadmap that raises exactly one axis by one level
• Capstone: Deliver a maturity assessment with a costed, sequenced improvement plan

Assembly. Every control from the previous modules wired into one pipeline for one application, with the failure behaviour, runtime budget and ownership model made explicit — then deliberately broken to prove each gate catches what it claims to catch.

Topics: Sequencing controls to keep total pipeline time acceptable · Fail-fast ordering and parallel scan stages · Handling scanner outages without blocking all delivery · Managing scanner and rule-set versions as code · Onboarding a second application to the same controls · Developer experience: feedback location, latency and signal quality · Running the programme: cadence, review and retirement of controls

• Assignments: (1) Introduce five distinct planted weaknesses and verify each is caught by the intended gate; (2) Measure and then reduce total pipeline time without removing a control
• Capstone: Deliver a complete secured pipeline for a real application with documented gates, owners and evidence of each control firing