As developers begin to be responsible for more and more elements beyond just coding, having tools take some of their burdens will become necessary. Developers are now expected to become security experts. While it’s essential 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 enable 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 ten security team members and 3000 developers.
“So ten are trying to keep up with 3000. And that doesn’t work. Right. So the evolution has been with all the things that we just talked about; you have to 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 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 reduce that friction, but only if they are carefully selected and meet all the development team’s needs. According to Johnson, there are several 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 consider 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 key areas that you have to take into consideration. Because if you don’t, you 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.