{"id":3147,"date":"2026-09-29T08:46:04","date_gmt":"2026-09-29T08:46:04","guid":{"rendered":"https:\/\/devsecopsschool.com\/blog\/?p=3147"},"modified":"2026-09-29T08:46:05","modified_gmt":"2026-09-29T08:46:05","slug":"devsecops-manifesto","status":"publish","type":"post","link":"http:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/","title":{"rendered":"DevSecOps Manifesto"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Complete Reference Tutorial \u2014 From Principles to Production Implementation<\/h2>\n\n\n\n

Version:<\/strong> 1.0
Updated:<\/strong> September 2026
Level:<\/strong> Beginner \u2192 Intermediate \u2192 Advanced
Audience:<\/strong> Developers, DevOps Engineers, SREs, Security Engineers, Platform Engineers, Architects, Engineering Managers, Compliance Teams<\/p>\n\n\n\n

\n\n\n\n

1. What Is DevSecOps?<\/h1>\n\n\n\n

DevSecOps<\/strong> means integrating security into the entire software development and delivery lifecycle rather than treating security as a separate activity performed immediately before production.<\/p>\n\n\n\n

At a simple level:<\/p>\n\n\n\n

DevSecOps\n    =\nDevelopment\n    +\nSecurity\n    +\nOperations<\/code><\/pre>\n\n\n\n
But this definition is incomplete.<\/p>\n\n\n\n
DevSecOps is really about changing:<\/p>\n\n\n\n
Security as a Gate\n        \u2193\nSecurity as an Engineering Capability<\/code><\/pre>\n\n\n\n
Instead of:<\/p>\n\n\n\n
Develop \u2192 Test \u2192 Deploy \u2192 SECURITY REVIEW \u2192 Production<\/code><\/pre>\n\n\n\n
we build security throughout the lifecycle:<\/p>\n\n\n\n
Plan\n \u2193\nDesign\n \u2193\nCode\n \u2193\nBuild\n \u2193\nTest\n \u2193\nRelease\n \u2193\nDeploy\n \u2193\nOperate\n \u2193\nMonitor\n \u2193\nRespond\n\nSecurity exists throughout \u2191<\/code><\/pre>\n\n\n\n
The original DevSecOps Manifesto centers on Security as Code<\/strong>, collaboration, automation, continuous feedback, proactive monitoring, exploit-based testing, and making security services consumable by engineering teams.<\/p>\n\n\n\n
\n\n\n\n
2. Why Was DevSecOps Needed?<\/h1>\n\n\n\n
Traditional security organizations often operated separately from development teams.<\/p>\n\n\n\n
A common historical model looked like this:<\/p>\n\n\n\n
Developer\n   \u2502\n   \u25bc\nApplication Development\n   \u2502\n   \u25bc\nQA\n   \u2502\n   \u25bc\nRelease Candidate\n   \u2502\n   \u25bc\nSecurity Team\n   \u2502\n   \u251c\u2500\u2500 Vulnerability scan\n   \u251c\u2500\u2500 Penetration test\n   \u251c\u2500\u2500 Compliance review\n   \u2514\u2500\u2500 Security approval\n   \u2502\n   \u25bc\nProduction<\/code><\/pre>\n\n\n\n
This created several problems.<\/p>\n\n\n\n
Problem 1 \u2014 Security discovered issues too late<\/h3>\n\n\n\n
Imagine discovering an architectural authentication flaw two days before release.<\/p>\n\n\n\n
Fixing it might require:<\/p>\n\n\n\n
Architecture Change\n      \u2193\nCode Changes\n      \u2193\nDatabase Changes\n      \u2193\nNew Tests\n      \u2193\nNew Deployment<\/code><\/pre>\n\n\n\n
The later a fundamental security problem is discovered, the more disruptive remediation becomes.<\/p>\n\n\n\n
\n\n\n\n
Problem 2 \u2014 Security became a bottleneck<\/h3>\n\n\n\n
Development teams increasingly moved toward:<\/p>\n\n\n\n
Agile\n+\nCI\/CD\n+\nCloud\n+\nContainers\n+\nMicroservices\n+\nInfrastructure as Code<\/code><\/pre>\n\n\n\n
They could potentially deploy dozens or hundreds of times per day.<\/p>\n\n\n\n
A security process based primarily on:<\/p>\n\n\n\n
Tickets\nDocuments\nManual approvals\nSpreadsheets\nPeriodic scans<\/code><\/pre>\n\n\n\n
could not scale at the same rate.<\/p>\n\n\n\n
\n\n\n\n
Problem 3 \u2014 Security teams became known as the team that says “No”<\/h3>\n\n\n\n
The conversation might look like:<\/p>\n\n\n\n
Developer:\nCan we deploy this?\n\nSecurity:\nNo.\n\nDeveloper:\nWhy?\n\nSecurity:\nSecurity policy.\n\nDeveloper:\nWhat do we need to change?\n\nSecurity:\nSee this 120-page document.<\/code><\/pre>\n\n\n\n
That creates friction rather than better security.<\/p>\n\n\n\n
The early DevSecOps principles explicitly argued that security needs to scale alongside continuous innovation rather than primarily operating as a gatekeeper.<\/p>\n\n\n\n
\n\n\n\n
3. The Fundamental DevSecOps Transformation<\/h1>\n\n\n\n
The DevSecOps transformation can be summarized like this:<\/p>\n\n\n\n
Traditional Security<\/th>DevSecOps<\/th><\/tr>
Security team owns security<\/td>Everyone contributes to security<\/td><\/tr>
Security review near release<\/td>Security throughout SDLC<\/td><\/tr>
Manual checks<\/td>Automated controls where practical<\/td><\/tr>
Documents<\/td>Machine-readable policy<\/td><\/tr>
Tickets<\/td>APIs and self-service<\/td><\/tr>
Periodic scans<\/td>Continuous testing<\/td><\/tr>
Vulnerability reports<\/td>Actionable remediation<\/td><\/tr>
Security gatekeeper<\/td>Security engineering partner<\/td><\/tr>
Reactive incident handling<\/td>Continuous detection<\/td><\/tr>
Compliance evidence gathered manually<\/td>Evidence generated continuously<\/td><\/tr>
Infrastructure configured manually<\/td>Infrastructure as Code<\/td><\/tr>
Secrets manually distributed<\/td>Automated secrets management<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
\n\n\n\n
4. What Is the DevSecOps Manifesto?<\/h1>\n\n\n\n
The DevSecOps Manifesto<\/strong> describes a different operating model for security practitioners.<\/p>\n\n\n\n
Its core philosophy is that security should work in a way developers and operations teams can actually consume.<\/p>\n\n\n\n
The manifesto emphasizes ideas including:<\/p>\n\n\n\n
    \n
  • Security as Code<\/li>\n\n\n\n
  • iterative improvement<\/li>\n\n\n\n
  • security services exposed through APIs<\/li>\n\n\n\n
  • developer-focused security feedback<\/li>\n\n\n\n
  • collaboration instead of isolated security ownership<\/li>\n\n\n\n
  • practical exploit testing<\/li>\n\n\n\n
  • continuous monitoring<\/li>\n\n\n\n
  • shared threat intelligence<\/li>\n\n\n\n
  • operationalized compliance<\/li>\n<\/ul>\n\n\n\n
    The official manifesto describes the goal as creating security capabilities that help teams move forward rather than merely producing reports or blocking deployments.<\/p>\n\n\n\n
    \n\n\n\n
    5. The Nine DevSecOps Manifesto Values<\/h1>\n\n\n\n
    The manifesto describes nine broad preferences.<\/p>\n\n\n\n
    Rather than memorizing the wording, understand the engineering philosophy behind each one.<\/p>\n\n\n\n
    \n\n\n\n
    Principle 1 \u2014 Enable Teams Instead of Automatically Blocking Them<\/h2>\n\n\n\n
    Traditional mindset<\/h3>\n\n\n\n
    Request\n  \u2193\nSecurity Review\n  \u2193\nNO<\/code><\/pre>\n\n\n\n
    DevSecOps mindset<\/h3>\n\n\n\n
    Request\n  \u2193\nUnderstand Risk\n  \u2193\nProvide Safe Pattern\n  \u2193\nAutomate Controls\n  \u2193\nEnable Delivery<\/code><\/pre>\n\n\n\n
    Security’s job is not to make risk disappear.<\/p>\n\n\n\n
    That is impossible.<\/p>\n\n\n\n
    The objective is to:<\/p>\n\n\n\n
    Understand Risk\n      +\nReduce Risk\n      +\nMake Risk Visible\n      +\nEnable Business<\/code><\/pre>\n\n\n\n
    Example<\/h3>\n\n\n\n
    A development team asks:<\/p>\n\n\n\n
    \n
    Can our application upload files to S3?<\/p>\n<\/blockquote>\n\n\n\n
    A gatekeeper answer might be:<\/p>\n\n\n\n
    No public S3 access allowed.<\/code><\/pre>\n\n\n\n
    A DevSecOps answer could instead define:<\/p>\n\n\n\n
    Application\n    \u2502\n    \u25bc\nIAM Role\n    \u2502\n    \u251c\u2500\u2500 PutObject\n    \u251c\u2500\u2500 GetObject\n    \u2514\u2500\u2500 DeleteObject\n    \u2502\n    \u25bc\nSpecific S3 Prefix<\/code><\/pre>\n\n\n\n
    Combined with:<\/p>\n\n\n\n
    Block Public Access\nEncryption\nAccess Logging\nLeast Privilege\nNo static AWS keys<\/code><\/pre>\n\n\n\n
    Security has enabled the use case while reducing risk.<\/p>\n\n\n\n
    \n\n\n\n
    6. Principle 2 \u2014 Use Evidence Instead of Fear<\/h1>\n\n\n\n
    Poor security communication sounds like:<\/p>\n\n\n\n
    \"This is dangerous.\"\n\n\"This could be hacked.\"\n\n\"This is insecure.\"\n\n\"We can't allow this.\"<\/code><\/pre>\n\n\n\n
    DevSecOps asks:<\/p>\n\n\n\n
    What is the threat?\nWhat is the likelihood?\nWhat is the impact?\nWhat evidence exists?\nWhich control reduces the risk?\nWhat residual risk remains?<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Example<\/h2>\n\n\n\n
    Suppose an internet-facing service has a vulnerability.<\/p>\n\n\n\n
    Instead of saying:<\/p>\n\n\n\n
    CRITICAL vulnerability!\nStop everything!<\/code><\/pre>\n\n\n\n
    evaluate:<\/p>\n\n\n\n
    CVSS severity\n       +\nInternet exposure\n       +\nExploitability\n       +\nExploit availability\n       +\nPrivileges required\n       +\nAffected asset value\n       +\nExisting compensating controls<\/code><\/pre>\n\n\n\n
    Risk prioritization therefore becomes:<\/p>\n\n\n\n
    Technical Severity\n        \u00d7\nExploitability\n        \u00d7\nExposure\n        \u00d7\nBusiness Impact<\/code><\/pre>\n\n\n\n
    rather than:<\/p>\n\n\n\n
    Scanner Severity = Business Priority<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    7. Principle 3 \u2014 Security Through Collaboration<\/h1>\n\n\n\n
    Security requirements should not exist exclusively inside a security department.<\/p>\n\n\n\n
    DevSecOps creates collaboration among:<\/p>\n\n\n\n
    Developers\n    +\nPlatform Engineering\n    +\nDevOps\n    +\nSRE\n    +\nSecurity\n    +\nArchitecture\n    +\nProduct\n    +\nCompliance<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Security Champion Model<\/h2>\n\n\n\n
    One useful implementation is:<\/p>\n\n\n\n
                     Security Team\n                      \u2502\n             \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n             \u2502        \u2502        \u2502\n             \u25bc        \u25bc        \u25bc\n          Team A    Team B    Team C\n             \u2502        \u2502        \u2502\n         Security  Security  Security\n         Champion  Champion  Champion<\/code><\/pre>\n\n\n\n
    Security champions do not replace security engineers.<\/p>\n\n\n\n
    They create security expertise closer to development.<\/p>\n\n\n\n
    \n\n\n\n
    8. Principle 4 \u2014 Make Security Consumable<\/h1>\n\n\n\n
    One of the strongest ideas in the manifesto is that security should become something developers can consume easily.<\/p>\n\n\n\n
    Traditional model:<\/p>\n\n\n\n
    Developer\n   \u2193\nSecurity Ticket\n   \u2193\nWait\n   \u2193\nSecurity Engineer\n   \u2193\nManual Configuration<\/code><\/pre>\n\n\n\n
    DevSecOps model:<\/p>\n\n\n\n
    Developer\n   \u2193\nSelf-Service Platform\n   \u2193\nApproved Security Pattern\n   \u2193\nAPI \/ Pipeline \/ Template\n   \u2193\nSecure Resource<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Example: Secure Infrastructure Module<\/h2>\n\n\n\n
    Instead of telling developers:<\/p>\n\n\n\n
    \n
    Configure S3 securely.<\/p>\n<\/blockquote>\n\n\n\n
    Create:<\/p>\n\n\n\n
    secure-s3-module<\/code><\/pre>\n\n\n\n
    that automatically enables:<\/p>\n\n\n\n
    \u2713 Block Public Access\n\u2713 Encryption\n\u2713 TLS enforcement\n\u2713 Logging\n\u2713 Standard tags\n\u2713 IAM guardrails<\/code><\/pre>\n\n\n\n
    Developer usage:<\/p>\n\n\n\n
    module \"application_bucket\" {\n  source = \".\/modules\/secure-s3\"\n\n  bucket_name = \"application-data\"\n}<\/code><\/pre>\n\n\n\n
    Security becomes:<\/p>\n\n\n\n
    Reusable\nRepeatable\nAutomated\nConsistent\nSelf-Service<\/code><\/pre>\n\n\n\n
    This is a major example of Security as Code<\/strong>.<\/p>\n\n\n\n
    \n\n\n\n
    9. Principle 5 \u2014 Connect Security to Business Risk<\/h1>\n\n\n\n
    Finding vulnerabilities is not itself the end goal.<\/p>\n\n\n\n
    Suppose a scanner finds:<\/p>\n\n\n\n
    Application A: 100 vulnerabilities\nApplication B: 5 vulnerabilities<\/code><\/pre>\n\n\n\n
    Which should be fixed first?<\/p>\n\n\n\n
    You cannot know from those numbers alone.<\/p>\n\n\n\n
    Application A might be:<\/p>\n\n\n\n
    Internal\nNo sensitive data\nNo internet exposure\nStrong compensating controls<\/code><\/pre>\n\n\n\n
    Application B might be:<\/p>\n\n\n\n
    Internet-facing\nPayment system\nCustomer PII\nPrivileged backend access<\/code><\/pre>\n\n\n\n
    So security prioritization should consider context.<\/p>\n\n\n\n
    \n\n\n\n
    Better Risk Model<\/h2>\n\n\n\n
    Risk\n =\nTechnical Severity\n \u00d7\nExploitability\n \u00d7\nExposure\n \u00d7\nAsset Criticality\n \u00d7\nBusiness Impact<\/code><\/pre>\n\n\n\n
    The objective is not:<\/p>\n\n\n\n
    Make Scanner Dashboard Green<\/code><\/pre>\n\n\n\n
    The objective is:<\/p>\n\n\n\n
    Reduce Meaningful Business Risk<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    10. Principle 6 \u2014 Test Whether Defenses Actually Work<\/h1>\n\n\n\n
    Automated scanners are valuable.<\/p>\n\n\n\n
    But:<\/p>\n\n\n\n
    Scanner Result \u2260 Proof of Security<\/code><\/pre>\n\n\n\n
    DevSecOps therefore complements scanning with offensive and defensive security testing.<\/p>\n\n\n\n
    \n\n\n\n
    Red Team<\/h2>\n\n\n\n
    Red teams simulate attackers.<\/p>\n\n\n\n
    They ask:<\/p>\n\n\n\n
    Can we compromise this system?<\/code><\/pre>\n\n\n\n
    Activities may include:<\/p>\n\n\n\n
    Exploitation\nPrivilege escalation\nCredential abuse\nLateral movement\nCloud attack paths\nApplication attacks\nSocial engineering where authorized<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Blue Team<\/h2>\n\n\n\n
    Blue teams focus on defense.<\/p>\n\n\n\n
    They ask:<\/p>\n\n\n\n
    Can we detect and stop the attack?<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Purple Team<\/h2>\n\n\n\n
    Purple teaming brings both together:<\/p>\n\n\n\n
    Red Team\n   \u2502\n Attack\n   \u2502\n   \u25bc\nBlue Team\n   \u2502\n Detect\n   \u2502\n   \u25bc\nImprove Detection\n   \u2502\n   \u25bc\nRetest<\/code><\/pre>\n\n\n\n
    The key question becomes:<\/p>\n\n\n\n
    \n
    Do our controls actually work against realistic attacks?<\/p>\n<\/blockquote>\n\n\n\n
    \n\n\n\n
    11. Principle 7 \u2014 Continuous Security Monitoring<\/h1>\n\n\n\n
    Traditional security:<\/p>\n\n\n\n
    Attack\n  \u2193\nSomething breaks\n  \u2193\nSomeone notices\n  \u2193\nSecurity investigates<\/code><\/pre>\n\n\n\n
    DevSecOps:<\/p>\n\n\n\n
    Telemetry\n   \u2193\nContinuous Detection\n   \u2193\nCorrelation\n   \u2193\nAlert\n   \u2193\nInvestigation\n   \u2193\nAutomated \/ Human Response<\/code><\/pre>\n\n\n\n
    Sources may include:<\/p>\n\n\n\n
    Application Logs\nCloud Audit Logs\nKubernetes Audit Logs\nIdentity Events\nWAF Logs\nNetwork Flows\nEndpoint Security\nRuntime Detection\nDatabase Audit Logs\nCI\/CD Audit Logs<\/code><\/pre>\n\n\n\n
    Security doesn’t end at deployment.<\/p>\n\n\n\n
    \n\n\n\n
    12. Principle 8 \u2014 Share Threat Intelligence<\/h1>\n\n\n\n
    Security knowledge loses value when isolated.<\/p>\n\n\n\n
    Imagine Security discovers:<\/p>\n\n\n\n
    Attackers are scanning \/admin\/debug\nusing a newly observed technique.<\/code><\/pre>\n\n\n\n
    That information should feed:<\/p>\n\n\n\n
    Security\n   \u2502\n   \u251c\u2500\u2500 Developers\n   \u251c\u2500\u2500 SRE\n   \u251c\u2500\u2500 SOC\n   \u251c\u2500\u2500 Platform Team\n   \u251c\u2500\u2500 Incident Response\n   \u2514\u2500\u2500 Detection Engineering<\/code><\/pre>\n\n\n\n
    The knowledge may produce:<\/p>\n\n\n\n
    New WAF Rule\nNew Detection\nNew Unit Test\nNew Security Test\nNew Coding Standard\nNew Threat Model<\/code><\/pre>\n\n\n\n
    This creates a feedback loop.<\/p>\n\n\n\n
    \n\n\n\n
    13. Principle 9 \u2014 Compliance as an Operational Capability<\/h1>\n\n\n\n
    Traditional compliance frequently looks like:<\/p>\n\n\n\n
    Audit Coming\n    \u2193\nCollect Screenshots\n    \u2193\nCollect Documents\n    \u2193\nCollect Spreadsheets\n    \u2193\nInterview Teams\n    \u2193\nSubmit Evidence<\/code><\/pre>\n\n\n\n
    DevSecOps aims for:<\/p>\n\n\n\n
    Infrastructure\n     \u2193\nPolicy as Code\n     \u2193\nAutomated Controls\n     \u2193\nContinuous Evidence\n     \u2193\nCompliance Dashboard<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Example<\/h2>\n\n\n\n
    Compliance requirement:<\/p>\n\n\n\n
    S3 buckets must not be public.<\/code><\/pre>\n\n\n\n
    Instead of checking annually:<\/p>\n\n\n\n
    Terraform Policy\n       +\nCloud Configuration Monitoring\n       +\nAutomated Alert<\/code><\/pre>\n\n\n\n
    Now compliance becomes continuous.<\/p>\n\n\n\n
    \n\n\n\n
    14. Security as Code<\/h1>\n\n\n\n
    Security as Code is one of the foundational concepts behind DevSecOps.<\/p>\n\n\n\n
    The basic idea is:<\/p>\n\n\n\n
    If something can be expressed\nas machine-readable policy,\nautomate it.<\/code><\/pre>\n\n\n\n
    Examples:<\/p>\n\n\n\n
    Infrastructure as Code\nPolicy as Code\nCompliance as Code\nDetection as Code\nConfiguration as Code\nPipeline as Code\nSecurity Tests as Code<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    15. Infrastructure as Code<\/h1>\n\n\n\n
    Instead of manually creating infrastructure:<\/p>\n\n\n\n
    Engineer\n   \u2193\nAWS Console\n   \u2193\nClick\nClick\nClick<\/code><\/pre>\n\n\n\n
    use:<\/p>\n\n\n\n
    Terraform\nCloudFormation\nPulumi\nCDK<\/code><\/pre>\n\n\n\n
    Example:<\/p>\n\n\n\n
    resource \"aws_s3_bucket_public_access_block\" \"example\" {\n  bucket = aws_s3_bucket.example.id\n\n  block_public_acls       = true\n  block_public_policy     = true\n  ignore_public_acls      = true\n  restrict_public_buckets = true\n}<\/code><\/pre>\n\n\n\n
    Now the security configuration is:<\/p>\n\n\n\n
    Version Controlled\nReviewable\nTestable\nRepeatable\nAuditable<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    16. Policy as Code<\/h1>\n\n\n\n
    Security policies can also become executable rules.<\/p>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
    Terraform\n   \u2193\nPolicy Engine\n   \u2193\nIs configuration allowed?\n   \u2502\n   \u251c\u2500\u2500 YES \u2192 Continue\n   \u2502\n   \u2514\u2500\u2500 NO  \u2192 Stop \/ Warn<\/code><\/pre>\n\n\n\n
    Example policy:<\/p>\n\n\n\n
    IF\n    S3 bucket is public\nTHEN\n    Reject deployment<\/code><\/pre>\n\n\n\n
    Other examples:<\/p>\n\n\n\n
    Database must be encrypted.\n\nProduction resources require specific tags.\n\nSecurity groups cannot expose SSH globally.\n\nContainers cannot run privileged.\n\nKubernetes workloads cannot use host networking.\n\nCritical images must come from approved registries.<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    17. Security in the Entire SDLC<\/h1>\n\n\n\n
    A mature DevSecOps program spreads controls throughout the lifecycle.<\/p>\n\n\n\n
    flowchart LR\n    A[Plan] --> B[Design]\n    B --> C[Code]\n    C --> D[Build]\n    D --> E[Test]\n    E --> F[Release]\n    F --> G[Deploy]\n    G --> H[Operate]\n    H --> I[Monitor]\n    I --> A<\/code><\/pre>\n\n\n\n
    Security surrounds every stage.<\/p>\n\n\n\n
    \n\n\n\n
    18. Plan Stage<\/h1>\n\n\n\n
    Security activities include:<\/p>\n\n\n\n
    Security requirements\nData classification\nRisk assessment\nCompliance requirements\nAbuse-case identification<\/code><\/pre>\n\n\n\n
    Questions:<\/p>\n\n\n\n
    What data are we processing?\n\nWhat regulations apply?\n\nWhat happens if this system is compromised?\n\nWho should have access?<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    19. Design Stage<\/h1>\n\n\n\n
    Perform:<\/p>\n\n\n\n
    Threat Modeling\nArchitecture Security Review\nTrust Boundary Identification\nAuthentication Design\nAuthorization Design\nEncryption Design<\/code><\/pre>\n\n\n\n
    A simplified threat model:<\/p>\n\n\n\n
    Internet\n   \u2502\n   \u25bc\n[ Load Balancer ]\n   \u2502\n   \u25bc\n[ Application ]\n   \u2502\n   \u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba [ Database ]\n   \u2502\n   \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u25ba [ External API ]<\/code><\/pre>\n\n\n\n
    Ask:<\/p>\n\n\n\n
    Where are trust boundaries?\n\nWhere does authentication happen?\n\nWhere can privilege escalation occur?\n\nWhat if the external API is compromised?\n\nCan one tenant access another tenant's data?<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    20. Code Stage<\/h1>\n\n\n\n
    Typical controls:<\/p>\n\n\n\n
    Secure coding standards\nIDE security feedback\nSecret detection\nSAST\nPeer review\nDependency policy<\/code><\/pre>\n\n\n\n
    Examples of vulnerabilities to detect early:<\/p>\n\n\n\n
    SQL injection\nCommand injection\nPath traversal\nHard-coded credentials\nWeak cryptography\nUnsafe deserialization\nAuthorization failures<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    21. Build Stage<\/h1>\n\n\n\n
    Typical controls:<\/p>\n\n\n\n
    Software Composition Analysis\nDependency vulnerability scanning\nSBOM generation\nArtifact signing\nContainer image scanning\nBuild provenance<\/code><\/pre>\n\n\n\n
    Supply-chain security becomes extremely important here.<\/p>\n\n\n\n
    A modern application may contain:<\/p>\n\n\n\n
    Your Code                 15%\nOpen Source Dependencies  70%\nRuntime \/ Base Image      15%<\/code><\/pre>\n\n\n\n
    The exact proportions vary, but the lesson is simple:<\/p>\n\n\n\n
    \n
    You must secure software you didn’t write too.<\/p>\n<\/blockquote>\n\n\n\n
    NIST’s SSDF specifically includes protecting software components from tampering and unauthorized access as one of its major practice groups.<\/p>\n\n\n\n
    \n\n\n\n
    22. Test Stage<\/h1>\n\n\n\n
    Security testing may include:<\/p>\n\n\n\n
    SAST\nDAST\nIAST\nAPI Security Testing\nFuzz Testing\nContainer Scanning\nInfrastructure Scanning\nPenetration Testing<\/code><\/pre>\n\n\n\n
    OWASP’s current DevSecOps guidance explicitly covers techniques including SAST, DAST, IAST, SCA, infrastructure scanning and container scanning.<\/p>\n\n\n\n
    \n\n\n\n
    23. Deploy Stage<\/h1>\n\n\n\n
    Typical controls:<\/p>\n\n\n\n
    Policy as Code\nAdmission Controls\nImage Verification\nSecure Configuration Validation\nLeast-Privilege IAM\nSecrets Injection\nEnvironment Protection<\/code><\/pre>\n\n\n\n
    Example Kubernetes deployment path:<\/p>\n\n\n\n
    Container Image\n     \u2193\nRegistry\n     \u2193\nImage Scan\n     \u2193\nSignature Verification\n     \u2193\nAdmission Policy\n     \u2193\nKubernetes<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    24. Operate Stage<\/h1>\n\n\n\n
    Security activities include:<\/p>\n\n\n\n
    Patch management\nSecrets rotation\nCertificate rotation\nIAM review\nRuntime protection\nConfiguration monitoring\nVulnerability management<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    25. Monitor Stage<\/h1>\n\n\n\n
    Security monitoring may include:<\/p>\n\n\n\n
    SIEM\nCloud Security Monitoring\nApplication Security Monitoring\nRuntime Detection\nEndpoint Detection\nNetwork Detection\nAnomaly Detection<\/code><\/pre>\n\n\n\n
    The important concept is:<\/p>\n\n\n\n
    Prevent\n   +\nDetect\n   +\nRespond<\/code><\/pre>\n\n\n\n
    Prevention alone will never be enough.<\/p>\n\n\n\n
    \n\n\n\n
    26. Shift Left<\/h1>\n\n\n\n
    You will frequently hear DevSecOps associated with:<\/p>\n\n\n\n
    \n
    Shift Left.<\/p>\n<\/blockquote>\n\n\n\n
    Imagine the SDLC as:<\/p>\n\n\n\n
    LEFT                                      RIGHT\n\nPlan \u2192 Design \u2192 Code \u2192 Build \u2192 Test \u2192 Deploy \u2192 Operate<\/code><\/pre>\n\n\n\n
    Historically, security often happened toward the right.<\/p>\n\n\n\n
    Shift Left means performing security earlier:<\/p>\n\n\n\n
    Plan\n \u2502\n \u251c\u2500\u2500 Security Requirements\n\nDesign\n \u2502\n \u251c\u2500\u2500 Threat Modeling\n\nCode\n \u2502\n \u251c\u2500\u2500 SAST\n \u2514\u2500\u2500 Secret Detection\n\nBuild\n \u2502\n \u251c\u2500\u2500 SCA\n \u2514\u2500\u2500 Container Scanning<\/code><\/pre>\n\n\n\n
    OWASP describes early detection as a central objective of its DevSecOps guidance.<\/p>\n\n\n\n
    \n\n\n\n
    27. Shift Right<\/h1>\n\n\n\n
    DevSecOps does not<\/strong> mean:<\/p>\n\n\n\n
    Shift Left = Everything<\/code><\/pre>\n\n\n\n
    Some problems can only be discovered in real environments.<\/p>\n\n\n\n
    Shift Right includes:<\/p>\n\n\n\n
    Runtime Monitoring\nAttack Detection\nIncident Response\nChaos Engineering\nPenetration Testing\nProduction Telemetry\nThreat Hunting<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    28. The Better Model: Shift Everywhere<\/h1>\n\n\n\n
    Modern DevSecOps is better thought of as:<\/p>\n\n\n\n
                  SECURITY\n\nPlan\n \u2193\nDesign\n \u2193\nCode\n \u2193\nBuild\n \u2193\nTest\n \u2193\nDeploy\n \u2193\nOperate\n \u2193\nMonitor\n\n              SECURITY<\/code><\/pre>\n\n\n\n
    Or:<\/p>\n\n\n\n
    Security Everywhere<\/code><\/pre>\n\n\n\n
    OWASP’s current project description similarly describes its direction as moving beyond only shift-left toward security throughout the lifecycle.<\/p>\n\n\n\n
    \n\n\n\n
    29. Example DevSecOps CI\/CD Pipeline<\/h1>\n\n\n\n
    Consider this workflow:<\/p>\n\n\n\n
    flowchart TD\n    A[Developer Commit] --> B[Secret Scan]\n    B --> C[SAST]\n    C --> D[Unit Tests]\n    D --> E[SCA]\n    E --> F[Build Container]\n    F --> G[Container Scan]\n    G --> H[Generate SBOM]\n    H --> I[Push Artifact]\n    I --> J[Deploy Test]\n    J --> K[DAST\/API Tests]\n    K --> L[Policy Check]\n    L --> M[Deploy Production]\n    M --> N[Runtime Monitoring]\n    N --> O[Detection and Response]<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    30. A More Detailed Security Pipeline<\/h1>\n\n\n\n
    Developer\n   \u2502\n   \u25bc\nGit Commit\n   \u2502\n   \u251c\u2500\u2500 Secret Detection\n   \u2502\n   \u25bc\nPull Request\n   \u2502\n   \u251c\u2500\u2500 Peer Review\n   \u251c\u2500\u2500 SAST\n   \u251c\u2500\u2500 Dependency Scan\n   \u251c\u2500\u2500 IaC Scan\n   \u2502\n   \u25bc\nBuild\n   \u2502\n   \u251c\u2500\u2500 Reproducible Build\n   \u251c\u2500\u2500 SBOM\n   \u251c\u2500\u2500 Artifact Signing\n   \u2502\n   \u25bc\nContainer Registry\n   \u2502\n   \u251c\u2500\u2500 Image Scan\n   \u251c\u2500\u2500 Signature\n   \u2502\n   \u25bc\nTest Environment\n   \u2502\n   \u251c\u2500\u2500 DAST\n   \u251c\u2500\u2500 API Testing\n   \u251c\u2500\u2500 Integration Tests\n   \u2502\n   \u25bc\nDeployment\n   \u2502\n   \u251c\u2500\u2500 Policy as Code\n   \u251c\u2500\u2500 Admission Control\n   \u2502\n   \u25bc\nProduction\n   \u2502\n   \u251c\u2500\u2500 Runtime Security\n   \u251c\u2500\u2500 Logs\n   \u251c\u2500\u2500 Metrics\n   \u251c\u2500\u2500 Traces\n   \u251c\u2500\u2500 Threat Detection\n   \u2502\n   \u25bc\nSIEM \/ Detection\n   \u2502\n   \u25bc\nIncident Response<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    31. Security Gates: Use Them Carefully<\/h1>\n\n\n\n
    DevSecOps does not mean:<\/p>\n\n\n\n
    Block every pipeline for every vulnerability.<\/code><\/pre>\n\n\n\n
    That quickly becomes unusable.<\/p>\n\n\n\n
    Instead define risk-based policies.<\/p>\n\n\n\n
    Example:<\/p>\n\n\n\n
    Finding<\/th>Possible Action<\/th><\/tr>
    Critical exploitable vulnerability<\/td>Block<\/td><\/tr>
    Critical secret exposure<\/td>Block<\/td><\/tr>
    Critical IaC misconfiguration<\/td>Block<\/td><\/tr>
    High vulnerability with known exploit<\/td>Block\/exception<\/td><\/tr>
    Medium vulnerability<\/td>Warn + remediation SLA<\/td><\/tr>
    Low vulnerability<\/td>Track<\/td><\/tr>
    Informational<\/td>Report<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    The exact thresholds depend on business risk.<\/p>\n\n\n\n
    \n\n\n\n
    32. False Positives Matter<\/h1>\n\n\n\n
    Imagine every deployment produces:<\/p>\n\n\n\n
    350 security warnings<\/code><\/pre>\n\n\n\n
    but engineers discover that:<\/p>\n\n\n\n
    320 are irrelevant\n20 are duplicates\n8 aren't exploitable\n2 require action<\/code><\/pre>\n\n\n\n
    Developers eventually learn:<\/p>\n\n\n\n
    Security Alert = Noise<\/code><\/pre>\n\n\n\n
    This is dangerous.<\/p>\n\n\n\n
    A successful DevSecOps program optimizes:<\/p>\n\n\n\n
    Signal\n\u2500\u2500\u2500\u2500\u2500\u2500\nNoise<\/code><\/pre>\n\n\n\n
    not just:<\/p>\n\n\n\n
    Number of Scanners<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    33. Secrets Management<\/h1>\n\n\n\n
    Bad:<\/p>\n\n\n\n
    AWS_ACCESS_KEY_ID: AKIA...\nAWS_SECRET_ACCESS_KEY: abc123...<\/code><\/pre>\n\n\n\n
    Better:<\/p>\n\n\n\n
    Application\n    \u2502\n    \u25bc\nWorkload Identity\n    \u2502\n    \u25bc\nCloud IAM<\/code><\/pre>\n\n\n\n
    or:<\/p>\n\n\n\n
    Application\n    \u2502\n    \u25bc\nSecrets Manager\n    \u2502\n    \u25bc\nShort-lived credential<\/code><\/pre>\n\n\n\n
    DevSecOps prefers:<\/p>\n\n\n\n
    Short-lived credentials\n       over\nLong-lived credentials\n\nIdentity federation\n       over\nStatic access keys\n\nAutomated rotation\n       over\nManual rotation<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    34. Cloud DevSecOps Example<\/h1>\n\n\n\n
    Suppose the platform uses:<\/p>\n\n\n\n
    GitHub\nTerraform\nAWS\nEKS\nDocker\nKubernetes\nDatadog<\/code><\/pre>\n\n\n\n
    A DevSecOps architecture might look like:<\/p>\n\n\n\n
    Developer\n   \u2502\n   \u25bc\nGitHub\n   \u2502\n   \u251c\u2500\u2500 Secret Scan\n   \u251c\u2500\u2500 SAST\n   \u251c\u2500\u2500 Dependency Scan\n   \u2502\n   \u25bc\nTerraform\n   \u2502\n   \u251c\u2500\u2500 IaC Scan\n   \u251c\u2500\u2500 Policy as Code\n   \u2502\n   \u25bc\nAWS\n   \u2502\n   \u25bc\nEKS\n   \u2502\n   \u251c\u2500\u2500 Admission Policy\n   \u251c\u2500\u2500 RBAC\n   \u251c\u2500\u2500 Network Policies\n   \u251c\u2500\u2500 Workload Identity\n   \u2502\n   \u25bc\nApplication\n   \u2502\n   \u25bc\nDatadog \/ Security Monitoring<\/code><\/pre>\n\n\n\n
    This demonstrates the manifesto better than simply buying a “DevSecOps tool.”<\/p>\n\n\n\n
    \n\n\n\n
    35. DevSecOps Is Not a Tool<\/h1>\n\n\n\n
    This is one of the most important lessons.<\/p>\n\n\n\n
    DevSecOps is not:<\/p>\n\n\n\n
    SonarQube\nSnyk\nTrivy\nCheckov\nWiz\nGitHub Advanced Security\nDatadog\nVault<\/code><\/pre>\n\n\n\n
    Those may support DevSecOps.<\/p>\n\n\n\n
    But:<\/p>\n\n\n\n
    DevSecOps \u2260 Security Tool<\/code><\/pre>\n\n\n\n
    DevSecOps is:<\/p>\n\n\n\n
    Culture\n+\nPeople\n+\nProcess\n+\nAutomation\n+\nArchitecture\n+\nSecurity Engineering\n+\nContinuous Feedback<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    36. DevSecOps Is Not Just “Shift Left”<\/h1>\n\n\n\n
    Another common misunderstanding:<\/p>\n\n\n\n
    DevSecOps = Add SAST to CI\/CD<\/code><\/pre>\n\n\n\n
    No.<\/p>\n\n\n\n
    That would only address one piece.<\/p>\n\n\n\n
    A mature program covers:<\/p>\n\n\n\n
    Design Security\nApplication Security\nCloud Security\nInfrastructure Security\nIdentity\nSupply Chain Security\nContainer Security\nRuntime Security\nDetection\nIncident Response\nCompliance<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    37. DevSecOps Is Not “Developers Own Everything”<\/h1>\n\n\n\n
    Another dangerous interpretation is:<\/p>\n\n\n\n
    Security is everyone's responsibility\n\ntherefore\n\nSecurity Team isn't needed.<\/code><\/pre>\n\n\n\n
    Wrong.<\/p>\n\n\n\n
    Shared responsibility means specialists still exist.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    Developers<\/h3>\n\n\n\n
    Own:<\/p>\n\n\n\n
    Secure coding\nDependency remediation\nApplication fixes<\/code><\/pre>\n\n\n\n
    Platform\/DevOps<\/h3>\n\n\n\n
    Own:<\/p>\n\n\n\n
    Secure pipeline\nInfrastructure controls\nPlatform guardrails<\/code><\/pre>\n\n\n\n
    Security<\/h3>\n\n\n\n
    Own or lead:<\/p>\n\n\n\n
    Threat modeling\nSecurity standards\nDetection strategy\nSecurity architecture\nOffensive testing\nIncident response\nRisk governance<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    38. Shared Responsibility Model<\/h1>\n\n\n\n
    flowchart TD\n    A[Security] --> E[Shared DevSecOps Responsibility]\n    B[Development] --> E\n    C[Platform \/ DevOps] --> E\n    D[SRE \/ Operations] --> E\n    E --> F[Secure Product]<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    39. Developer Experience Matters<\/h1>\n\n\n\n
    Imagine requiring developers to execute:<\/p>\n\n\n\n
    15 security tools\n8 manual commands\n5 websites\n4 approval tickets<\/code><\/pre>\n\n\n\n
    before every deployment.<\/p>\n\n\n\n
    Security technically exists.<\/p>\n\n\n\n
    But DevSecOps has failed.<\/p>\n\n\n\n
    Good security should ideally feel like:<\/p>\n\n\n\n
    git push\n   \u2193\nAutomated Checks\n   \u2193\nClear Feedback\n   \u2193\nFix\n   \u2193\nContinue<\/code><\/pre>\n\n\n\n
    The best security controls often disappear into the engineering platform.<\/p>\n\n\n\n
    \n\n\n\n
    40. Golden Paths<\/h1>\n\n\n\n
    Platform engineering can provide secure Golden Paths<\/strong>.<\/p>\n\n\n\n
    For example:<\/p>\n\n\n\n
    Create New Microservice\n          \u2193\nApproved Template\n          \u2193\nRepository\n          +\nCI\/CD\n          +\nLogging\n          +\nMonitoring\n          +\nIAM\n          +\nSecrets\n          +\nSecurity Scanning\n          +\nInfrastructure<\/code><\/pre>\n\n\n\n
    Developers start secure by default.<\/p>\n\n\n\n
    This is much more scalable than telling every development team to reinvent security.<\/p>\n\n\n\n
    \n\n\n\n
    41. Secure by Default<\/h1>\n\n\n\n
    Suppose engineers can choose:<\/p>\n\n\n\n
    Option A: Secure\nOption B: Insecure<\/code><\/pre>\n\n\n\n
    Eventually somebody will choose B.<\/p>\n\n\n\n
    Better:<\/p>\n\n\n\n
    Default Platform\n      =\nSecure Configuration<\/code><\/pre>\n\n\n\n
    Exceptions then become explicit.<\/p>\n\n\n\n
    This complements the broader Secure by Design<\/strong> approach promoted by security agencies such as CISA, where security properties are incorporated into the product architecture rather than treated only as downstream controls.<\/p>\n\n\n\n
    \n\n\n\n
    42. DevSecOps and NIST SSDF<\/h1>\n\n\n\n
    The DevSecOps Manifesto is a philosophy.<\/p>\n\n\n\n
    NIST’s Secure Software Development Framework provides a more structured secure-development framework.<\/p>\n\n\n\n
    NIST SSDF organizes its current final framework into four groups:<\/p>\n\n\n\n
    PO \u2014 Prepare the Organization\n\nPS \u2014 Protect the Software\n\nPW \u2014 Produce Well-Secured Software\n\nRV \u2014 Respond to Vulnerabilities<\/code><\/pre>\n\n\n\n
    A useful mapping is:<\/p>\n\n\n\n
    DevSecOps Manifesto\n        \u2193\nCulture \/ Philosophy\n\nNIST SSDF\n        \u2193\nSecure Development Practices\n\nOWASP\n        \u2193\nApplication \/ Pipeline Guidance\n\nCI\/CD + Cloud Platform\n        \u2193\nTechnical Implementation<\/code><\/pre>\n\n\n\n
    As of September 2026, NIST lists SSDF 1.1 as final while SSDF 1.2 is represented by the December 2025 initial public draft.<\/p>\n\n\n\n
    \n\n\n\n
    43. DevSecOps Metrics<\/h1>\n\n\n\n
    Never measure DevSecOps only by:<\/p>\n\n\n\n
    Number of vulnerabilities found.<\/code><\/pre>\n\n\n\n
    Finding more vulnerabilities may simply mean you deployed more scanners.<\/p>\n\n\n\n
    Useful metrics include:<\/p>\n\n\n\n
    Vulnerability Metrics<\/h3>\n\n\n\n
    Mean Time to Remediate\nCritical Vulnerability Age\nKnown Exploited Vulnerabilities\nReopened Vulnerabilities\nRisk Acceptance Age<\/code><\/pre>\n\n\n\n
    Pipeline Metrics<\/h3>\n\n\n\n
    Security Scan Duration\nFalse Positive Rate\nPipeline Security Failure Rate\nSecurity Test Coverage<\/code><\/pre>\n\n\n\n
    Detection Metrics<\/h3>\n\n\n\n
    Mean Time to Detect\nMean Time to Respond\nDetection Coverage\nFalse Positive Rate<\/code><\/pre>\n\n\n\n
    Engineering Metrics<\/h3>\n\n\n\n
    Percentage of repositories scanned\nPercentage generating SBOM\nPercentage of signed artifacts\nPercentage using approved pipelines<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    44. Avoid Bad Metrics<\/h1>\n\n\n\n
    Bad metric:<\/p>\n\n\n\n
    We found 7,000 vulnerabilities.<\/code><\/pre>\n\n\n\n
    It tells us almost nothing.<\/p>\n\n\n\n
    Better:<\/p>\n\n\n\n
    99% of internet-facing critical vulnerabilities\nare remediated within the defined SLA.<\/code><\/pre>\n\n\n\n
    Even better:<\/p>\n\n\n\n
    Known exploitable vulnerabilities affecting\ninternet-facing Tier-1 systems remain unresolved: 0<\/code><\/pre>\n\n\n\n
    Metrics should lead to decisions.<\/p>\n\n\n\n
    \n\n\n\n
    45. DevSecOps Maturity Model<\/h1>\n\n\n\n
    A simple maturity model can help organizations understand their current state.<\/p>\n\n\n\n
    \n\n\n\n
    Level 0 \u2014 Reactive<\/h2>\n\n\n\n
    Security after deployment\nManual reviews\nLittle automation\nIncident-driven changes<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Level 1 \u2014 Basic<\/h2>\n\n\n\n
    SAST\nDependency scanning\nContainer scanning\nBasic secrets management<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Level 2 \u2014 Integrated<\/h2>\n\n\n\n
    Security inside CI\/CD\nIaC scanning\nAutomated policies\nThreat modeling\nCentralized logging<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Level 3 \u2014 Managed<\/h2>\n\n\n\n
    Risk-based security gates\nSBOM\nArtifact signing\nSecurity champions\nRuntime detection\nAutomated compliance<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Level 4 \u2014 Optimized<\/h2>\n\n\n\n
    Secure golden paths\nContinuous security validation\nAttack-path analysis\nPurple teaming\nSecurity metrics tied to business risk\nAutomated remediation\nContinuous feedback<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    46. Anti-Patterns<\/h1>\n\n\n\n
    Anti-pattern 1<\/h2>\n\n\n\n
    Install 12 scanners\n=\nDevSecOps<\/code><\/pre>\n\n\n\n
    No.<\/p>\n\n\n\n
    \n\n\n\n
    Anti-pattern 2<\/h2>\n\n\n\n
    Block everything.<\/code><\/pre>\n\n\n\n
    Developers will eventually bypass security.<\/p>\n\n\n\n
    \n\n\n\n
    Anti-pattern 3<\/h2>\n\n\n\n
    Security owns every security problem.<\/code><\/pre>\n\n\n\n
    Doesn’t scale.<\/p>\n\n\n\n
    \n\n\n\n
    Anti-pattern 4<\/h2>\n\n\n\n
    Developers own all security.<\/code><\/pre>\n\n\n\n
    Also doesn’t scale.<\/p>\n\n\n\n
    \n\n\n\n
    Anti-pattern 5<\/h2>\n\n\n\n
    Pass compliance audit\n=\nSecure<\/code><\/pre>\n\n\n\n
    Compliance and security overlap, but they are not identical.<\/p>\n\n\n\n
    \n\n\n\n
    Anti-pattern 6<\/h2>\n\n\n\n
    Shift Left\n=\nIgnore production security<\/code><\/pre>\n\n\n\n
    Production remains where real attackers operate.<\/p>\n\n\n\n
    \n\n\n\n
    47. A Practical DevSecOps Operating Model<\/h1>\n\n\n\n
    A strong program can be represented as six layers:<\/p>\n\n\n\n
    \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502        SECURITY CULTURE             \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502        SECURE DESIGN                \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502        SECURE DEVELOPMENT           \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502        SECURE CI\/CD                 \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502        SECURE PLATFORM              \u2502\n\u251c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2524\n\u2502   RUNTIME SECURITY & RESPONSE       \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/code><\/pre>\n\n\n\n
    All six are important.<\/p>\n\n\n\n
    \n\n\n\n
    48. Recommended Implementation Roadmap<\/h1>\n\n\n\n
    Do not start with 30 tools.<\/p>\n\n\n\n
    Start with risk.<\/p>\n\n\n\n
    \n\n\n\n
    Phase 1 \u2014 Foundation<\/h2>\n\n\n\n
    Establish:<\/p>\n\n\n\n
    Asset inventory\nSecurity ownership\nSecurity standards\nData classification\nThreat modeling\nSecrets management\nLogging<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Phase 2 \u2014 Secure Development<\/h2>\n\n\n\n
    Introduce:<\/p>\n\n\n\n
    Secure coding training\nSAST\nSCA\nSecret scanning\nCode review rules<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Phase 3 \u2014 Secure Infrastructure<\/h2>\n\n\n\n
    Introduce:<\/p>\n\n\n\n
    Infrastructure as Code\nIaC scanning\nCloud configuration controls\nLeast privilege\nNetwork segmentation<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Phase 4 \u2014 Secure Supply Chain<\/h2>\n\n\n\n
    Introduce:<\/p>\n\n\n\n
    SBOM\nArtifact integrity\nDependency governance\nImage signing\nBuild provenance\nApproved registries<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Phase 5 \u2014 Runtime Security<\/h2>\n\n\n\n
    Introduce:<\/p>\n\n\n\n
    Continuous monitoring\nRuntime detection\nCloud threat detection\nSIEM\nIncident response<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Phase 6 \u2014 Continuous Improvement<\/h2>\n\n\n\n
    Introduce:<\/p>\n\n\n\n
    Purple teaming\nThreat intelligence\nAutomated remediation\nSecurity metrics\nSecurity champions\nContinuous compliance<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    49. A 90-Day Starter Plan<\/h1>\n\n\n\n
    Days 1\u201330<\/h2>\n\n\n\n
    Understand current state.<\/p>\n\n\n\n
    Inventory applications\nInventory pipelines\nInventory secrets\nIdentify critical assets\nIdentify internet-facing services\nDefine vulnerability severity policy\nEnable centralized logging<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Days 31\u201360<\/h2>\n\n\n\n
    Automate high-value security controls.<\/p>\n\n\n\n
    Secret scanning\nSAST\nSCA\nContainer scanning\nIaC scanning\nBasic policy checks<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    Days 61\u201390<\/h2>\n\n\n\n
    Improve operational security.<\/p>\n\n\n\n
    Threat modeling\nSecurity champions\nRuntime monitoring\nResponse playbooks\nRisk-based pipeline gates\nSecurity dashboards<\/code><\/pre>\n\n\n\n
    Do not attempt complete maturity in 90 days.<\/p>\n\n\n\n
    Build the feedback loop first.<\/p>\n\n\n\n
    \n\n\n\n
    50. The DevSecOps Feedback Loop<\/h1>\n\n\n\n
    A mature DevSecOps organization continuously learns.<\/p>\n\n\n\n
    flowchart LR\n    A[Build] --> B[Test]\n    B --> C[Deploy]\n    C --> D[Monitor]\n    D --> E[Detect]\n    E --> F[Learn]\n    F --> G[Improve Controls]\n    G --> A<\/code><\/pre>\n\n\n\n
    For example:<\/p>\n\n\n\n
    Production Attack\n      \u2193\nDetection\n      \u2193\nIncident Analysis\n      \u2193\nRoot Cause\n      \u2193\nNew Secure Coding Rule\n      \u2193\nNew SAST Rule\n      \u2193\nNew Unit Test\n      \u2193\nNew WAF Detection\n      \u2193\nDeveloper Training<\/code><\/pre>\n\n\n\n
    The incident produces engineering improvement.<\/p>\n\n\n\n
    \n\n\n\n
    51. The DevSecOps Infinite Loop<\/h1>\n\n\n\n
    Conceptually:<\/p>\n\n\n\n
                  PLAN\n           \u2197        \u2198\n       MONITOR      CODE\n         \u2191            \u2193\n       OPERATE      BUILD\n         \u2191            \u2193\n        DEPLOY \u2190 TEST<\/code><\/pre>\n\n\n\n
    Security participates throughout.<\/p>\n\n\n\n
    The goal is not:<\/p>\n\n\n\n
    Secure Release<\/code><\/pre>\n\n\n\n
    The goal is:<\/p>\n\n\n\n
    Continuous Secure Delivery<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    52. How the Manifesto Changes the Security Engineer’s Role<\/h1>\n\n\n\n
    Traditional:<\/p>\n\n\n\n
    Security Engineer\n      =\nReviewer\nGatekeeper\nAuditor<\/code><\/pre>\n\n\n\n
    DevSecOps:<\/p>\n\n\n\n
    Security Engineer\n      =\nSecurity Developer\nSecurity Architect\nPlatform Contributor\nRisk Advisor\nDetection Engineer\nAutomation Engineer\nSecurity Coach<\/code><\/pre>\n\n\n\n
    Security moves closer to engineering.<\/p>\n\n\n\n
    \n\n\n\n
    53. How It Changes the Developer’s Role<\/h1>\n\n\n\n
    Developers are no longer expected simply to:<\/p>\n\n\n\n
    Write feature\n\u2192\nSend it to security.<\/code><\/pre>\n\n\n\n
    They participate in:<\/p>\n\n\n\n
    Secure design\nSecure coding\nDependency management\nSecurity remediation\nThreat modeling\nSecurity testing<\/code><\/pre>\n\n\n\n
    But the platform should make these responsibilities practical.<\/p>\n\n\n\n
    \n\n\n\n
    54. How It Changes DevOps \/ Platform Engineering<\/h1>\n\n\n\n
    DevOps and platform teams become extremely important in DevSecOps because they own many control points:<\/p>\n\n\n\n
    CI\/CD\nInfrastructure as Code\nCloud IAM\nKubernetes\nSecrets\nArtifact Registries\nDeployment Platforms\nObservability<\/code><\/pre>\n\n\n\n
    A security team may define a policy.<\/p>\n\n\n\n
    Platform engineering often turns that policy into:<\/p>\n\n\n\n
    Code\n+\nAutomation\n+\nGuardrails<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    55. Example Transformation<\/h1>\n\n\n\n
    Before DevSecOps<\/h3>\n\n\n\n
    Developer commits code\n\n\u2193 3 weeks\n\nSecurity scan\n\n\u2193 200 vulnerabilities\n\nPDF report\n\n\u2193 Ticket\n\nDeveloper fixes\n\n\u2193 Rescan\n\nRelease delayed<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    After DevSecOps<\/h3>\n\n\n\n
    Developer opens PR\n        \u2193\nSecret Scan\n        \u2193\nSAST\n        \u2193\nSCA\n        \u2193\nIaC Scan\n        \u2193\nDeveloper receives feedback\n        \u2193\nFixes before merge\n        \u2193\nContainer Scan\n        \u2193\nDeploy Test\n        \u2193\nDAST\n        \u2193\nRisk Policy\n        \u2193\nProduction\n        \u2193\nRuntime Monitoring<\/code><\/pre>\n\n\n\n
    This captures the practical meaning of the manifesto.<\/p>\n\n\n\n
    \n\n\n\n
    56. DevSecOps Decision Framework<\/h1>\n\n\n\n
    For every security control, ask:<\/p>\n\n\n\n
    1. What risk are we addressing?<\/h3>\n\n\n\n
    Threat?\nAsset?\nImpact?<\/code><\/pre>\n\n\n\n
    2. Where should we detect it?<\/h3>\n\n\n\n
    IDE?\nPR?\nBuild?\nDeployment?\nRuntime?<\/code><\/pre>\n\n\n\n
    3. Can it be automated?<\/h3>\n\n\n\n
    Yes \u2192 Automate\n\nNo \u2192 Define human process<\/code><\/pre>\n\n\n\n
    4. Should it block delivery?<\/h3>\n\n\n\n
    Risk-based decision<\/code><\/pre>\n\n\n\n
    5. Who owns remediation?<\/h3>\n\n\n\n
    Explicit owner<\/code><\/pre>\n\n\n\n
    6. How will we measure effectiveness?<\/h3>\n\n\n\n
    Metric<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    57. DevSecOps Reference Architecture<\/h1>\n\n\n\n
                           \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502   Developer IDE     \u2502\n                       \u2502 Secure Coding       \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u25bc\n                       \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502   Source Control    \u2502\n                       \u2502 Secret Detection    \u2502\n                       \u2502 Code Review         \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u25bc\n                       \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502       CI            \u2502\n                       \u2502 SAST \/ SCA \/ IaC    \u2502\n                       \u2502 Unit Tests          \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u25bc\n                       \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502 Artifact Registry   \u2502\n                       \u2502 Scan \/ Sign \/ SBOM  \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u25bc\n                       \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502       CD            \u2502\n                       \u2502 Policy as Code      \u2502\n                       \u2502 Approval Rules      \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u25bc\n                       \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502 Runtime Platform    \u2502\n                       \u2502 Cloud \/ Kubernetes  \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u25bc\n                       \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502 Security Monitoring \u2502\n                       \u2502 SIEM \/ Detection    \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u25bc\n                       \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n                       \u2502 Incident Response   \u2502\n                       \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u252c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                                 \u2502\n                                 \u2514\u2500\u2500\u2500\u2500\u25ba Feedback to Engineering<\/code><\/pre>\n\n\n\n
    \n\n\n\n
    58. DevSecOps Checklist<\/h1>\n\n\n\n
    Planning<\/h2>\n\n\n\n
      \n
    • Security requirements identified<\/li>\n\n\n\n
    • Compliance requirements identified<\/li>\n\n\n\n
    • Data classified<\/li>\n\n\n\n
    • System criticality defined<\/li>\n<\/ul>\n\n\n\n
      Design<\/h2>\n\n\n\n
        \n
      • Threat modeling performed<\/li>\n\n\n\n
      • Authentication reviewed<\/li>\n\n\n\n
      • Authorization reviewed<\/li>\n\n\n\n
      • Trust boundaries identified<\/li>\n\n\n\n
      • Encryption architecture defined<\/li>\n<\/ul>\n\n\n\n
        Code<\/h2>\n\n\n\n
          \n
        • Secure coding standards<\/li>\n\n\n\n
        • Peer review<\/li>\n\n\n\n
        • Secret scanning<\/li>\n\n\n\n
        • SAST<\/li>\n\n\n\n
        • Dependency scanning<\/li>\n<\/ul>\n\n\n\n
          Build<\/h2>\n\n\n\n
            \n
          • Reproducible\/controlled build<\/li>\n\n\n\n
          • Container scanning<\/li>\n\n\n\n
          • SBOM generated<\/li>\n\n\n\n
          • Artifact integrity protected<\/li>\n<\/ul>\n\n\n\n
            Test<\/h2>\n\n\n\n
              \n
            • Security tests<\/li>\n\n\n\n
            • API tests<\/li>\n\n\n\n
            • DAST where appropriate<\/li>\n\n\n\n
            • Infrastructure validation<\/li>\n<\/ul>\n\n\n\n
              Deployment<\/h2>\n\n\n\n
                \n
              • Policy as Code<\/li>\n\n\n\n
              • Secure configuration<\/li>\n\n\n\n
              • Least privilege<\/li>\n\n\n\n
              • Secure secrets injection<\/li>\n<\/ul>\n\n\n\n
                Runtime<\/h2>\n\n\n\n
                  \n
                • Logs centralized<\/li>\n\n\n\n
                • Alerts configured<\/li>\n\n\n\n
                • Runtime security<\/li>\n\n\n\n
                • Vulnerability management<\/li>\n<\/ul>\n\n\n\n
                  Response<\/h2>\n\n\n\n
                    \n
                  • Incident response plan<\/li>\n\n\n\n
                  • Security ownership<\/li>\n\n\n\n
                  • Playbooks<\/li>\n\n\n\n
                  • Root-cause process<\/li>\n\n\n\n
                  • Feedback into engineering<\/li>\n<\/ul>\n\n\n\n
                    \n\n\n\n
                    59. Ten Questions Every DevSecOps Engineer Should Ask<\/h1>\n\n\n\n
                      \n
                    1. What are our most critical assets?<\/strong><\/li>\n\n\n\n
                    2. Where are our trust boundaries?<\/strong><\/li>\n\n\n\n
                    3. How could an attacker compromise this system?<\/strong><\/li>\n\n\n\n
                    4. Which security problems can we prevent automatically?<\/strong><\/li>\n\n\n\n
                    5. Which security problems can we detect automatically?<\/strong><\/li>\n\n\n\n
                    6. What should actually block deployment?<\/strong><\/li>\n\n\n\n
                    7. How quickly can developers understand and fix findings?<\/strong><\/li>\n\n\n\n
                    8. What happens when prevention fails?<\/strong><\/li>\n\n\n\n
                    9. How will we detect an attack in production?<\/strong><\/li>\n\n\n\n
                    10. How does what we learn in production improve development?<\/strong><\/li>\n<\/ol>\n\n\n\n
                      If your DevSecOps program can answer these questions clearly, it is probably moving in the right direction.<\/p>\n\n\n\n
                      \n\n\n\n
                      60. The Most Important Concept<\/h1>\n\n\n\n
                      DevSecOps is sometimes explained as:<\/p>\n\n\n\n
                      Put Security into DevOps.<\/code><\/pre>\n\n\n\n
                      A stronger definition is:<\/p>\n\n\n\n
                      \n
                      DevSecOps is an engineering operating model in which security becomes a shared, automated, measurable and continuously improving capability embedded throughout software design, development, delivery and operation.<\/strong><\/p>\n<\/blockquote>\n\n\n\n
                      The DevSecOps Manifesto therefore represents a transition:<\/p>\n\n\n\n
                      FROM\n\nSecurity Teams\nManually Inspecting\nSoftware Created by Others\n\n               \u2193\n\nTO\n\nEngineering Teams\nBuilding Security\nInto the System<\/code><\/pre>\n\n\n\n
                      \n\n\n\n
                      61. One Diagram to Remember Everything<\/h1>\n\n\n\n
                                               DEVSECOPS\n\n                            \u2502\n          \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n          \u2502                 \u2502                 \u2502\n        PEOPLE            PROCESS          TECHNOLOGY\n          \u2502                 \u2502                 \u2502\n   Collaboration       Secure SDLC        Automation\n   Shared Ownership    Threat Modeling    CI\/CD Security\n   Security Champion   Risk Management    Security as Code\n          \u2502                 \u2502                 \u2502\n          \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                            \u2502\n                            \u25bc\n                     SECURITY EVERYWHERE\n                            \u2502\n          \u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n          \u2502                 \u2502                 \u2502\n      SHIFT LEFT       SECURE DELIVERY    SHIFT RIGHT\n          \u2502                 \u2502                 \u2502\n      Design           CI\/CD Controls      Monitoring\n      Code             Policy as Code      Detection\n      Dependencies     Supply Chain        Response\n          \u2502                 \u2502                 \u2502\n          \u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u253c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518\n                            \u2502\n                            \u25bc\n                 CONTINUOUS FEEDBACK\n                            \u2502\n                            \u25bc\n                    CONTINUOUS IMPROVEMENT<\/code><\/pre>\n\n\n\n
                      \n\n\n\n
                      62. Final Mental Model<\/h1>\n\n\n\n
                      Remember these ten ideas:<\/p>\n\n\n\n
                      1. Security is everyone's responsibility.\n\n2. Security starts before coding.\n\n3. Automate repeatable security controls.\n\n4. Treat security configuration as code.\n\n5. Give developers fast, actionable feedback.\n\n6. Prioritize actual risk rather than scanner counts.\n\n7. Make secure behavior the easiest behavior.\n\n8. Security continues after deployment.\n\n9. Learn continuously from attacks and incidents.\n\n10. Security should enable engineering rather than\n    simply acting as a release gate.<\/code><\/pre>\n\n\n\n
                      And the entire DevSecOps Manifesto can be reduced to one transformation:<\/p>\n\n\n\n
                                OLD WORLD\n\nDevelopment \u2192 Operations \u2192 Security\n\n                 \u2193\n\n             DEVSECOPS\n\n\u250c\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2510\n\u2502 Development + Security + Operations \u2502\n\u2502                                      \u2502\n\u2502     collaborate continuously         \u2502\n\u2502     automate continuously            \u2502\n\u2502     test continuously                \u2502\n\u2502     monitor continuously             \u2502\n\u2502     learn continuously               \u2502\n\u2514\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2518<\/code><\/pre>\n\n\n\n
                      \n\n\n\n
                      63. Reference Framework<\/h1>\n\n\n\n
                      For further study, use these together:<\/p>\n\n\n\n
                      Resource<\/th>Purpose<\/th><\/tr>
                      DevSecOps Manifesto<\/td>Philosophy and culture<\/td><\/tr>
                      OWASP DevSecOps Guideline<\/td>Practical DevSecOps implementation<\/td><\/tr>
                      OWASP SAMM<\/td>Software security maturity<\/td><\/tr>
                      NIST SSDF<\/td>Secure software-development practices<\/td><\/tr>
                      OWASP ASVS<\/td>Application security requirements<\/td><\/tr>
                      OWASP Top 10<\/td>Common application risks<\/td><\/tr>
                      MITRE ATT&CK<\/td>Adversary techniques<\/td><\/tr>
                      CIS Benchmarks<\/td>Secure configuration guidance<\/td><\/tr>
                      SLSA<\/td>Software supply-chain integrity<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
                      OWASP’s DevSecOps project specifically aims to help organizations build secure pipelines and integrate security testing into normal development and delivery processes.<\/p>\n\n\n\n
                      NIST SSDF complements this by providing a structured set of secure software-development practices intended to integrate with existing SDLC models rather than requiring organizations to replace their development methodology.<\/p>\n\n\n\n
                      \n\n\n\n
                      64. Final Takeaway<\/h1>\n\n\n\n
                      The DevSecOps Manifesto is not primarily about adding more security tools.<\/strong><\/p>\n\n\n\n
                      It is about changing how security operates.<\/p>\n\n\n\n
                      Not:\n\n\"We need security approval before production.\"\n\n\nInstead:\n\n\"How do we engineer security into the way\nsoftware is designed, built, deployed,\noperated and continuously improved?\"<\/code><\/pre>\n\n\n\n
                      That is the heart of DevSecOps.<\/p>\n\n\n\n
                      Security becomes part of engineering rather than something engineering goes through.<\/strong><\/p>\n\n\n\n
                      <\/p>\n","protected":false},"excerpt":{"rendered":"
                      Complete Reference Tutorial \u2014 From Principles to Production Implementation Version: 1.0Updated: September 2026Level: Beginner \u2192 Intermediate \u2192 AdvancedAudience: Developers, DevOps… <\/p>\n","protected":false},"author":6,"featured_media":3148,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"series":[],"class_list":["post-3147","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"yoast_head":"\nDevSecOps Manifesto - DevSecOps School<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"DevSecOps Manifesto - DevSecOps School\" \/>\n<meta property=\"og:description\" content=\"Complete Reference Tutorial \u2014 From Principles to Production Implementation Version: 1.0Updated: September 2026Level: Beginner \u2192 Intermediate \u2192 AdvancedAudience: Developers, DevOps...\" \/>\n<meta property=\"og:url\" content=\"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/\" \/>\n<meta property=\"og:site_name\" content=\"DevSecOps School\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-29T08:46:04+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-29T08:46:05+00:00\" \/>\n<meta property=\"og:image\" content=\"http:\/\/devsecopsschool.com\/blog\/wp-content\/uploads\/2026\/09\/image-17.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1536\" \/>\n\t<meta property=\"og:image:height\" content=\"1024\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"rajeshkumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"rajeshkumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"10 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/\"},\"author\":{\"name\":\"rajeshkumar\",\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/#\\\/schema\\\/person\\\/3508fdee87214f057c4729b41d0cf88b\"},\"headline\":\"DevSecOps Manifesto\",\"datePublished\":\"2026-09-29T08:46:04+00:00\",\"dateModified\":\"2026-09-29T08:46:05+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/\"},\"wordCount\":2194,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/devsecopsschool.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/image-17.png\",\"inLanguage\":\"en\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/\",\"url\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/\",\"name\":\"DevSecOps Manifesto - DevSecOps School\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#primaryimage\"},\"thumbnailUrl\":\"http:\\\/\\\/devsecopsschool.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/image-17.png\",\"datePublished\":\"2026-09-29T08:46:04+00:00\",\"dateModified\":\"2026-09-29T08:46:05+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/#\\\/schema\\\/person\\\/3508fdee87214f057c4729b41d0cf88b\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#breadcrumb\"},\"inLanguage\":\"en\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en\",\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#primaryimage\",\"url\":\"http:\\\/\\\/devsecopsschool.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/image-17.png\",\"contentUrl\":\"http:\\\/\\\/devsecopsschool.com\\\/blog\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/image-17.png\",\"width\":1536,\"height\":1024},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/devsecops-manifesto\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"DevSecOps Manifesto\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/\",\"name\":\"DevSecOps School\",\"description\":\"DevSecOps Redefined\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/devsecopsschool.com\\\/blog\\\/#\\\/schema\\\/person\\\/3508fdee87214f057c4729b41d0cf88b\",\"name\":\"rajeshkumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g\",\"caption\":\"rajeshkumar\"},\"url\":\"http:\\\/\\\/devsecopsschool.com\\\/blog\\\/author\\\/rajeshkumar\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"DevSecOps Manifesto - DevSecOps School","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/","og_locale":"en_US","og_type":"article","og_title":"DevSecOps Manifesto - DevSecOps School","og_description":"Complete Reference Tutorial \u2014 From Principles to Production Implementation Version: 1.0Updated: September 2026Level: Beginner \u2192 Intermediate \u2192 AdvancedAudience: Developers, DevOps...","og_url":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/","og_site_name":"DevSecOps School","article_published_time":"2026-09-29T08:46:04+00:00","article_modified_time":"2026-09-29T08:46:05+00:00","og_image":[{"width":1536,"height":1024,"url":"http:\/\/devsecopsschool.com\/blog\/wp-content\/uploads\/2026\/09\/image-17.png","type":"image\/png"}],"author":"rajeshkumar","twitter_card":"summary_large_image","twitter_misc":{"Written by":"rajeshkumar","Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#article","isPartOf":{"@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/"},"author":{"name":"rajeshkumar","@id":"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b"},"headline":"DevSecOps Manifesto","datePublished":"2026-09-29T08:46:04+00:00","dateModified":"2026-09-29T08:46:05+00:00","mainEntityOfPage":{"@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/"},"wordCount":2194,"commentCount":0,"image":{"@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#primaryimage"},"thumbnailUrl":"http:\/\/devsecopsschool.com\/blog\/wp-content\/uploads\/2026\/09\/image-17.png","inLanguage":"en","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/","url":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/","name":"DevSecOps Manifesto - DevSecOps School","isPartOf":{"@id":"https:\/\/devsecopsschool.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#primaryimage"},"image":{"@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#primaryimage"},"thumbnailUrl":"http:\/\/devsecopsschool.com\/blog\/wp-content\/uploads\/2026\/09\/image-17.png","datePublished":"2026-09-29T08:46:04+00:00","dateModified":"2026-09-29T08:46:05+00:00","author":{"@id":"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b"},"breadcrumb":{"@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#breadcrumb"},"inLanguage":"en","potentialAction":[{"@type":"ReadAction","target":["https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/"]}]},{"@type":"ImageObject","inLanguage":"en","@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#primaryimage","url":"http:\/\/devsecopsschool.com\/blog\/wp-content\/uploads\/2026\/09\/image-17.png","contentUrl":"http:\/\/devsecopsschool.com\/blog\/wp-content\/uploads\/2026\/09\/image-17.png","width":1536,"height":1024},{"@type":"BreadcrumbList","@id":"https:\/\/devsecopsschool.com\/blog\/devsecops-manifesto\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/devsecopsschool.com\/blog\/"},{"@type":"ListItem","position":2,"name":"DevSecOps Manifesto"}]},{"@type":"WebSite","@id":"https:\/\/devsecopsschool.com\/blog\/#website","url":"https:\/\/devsecopsschool.com\/blog\/","name":"DevSecOps School","description":"DevSecOps Redefined","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/devsecopsschool.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en"},{"@type":"Person","@id":"https:\/\/devsecopsschool.com\/blog\/#\/schema\/person\/3508fdee87214f057c4729b41d0cf88b","name":"rajeshkumar","image":{"@type":"ImageObject","inLanguage":"en","@id":"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g","caption":"rajeshkumar"},"url":"http:\/\/devsecopsschool.com\/blog\/author\/rajeshkumar\/"}]}},"_links":{"self":[{"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/3147","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=3147"}],"version-history":[{"count":1,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/3147\/revisions"}],"predecessor-version":[{"id":3149,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/3147\/revisions\/3149"}],"wp:featuredmedia":[{"embeddable":true,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/media\/3148"}],"wp:attachment":[{"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=3147"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=3147"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=3147"},{"taxonomy":"series","embeddable":true,"href":"http:\/\/devsecopsschool.com\/blog\/wp-json\/wp\/v2\/series?post=3147"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}