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.