DevSecOps Engineer

The journey

1. Practised under observation

   1. 01DevSecOps foundations and the shared substrateWhat this seat actually is: security as a property of how software is delivered, and the two substrates it stands on, consolidated rather than taught again.Practised under observation

      MilestoneConsolidates the substrate, sees the security path

      You have built the path your code takes to production, and you can say what the machine that builds it could reach if somebody else owned it.

2. From here, milestones are verified rather than practised.

   Verified against a real task

   1. 02Threat modeling and security requirements for deliveryDeciding what the pipeline must enforce, with threat modeling applied to the application and to the pipeline itself, and requirements that turn into automation.Verified against a real task

      MilestoneModels the threat, writes the enforceable requirement

      A requirement is written either as something a pipeline can check or as something only a person can, and the line between what blocks and what merely opens a ticket is a decision you can defend.

   2. 03Security testing automation in the pipelineThe scanning layer done properly: the right test at the right stage, tuned for signal, with findings developers can actually act on.Verified against a real task

      MilestoneScanning that produces signal, not noise

      Every scanner has a false-positive rate you measured rather than assumed, one of them was tuned or deleted on that evidence, and a finding reaches the person who can fix it rather than a report nobody owns.

   3. 04Supply chain and artifact integrityTrusting what you ship, with the build system hardened as the highest-value target, artifacts signed, and provenance that survives an audit.Verified against a real task

      MilestoneThe chain verified, the pipeline hardened

      An artifact nobody signed does not deploy, and when a new vulnerability is disclosed the question of who is affected is a query rather than a week.

   4. 05Secrets, configuration and runtime securityWhat the pipeline hands to production: secrets managed properly, infrastructure and containers enforced by policy, and runtime security wired in at deploy.Verified against a real task

      MilestoneSecrets held, policy enforced, runtime constrained

      The credentials the pipeline hands out expire on their own, an insecure resource is stopped before it exists rather than found afterwards, and the emergency path that skips the controls leaves a trail somebody can read.

   5. 06Compliance automation and governance as codeEvidence without the scramble, with controls encoded, compliance generated by the pipeline, and the audit that becomes a query rather than a project.Verified against a real task

      MilestoneCompliance generated, not assembled

      Compliance evidence is produced by a query rather than assembled by hand, and a control that exists in the policy and not in the practice is reported as such.

   6. 07Operating the security pipeline at scaleMaking it work across an organisation: metrics that drive improvement, the developer experience of security, and incident response when the pipeline is the problem.Verified against a real task

      MilestoneOperated at scale, and it helps

      Asking developers whether the tooling helps is part of running it, each gate fails open or fails closed because somebody decided which, and measurement improves the pipeline instead of ranking the people shipping through it.

   7. 08The DevSecOps Engineer in the organizationThe seat between two cultures, trusted by developers and by security, and effective precisely because it is not the department of no.Verified against a real task

      MilestoneCredible to both sides

      Security gets adopted because it works rather than because it was mandated, and the release that must not ship is the one you block.

3. 1. Capstone

      A delivery pipeline that ships secure software

      A complete DevSecOps engagement for a realistic organisation, proposed by you and approved by an instructor, built under observation, from a working pipeline and its threat models through tuned security testing, a hardened supply chain, secrets and policy enforcement and continuous compliance evidence to operating the whole thing across an organisation.

      Defence

      You walk an instructor through your own pipeline: what it catches and what gets through it, which of your scanners you would delete and why, what somebody who compromised your build system could reach, and which control fails open and why that is right. The credential is not awarded if you cannot account for your own work.

   2. Credential

      High-assurance credential

      Evidence that you can build security into delivery so that the secure path is the fast path, and say what the pipeline catches and what it does not. It does not claim seniority, and it does not oblige any employer to accept it.

      See how proof works