As developers begin to be responsible for more and more elements beyond just coding, having tools take some of the burden off them will become important. Developers are now expected to become security experts, and while it’s important to know the basics such as how to write secure code, there also becomes a dependence on tools, such as static application security testing (SAST) and static code analysis (SAS), to make that added responsibility easier.

Scott Johnson, senior director of product management at Synopsys, explained in a recent episode of the podcast What the Dev that more and more, the security elements of a company are becoming more developer-centric and falling more on developers. For a company to be successful, they need to ensure that their app security teams are enabling developers to write secure code. 

Johnson shared a story of meeting with a bank and the person he was speaking with said their security team had been feeling worn out. He asked how many security people they had, and how many developers. The response was 10 security team members and 3000 developers. 

“So 10 are trying to keep up with 3000. And that just doesn’t work. Right. So the evolution has been with all the things that we just talked about, you have to really enable the developers. The app sec team members are still key, but they’re more of the Guardians of application security. And more and more the developers are the ones doing it. They’re the ones getting validation, running the scans, using Jenkins from a build server integration perspective, and trying to crank out their code and doing it as fast as they can, and as secure as they can.”

One thing to watch out for is making sure you’re not adding unnecessary friction between the development team and the application security team. 

Friction can occur when the security team starts layering on processes and tools that significantly slow down the development process. 

“It’s the friction that could create the conditions where the developers might do workarounds, you know, ‘hey, I’m not going to use that IDE because that’s not that’s not enabling me to release the software that I want to create.’”

Scanning solutions can help to reduce that friction, but only if they are carefully selected and meet all the needs of the development team. According to Johnson, there are a number of features that companies should be looking for when trying to find a new scanning solution. 

First of all, it should cover the languages and frameworks that are being used to develop applications. Other areas to keep in mind are its automation and integration capabilities, tooling, whether or not it has open APIs, and how much detail it provides on dependencies. 

“Those are all really key areas that you have to take into consideration. Because if you don’t you then end up in situations where that friction comes back into play. And what did developers not like? They don’t like friction. They don’t like things that slow them down,” said Johnson.