Within many large organizations, the digital security, software development and IT-operations teams have reached the point where DevSecOps — the idea that security, development, and operations teams should work happily and harmoniously together — is a commonly understood concept.
But that doesn't mean DevSecOps is properly practiced. Often, the development and security teams still work at cross-purposes, with each blaming the other for getting in the way.
For developers, the pressure is always mounting to meet pushed-forward deadlines. The continuous integration/continuous delivery (CI/CD) process, meant to integrate development and operations, sometimes just turns up the pressure.
Meanwhile, security teams are trying to keep up with the faster pace of software development. Their efforts to make sure nothing goes wrong only slow down the development process. This creates confusion, anger and delay.
It's time for both the security and development teams to take a step back, learn more about each other’s methods and goals, learn how to better communicate, and leverage the power of automation to build a truly developer-first security culture.
"I would define a developer-first security culture as one that is well aware [of], prioritizes and integrates well with software development processes,” says Liam Mayron, Principal Product Manager at Fastly, a leading provider of web-application security and content delivery. “One that is incorporated, blended into every stage of development, rather than something that is a phase that you do, or something that is added on, less organic."
The initiative for these mutual-understanding efforts must come from top leadership, but all members of both teams need to be active participants.
"There are better outcomes for everyone, better security outcomes, better development outcomes, by having closer collaboration, better understanding between these two perspectives and taking advantage of ways to really automate security, integrate it into the development process," Mayron says.
The problems with trying to mesh security and development
It's a running joke in some organizations that the security team is the "Department of No," as in, "No, you can't do that."
The security team may have very good reasons to insist that a particular practice or innovation be halted, but those reasons aren't always clear to the product managers and developers who are trying to get something out the door, or to the CIO and CTO who want the whole process to move efficiently.
"There's complexity from adding these security requirements, complexity in understanding them and in the resulting product as well," explains Fastly's Mayron. "It could be that security requirements require cutting scope somewhere else to meet a deadline."
Likewise, it's not always apparent to the security team why a project really needs to move as quickly as possible. Mayron says this happens in situations where the two teams don't work well together.
"The security requirements are less connected to the development process," he says. "If a new CVE comes up, a new bug, it's something that can be in those types of cultures very disruptive, because security is not built into the process."
Foisting security tools upon developers isn't always the answer. The tools aren't always tailored for developer use and may require a steep learning curve that developers haven't got time for.
"If these security tools are maybe used or accessible to the development team, but they're not built for software developers, there could be additional context there that that team now needs to learn to make use of them and to ensure that their software is secure," Mayron says, adding that it's better to choose "security tools that just integrate naturally into development workflows."
How to mesh the two teams' efforts
The key to getting security and development teams to work together is to make it clear that their efforts share a common goal greater than each team's specific mission. Is the "dev" or the "sec" more important in DevSecOps? Mayron has a surprising reply.
"Neither is more important," he says. "It's really the 'ops' part that ties it all together, how everyone works together.
"Dev is critical," Mayron adds. "Security is absolutely non-negotiable. But how you operate — to me, that is really the glue to DevSecOps."
There are four main aspects that must be stressed in each organization to achieve a proper DevSecOps process:
Understanding
Software developers and security teams will never be able to work together unless they truly "get" what the other side is doing.
Fostering mutual understanding can begin with finding individual members of each team who understand the other team's mission. Those individuals can become evangelists of a sort who help to spread their knowledge among members of their own teams.
This should be followed up with training sessions that, perhaps counterintuitively, teach one team how to better do its own job by educating it about how the other team works.
"For development teams, it's really important to understand the threat landscape and to understand risk and why these security requirements are just that — requirements," Mayron explains. "For security teams, it's beneficial to understand how complex modern development environments can be, and it's also very important to realize the pressure and importance of moving quickly for software teams."
Communication
Mutual understanding should foster better communication, but it's never too early to get developers and security personnel to try to speak freely and honestly with each other.
"Working together, having requirements that make sense in the vernacular of the other team, just being clear in why something is valuable," says Mayron. "Having those lines of communication can definitely help increase trust between those teams."
It's paramount that security teams make clear exactly what they need, and why, in language anyone in the organization can comprehend.
"The security guidance should be really clear," says Mayron. "It should be something that everyone can see and understand — 'Yeah, this makes sense.' It's not overly complex, it's not overly burdensome."
Automation
As the pace of development accelerates, leveraging the speed and accuracy provided by automation becomes essential. Automated tools that perform static and dynamic application software testing (SAST and DAST) can be enormously beneficial to both developers and security practitioners, as can automated software composition analysis (SCA) for dev teams that rely highly on open-source software.
Automated tools can also run all night, yield consistent results and never get tired — three important aspects when development teams are trying to deliver secure software.
"There's a lot of things that can be done to balance speed and security, but automation, I think, stands above the other things," says Mayron. "The other thing about automation is it can let you identify issues earlier in the development process, which is always much, much, much better, because you can run automation in more places, more frequently, more thoroughly. And that's a big advantage."
Leadership
As with all organizational changes that affect more than one department, the proper integration of security and development efforts needs to be initiated from the top down. Leadership should persuade the two teams to work smoothly together. If persuasion doesn't work, then firmer methods may be needed.
"Ultimately, it comes down to the teams," Mayron says. "But having that vision from leadership, that directive, I think, is certainly very, very important. You know, setting that tone from the top down is really key."
Blueprint for a developer-first security culture
Ultimately, security should be so baked into the development process that it becomes almost inevitable. Mayron says that Fastly can aid in those efforts by, for example, having its next-generation web application firewall (WAF) folded into the software-development life cycle.
"A security team could produce a module that automatically deploys their Fastly next-gen WAF configuration in front of any new applications," he explains. "Whenever you build that application, the WAF just gets put there in front of it with consistent rules, consistent support across all applications."
"It doesn't really become a decision or a burden for the development team," Mayron adds. "It's there and it serves the purposes of the company."
Your organization should end up with a culture that has security accompanying, not driving or halting, development, one where the efforts of coders and project managers proceed smoothly and securely.
"It really comes down to having objectives in common between the teams," Mayron says. "Having the teams have the same goal, even if one comes in the form of achieving security requirements, maintaining compliance, and the other in shipping software."
