Security has become enough of a drumbeat issue that its importance has trickled down from the CISOs through the security organization to software developers. And slowly but surely, developers are beginning to take ownership of security as a part of the development life cycle.
But this heightened awareness of security hasn’t necessarily led to better software. Development teams are beginning to take some measure to make their code more secure, but they often are taking the most convenient ones, which are not always the most efficacious.
Organizations are now asking those development teams to do a lot of testing and to stop their shipments until that’s done. And, according to Tim Jarrett, senior director of product management at software assurance company Veracode, “You can only do that to development teams so many times before they say, ‘Hey, if this is going to keep me from shipping my work, I’m going to start looking at it, and I’m going to start doing it a little earlier in the cycle.’ “
RELATED CONTENT: ‘Security debt’ focus of 2019 State of Software Security report
Awareness on the part of developers is one thing, and buy-in is quite another. Jarrett said he knows of some organizations — especially those that have a lot of compliance requirements — where the threat of job loss for not doing security hangs in the air. In other industries, he said, the more compelling argument is appealing to the developers’ own better judgment and better instincts.
“If you have a team that’s empowered to do all of the things with their software and they also take the time to learn from what they’ve done and make improvements, then, unsurprisingly, you actually get improvements in the process and in the building of the software.” Jarrett said. “As we see teams pulling security into those sets of responsibilities they’re dealing with, then we see some of that same continuous improvement going on around security. Fundamentally, it’s about writing good code.”
Asking too much of developers?
It seems that every part of the development life cycle is arguing to be shifted left … testing, security, even deployment and infrastructure. And all the while, developers are being called on to add features to stay ahead of the market, and have those applications offer engaging user experiences.
How does all this get balanced? Different organizations are tackling that issue in different ways. Some have created development ‘squads,’ which include business stakeholders, security and test experts, developers and even operations engineers, to take a holistic approach to creating software.
Jarrett said Veracode is seeing some customers creating the role of security champion. “You identify a couple of developers in the organization who have some affinities for learning about security and … know enough about the foundations that they can participate in discussions with the team; they can call out where they see an area of concern, and they can call for help if they see something that requires different levels of attention.” He added that the security expert on the team must also have “a developer hat, because you can’t hire enough security experts to have one on every development team, unfortunately.”
And because not every developer is a security expert, Jarrett said that’s one of the reasons that you want to equip them with tools that will help catch things that they do.
Tools tailored for developers
Veracode, which has been in software security for many years, has had to change the way its thinks about security as its focus has shifted to developers. “Because developers are taking the process into their own hands, we’re changing the way that software testing technology works to be more developer friendly,” Jarrett said. “Otherwise, they just won’t use it.”
Specifically, Veracode has made its tool run faster and has tailored them more closely to work at the beginning of the development cycle. Jarrett said, “Where there might have once been a static application security test that happened at the end of the cycle that a few years ago took hours, that test at the end of the cycle now takes about eight minutes. And you can look at the same test earlier in the cycle and have it take somewhere between one and two minutes. And then you can have the same tests run on a smaller chunk of code while the developer is typing, and when they save it, they get feedback in a couple of seconds.”
The company also has been working to enable developers to more easily adopt the tooling into their processes, replacing traditional developer integrations with scripts that developers can check in with their code and don’t require additional maintenance, Jarrett explained.
Finally, Veracode has taken the time to learn about how developers learn. The company is offering computer-based training courses for developers who want to get a grounding in the foundation of application security, and has added hands-on interactive labs that help developers not only learn how to fix vulnerabilities but how to exploit them. “I think that inevitably, the more time you spend talking directly with developers rather than with the security team trying to guess what they want, you get better at figuring out how they’re going to work with the tools you’re trying to give them and what they need to be successful,” Jarrett said.
Content provided by SD Times and Veracode