Knowledge alone isn’t enough to manage vulnerabilities. Developers need to be part of a proactive security process with integrated AppSec tools.
I love the boundless possibilities of modern software development. Anyone with a computer and an internet connection can code. More than any other time in human history, each of us has the power to build something in software, to realize whatever we can imagine.
At the same time, a thriving ecosystem of open source software components allows us to stand upon the shoulders of giants, to quickly assemble huge building blocks of existing functionality that can rocket us toward our own goals.
At some point, of course, reality intrudes. Gravity is a harsh mistress. If we create buildings, they must not collapse. If we create airplanes, they must stay aloft until they’re ready to land.
If we create software, it must not fail, either by accident or under attack.
In some sense, developers are like the goose that laid golden egg. After all, developers are the creative workers that produce the software that brings in revenue.
However, security vulnerabilities are essentially mistakes made by developers; every once in a while, the goose lays a dud.
Sometimes the connection between developers and security vulnerabilities leads management to make bad decisions. If developers are the source of vulnerabilities, the reasoning goes, then let’s just train them in security so they don’t make any more mistakes.
Problem solved, right? Not at all.
Although giving developers more knowledge about software security is an excellent step forward, it is a narrow, simplistic approach to a much larger challenge.
The notion that developers create software is a gross oversimplification. Software is made from of the effort of a wide variety of contributors.
The path that leads all the way from an idea to a user is the software supply chain. Developers are important, but they only occupy one link of the whole supply chain. Building secure software is about taking steps to reduce risk across the entire supply chain.
You can move a big pile of dirt with a shovel, but if you have a backhoe handy, it’ll go much faster. Making software more secure works the same way. You can hunt down vulnerabilities manually, but if you can use automated tools, you can accomplish so much more.
A single software application could have many thousands of lines of code, sometimes millions, especially if you add in the open source components that are part of the application. It is simply not feasible to have developers hunt security vulnerabilities manually.
Security tools are not as smart as humans (yet), but they can do a huge amount of analysis in a relatively short amount of time. Effective security programs use the best parts of tools and humans; tools can cover broad areas quickly, and humans can do more targeted analysis.
Some activities simply cannot be automated. Most, if not all, the security analysis that happens during the design phase, for example, must be done by humans. But during development, testing, deployment, and maintenance, a variety of useful automated testing techniques help flush out security vulnerabilities.
Developers are creative people who solve tough problems. The core of the job is creating code that gets something done. While security is an important part of building applications, it is not really at the heart of what developers do.
So yes, it’s good if developers know about security, but what they really need is to be part of a proactive security process. When developers make mistakes, automated tools should let them know and help them fix it. This needs to happen in the least intrusive way possible, which means integrating security into the tools that developers already use.
In a properly implemented software development process, security is nearly invisible to developers—just a normal part of everyday life. They spend their days writing code, confident that the designs they’re implementing have already been evaluated and hardened from a security perspective. When they make coding errors, a plug-in in their development environment (Code Sight™, for example) tells them about the vulnerability and provides pointers about how to fix it. When they commit their code to the source repository, automated tools—such as Coverity® static application security testing (SAST), Black Duck® software composition analysis (SCA), Seeker® interactive application security testing (IAST), and so on—find vulnerabilities, which are fed back to developers via the issue-tracking systems (such as Jira) that they are already using.
At the end of the day, security demands not that we improve developers, but that we build a better process around developers.
Jonathan Knudsen likes to break things. He has tested all kinds of software, from network infrastructure and medical devices to cryptocurrency nodes. Jonathan has worked as a developer, consultant, and author. He has published books about 2D graphics, cryptography, and Lego robots, and has written more than one hundred articles on a wide range of technical subjects.