Pricing Login
Interactive demos

Click through interactive platform demos now.

Live demo, real expert

Schedule a platform demo with a Sumo Logic expert.

Start free trial
Back to blog results

March 4, 2018 By Michael Churchman

DevSecOps 2.0

You’re doing DevSecOps, and that’s a good thing. But have you taken it to the next level yet? Are you doing DevSecOps 2.0?

In this post, we’ll look at what DevSecOps 2.0 is all about, and what it takes to get there.

DevSecOps: Don’t Leave Home Without It.

But before we go on, let’s take care of another point. We said that doing DevSecOps is a good thing, but that’s really an understatement. These days, DevSecOps is more than just a good thing—It’s a necessity. If your organization hasn’t implemented at least basic DevSecOps practices by now, it’s time to catch up, and do so very, very quickly.

At its core, DevSecOps is what naturally happens when you merge DevOps and SecOps. We say “naturally” because it reflects the basic nature of both DevOps and SecOps. As with all forms of DevOps, it is not siloed—The security elements of DevSecOps are built in at every stage of your continuous delivery pipeline. And like SecOps, it is strongly focused on security— not simply as an afterthought, but as an intrinsic part of your application and your delivery process.

Security the Old-Fashioned Way

Consider the traditional position of security in the software development cycle: design, code, test, integrate, analyze for vulnerabilities (near the end of the test-and-integrate phase), then eliminate or patch vulnerabilities and add security features to compensate for the vulnerabilities that can’t be eliminated without wholesale redesign.

In the days when most software ran on desktop systems or local networks with limited outside connectivity, and development proceeded at a more or less leisurely pace, the inefficiency and limited coverage of this kind of after-the-fact security was generally acceptable.

Basic DevSecOps

Needless to say, in a world where everything is online and continuous delivery is the norm, such a late-in-the-day approach to security doesn’t even meet the minimum requirements for practicality, let alone efficiency or adequate coverage. To a considerable degree, security in DevOps has to fit the basic requirements of DevSecOps if it’s going to be anything at all. Basic DevSecOps means building in security, starting with design, and addressing security concerns as an intrinsic part of coding, including security in all stages of testing, and of course, making security a top priority in deployment and operations. (If you’re not doing these things already, you need to formulate a basic DevSecOps plan ASAP.)

Beyond the Basic

If that is basic DevSecOps, what is DevSecOps 2.0?

The starting point (and it is only the starting point) for DevSecOps 2.0 is that point at which the culture of your DevOps team and the culture of your security team merge into a true DevSecOps culture. In order for this to happen, the DevOps team needs to understand security not only as a necessary part of the operating environment and as a set of modifications which must be made to the application code, but as a fundamental functional and performance requirement of the software itself.

At the same time, the Security team needs to develop a full appreciation of the application, the development and test environments, the deployment and monitoring tools, and the overall infrastructure as entities made up of code, rather than black (or white) boxes to be probed, tested, monitored, and evaluated. The world of DevOps and the world of security must become completely visible to each other.

Security As Design

What does this mean in practice?

Ultimately, it has the effect of shifting security left, into the design of the code itself (and not just as a set of high-level design requirements to be applied post-development). This shift typically plays out in a variety of ways along the full length of the continuous delivery chain. The key features of DevSecOps 2.0 include (but are hardly limited to):

Security as a Design Requirement

Shifting security into design at the code level means that fundamental security considerations need to be explicitly addressed as a part of the process of code design at all levels, from the overall application framework to individual programs and components, and down to the lowest functional units.

What kind of security considerations? Depending on the actual design level, they might include:

  • What targets could be accessed or compromised by means of this code?
  • What potential vulnerabilities could an attacker exploit?
  • What resources does it require, and what are their vulnerabilities?
  • Are these vulnerabilities addressed elsewhere, and if they are, should they also be addressed by the code in question?

These questions need to be a part of the design process for all elements of the application code, even if the code in question has no obvious connection with known targets or attack surfaces.

Target Identification During the Design Phase

If potential access to attack targets is a major consideration in secure code design, you need to identify the targets—and not surprisingly, you also need to know what those same targets are when you build security in at the testing, deployment, and infrastructure levels.

You can separate targets into two general (although often overlapping) groups:

Primary Targets

These are typically assets which are valuable to potential attackers in and of themselves (information which can be extracted and exploited outside of your application). This includes financial and medical records, trade secrets and other proprietary data, classified documents, personal user information—basically, any type of data that can be used to advantage by malicious parties if they gain access to it.

Secondary Targets

These are targets which provide access to other targets (either primary or secondary). They are of value within the scope of your application, but not outside of it; typically, they are potential vulnerabilities which ultimately can be used to gain access to primary targets.

Note that user ID and password lists fall into both categories—They can provide access to your application and, since many people reuse passwords, potentially to other applications. This means that as long as your software requires password logins, you should treat the password list as a high-value primary target, even if no other sensitive data is involved.

Build Security Into Test Design

In many ways, this is a basic part of DevSecOps 1.0, but it bears repeating: You should be testing for vulnerabilities at all stages of your continuous delivery chain, from code and unit testing all the way to the post-deployment phase. Vulnerability testing should be included in your standard test regime, along with functional and performance tests, not as a substitute for ongoing testing and monitoring by the security team, of course, but in addition to it.

Build Security In at the Infrastructure Level

DevSecOps is (as are most other elements of DevOps) a work in progress, and this is as true at the infrastructure level as it is throughout the continuous delivery process. In many ways, DevSecOps has always been about infrastructure—about integrating security tools into cloud-based infrastructure, and integrating cloud providers’ own security tools into development and deployment infrastructure.

The future of DevSecOps at the infrastructure level is likely to include more security built into infrastructure code (i.e., within containers and VMs), and perhaps more importantly, building full-dashboard security monitoring and analytics service integration in at the code design level, in effect shifting key infrastructure security features left into application code.

Ultimately, perhaps, DevSecOps 2.0 is simply the recognition (put into practice) that in a cloud-based software environment, security can no longer be separated from development and operations in any meaningful way.

Today, DevSecOps isn’t a choice. It’s a fact.


How DevSecOps Can Help Manage Meltdown and Spectre:

Complete visibility for DevSecOps

Reduce downtime and move from reactive to proactive monitoring.

Sumo Logic cloud-native SaaS analytics

Build, run, and secure modern applications and cloud infrastructures.

Start free trial
Michael Churchman

Michael Churchman

Michael Churchman started as a scriptwriter, editor, and producer during the anything-goes early years of the game industry. He spent much of the ‘90s in the high-pressure bundled software industry, where the move from waterfall to faster release was well under way, and near-continuous release cycles and automated deployment were already de facto standards. During that time he developed a semi-automated system for managing localization in over fifteen languages. For the past ten years, he has been involved in the analysis of software development processes and related engineering management issues. He is a regular contributor.

More posts by Michael Churchman.

People who read this also enjoyed