DevSecOps is the seamless integration of security testing and protection throughout the software development and deployment lifecycle. Like DevOps, DevSecOps is as much about culture and shared responsibility as it is about any specific technology or techniques. Also, like DevOps, the goals of DevSecOps are to release better software faster, and to detect and respond to software flaws in production faster and with more efficiency.
That’s a lot to digest. In the sections below, I’ll unpack each of those thoughts so you can better understand how your organization can move towards a fuller embrace of DevSecOps.
What is DevSecOps?
In practice, DevSecOps is a tactical trifecta that connects three different disciplines: development, security, and operations. The goal is to seamlessly integrate security into your continuous integration and continuous delivery (CI/CD) pipeline in both pre-production (dev) and production (ops) environments. Let’s take a look at each discipline and the role it plays in delivering better, more secure software faster.
Development teams create and iterate on new software applications. This includes:
- Custom, built-in-house apps designed for a single, specific purpose
- API-driven connections that bridge the gap between legacy systems and new services
- Apps that leverage open-source code to accelerate the development process
Modern development practices rely on agile models that prioritize continuous improvement versus sequential, waterfall-type steps. If developers work in isolation without considering operations and security, new applications or features may introduce operational issues or security vulnerabilities that can be expensive and time-consuming to address.
Operations refers to the processes of managing software functionality throughout its delivery and use life cycle, including:
- Monitoring system performance
- Repairing defects
- Testing after updates and changes
- Tuning the software release system
DevOps has gained ground in recent years as a way to combine key operational principles with development cycles, recognizing that these two processes must coexist. Siloed post-development operations can make it easier to identify and address potential problems, but this approach requires developers to circle back and solve software issues before they can move forward with new development. This creates a complex road map instead of a streamlined software workflow.
Implementing operations in parallel with software development processes allows organizations to reduce deployment time and increase overall efficiency.
Security refers to all the tools and techniques needed to design and build software that resists attack, and to detect and respond to defects (or actual intrusions) as quickly as possible.
Historically, application security has been addressed after development is completed, and by a separate team of people — separate from both the development team and the operations team. This siloed approach slowed down the development process and the reaction time.
Also, security tools themselves have historically been siloed. Each application security test looked only at that application, and often only at the source code of that application. This made it hard for anyone to have an organization-wide view of security issues, or to understand any of the software risks in the context of the production environment.
By making application security part of a unified DevSecOps process, from initial design to eventual implementation, organizations can align the three most important components of software creation and delivery.
How DevSecOps differs from the “waterfall” approach
Traditional software development is often called the waterfall approach because each stage of the process — design, development, testing, and final approval — is separate and one stage can start only when the previous one is completed.
In most organizations, waterfall has largely been replaced by Agile methodology, which separates a project into sprints. But security tests are still typically delayed until the end of the sprint—waterfall style! This delay forces developers to shift gears and backtrack their thinking in order to remediate security problems. This “context switching” is error-prone and time-consuming.
DevSecOps, on the other hand, enables security testing to occur seamlessly and automatically in the same general timeframe that other development and testing are happening. For example, developers can run security tests in the development stage in near-real-time to prevent wasting time context switching. They can also run security tests in the production phase in near-real time so they can immediately discover all instances of a vulnerability running in production soon after the vulnerability is announced.
Challenges in implementing DevSecOps
Implementing DevSecOps has some challenges.
The first challenge involves people and culture. You might find it necessary to retrain the people on your DevOps teams so they understand security best practices and know how to operate your new security tooling. In terms of culture, your teams need to truly adopt the mindset that they are responsible for the security of the software they build and deploy, just as much as they are responsible for feature, function, and usability.
A second challenge is finding the right security tooling and integrating it into your DevOps workflow. The more automated your DevSecOps tooling is, and the more integrated it is with your CI/CD pipeline, the less training and culture-shifting you need to do.
In many cases, however, choosing a more automated version of the security tools you have been using for years is not the right answer. Why? Because your development environment has likely changed drastically over the past few years. The typical modern software application is comprised of 70% open-source software. Unfortunately, accurately detecting vulnerabilities in open-source software is not something traditional security tools were designed to do.
Similarly, modern cloud-native applications run in containers that may spin up and down very quickly. Traditional security tools designed for production environments—even those that now advertise themselves as “cloud security” tools—can’t accurately assess the risks of applications running in containers.
Want to learn more about DevOps?
Streamline the way IT operates and enterprises grow with observability and AIOps. Read our DevOps eBook – A Beginners Guide to DevOps Basics
Top traits of successful DevSecOps practices
If the goals of DevSecOps are 1) to release better software faster, and 2) to detect and respond to software flaws in production faster and more efficiently, what are the capabilities you should cultivate to achieve them? What key performance indicators (KPIs) should you use to measure the quality of your DevSecOps initiatives?
Here are the most important characteristics of a strong DevSecOps program:
1. Security awareness and ownership
Everyone involved with software development and operations should be aware of security fundamentals and have a sense of ownership in the results. The philosophy “security is everyone’s responsibility” should be a part of your organization’s DevSecOps culture.
2. Automated operation
To align with the high degree of automation present in most CI/CD tool chains, your DevSecOps security tooling needs to run with complete automation — no manual steps, no configurations, no custom scripts. It needs to provide information about the security of your application even when your developers might want to avoid running a security test for fear that it would slow them down.
3. Fast results
Your security tooling needs to produce results in near-real-time because speed is a high priority for modern DevOps teams.
4. Wide scope
Your security tooling should function across all types of compute environments including containers, Kubernetes, serverless, PaaS, hybrid clouds, and multiclouds. No blind spots. No silos.
Also, your security tooling needs to provide information about all types of applications — including applications that are mostly based on open-source software, as well as applications that you purchased from a third party, for which you have no source code at all.
5. Shift-left and shift-right
Much has been written about the benefits of conducting security assessments early in the software development lifecycle (“shift left”), before vulnerabilities find their way into production. However, DevSecOps also needs to extend to production environments (“shift right”) for four reasons:
- Production is where most attacks happen.
- Scanning source code can’t give you the same rich insights you can get by observing the application when it is running in production.
- Some applications you run in production may not have run through your dev environment, so they never had a chance to be scanned by security tools in your dev environment.
- To detect new zero-day vulnerabilities, you need to monitor existing applications in your production environment.
Automation is important, but you also need accuracy and quality. In our recent CISO survey, 77% of respondents said most security alerts and vulnerabilities they receive from their current security tools are false positives that don’t require action, because they’re not actual exposures.
To achieve DevSecOps efficiency, you need security tests that eliminate false positives and false negatives, and provide useful information to your remediation team.
7. Developer acceptance
Everything about your DevSecOps program needs to be accepted by the people who will be developing the software, running the tests, scanning for vulnerabilities, and remediating the security issues that are found.
The Top 8 DevSecOps trends in 2022
From Infrastructure as Code to GitOps and serverless architecture, the top DevSecOps trends in 2022 will continue to enable teams to automate, streamline their CI/CD pipelines, and make time for innovation.
A platform for all stages of DevSecOps
To respond to the need for application security that spans both production (shift-right) and pre-production (shift-left), many organizations are choosing to leverage the security information that is available from their existing application performance monitoring platform.
With the Dynatrace Software Intelligence Platform’s Application Security module, the same OneAgent that provides deep observability for application performance also provides deep observability for security issues. The Dynatrace OneAgent provides rich information, such as which libraries are called, how they are used, whether a process is exposed to the Internet, and whether an application or service interacts with sensitive “crown jewel” type data. This is much richer information than traditional security scanners or behavioral anomaly tools can deliver. By combining security with contextual awareness and observability, Dynatrace Application Security delivers the accuracy and precision teams need to achieve their DevSecOps goals. Explore our interactive product tour to see how our unique approach to application security helps DevSecOps teams innovate faster with less risk and drive better business outcomes.
What is DevSecOps? It’s the seamless integration of security testing and protection throughout the software development and deployment lifecycle. With real-time security intelligence across pre-production and production environments, and with AI-driven recommendations and automation that can help manage every stage of the DevOps workflow, your teams can produce better, higher-performing, more secure software faster and with less effort.
To learn more about the challenges of securing modern, cloud-native applications, download the eBook Securing cloud-native applications and discover what top cybersecurity professionals say about how integrated security platforms and automation can close the cloud security maturity gap.