Getting Started With DevSecOps

As organizations increasingly adopt DevOps, the approach to security must evolve alongside it. Modern software development introduces complex supply chains that include not just your code but also third-party components, CI/CD tools, and cloud environments. DevSecOps addresses this expanded attack surface by embedding security into every stage of the pipeline, ensuring that all dependencies and artifacts are trustworthy and protected.

This Refcard aims to help readers understand how to build or improve a DevSecOps program by identifying key security risks in the software delivery lifecycle, applying core principles for secure development and deployment, and integrating practical controls and automation strategies that scale with modern pipelines. Whether you're just starting or looking to mature your program, this Refcard provides actionable insights for embedding security into your DevOps culture and workflows.

Cybersecurity has changed dramatically in recent decades. Table 1 reviews some of the key differences between security "then" (before 2010) and security "now" (2010–present):

Table 1

To understand why security matters for DevOps, we must first consider the value DevOps delivers and what needs protecting. If you're tasked with building or enhancing a DevSecOps program, frameworks like BSIMM, CSA CCM, or ISO/IEC 27017 can offer guidance. Compliance-specific frameworks are also increasingly mandating DevSecOps practices for organizations in regulated industries or those handling sensitive data.

The following table provides an overview of various security- and compliance-related frameworks:

Table 2

An effective DevSecOps program is built on continuous feedback loops. Developers, security engineers, and operations must all have real-time visibility into risks and remediation guidance. The earlier these insights surface — ideally in the IDE or pull request — the faster and more effectively teams can respond. However, implementing DevSecOps at scale often proves complex. Teams should therefore embrace Policy as Code: embedding security and compliance checks directly into CI/CD workflows (e.g., blocking deployments with critical vulnerabilities or unsigned code).

Key Integration Points in the DevSecOps Lifecycle

Security must be embedded across the SDLC, not bolted on after the fact. Below are key integration points mapped to delivery stages:

• Pre-Commit – use secret scanners, linters, and secure coding plugins directly in the developer's IDE
• Build – automate SAST, dependency scanning, container checks, and code signing; secure CI/CD pipelines
• Test – run DAST, IaC analysis, and vulnerability scanning in isolated environments
• Deploy – enforce Policy as Code (e.g., reject unsigned builds or critical CVEs) and validate signatures
• Run – monitor with WAF, RASP, and anomaly detection; collect telemetry for proactive defense and incident response

Embedding security at each stage minimizes gaps, shortens remediation time, and builds trust into your pipeline.

A Simple DevSecOps Framework

DevSecOps is about designing, building, and maintaining secure software. There are five main categories of DevSecOps activities: govern, find, fix, prevent, and measure and improve.

Govern

There are a number of high-level factors to consider when you are thinking about DevSecOps, including compliance regulations, relationships with other organizations, and having a solid understanding of what you're supposed to be securing in the first place. It's also important to define metrics up front so that you can demonstrate the success of your program over time.

Find

There are many ways to find security problems at different points in any SDLC, whether your organization follows a Waterfall, Agile, or DevOps methodology. Security problems exist in two broad categories: bugs and flaws. You can think of bugs as code-level security issues and flaws as design-level security issues.

Fix

It is not good enough to just focus on finding security issues — the quality of software does not improve until the problems are addressed or eliminated. Fixing security issues requires effective communication, coordination, and integration with development teams and processes.

Prevent

Developers building the software must understand why vulnerable code is insecure, and therefore, must be empowered with tech-stack-specific knowledge and tools to help them avoid creating security bugs and flaws. Ideally, good programming practices and well-designed frameworks make it easier for developers to write secure software by default and harder for them to make mistakes.

Measure and Improve

DevSecOps is not a one-time setup but an evolving capability. Set clear KPIs like fixed rates, coverage ratios, and false positive rates. Use dashboards to track test effectiveness over time and correlate security outcomes with business impact. Continuously improve by analyzing where vulnerabilities are introduced and why — across people, tools, and processes.

In short, cloud environments must be configured correctly to prevent security vulnerabilities from being exploited, and attacks should be discovered and stopped as early as possible to minimize damage.

