This document outlines an approach for integrating security into the software development lifecycle (SDLC) using DevSecOps principles. It discusses how security can shift left by being incorporated into various phases of product development and delivery, including product management, design, development, deployment, defect management, and monitoring. It provides examples of how to integrate security practices and tools at each stage. The goal is to establish security as a critical product feature rather than an afterthought, and foster collaboration between security and development teams through a DevSecOps model and maturity criteria.

1. Security’s DevOps Transformation
How You *really* Get to “Shift Left”

2. 2
Warning:
Silly Memes Ahead

3. 3
What This Talk Isn’t

4. 4
“In working with many organizations over the years, we’ve encountered a common
perception that security processes and procedures are mostly security theater, with
very little impact on overall security posture. This mindset doesn’t help already
strained relationships between the security team and other delivery teams.”
From “2019 State of DevOps Report | Presented by Puppet, CircleCI & Splunk”
End of Security Theater

5. 5
•If you want to make developers care about security, you have to speak their language,
i.e. Agile and DevOps.
•Focus on “Security as a feature” in the product portfolio otherwise it’s just another
set of NFRs (non-functional requirements) in the backlog.
•Remove heavy “gates” that block continuous development and shift “to the left” with
security practices by building security validation into multiple phases of product
development and delivery.
•Offer security capabilities as a platform or toolchain.
DevSecOps Is the New DevOps

6. 6
What Security People Think

7. 7
What Developers Think

8. 8
Integrating Security Into Your SDLC
1. DevSecOps
2. Product Management
3. Design and Develop
4. Deliver and Deploy
5. Defect Management
6. Monitoring
7. DevOps Security Maturity Criteria

9. 9
Leaning in over Always Saying “No”
Data & Security Science over Fear, Uncertainty and Doubt
Open Contribution & Collaboration over Security-Only Requirements
Consumable Security Services with APIs over Mandated Security Controls & Paperwork
Business Driven Security Scores over Rubber Stamp Security
Red & Blue Team Exploit Testing over Relying on Scans & Theoretical Vulnerabilities
24x7 Proactive Security Monitoring over Reacting after being Informed of an Incident
Shared Threat Intelligence over Keeping Info to Ourselves
Compliance Operations over Clipboards & Checklists
http://www.devsecops.org/
DevSecOps Manifesto

10. 10

11. 11
•Build security, compliance and risk topics into an MVP
template.
•Security as a product “feature.”
•Refining roadmaps with product managers (and customers)
to consider security and compliance needs.
Security: Product Management

12. 12
Security MoSCoW Feature Example
Must Have:
MFA support
Obfuscation of NPI in UI
Encryption of data-at-rest and in-transit
Proper key management
Input validation
Should Have:
Real-time security event monitoring
Could Have:
Automated security alerts sent to chatbot
Won’t Have:
Automated threat detection integration

13. 13

14. 14
•Use nimble threat modeling techniques with product owner and development team
through questionnaires and workflow tools.
•Integrate User Security Stories into sprints with product team.
•Train developers on secure coding techniques/standards.
•Architecture risk reviews.
•“Policy as Code” Establish what needs to be enforced with security’s technical
requirements, then operationalize with DevOps teams through automation systems
in order to align with the CI/CD pipeline.
Design and Develop

15. 15
https://github.com/OWASP/user-security-stories
User Security Story

16. 16
•Supply Chain Security using pre-validated, hardened Golden Images (VMs, AMIs
and Containers).
•Integration of automated security testing and validation tools through a
DevSecOps Toolchain built into the deployment pipeline(s).
•Aspire to fail builds before vulnerabilities are introduced.
•Prevent deployment of non-compliant Infrastructure-as-Code.
Deliver and Deploy

17. 17

18. 18

19. 19
Example
DevSecOps
Toolchain

20. 20

