The recent high-profile attacks on Rockstar Games and Uber may not have been due to DevSecOps issues, but this aspect of security is worth having discussions about now.
One of the goals of applying a DevSecOps approach to software development is to get security built in earlier rather than later in the cycle. Whether or not that translates into increased security is debatable.
Speed of development and deployment with built-in security are some of the expected benefits of DevSecOps, though it can mean that different types of teams must adapt to each other, if not compromise. What if those compromises include reducing security for the sake of software delivery?
“We need to focus on tools and automation to help security engineering move at the same speed and give them visibility,” says Om Vyas, co-founder and chief product officer at Oak9, a security platform for developers. He says that security engineering has matured beyond the use of Microsoft Word documents to define how security should be implemented. Automation for security, says Vyas, could help better harness the potential of DevSecOps. “Why can’t we let a security engineer sit down with a DevOps team to really unlock DevSecOps?”
Getting DevSecOps elements to align takes focus and understanding, especially if they’re used to operating very independently of one another, says Josh Heller, supervisor of information security engineering for products and services with DigiInternational. “Security or operations may not actually work for the business unit where the development is actually happening [in].”
DevSecOps culture changes
That can lead to teams moving on to other tasks, he says, which may mean that the particular code base doesn’t become their priority. The DevSecOps culture has changed, Heller says, to inject more security testing, though development teams may have some initial frustrations. “It is going to mark a lot of false positives; there’s going to be some fatigue there,” she says.
Greater mutual understanding is needed, Heller says, because it would be much more expensive to introduce fixes into production after a problem arises. Most security tools are designed around incidents that have already occurred, which means they may have gaps in knowledge of new types of attacks. “The majority [zero-day vulnerabilities] in the infractions maybe there are things that we simply did not know, or it is the human factor”, he says.
A bit of bold honesty can go a long way in making DevSecOps resilient in the face of the biggest security threats. “We all have to admit, every business in America, in global IT, that at some point you’re going to have a breach that you may not even be aware of for six to 12 months,” says Heller. Security needs to be fully integrated into DevSecOps teams, she says, so they stay on the development path and raise questions along the way.
DevSecOps is often tied to CI/CD for the good of customers, Heller says, with pressure to roll out features as soon as possible, which can conflict with another aspect of the strategy. “Security people want to slow things down and make sure that what the customer receives doesn’t put them at risk,” she says.
Importance of prioritization
Understanding the real severity of potential risks, Heller says, can help bridge the gap between those schools of thought and prioritize how organizations respond. “You just can’t answer everything. You have to have a rubric that enables autonomy for DevOps,” she says. “DevOps doesn’t want security to investigate every finding in their software composition tool.”
The rush to automate everything in IT and security can also leave something to be desired in how DevSecOps works. “We don’t spend time manually understanding what we’re doing before we do the automations,” says Heller. For example, developers can create automation for operational tasks in the pipeline, but the operations might not understand the codebase, potentially leading to confusion. “They need to be there to help build it together so there’s an understanding of what’s going on,” she says. Similarly, putting security tools in process with other teams that don’t understand the codebase can also lead to confusion and vulnerabilities.
“Sometimes operations and security falls under the umbrella of IT and many times it’s focused on other business goals as well,” says Heller. “For a true DevSecOps team to reach the level of understanding that’s needed, they really have to come together as a team and work for that business unit so their goals are the same.”
What to read next:
4 lessons learned from the latest Uber breach
Twilio Breach: 5 questions to ask about protecting your own business
SolarWinds CEO talks about IT security in the wake of Sunburst