Last Updated on September 8, 2023
The rise of cloud computing spawned DevOps, a better way to build and deploy applications. But what about application security in these fast-paced pipelines? Many orgs have yet to implement DevSecOps—but that’s changing fast.
André Keartland, Solutions Architect at Netsurit, gives business and technical leaders an expert overview of what DevOps teams can expect when putting DevSecOps in place, ideas for getting started, and sharp insights on common missteps to avoid.
Join us as we discuss:
- Critical success factors for DevSecOps rollouts
- Top open standards to support your DevSecOps efforts
- Market forces that are driving a rapid increase in DevSecOps adoption
What is DevSecOps?
While DevOps is mainstream, DevSecOps—the integration of security processes into your DevOps pipeline—frequently remains an afterthought. Application vulnerabilities proliferate as a result, putting countless orgs at risk.
DevSecOps takes a security mindset plus automation and often semi-automated and/or manual steps from the earliest phases of the software development lifecycle (SDLC). Many dev teams lack security expertise, making training an essential component of most DevSecOps programs.
“In many development teams, there’s an idea that security is somebody else’s problem,” André relates. “Often that leads to a situation where applications have vulnerabilities in them getting exploited. Then everybody acts all surprised. But they were dead men walking from the beginning because they didn’t think of security from step one.”
Getting started with DevSecOps
If you’re thinking of launching a DevSecOps program, where and how should you start?
André advises using a greenfield development project for your initial DevSecOps forays.
From there, André recommends: “Start with the basics. Always go from the simplest to the most complex. So, to get going, sort out some of the security basics in your environment. Even if you’re not formally doing DevSecOps as a program or standard within your organization, start looking at things like protecting your Dev environments.”
Software development—including the behavior of developers themselves—can introduce massive cyber risk into an organization. Code is such important intellectual property. And compromised production applications have spawned some of the most brutal hacks in history. Yet many development and test environments are rife with vulnerabilities.
Understanding application-specific risks
For DevSecOps to really drive improved web app security, business and security leaders need to know the specific cyber risks associated with each specific application. Otherwise your defenses will be generic and you might miss critical focus areas.
Threat modeling, along with research and obtaining expert guidance, are recommended approaches for application risk analysis.
“Diversity of opinion is probably your best friend,” André advocates. “So don’t ask the developers what they think are the risks. Don’t ask the project stakeholder, or even your InfoSec guy. Talk to black hats, talk to penetration testers, talk to other organizations that run similar types of software. Start understanding, what are the application-specific risks?”
Shifting DevSecOps left
To build security into your web applications, you need to start at the initial SDLC stages, when the solution is being conceptualized and architected. This is what is meant by “shifting security left” on the delivery timeline. This is in direct opposition to the “traditional”—and ineffective—application security approach, where security is a “speed bump” stuck at the end of the SDLC, right before shipping the product.
“Look at securing your application as it’s getting architected and you are making the big decisions about what technologies to use, what platforms to support, what programming languages to use,” describes André. “Because the time you’re going to spend sorting out your security at the beginning is going to save you a lot of time, money, and effort later on down the process.”
Open standards can help with DevSecOps
Industry-leading open standards bodies like the Open Web Application Security Project (OWASP) and the Cloud Security Alliance (CSA) have numerous publications to help you develop a mature DevSecOps process and shake vulnerabilities out of your applications from before you even start coding. These include the famous OWASP Top 10 web application security vulnerabilities, the OWASP Software Assurance Maturity Model (SAMM), and the OWASP Application Security Verification Standard (ASVS).
André particularly recommends OWASP SAMM for assessing current practices and setting a course for improvement while measuring your progress. SAMM gives teams both a framework of practices to compare against, as well as goals to aim for. DevSecOps doesn’t happen overnight, and a roadmap is essential.
“You’ll never build a security culture in an organization in a year,” André reframes. “You need to start breaking it down and saying, ‘What do I do this quarter? Next quarter? Quarter after that? What do I do next year, and the year after that?’ Then you follow that program and you need to measure as you go along. OWASP SAMM is one of the models that’s useful for that,” summarizes André.
Your stakeholders may require DevSecOps
If you’re producing a SaaS application that other orgs will use, if you do business in a US government supply chain, or you’re in a regulated industry, implementing DevSecOps is what your future looks like—if not your present.
As a CISO or other security or business decision-maker, you might think DevSecOps is too much work to do right now. But before long you may not have that option.
André observes: “A lot of the time, the security standards or goals that you’re trying to meet are not necessarily those of your organization. Especially if you’re writing software for other people, you have to be ready [for compliance requirements].”
For more guidance on this topic, listen to Episode 114 of The Virtual CISO Podcast with guest André Keartland from Netsurit.