As companies shift their businesses to engage with customers online, developers are becoming a center point for innovation. So as these companies build out DevOps and DevSecOps practices, they’re assembling teams around the developer to ensure that as they’re building new features at a rapid pace, security and operations components move along with that.

Yet development and security traditionally have been at odds. Development is about moving quickly to innovate, while security is about risk management in the organization, and that takes time. As development teams have gained more influence inside the business, security leaders have had to change their mindset and find new ways to talk to developers.

Eric Swenson, VP of product marketing for security solutions provider Checkmarx, said security needs to work to enable secure development and move beyond a “department of no” stigma to help reduce risk down from what it’s doing because it’s going to potentially introduce risk. 

RELATED CONTENT: The modern risks of open-source code

Some years back, Swenson said, “I had a conversation with a friend of mine, who was a security architect for an online streaming company. I challenged his mentality around security being a gate or possible blocker. He told me at one point, he would rather shut down a website to prevent any sort of data breach or disruption to business operations. And I said, ‘Well, you know, that’s interesting, but try to go into your CEO to tell him you’re going to shut down the website because you’re concerned about a security risk. You may be making a career limiting move.’ ” 

DevOps — and DevSecOps — require moving security planning and testing into software development. Applications are being built in small pieces, moving through CI/CD pipelines, and deployed into containers. Some teams are working only on the front end of the application. Others are only working on the back end, and still others are working on the integrations. Because of this, security has to be considered across the entire development lifecycle, compared to waiting until the application is running in production — which leads to higher costs for remediating vulnerabilities, and slows innovation.

“Developers are checking in and out pieces of the application they’re responsible for, adding additional features and capabilities then checking them back into the central repository as it moves through the development process; scanning for critical vulnerabilities as early in this process as possible by the developer presents an opportunity for share ownership in securing the application,” Swenson explained.

And because applications are being built from small services and components, it makes sense to have the developers creating those pieces own it all, including security testing. 

“For organizations adopting a DevOps philosophy for application development, part of that philosophy is empowering developers to use the tools and technologies necessary to move quickly and innovate; security teams have to shift their approach to a more consultative role with developers,” he said. “And so really, if you’re thinking about the entire software development life cycle, it’s definitely an evolving process. Traditionally, the heavy-handed role of security has to evolve to educate and guide development in toward best practices for secure development.”

Yet developers often do not have education in security, so to ask them to be responsible for it in their applications or components requires some training, Swenson said. Importantly, while training developers in security, it’s important this is a collaborative effort between developers and security. “This is about bringing two teams with differing goals, together to focus on a common objective, coding securely.”

Swenson added that the argument that developers don’t care about security is quickly going away. Developers, he noted, would rather fix something early on, while in development, rather than having to go back and fix it post production, because the business wants its developers to continue to move forward with the next feature release. He said that developers think, “If I just fixed it before I released it, or before it’s in production, I would be in a much better place, a much happier developer, because, you know, nobody wants to go back and do the re-work. They always want to be pushing on to the next thing and seeing what they can accomplish there.”

 

Content provided by Checkmarx and SD Times