The push to innovate and create can often drive software developers to move at breakneck speed to deliver new apps, updates and bug fixes — a frenetic pace that can lead to security oversight.
DevSecOps — a portmanteau for developers, cybersecurity and operations — is a collaborative method that brings principles of application security into software development and operations with as little friction and as much agility as possible. The goal? Products can be rolled out at speed without compromising application security.
Adding security to the software lifecycle
DevSecOps bakes security into the product at every stage of the software development and delivery process, according to software intelligence firm DynaTrace, which released a white paper on the matter.
Must-read security coverage
- UK Police Convicts Pair in £5.5 Billion Bitcoin Launder Case
- Blackpoint Cyber vs. Arctic Wolf: Which MDR Solution is Right for You?
- How GitHub Is Securing the Software Supply Chain
- 8 Best Enterprise Password Managers
“DevSecOps grants visibility into code vulnerability; it also provides a deep understanding of how a target tolerates a real attack, and just how far an attacker can go,” DynaTrace said.
Edward Amoroso, CEO of TABCyber, said security in operations is driven by how quickly changes need to be made.
“Are circumstances changing hour by hour, minute by minute, or month by month? If it’s a pacemaker, the software isn’t getting updated, if it’s social media, it is,” Amoroso said. “Do I really need to automate DevOps security telemetry for a device that will not receive software upgrades?”
SEE: Why more is not necessarily better when it comes to security solutions.
Key elements of DevSecOps
Shifting left
According to some in the industry, “shifting left” means Identifying code vulnerabilities during development instead of production — a move that is key, because at production it becomes infinitely more difficult to engage developers in remediation after they may have moved onto other projects (Image A).
Image A
“’Shifting left’ is a core tenet of DevSecOps, but we can actually take that another step further,” said Meredith Bell, CEO of AutoRABIT, a platform for Salesforce DevSecOps.
“We also use ‘shift in’ to refer to the practice of creating a stream of communication where feedback constantly flows between each stakeholder,” Bell added.
Bell said that by deploying this practice, everyone involved in the project remains aware of all contingencies so there is no confusion. “A constant circle of acting, measuring, adjusting and improving is created. These feedback loops tighten up and amplify each other to create an environment more conducive to clean, safe code,” he said.
Automated processes
Automation helps take human mistakes out of the production portion of the software lifecycle.
According to software intelligence firm DynaTrace, automation is a critical part of the DevSecOps process, it explained in a recent whitepaper.
“ … Teams should automate testing, but also workflows, such as advancing software from test to release or committing code to a repository,” the company wrote in its report.
Amaroso said there are many vendors delivering automated solutions. “Most people would say automated is better than not, continuous is better than periodic and complete is better than spotty coverage. And there are at least 30 companies that are commercially viable doing this.”
Making software security easier
Experts in both developer and security fields agree that DevSecOps should involve developers in security goals. Nair said traditional operational security used to be the job of the compliance officer, who would run a scan, find a problem and report it to the developer.
“Six months after building it, that software might as well be someone’s else’s code. Dealing with these audit-centric approaches was the innovation that created what we call DevSec,” he said.
Nair said developers rarely encounter security as a practice.
“Computer science schools don’t teach security,” he said.
Michael McGuire, senior software solutions manager at Synopsys, said he agreed.
“I cut my teeth as a developer, and didn’t learn a single thing about secure coding in college. I think it’s becoming more of a topic but you have to understand, developers who are writing a lot of this code now probably don’t care about security because they weren’t taught it. I certainly didn’t care. That’s because how good a developer is at their job is decided by how quickly they can get a bug fixed or a ticket completed and out the door in a quality fashion,” McGuire said.
He said that because developers are being asked to care more about application security, tools need to meet developers where they’re at.
“We’re on our way there, and there are a lot of options out there,” McGuire said.