Recent high-profile hacks at Rockstar Games and Uber might not stem from DevSecOps issues, but discussions of this aspect of security may be worth having now.
One of the goals of applying a DevSecOps approach to software development is to get security onboard sooner rather than later in the cycle. Whether or not that translates into increased security can be debated.
Speed of development and deployment with security baked in are some of the expected benefits of DevSecOps, though it can mean different types of teams must adapt to each other, if not compromise. What if those compromises include easing up on security for the sake of delivering software?
“We need to focus on tools and automation to help security engineering move at the same velocity and give them visibility,” says Om Vyas, co-founder and chief product officer with Oak9, a security platform for developers. He says security engineering has matured beyond using Microsoft Word documents to define how security should be implemented. Automation for security, Vyas says, could help better realize the potential of DevSecOps. “Why can’t we enable a security engineer to sit with a DevOps team to truly unleash DevSecOps?”
Getting the elements to DevSecOps to align takes focus and understanding, especially if they are accustomed to operating very independently of each other, says Josh Heller, supervisor of information security engineering for products and services with Digi International. “Security or operations might not actually work for the business unit that the development is actually happening [in].” Shifts in DevSecOps Culture
That can lead to teams being pulled into other tasks, he says, which can mean that particular codebase does not become their priority. DevSecOps culture has shifted, Heller says, to inject more security testing, although development teams may have some initial frustrations. “It’s going to flag a lot of false positives; there’s going to be some fatigue there,” he says.
More mutual understanding is needed, Heller says, because it would be much more expensive to introduce fixes in production after an issue arises. Most security tools are designed around incidents that have already happened, which means they can have gaps in awareness of new types of attacks. “Most [zero-day vulnerabilities] in breaches are maybe things we simply didn’t know — or it’s the human factor,” he says.
Some boldface honesty may be part of the remedy for making DevSecOps hold up in the face of heightened threats to security. “We should all admit, every business in America, in global IT, that at some point you will suffer a breach that you might not even know about for six to 12 months,” Heller says. Security should be thoroughly embedded in DevSecOps teams, he says, so they are on the development track raising questions along the way.
DevSecOps is often tied to CI/CD for the sake 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 is getting isn’t going to put them at risk,” he 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 simply can’t respond to everything. You have to have a rubric that allows for autonomy for DevOps,” he says. “DevOps doesn’t want security looking into every finding in their software composition tool.”
The rush to automate everything in IT and security might also leave something to be desired in how DevSecOps functions. “We’re not spending the time to manually understand what we’re doing prior to doing the automations,” Heller says. For example, developers might create an automation for operational tasks for the pipeline, but operations might not understand the codebase, possibly creating confusion. “They need to be there to help build it together so there’s this understanding of what’s happening,” he says. Likewise, putting security tools in the pipeline with other teams not understanding the codebase can also lead to confusion and vulnerabilities.
“Sometimes operations and security fall under the IT umbrella and a lot of times you’re also focused on other business goals,” Heller says. “For a true DevSecOps team to get to the level of understanding that is needed, you really have to be embedded as a team and work for that business unit so that your 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 Securing IT in the Wake of Sunburst
Source link
