Developer Tooling: A New Hope

With all the doom and gloom surrounding the endless stream of data breaches, it’s sometimes easy to feel pessimistic about the future state of the AppSec industry. I should know, being British, my default psyche is that the glass is always half empty, not half full. But for me, AppSec is different. I have been in the AppSec business for almost 20 years and have never felt as optimistic that we are going to see a fundamental improvement in the coming years. Many are saying that changing development processes will make AppSec even more challenging, but I feel the opposite. In fact, my optimism stems from the advances in developer tooling and the subsequent development practices that these software development tools are facilitating. I believe these advances will actually move the needle versus simply plugging more holes in the dyke. Let's face it; the penetrate and patch model hasn't worked for the last 20 years. At this point, there are enough role model companies like Microsoft that have shown that when you “bake security in” and empower developers to “do security,” things do change. It takes a few years to take hold and course correct big ships, but change does come.

The great challenge of course has always been that “baking security in” and “empowering developers” was hard because security didn’t insert seamlessly into the developer workflows. But new tools and processes are making it easier to work security into developer processes, and giving us reason for optimism in the AppSec world.

Code Editors

When I worked at Microsoft in the Developer Division many moons ago, we shipped Visual Studio along with built-in security scanning. The usage stats on how many Microsoft developers used Alt F5 and scanned their code regularly was staggering. The lesson was that if you make it easy and available, they will use it. And this is important, because the more you scan, the more you fix. Our just-released State of Software Security Volume 9 report shows that the more often people scan their code, the less vulnerabilities remain unfixed. In fact, we found that flaws persist 3.5x longer in applications only scanned one to three times per year compared to ones tested seven to 12 times per year.

These days, modern developers have embraced the less complex polyglot editors, notably VS Code and, boy, what an ecosystem has formed around it. Being able to deploy plugins that help developers get security on their desktop and address security early is exciting. No more security hangovers and after-thoughts. No more parallel processes.

There are still some serious concerns with the security of editors, and several significant attack vectors to the software supply chain. Well cover those in later posts and a talk series in 2019.

Git

Whether it’s GitHub or Gitlab, distributed version control systems (DVCS) have revolutionized software development. The ability to share code and reuse code has obvious benefits, but it’s actually the Git workflow that excites me the most. When I watch developers in the SourceClear team at work, everything revolves around the Pull Request, or PR. The PR has become a de facto control gate that requires that tests have been run or eyeballs have looked at it before it is merged, and consensus must be reached that it is meeting the quality bar before being allowed into the master branch. This is exciting because when the Git workflow is embraced, it has the effect of changing culture and empowering developers to apply quality checks right inside of the developer workflow. As Peter Drucker once said, culture beats process everyday. Developer tools like GitHub and GitLab have PR APIs that allow vendors and teams to integrate security tools and run common tasks like security linting, basic software composition analysis (SCA), and secrets checking. Who would have thought at first blush that distributed version control would emerge with such an important centralized control gate.

As with code editors, there are still some serious concerns with the security of some Git setups and several significant attack vectors to the software supply chain. We’ll cover these in later posts and a talk series in 2019.

Continuous Integration

Without a doubt in my mind, the most important security building block in the modern tool chain today is Continuous Integration, or CI. From its early days of acting as a central build server to its most common use-case today as a central testing system, CI offers “the authoritative source of record” if code meets the quality bar. This is obviously great for quality, but doubly great for security, because CI is the only place in the developer toolchain where code is actually built and, therefore, accurate analysis can take place. By integrating into the build process, you can generate a call graph and a dependency graph, two core techniques needed for accurate SAST and complete software composition analysis (SCA).

And, you guessed it, just as with code editors and Git, there are still some serious concerns with the security of some CI setups and several significant attack vectors to the software supply chain. We will also cover these in later posts and a talk series in 2019.

Continue the Conversation

Ultimately, embracing the innovation happening in developer tools is exciting for security and offers a new hope.

Let’s continue this conversation. I’ll be talking about these trends, their security implications, and specifically how they fit into the open source risk discussion when I hit the road this month. Please join me for the Open Source Conundrum Roadshow, coming to a city near you