There are several key methods and techniques that can be used to incorporate DevSecOps into the SDLC. Less mature DevSecOps programs use a few approaches, while more mature DevSecOps programs may use several.

Code Signing for Software Integrity

Code signing is a foundational DevSecOps practice that ensures that software artifacts have not been tampered with and originate from a trusted source. By cryptographically signing executables, containers, scripts, and Infrastructure-as-Code (IaC) templates, organizations can enforce trust, integrity, and provenance across the SDLC.

Code signing helps:

• Ensure software integrity and authenticity
• Build trust across internal and external software supply chains
• Block unsigned or malicious artifacts from being deployed
• Meet compliance standards
• Reduce risk of malware injection through compromised or spoofed releases

Code signing provides irrefutable proof of authorship and content integrity, making unauthorized modifications detectable. It also supports legal non-repudiation by ensuring you can prove, cryptographically, that a specific version of software was (or was not) created and released by your organization.

To be effective at scale, code signing must be integrated into the SDLC and automated through CI/CD pipelines as manual signing processes are slow and error prone. Integrated workflows using tools like Sigstore (Cosign) or GitHub Actions enable continuous signing, verification, and artifact validation without interrupting release velocity.

Private signing keys must be protected using secure, access-controlled environments such as hardware security modules (HSMs) that are FIPS 140-2 Level 2 or EAL4+ certified, or cloud-native services like AWS KMS, Azure Key Vault, or GCP KMS. Never store keys in plaintext files, source code repositories, or local machines.

Implement automated key rotation policies to reduce the window of opportunity for key misuse. Rotate keys regularly, and ensure proper key revocation procedures are in place. It's also crucial to go beyond key rotation:

• Define clear policies for key generation, usage, storage, expiration, renewal, and revocation
• Enforce role-based access controls, separation of duties, and least privilege to minimize the risk of key compromise

Governance policies should guide developers and release engineers on compliant practices, audit readiness, and regulatory requirements.

Success Metrics

Like any business initiative, a DevSecOps program should have objectives and measurements to determine if those objectives are being met. And every DevSecOps practitioner needs to know how to optimize their unique program using data, metrics, and risk management objectives. For example, a risk management objective for DevSecOps could be to "Reduce the probability of attackers causing critical applications to stop functioning."

A typical metric that organizations use to help measure DevSecOps success is defect density, meaning the number of vulnerabilities divided by lines of code (lines of code are typically indicated by the 1000s). Additional integrity-focused metrics can include:

• Percentage of signed builds/releases
• Time since last key rotation
• Number of unauthorized artifacts blocked due to signature mismatch

These metrics help track the maturity of secure software delivery practices and supply chain protection.

A security metric often measures activities to provide decision support to perform functions better in the future. This data can help answer questions that an executive or operator might have about a particular area (e.g., source code review) using evidence-based information instead of opinion or anecdotes. It is indisputable that measuring results and performance is crucial to an organization's effectiveness, and this definitely applies to DevSecOps.

Defect Discovery and Testing

Penetration tests (also known as "pen tests") are a type of manual security testing that provides insight into an application's security by systematically reviewing its features and components. This type of exercise improves the security coverage because the test is intended to explore the complete app rather than just focus on one type of vulnerability or particular section. Pen tests follow methodologies related to topics like input validation, authentication, and access controls to identify flaws in the app's implementation.

Pen Testing as a Service (PTaaS) provides on-demand manual penetration testing for web applications, mobile applications, and APIs. Findings are delivered through a platform that integrates with developer tracking systems like JIRA and GitHub. A SaaS platform also facilitates collaboration between pen testers, security team members, and development teams to not only find but also fix issues.

Security scanners can be programmed to automatically identify certain vulnerabilities. DevSecOps scanners come in two flavors:

• Static application security testing (SAST) scanners examine an application's source code, binary, or byte code.
• Dynamic application security testing (DAST) scanners examine the application from the outside when it is running.

