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
Intro
DevSecOps Fundamentals
DevSecOps integrates security into the way you plan, build, test, release, and operate software. It does not create a separate security phase. It makes security part of the delivery system and gives every change a path from risk to evidence.
Use this mental model:
risk → requirement → change → checks → release decision → runtime feedback
↑ ↓
└────────────── defects, incidents, and learning ────────┘
The loop matters more than any single tool. A scanner can detect a known pattern. It cannot decide which risks matter to the product. A signed artifact can prove where a build came from. It cannot prove that the application has no vulnerabilities. DevSecOps connects these forms of evidence to owners and decisions.
What changes with DevSecOps
Traditional delivery can hand software from development to security and then to operations. Each handoff delays feedback and loses context. DevSecOps keeps the specialties but changes the working system.
- Product teams include security requirements in planned work.
- Developers receive fast feedback while a change is still small.
- Security specialists define standards, threat models, reusable controls, and escalation paths.
- Platform teams provide protected build and deployment paths.
- Operations teams return runtime findings and incidents to the backlog.
- Accountable owners make explicit release and risk decisions.
Security remains skilled work. Shared responsibility does not mean that responsibility is vague. Every control, exception, finding, and response action needs an owner.
Start with outcomes, not tools
NIST's Secure Software Development Framework groups secure development into four practice areas: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. These outcomes apply across development methods.
For one service, translate them into questions:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
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
