DevSecOps Fundamentals
DevSecOps integrates security practices into every stage of the software delivery pipeline rather than treating security as a separate gate at the end. It shifts vulnerability detection left, automates security testing, and makes security a shared responsibility across development, operations, and security teams.
itOffensive security and application security | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic: DevSecOps Fundamentals
DevSecOps treats security as part of software delivery, not as a final checkpoint staffed by people who arrive after the release date has acquired a personality. A change travels from risk and requirement through code, checks, release decision, deployment, and runtime feedback. Security belongs on that route because each stage can prevent a failure or produce evidence about one.
The first useful idea is evidence. A scanner result, threat model, SBOM, provenance, signature, and runtime alert are not interchangeable souvenirs from the software factory. An SBOM says which components are present. Provenance says where and how an artifact was made. A signature helps establish authenticity. A security test reports what its configured scope found. None proves that the application is safe, because software has declined to become that cooperative.
The second is ownership. Shared responsibility does not mean a finding, gate, exception, or response action belongs to a committee that meets every third lunar eclipse. Product owners decide acceptable impact. Developers implement controls. Security specialists set standards and challenge evidence. Platform engineers protect the delivery path. Operations returns production evidence. Every decision needs a named owner.
Then comes the surprising bit: shifting checks left is useful, but it is not a campaign to move every control into a pull request. Fast secret, code, and dependency checks fit near a change. Dynamic tests fit a protected environment. Artifact verification and policy fit the release boundary. Production still has identities, configuration, traffic, and attackers that earlier stages cannot inspect. Keep controls right as well.
The pipeline deserves suspicion. It may read source, fetch dependencies, use credentials, create artifacts, and deploy them. Review pipeline changes, use least-privilege identities, isolate jobs, restrict secrets, verify external inputs, and verify the artifact before deployment.
Read the Intro for the delivery map. Use Slides for the feedback loop and gate decisions. Keep the Cheatsheet nearby when placing checks or defining a finding record. Field Notes covers the operational costs that turn good intentions into ignored dashboards. The Quiz checks whether the distinctions stayed in the right compartments.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://csrc.nist.gov/pubs/sp/800/218/final
Supports
- SSDF version 1.1 as high-level practices integrated into any software development lifecycle
- Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities practice groups
- Security requirements, protected development environments, third-party component checks, release integrity, and vulnerability response
- Root-cause improvement and the limits of individual tools or lifecycle phases
- Intro, slides, cheatsheet, quiz, links, and narration claims about lifecycle outcomes
- https://devguide.owasp.org/en/09-operations/01-devsecops/
Supports
- DevSecOps as security steps embedded into existing development and release pipelines
- Shift-left security feedback and secure pipeline foundations
- Threat modeling, secrets management, linting, static, dynamic, interactive, composition, infrastructure, and container scanning
- Claims and quiz answers about complementary techniques and early feedback
- https://owasp.org/www-project-devsecops-guideline/
Supports
- DevSecOps guidance for secure pipelines and early detection of security issues
- Automated pipeline activities including secret, code, component, infrastructure-as-code, container, infrastructure, and compliance checks
- Shift-left quiz answer and introductory delivery guidance
- https://owasp.org/www-project-devsecops-guideline/latest/00b-Threat-modeling
Supports
- Threat modeling as a collaborative and repeatable activity
- Threat-model outputs including diagrams, security requirements, and identified threats
- The quiz scenario that distinguishes design evidence from a static scan
- https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html
Supports
- CI/CD as automated processes for building and delivering software
- High impact of compromise when pipeline steps use privileged identities
- Secure source control, execution environments, secrets, least privilege, identity lifecycle, third-party code, integrity, visibility, and monitoring
- Pipeline protection guidance across all learner artifacts and quiz answers
- https://owaspsamm.org/model/
Supports
- Governance, Design, Implementation, Verification, and Operations as five business functions
- Fifteen security practices used to assess and improve a software security program
- Incremental capability improvement and program ownership claims
- https://owaspsamm.org/model/governance/strategy-and-metrics/
Supports
- Risk-aligned software security objectives and an improvement roadmap
- Metrics chosen to evaluate program effectiveness rather than activity alone
- Intro, cheatsheet, and quiz guidance about outcome-oriented measures
- https://owaspsamm.org/model/implementation/secure-deployment/
Supports
- Automated deployment with integrated security verification milestones
- Protected secrets, managed storage, dynamic injection, and audited access
- Least-privilege pipeline identity and deployment guidance
- https://owaspsamm.org/model/implementation/defect-management/
Supports
- Collection, recording, analysis, ownership, and metrics for security defects
- Feedback and recurring-defect quiz scenarios
- Finding triage and remediation measures
- https://www.cisa.gov/resources-tools/resources/2025-minimum-elements-software-bill-materials-sbom
Supports
- An SBOM as a formal record of software components and supply-chain relationships
- Updated minimum data fields, automation support, practices, processes, coverage, and release frequency
- Release-specific component inventory claims and the linked study rationale
- https://slsa.dev/spec/v1.2/about
Supports
- SLSA as incrementally adoptable software supply-chain security guidelines
- Separate tracks and levels with stronger guarantees at higher levels
- Scope limits, including that SLSA does not establish code quality or producer intent
- https://slsa.dev/spec/v1.2/provenance
Supports
- Provenance as verifiable information about where, when, and how an artifact was produced
- Distinction between build provenance and source provenance
- Intro, slides, cheatsheet, quiz, and narration provenance definitions
- https://slsa.dev/spec/v1.2/build-track-basics
Supports
- Build Level One provenance, Level Two hosted signed provenance, and Level Three hardened builds
- Security benefits and limits of each Build level
- SLSA progression tables and quiz answers
- https://slsa.dev/spec/v1.2/verifying-artifacts
Supports
- Verification of artifact provenance against a configured root of trust
- Checks for signature, builder identity, build type, and expected parameters
- Deployment enforcement guidance and the final quiz answer
- https://owasp.org/about/
Supports
- Research source for this course enrichment artifact
- https://owasp.org/www-project-developer-guide/
Supports
- Research source for this course enrichment artifact
- https://owaspla.owasp.org/assets/prez/OWASPLA_prez_2024_11-1.pdf
Supports
- Research source for this course enrichment artifact
- https://devopsdays.org/about/
Supports
- Research source for this course enrichment artifact
- https://www.nist.gov/publications/mitigating-risk-software-vulnerabilities-adopting-secure-software-development-framework
Supports
- Research source for this course enrichment artifact
- https://www.cisa.gov/topics/cybersecurity-best-practices/executive-order-improving-nations-cybersecurity
Supports
- Research source for this course enrichment artifact
- https://slsa.dev/blog/2023/04/slsa-v1-final
Supports
- Research source for this course enrichment artifact
- https://github.com/security/advanced-security
Supports
- Research source for this course enrichment artifact
- https://about.gitlab.com/pricing/ultimate/
Supports
- Research source for this course enrichment artifact
- https://snyk.io/plans/
Supports
- Research source for this course enrichment artifact
- https://semgrep.dev/products/semgrep-appsec-platform/
Supports
- Research source for this course enrichment artifact
- https://www.sonarsource.com/products/sonarqube/server/
Supports
- Research source for this course enrichment artifact
