DevSecOps explained
May 23, 2022 // 11 min read
DevSecOps builds on the ideas of DevOps by applying security practices throughout the software development lifecycle to ship more secure code faster.
Through collaboration, automation, and continuous improvement, DevSecOps offers a set of practices that help companies embed security into their work to build more secure, high-quality software at scale.
DevOps has transformed how many organizations build and ship software. But until recently one aspect of the software development lifecycle (SDLC) has remained outside DevOps: security. DevSecOps seeks to correct that by baking security into the software development lifecycle (SDLC) in the same way that DevOps prioritizes quality, speed, and deep collaboration throughout all stages of software development. For modern organizations, DevSecOps becomes just “DevOps”: security is baked into the SDLC experience.
Organizations that adopt DevSecOps typically see advantages that include:
Reduced risk of data breaches: DevSecOps seeks to make code secure by design. A combination of secure coding cultural practices, secure developer environments, and automated security tests throughout the SDLC help reduce the chances of security vulnerabilities or flaws making it into production software.
Improved compliance: DevSecOps practitioners often use automation to enforce code compliance and integrate policy enforcement tooling directly into the CI/CD pipeline.
Greater confidence in dependencies: The modern technology stack depends heavily on third-party code, often from public package repositories. DevSecOps practitioners frequently leverage tooling and automated tests to identify potential issues before a software release.
Value gets to end users faster: By creating a security-first culture and applying automated checks, DevSecOps reduces the need for distinct security reviews that slow down code deployments.
What is the main benefit of DevSecOps?
DevSecOps seeks to build security into every step of the SDLC. This ideally means that security related tests (automated and not) take place at each stage from coding to merging branches to builds, deployments, and on into operation of production software. Moreover, DevSecOps advances the idea that everyone working on a product is accountable for its security. This helps teams catch vulnerabilities before they make it to production and reduces the need for late-stage, manual security reviews, which can slow down software releases.
DevSecOps best practices
Push buggy code into production and the result might be a bad customer experience and potential lost business due to downtime. But if you deploy insecure code, the fallout can be far more severe.
DevSecOps is a natural evolution of DevOps and seeks to make security a core part of the SDLC instead of a siloed process that takes place right before a release. Just like how testing and operations teams were often siloed from development in the pre-DevOps world, security today is often the job of specialized teams whose work take place outside the DevOps lifecycle.
DevSecOps argues that security needs to be embedded across the SDLC. Whether your organization already practices DevOps or you’re looking at how to adopt a DevOps culture, here are the foundational best practices you need to establish a DevSecOps practice:
Create a DevSecOps culture: Success in DevSecOps relies on everyone taking responsibility for security. That means each person in the SDLC codes, builds, tests, and configures application and infrastructure settings defensively. Just like DevOps, DevSecOps thrives in an open culture where each individual works together to build the best and most secure product possible.
Design security into the product: DevSecOps seeks to design security into products from the initial planning stages to deployed production-level code. This means security work is planned alongside feature work, and practitioners are provided security knowledge and testing throughout each stage of their development work. The goal is to make security an everyday part of your team’s work.
Build a threat modeling practice: The seeds of security vulnerabilities are often sown before a line of code is written. Model potential threats during the planning phase and design your infrastructure and the application’s architecture to mitigate those issues. And periodic penetration testing, where a trusted person attempts to break into your system, can help unveil weaknesses you may miss in your threat models.
Automate for speed and security: Automated testing is used throughout the SDLC to ensure the right security checks happen at the right time. That gives people more time to focus on building the core product while ensuring security requirements are met.
Plan security checkpoints in your product development: Identify transition points in your SDLC where the risk profile changes. That could be the point at which a developer merges their code into the main branch, which might increase the potential for that code to be run on the machines of colleagues and eventually reach production. In that case, opening a pull request might be a good trigger event for automated security checks, along with the appropriate manual escalations.
Approach security failures as learning opportunities: Building on DevOps’ culture of continuous improvement, a successful DevSecOps practice strives to turn security incidents into learning opportunities. This can be accomplished by leveraging audit logs, building incident reports, and modeling malicious behavior to improve tooling, testing, and processes to further secure your applications and systems.
Stay on top of dependencies: Understanding and mitigating the potential threats from dependencies is critical to your product’s security. Apply the same threat modeling and automated testing to your dependencies as to your in-house code. At GitHub we’ve identified and shared details of tens of millions of threats in open source software, helping organizations and developers be more aware of and avoid vulnerabilities.
Build your analytics and reporting capabilities: Continuous monitoring is a critical part of a DevSecOps practice—and that includes real-time alerts, system analytics, and proactive threat monitoring. By measuring every aspect of your application and your DevSecOps pipeline you can create a common point for understanding application health. Reporting dashboards and alerts highlight problems early. When a problem does occur, the telemetry you’ve set up—such as application-level logging—provides insight for incident resolution and root cause analysis.
DevSecOps culture
Creating a DevSecOps culture begins by making security everyone’s responsibility. This can be a big change for many organizations. Traditionally, security was something developers left in the hands of specialist security professionals. It could also become a point of friction as well. Engineering teams often looked at security practices as an impediment to shipping software fast.
DevSecOps fundamentally seeks to change this perception by making security as core to the SDLC as writing code, running tests, configuring services. Each new feature or fix begins with considering its security implications. Security and compliance policies are enforced through tests. When something goes wrong, it’s an opportunity to learn and to do it better next time.
And instead of something that slows down software releases, security in a DevSecOps practice becomes a part of the release itself leading to faster and more secure deployments.
But building a successful DevSecOps practice requires building security into every stage of the SDLC. This varies from one organization to another. Even so, there are core pillars that define a DevSecOps culture. These include:
People: A DevSecOps practice seeks to remove the barriers between different disciplines and build a naturally collaborative environment where each person shares responsibility for a product’s security and quality.
Process: DevSecOps moves security from being a distinct stage that often comes at the end of the SDLC to an integral part of each person’s work. Automated security evaluations, security-focused unit testing, widespread monitoring, and defensive coding create rapid feedback loops where vulnerabilities are surfaced earlier in the product life cycle and can be fixed faster.
Products: DevSecOps builds on the DevOps toolchain by using technologies such as CI/CD to automate the identification of security issues. Dependency scanning, static and dynamic application security testing, and automated policy enforcement tools are often used to help build security into every stage of the SDLC. A wide range of best-in-breed solutions can be integrated with one another to create an “open” toolchain. Other organizations, however, may find that more integrated and security-focused product suites can often provide a more holistic experience.
Governance: Continuous improvement is central to DevSecOps and it requires creating a culture of measurement that enables practitioners to identify opportunities to refine processes and tooling.
DevSecOps pipeline
A DevSecOps culture seeks to establish security as a fundamental part of creating software—but that’s only one part of what it takes to successfully adopt a DevSecOps practice. The next step is to integrate security into each stage of a DevOps pipeline.
With security specific tooling and processes throughout the SDLC, a DevSecOps pipeline helps practitioners design more secure products and catch security issues early in the product life cycle.
Common DevSecOps pipeline stages
DevSecOps builds on DevOps, and a DevSecOps pipeline builds on a DevOps pipeline. Just as DevOps integrated quality and speed into each step, the best DevSecOps pipelines are designed to anticipate key points in the SDLC where security issues are likely to arise.
This breaks down into the following common DevSecOps pipeline stages:
Plan: In a DevSecOps practice, security starts at the planning stage in the SDLC pipeline. This can include analyzing potential security threats and determining how to combat them with threat modeling. It can also involve designing security into your products proactively to ensure it’s baked into the work from the beginning with key data hygiene and other security decisions taken up front.
Code: At the coding stage in a DevSecOps pipeline, it’s important to create a culture of defensive programming with policies that help practitioners proactively navigate security and compliance issues. This could be as simple as specifying rules for how to handle particularly risky aspects of code, such as NULLs, or involve broader guidelines on areas such as input validation.
Build: In the build stage, a typical DevSecOps pipeline will include automated security checks to catch vulnerabilities in source code before they hit the main branch. This can involve using pre-commit hooks to run static application security testing (SAST) tools where any potential issues in code will stop the build, much like a failed test, and provide time to fix any potential vulnerabilities in proprietary source code before work can progress. It should also include software composition analysis (SCA) tools to track open source components in the codebase and detect any vulnerabilities in dependencies.
Test: The test stage of a DevSecOps pipeline is a key point where practitioners will develop a testing strategy and automated testing suite to catch any potential security vulnerabilities or issues. This commonly includes using unit tests at a base level to look for security issues such as the way in which the application deals with unexpected or malformed input. It can also include dynamic application security tests to find vulnerabilities in the application when run. This way, the test phase becomes as much as security as it does functionality. A good tip at this stage is to integrate dynamic application security testing (DAST) into the DevSecOps pipeline.
Release: In the release stage, a DevSecOps pipeline will often include additional automated security testing and vulnerability scanning to catch issues that might not have been apparent in earlier stages. Some organizations will also deploy the principle of least privilege where each person and tool has access only to precisely what they need.
Deploy: At the deployment stage, a DevSecOps practitioner will work to ensure that code makes it to production only if it has passed security checks at each previous stage. This can involve applying automated tests to application code and the underlying infrastructure used to run the software in production to catch any run-time security concerns.
Operate and monitor: In the operations and monitoring stages of a DevSecOps pipeline, organizations will often use application-level and infrastructure metrics to identify unusual activity that could indicate a security breach. When an incident occurs, use logging and other instrumentation can be used to pinpoint the issue and understand its impact.
DevSecOps automation principles
When it’s correctly implemented, automation accelerates the SDLC by enabling people to use technology to accomplish repetitive, manual tasks and deliver higher-quality software faster. DevSecOps takes automation further by integrating security tests across all stages of the SDLC to improve speed, consistency, and mitigate against potential risks.
If DevSecOps makes security everyone’s responsibility, DevSecOps automation strives to give everyone the tools they need to ensure code and configurations are secure without requiring them to become security specialists.
When considering where to apply automation in your own DevSecOps pipeline, consider the following principles:
Automation should be strategic: A DevOps practice often seeks to use automation to facilitate speed and quality across the SDLC. But just as being strategic is important in a DevOps practice, it’s equally—if not more—important to be strategic about how and when automation is applied in a DevSecOps environment.
Let people focus on being creative: Automate repetitive tasks wherever possible. That way, people can save their time and mental energy for more involved work while checks are applied more consistently and at scale.
Systematize code review: Use tools such as static application security testing to automate elements of your code review. Human-led code review is still important though and it’s critical to ensure your code review checklist covers security issues specific to your technology stack. Create a feedback cycle so each time a new information becomes available you build it into the checklist. For example, when an incident occurs consider how you could have caught the problem earlier with a code review or automated test.
DevSecOps toolchain
Adopting DevSecOps starts with a cultural shift that involves making security a core concern of everyone involved in the SDLC. To accomplish this, organizations will often adopt new processes and build a DevSecOps toolchain that applies automated security tests and security tooling to the SDLC.
DevSecOps tooling often builds on common DevOps tools such as CI/CD, automated tests, configuration management, and monitoring. The goal is to integrate security-focused tooling into each stage of the product life cycle.
Key components of the DevSecOps toolchain
Automated security tests on commits and merges: A basic goal of any DevSecOps practice is to catch issues in code before they can do harm by triggering automatic scans using pre-commit and merge triggers. Some of the scans organizations might implement include:
Code scanning: Often called static application security testing, this evaluates code at rest—in other words, without having to run it—to discover code that could lead to a vulnerability.
Vulnerability scanning: Dynamic application scanning tools build and deploy the application to a sandboxed environment and then observe how it responds to known security threats.
Secret scanning: Even with the most stringent policies, secrets occasionally make it into a commit. Secret scanning tools are used to catch them before the commit is made. These also pair with SCA tools, which are used to detect any vulnerabilities in open source dependencies within a given codebase.
- Configuration management: In DevSecOps, a general rule is it’s best to remove the uncertainty from systems configuration—and this is often accomplished by adopting infrastructure as code. Tools such as Docker, Terraform, and Ansible use YAML and similar configuration files that can be automatically scanned for issues, committed to version control, and rolled out automatically to multiple instances of a service.
Container orchestration: In some environments, organizations may adopt a microservices architecture to better support complex, cloud-native applications. This requires maintaining multiple containers and scaling them as needed and securely—and that involves container orchestration tools. Just like configuration management tools, container orchestration tooling will often use YAML configuration files to dictate interactions between containers.
Runtime verification: Also known as runtime application self-protection tools, these tools will actively monitor and/or direct threats towards your application as it runs with reports highlighting any vulnerabilities.
Continuous monitoring and reporting: One of the simplest yet highly effective aspects of DevSecOps tooling is measurement—and that involves logging everything at the application and infrastructure level. The best tools will provide real-time intelligence when something goes wrong and include a reporting system so you can catch issues early. Outbound data from an unexpected port, for example, could indicate a compromise but without monitoring and reporting it might go undetected.
The bottom line
Security is a defining issue in software development organizations today. Getting it wrong has far-reaching implications—both for the organizations and even the individuals involved. DevSecOps offers a framework for creating software securely from the very first step. And building on the well understood culture and processes of DevOps means that, for most businesses, a shift left to DevSecOps is a natural evolution.
Build your DevSecOps practice on GitHub
GitHub is an integrated platform that takes companies from idea to planning to building to production, combining a focused developer experience with powerful, fully managed development, automation, and test infrastructure.
Our philosophy is to build automation and great DevOps for the company you will be tomorrow.
Senior SCM Engineer Todd O'Connor at Adobe
| Go from planning to building | Increase developer velocity |
|---|---|
| Build roadmap plans right next to your codebase and quickly assign tasks to team members with powerful project boards and tables that are fully integrated into your project. Learn about GitHub Issues > |
Reduce the time to commit. Eliminate environment management and context switching for your developers. Simplify IT procurement and maintenance with a secure, managed space in the cloud. Explore Codespaces > |
| Automate everything | Secure your code as you write it |
| ---------- | ---------- |
| Automate all your software development workflows with GitHub Actions. Scale reliably and securely with powerful development, test, and automation infrastructure, fully managed by GitHub. Learn more about GitHub Actions > |
Secure your code, dependencies, tokens, and sensitive data through the entire software development lifecycle and automatically resolve vulnerabilities. See how we help you stay secure > |
Tags