21. 21
•Product security vulnerabilities addressed along with other product defects.
•Security defect severity levels align with CVSS, CWSS scores.
•Establish SLAs for remediation. Track product security defects within product
ALM.
•Remediation and tracking of Priority 1 defects handled via incident management
process.
Defect Management

22. 22
• Automated post-deployment monitoring and enforcement, when possible.
• Violation of standards results in automatic shutdown/deletion of running assets.
• Automated detection and remediation of security incidents (aspirational goal).
Monitoring

23. 23

24. 24
• Include security criteria in DevOps
maturity scoring.
• Create ongoing partnership with
DevOps/Agile practitioners.
• Measure team success and
opportunities for improvement.
DevOps Security Maturity Model

25. 25
DevOps Security Maturity Elements
Categories Description
Technology What security controls we
use.
Process How we implement
technologies.
People Who implements or uses the
processes and technologies.
Culture Establishing why security is
critical to the business.

26. 26
DevOps Security Scoring Levels
Scores Description
Basic (aka Crawl or
Walk)
Reactive approach, no contextual reporting or metrics to demonstrate
progress, checkbox-driven compliance approach. No collaboration
between security and development teams.
Progressing (aka run
or leap)
Technology-driven approach. Tools are not fully integrated to provide
automated decision points in CI/CD pipeline. Testing occurs, but security
still happens late, generally closer to the end of the development cycle.
Security focuses on remediation of defects, not prevention.
Advanced (aka fly) Security is proactive by shifting-left and is integrated within all areas of
application development; product management, sprint grooming, and
testing. Security tools provide automated validation in DevOps pipelines
and output is used for metrics in demonstrating success of program.

27. 27
Technology Criteria
Category Basic Progressing Advanced
Technology Tools are an afterthought, not
integrated into pipelines and not
validated for automation
capabilities.
Tools have APIs or CLIs
that can be used in
automation build pipelines,
but not tested. Output may
be used for tracking and
reporting “soft” fails.
Existence of
DevSecOps toolchain
capable of security
validation at multiple
points in the DevOps
supply chain. Modular
and portable, aligned
with DevOps platform
tools.

28. 28
Process Criteria
Category Basic Progressing Advanced
Process Reactive, no automation. Little to
no correlation of output from
tooling.
Output from tooling may be
integrated into CI/CD, but not used
as criteria for completing build.
Security metrics generated, but
defects not tracked in ALM.
DevSecOps toolchain is
well-documented and
easily consumable by
developers in order to
embed into pipelines.
Criteria is clear for
“breaking builds” or “hard”
fails with clear path for
remediation and
identifying false positives.
Proactive security
becomes reality.

29. 29
People Criteria
Category Basic Progressing Advanced
People White-glove, manual processes.
No security-minded culture
within development teams.
Security activities are avoided
and development teams are not
empowered by knowledge of
application security “best
practices.”
Developers have some
understanding of security
requirements, but not prioritized
in backlogs. Application security
practices are inconsistent and
knowledge is spotty among
developers.
Security is included from
product inception. User
security stories are
embedded in software
projects. Reference
models are used by
development team.
Secure coding training is
required and teams have
at least one Security
Champion. There is cross-
functional collaboration
between security and
development teams.

30. 30
Culture Criteria
Category Basic Progressing Advanced
Culture No partnership or collaboration
between security and
development teams. SSDLC
strategy is unclear and not
mapped to practices. “Security as
Roadblock.”
Recognition that security should
be integrated better, but still
considered a lower-priority, non-
functional requirement in the
backlog. “Security as
Inconvenience.”
Security evolves from
NFR to critical product
feature. Through cross-
functional partnership,
security “shifts left” and is
embedded into earliest
phases of product
management lifecycle.
“Security as Feature.”