These scanners often support the creation of software bills of materials (SBOMs), which list all software components and their versions. SBOMs provide visibility into dependencies — especially third-party and open-source ones — and help assess risk across applications. They are essential for identifying vulnerabilities tied to widely used libraries and enable faster response to CVEs or zero-days. SBOMs also support compliance and are often required during vendor assessments, alongside penetration test results or policy documentation. DevSecOps teams can generate SBOMs using integrated scanner outputs or standalone tools.

Code review is the manual review of one developer's code by another developer. It's intended to find mistakes and improve code quality. Similarly, secure code review is a manual code review by a security expert, which is intended to find coding errors that may introduce security vulnerabilities. Secure code review is a manual process that often leverages SAST technology. Every so often, a security researcher not directly associated with an organization will discover and report a security vulnerability, which is called vulnerability disclosure. 

Table 3: AI tools that support code reviews

A bug bounty is a type of vulnerability disclosure program that leverages a crowd of globally sourced researchers in competition. In a public bug bounty, anyone in the world can submit a potential security vulnerability to an organization, and the first to find a valid bug will be paid a "bounty."

Teamwork

Once security testing has identified potential issues, the next step is to collaborate across teams to prioritize, address, and prevent them. The development team is a critical stakeholder when it comes to prioritizing fixes, remediating issues, and ideally, preventing the same issues from coming up again.

Known vulnerabilities often have threat rankings already that can be used with your own internal criteria to set severity and time frame for changes. There are also useful resources on how to mitigate or fix issues for known vulnerabilities from the National Vulnerability Database (NVD) and dev communities.

Now that you have inventoried your software and identified security issues, you need to keep track of what has been tested, by what means, and when. Monitor the findings from each security test and prioritize any necessary bug fixes or feature enhancements. In doing so, use business context to better understand which issues matter the most and work with development teams to fix those first.

Make sure you always know which issues are open and which have been addressed and can be closed. Then, report summary information to the relevant stakeholders so that everyone is always aware of the current status. 

Proactive Techniques

The best DevSecOps training for developers is based on real security findings, whether these trainings are demonstrated during an actual security incident or found via manual penetration testing. The OWASP Top 10 contains a list of common DevSecOps risks; however, each organization will have its own unique top 10 list. Within your own organization, use this information to prevent entire categories of security vulnerabilities by implementing developer-focused training.

Threat modeling is a type of design-level security assessment that is intended to examine the way an application system works to identify potential flaws. The process involves analyzing assets, security controls, and threat actors within an application system. When flaws are detected using threat modeling before software implementation, some security problems can be avoided.

A few examples of preventive security controls informed by threat modeling:

• Cross-site request forgery tokens prevent cross-site request forgery attacks.
• A content security policy defines open-list assets that the browser allows to load and execute, thus minimizing the impact of cross-site scripting exploits.
• HTTP Strict Transport Security encrypts data in transit and prevents fallback to non-HTTPS traffic.

Other security issues can be avoided by securely configuring the software environment, for example, by following the Amazon CIS benchmark to harden AWS accounts and cloud services. Similarly, code signing acts as a preventive control by making unauthorized modification of software detectable.

• Mandate digital signing of executables, containers, and IaC artifacts.
• Use signed commits and verified authorship in version control systems (e.g., Git with GPG or Sigstore).
• Educate teams on the importance of signature trust chains and how to validate them.

There are various tools meant to protect an application by identifying and stopping malicious activity while the application is running:

• Web application firewalls (WAF) examine web traffic to identify and block suspicious activity, such as comment spam, XSS, and SQL injection attacks.
• Runtime application self-protection (RASP) operates in the runtime environment to monitor, detect, and alert in real time.
• Interactive application security testing (IAST) works inside an application, typically in a QA environment, to analyze code and report vulnerabilities.

Both WAF and RASP can be run in either "detect and alert" or "detect, alert, and block" mode. They are most effective at preventing security issues when running in "detect, alert, and block" mode. However, this forces the business to risk blocking legitimate application activity and malicious activity.

The "Three Ways" of Security