31. 31
Technology Objectives
Ref # Component Short-term goal Long-term goal
Tech.1 SAST/DAST/IAST Inventory current tooling to understand which tools
support automation and fulfill test coverage across
software projects, Identify gaps.
Tools that are flexible and integrate into
DevSecOps Toolchain with the
comprehensive test coverage across
projects.
Tech.2 Dependency
checking/OSS/license
compliance
Inventory current tooling to understand which tools
support automation and fulfill test coverage across
software projects, Identify gaps.
Tools that are flexible and integrate into
DevSecOps Toolchain with the
comprehensive test coverage across
projects.
Tech.3 IDE Plugins Inventory current tooling, verify code coverage and usage. Comprehensive IDE plugin coverage
across projects.
Tech.4 Security metrics
correlation and
reporting tools
Identify how application security vulnerability results are
currently correlated across projects and opportunities for
Correlation tool that assists in providing
metrics to measure improvements in
DevOps Security Maturity.
Tech.5 Monitoring, alerting and
prevention
Inventory current capabilities, identify gaps. Focus on prevention opportunities
(WAF, RASP)

32. 32
Process Objectives
Ref # Component Short-term goal Long-term goal
Proc.1 DevSecOps Toolchain for
continuous security testing
Build active prototype in collaboration between DE,
Cyber Architecture/Engineering to validate in
OnePipeline
Working DevSecOps toolchain that
transparently interacts with the build
pipeline to actively prevent the
deployment of vulnerable applications.
Proc.2 Automated vulnerability
metric reporting.
Investigate how vulnerabilities are reported/tracked
across software projects.
Automated metrics reporting per AIT to
measure security vulnerability
remediation improvements.
Proc.3 Defect management Identify opportunities for alignment with product defect
management and ALM.
Integrate security defect management
SLAs into product ALM to measure
security maturity improvements.
Proc.4 Architectural risk
assessments
Identify intake process with questionnaire to assist in
creation of architectural documents necessary to
assess risk.
Process based on OWASP ASVS to
provide continuously updated
documentation.
Proc.5 Threat Modeling Improve intake process and training to empower
application development teams. Identify opportunities
for self-service.
Use self-service questionnaires to
create threat models that are
continuously updated.

33. 33
People Objectives
Ref # Component Short-term goal Long-term goal
People.1 Reference Models Create documentation for current application
architecture.
To improve security and efficiency, build
standard reference models for types of
application architectures including cloud-native
and 12-factor.
People.2 Secure Coding Training Build standard secure coding curriculum for
developers.
Include secure coding training into
professional development plans for
developers.
People.3 User Security Stories Build a User Security Stories template in Jira that
can be leveraged for product backlogs.
Embed user security stories and acceptance
criteria into all product backlogs.
People.4 Security Champions Identify delegates within application teams to
collaborate with Cyber in creation of cross-
functional security capabilities.
Build the program strategy, including training
and mentoring of members. Delegates act as
advocates, evangelizing “best practices.”
People.5 Readiness Checklists Build security checklists for applications to use to
validate security in production readiness state.
Embed security readiness checklists in
application onboarding process.

34. 34
Culture Objectives
Ref # Component Short-term goal Long-term goal
Cult.1 Security as a feature Evangelize the “shift left” concept for efficiently and
effectively adding security to the application
development process.
Security components are associated with a
functional request. Security is seen as a value-add
for the customer.
Cult.2 Policy as code Identify opportunities to transform applications by
using secure coding practices to embed security
requirements.
The next generation of application security, which
codifies security policies, standards and baselines
into the software and architecture.
Cult.3 MVP Contract: Risk
and compliance
topics
Create MVP contract template with risk and
compliance topics that can be used to define security
requirements at product inception.
Standardize the use of MVP contracts across the
organization.
Cult.4 SSDLC strategy Articulate elements of SSDLC in written strategy,
disseminate to Delivery Experience team and Agile
CoP for feedback.
Collaborate with development teams to create a
strategic feedback loop for security components of
the software development lifecycle.
Cult.5 Information Security
partnership
Identify collaboration challenges and opportunities for
improvement.
Build a cross-functional partnership to continuously
improve software development.

35. 35
From James Wickett’s, “A DevSecOps Tale of Business, Engineering and People”