For decades, both software and security have struggled with poor-quality results, cost overruns, and processes that require experts. While DevOps has shown promise on the software side, security is still practiced in very traditional ways. DevSecOps is not just shoving traditional security practices and tools into DevOps.

Instead, we must rethink safety work and will need new practices and technologies to do this. We can give this transformation structure using the "Three Ways" from The Phoenix Project. By framing the problem this way, we can see that we need to:

• Get security work flowing – Most security work is monolithic and attempts to cover all risks in a single task, like a complete security architecture or security scan.
• Ensure instant security feedback – Security is one of the most common causes of technical debt, and the cost of this work increases dramatically the further it progresses across the SDLC. Several reasons include a lack of knowledge and limited security specialists.
• Create a security culture – Many organizations have a security culture of blind trust, blame, and hiding that prevents developers and operations from working with security.

How to tackle the "Three Ways" of security:

• Get your security work flowing
  • Make the work visible
  • Work a single security challenge at a time
  • Limit work in progress and reduce handoffs
  • Automate everything in your CI/CD pipeline
• Ensure instant security feedback
  • Increase awareness about the importance of security
  • Identify potential problems
  • Make problems instantly visible
  • Swarm on the problem and seek the cause
  • Ensure security "findings" are designed for easy consumption
  • Focus on providing a solution rather than exaggerating the problem
• Encourage a culture of security
  • Empower everyone to challenge security design and implementation
  • Take every opportunity to make security threats, policies, architecture, and vulnerabilities visible
  • Allow everyone on the team to participate in security
  • Trust that engineering teams want to do the right thing
  • Celebrate the knowledge gleaned from security issues rather than blaming those involved
  • Dedicate more time and effort on upgrading practices and preventive measures than on vulnerability remediation and incident response
  • Plan trainings and conduct workshops to maintain continuous security throughout all teams

By following these core approaches, teams will see security as a concrete output from the development process. It is a combination of security features and assurance captured in a tangible way. By applying DevOps concepts, we can produce this concrete security continuously and effectively as a part of standard software development.

The "Five Ideals"

Six years after The Phoenix Project was released, The Unicorn Project was published in 2019. The Unicorn Project is not the sequel to The Phoenix Project. In fact, the stories of both novels take place along the same timeline and provide two different perspectives. The Phoenix Project introduces the "Three Ways" of security, whereas The Unicorn Project introduces "The Five Ideals."

Gene Kim, the author of both books, introduces "The Five Ideals" to frame today's modern business and engineering challenges:

1. Locality and simplicity relates to the degree to which a development team can make local code changes in a single location without impacting various teams.
   • We need to design things so that we have locality in our systems and the organizations that build them. We need simplicity in everything we do.
   • The last place we want complexity is internally, whether it's in our code, organization, or processes.
2. Focus, flow, and joy is all about how our daily work feels.
   • Is our work marked by boredom and waiting for other people to do things for us?
   • Do we blindly work on small pieces of the whole, only seeing the outcomes of our work during deployment when everything blows up, leading to firefighting, punishment, and burnout? Or do we work in small batches, ideally single-piece flow, getting fast and continual feedback on our work?
   • These are the conditions that allow for focus and flow, challenge, learning, discovery, mastering our domain, and even joy. This is what being a developer means.
3. Improving daily work addresses paying down technical debt and improving architecture.
   • When technical debt is treated as a priority and paid down, and architecture is continuously improved and modernized, teams can work with flow, delivering better value sooner, safer, and happier.
   • The business ultimately wins when developers can meet enterprise performance goals.
4. Psychological safety is one of the top predictors of team performance.
   • When team members feel safe to talk about problems, problems can not only be fixed but also prevented. Solving problems requires honesty, and honesty requires an absence of fear.
   • In knowledge work, psychological safety should be treated with the same importance as physical safety is treated in manufacturing.
5. Customer focus relates to the difference between core and context as defined by Geoffrey Moore.
   • Core is what customers are willing and able to pay for, the bread and butter of your business, while context is what they don't care about and what it took to get them that product, including all of an organization's back-end systems (e.g., HR, marketing, development).
   • It's critical to look at these context systems as essential and fund them appropriately. Context should never kill the core.

Here are some key criteria for how to set up a DevSecOps program:

• Check for accurate software inventory
  • Maintain a complete and detailed inventory of all your web, mobile, and cloud applications and APIs
  • Generate and manage SBOMs to track all software components, including dependencies, versions, and open-source tools
• Conduct risk ranking
  • Assign a risk rank to each piece of software based on multiple criteria (e.g., business criticality; data sensitivity, exposure, accessibility)
  • Prioritize software that has access to low-level system controls, root privileges, or privileged execution environments since compromise of these components can lead to high-impact attacks and systemic breaches
  • High-risk applications should have enhanced and targeted security activities compared to lower-risk ones, such as more frequent assessments, stricter deployment gates, and additional monitoring
  • For identified vulnerabilities, set timelines for fixing them based on their risk ranking
• Incorporate code signing
  • Sign all production artifacts, including binaries, containers, scripts, and IaC templates
  • Integrate automated code signing into CI/CD pipelines to ensure consistent artifact integrity
  • Enforce verification of digital signatures as part of deployment gates and release approvals
  • Use standard-compliant signing protocols (e.g., X.509 certificates, Cosign for containers)
  • Maintain an inventory of signed artifacts and track who signed them and when
• Follow key management best practices
  • Store private signing keys in secure environments
  • Enforce least privilege access controls and maintain detailed audit logs for all key operations
  • Implement key rotation policies regularly or in response to potential compromise, and automate provisioning, rotation, renewal, and revocation using tools integrated with your CI/CD workflows
  • Continuously monitor for unauthorized key usage and alert on anomalous behavior to maintain the integrity of the code signing process
• Adhere to compliance and governance requirements
  • Identify and align security controls based on your application's business function, data sensitivity, and geographical compliance requirements 
• Sign your software releases
  • Sign your software to establish authenticity and integrity
  • Enable users and systems to verify signatures to detect tampering and prevent compromised releases

Not all DevSecOps journeys look the same. A maturity model helps benchmark your organization's current state and identify realistic next steps. Use the model below to prioritize improvements and track adoption milestones. Aim for steady progress over perfection.

• Level 0: Ad Hoc – no formal security integration, reactive fixes
• Level 1: Basic – static analysis in CI/CD, occasional reviews
• Level 2: Automated – scanners, code signing, and secrets detection integrated into pipelines
• Level 3: Intelligent – risk-based triage, context-aware testing, developer feedback loops
• Level 4: Embedded – security ownership distributed, threat modeling automated, Policy as Code enforced
• Level 5: Predictive – real-time analytics, adaptive defense, self-healing security pipelines

DevSecOps is a team effort. Security professionals can't do it alone; they must collaborate with development teams. A holistic approach that matches DevSecOps talent and resources with the right technology is required to run the program. Each organization will have a business-specific context for different resource allocation tradeoffs, program-level metrics, and KPIs.

Today's requirements for DevSecOps activities include:

• Costs that enables higher frequency testing and greater coverage across an application portfolio
• Access to quality security talent who can perform manual testing on demand
• Strong integration with development processes and tools in order to fix security issues and prevent them in the future

DevSecOps activities must be agile, actionable, and cost effective. Incorporating code signing into your DevSecOps pipeline helps build verifiable trust into every release. By combining secure key storage, key rotation, and automated artifact validation, organizations can significantly reduce software supply chain risks and enhance regulatory compliance.

Additional DZone Refcards on DevOps and CI/CD security for further reading:

• Software Supply Chain Security Core Practices by Justin Albano
• SBOM Essentials by Siri Varma Vegiraju
• Getting Started With CI/CD Pipeline Security by Sudip Sengupta
• Cloud-Native Application Security Patterns and Anti-Patterns by Samir Behara
• Threat Modeling Core Practices by Apostolos Giannakidis
• Threat Detection Core Practices by Sudip Sengupta
• Advanced Cloud Security by Samir Behara
• IaC Security Core Practices by Payton O'Neal
• Continuous Delivery Pipeline Security Essentials by Sudip Sengupta