Let’s Level Up Software Security

Photo by Shahadat Rahman on Unsplash

We’ve all heard, “Software is eating the world.” But, today let’s talk about a corollary: “Software bugs are the root of all evil.” Software developers certainly will be nodding their heads in agreement, but all of us from Luddites to gadget lovers need to consider how important it is to minimize the number of software bugs living in the wild, particularly when it comes to our online security and — as software continues to eat away — our physical safety, too. When software is key to the operation of our cars, highways, energy production, communications, personal memory storage, and entertainment, any bug that allows a bad actor to cause disruption is important to remove.

There’s a whole segment of cybersecurity dedicated to trying to protect us from these bugs called Application Security, or AppSec.

Let’s dig into this a bit more. Looking at Momentum Cyber’s 2020 CYBERscape, it breaks AppSec companies into two categories: WAF & Application Security and Application Security Testing.

I think a good way to look at the two groups are as companies that help identify bugs when software is being developed versus companies that help identify bugs when software is in production.

When software is being developed, bugs can be identified and fixed before the release. If bugs causing security vulnerabilities make it into the wild and are then identified, these vulnerabilities have to be mitigated using additional tools and methodologies until new versions of the software are released.

In an environment where office operations are becoming more distributed and virtual, we can no longer rely on many of the perimeter-based vulnerability mitigation methods of the past. When mitigation becomes more difficult, the best way to ensure safe and secure operations in today’s environment is to fix the problems in software during its development — before it’s released.

It’s important to clarify that this discussion has expanded to cover much more than just application security. Typically, application security focuses on software applications running on the web, in the cloud, or on your laptop or mobile phone. Identifying and fixing software bugs before they are released covers a much broader topic of general software testing, which includes any type of software — web applications, desktop software, mobile apps, firmware, industrial control software, etc.

Given the broad topic of software testing, let’s look at how testing fits into the modern Software Development Life Cycle (SDLC), and more specifically, how security-related testing fits in. Within the SDLC, there is the Code-Build-Test-Deploy iterative cycle. During this cycle, many types of testing tools and methodologies can be used:

• Automated integration testing tools
• Unit testing
• Behavior-driven or Test-driven software development
• Performance testing tools
• Lint tools (often built into integrated development environments [IDEs])

To handle running all the different types of testing along with the many build and deployment processes, development teams piece together a network of tools to attempt to create a seamless, automated process that can be run in an iterative fashion. When successful, the iterative process will provide feedback of the testing results to developers as quickly as possible directly into their IDE or their centralized bug-tracking tool.

In more recent years, security testing tools have been added into this mix. Several subcategories of security testing tools are run at different stages in the SDLC:

• Static analysis security testing (SAST): These tools scan code looking for patterns that have been identified as risky or have the potential to cause security vulnerabilities.

• Dynamic application security testing (DAST): These tools run code to attempt to find security vulnerabilities. Often, these tools focus more on web applications and less on desktop software and firmware — but the concepts apply to all types of software.

• Interactive application security testing (IAST): These tools iteratively combine SAST and DAST techniques together. Again, these tools mostly focus on web application testing.

• Database security scanning: As the name suggests, these tools scan databases in search for configuration and design weaknesses that can lead to security vulnerabilities.
• Penetration testing: Efforts typically run once software has been released into a testing or even a production environment where a mix of human-based and automated scanning efforts attempt to uncover security vulnerabilities. This often takes a more holistic testing view, often attacking the software and the infrastructure/environment it’s running on in the test.

Security testing is still relatively new and, therefore, is often not effectively integrated into the network of tools teams use to streamline and automate the SDLC. In addition, because security testing is so heavily oriented around automated scanning and automated weakness checks, these tools notoriously generate massive amounts of results, often not applicable within the context of the software. In addition, the different types of tools will often identify the same issues multiple times. As if these weaknesses were not enough to cause development teams to throw up their hands in frustration, organizations often wait until the end of the development cycle to run security tests. This violates today’s philosophies of integrating testing into the continuous iteration generally found in teams following agile methodologies.

These challenges scream for tools and processes that help better integrate security testing into the SDLC. Playing off the overused term “DevOps,” the industry has started using the soon-to-be even more cliché term “DevSecOps.” DevSecOps describes not only integrating the effort of managing and automating the SDLC, deployment, and management of the production system into one team, but also adding the responsibility of managing and integrating security testing and monitoring into the same team. The good news is that Gartner has created a great diagram showing how this works and the tools that may be used at each step in the process. It’s called the DevSecOps Toolchain.

The diagram shows where in the process each of the different types of security testing tools and methodologies fit.

With so many types of security testing at different stages in the SDLC, the importance of having tools to help orchestrate and centralize this type of testing becomes clear. In today’s agile development projects, not using a build tool like Maven or Gradle or a continuous integration(CI)/continuous deployment (CD) tool like Jenkins to help automate the process would be considered crazy. Similarly, no team following a truly integrated and automated DevSecOps process should be without tools that orchestrate and centralize the management of the security testing processes.

You wouldn’t develop without using build tools to orchestrate the process. Why do security testing without a tool to manage it all?

This type of tool should handle orchestrating security testing and automate importing test results or production operation feedback all into one central repository. It should then correlate results; remove duplicates when the same problem is found using multiple testing techniques; prioritize the results so that only the most important can be the developers’ primary focus; and, finally, integrate with issue tracking, build, and IDE tools to quickly feed the prioritized insight to the developers in near real time. The faster and easier it is in feeding prioritized testing results back to the developers, the faster the team can go, thereby enabling more bugs to be fixed and increasing the security of the produced software.

So, what is this tool? Can one get this capability from existing software test automation frameworks and tools? Maybe. But, software test automation tools often fall into a few buckets:

• Unit testing frameworks: These frameworks, Like Mocha or Mockito, mostly focus on early SDLC testing. They help make unit testing and test-driven development (TDD) methodologies go quickly.
• Functional testing framework: Selenium is the open source 800-pound gorilla in this space. Most tools focused on automated functional testing are web oriented and user interface oriented.
• Performance testing frameworks: While the previous two categories are solidly functional testing oriented, this category of tools tests how your software and infrastructure scale. Again, these tools (for example, JMeter, LoadRunner, and LoadNinja) are often web oriented.

These categories generally focus on just one part of the SDLC. It’s not common to find a tool that will combine test results from both unit tests and automated functional tests, and the same tool certainly wouldn’t additionally combine manual test results or feedback from linting tools all into a centrally managed repository. Because security testing tools operate at many points throughout the SDLC, there is a needed ability to combine results from many tools, and the three categories of tools listed above are not well positioned to do this.

Then, do tools like this exist? As it turns out, Gartner defined a category of tools last year called Application Security Orchestration and Correlation (ASOC). While that is a bit of a mouthful, it does describe a nascent set of companies working on the types of security testing problems described above. These companies focus on this extremely important keystone capability — orchestrating and streamlining the development processes needed to reduce software bugs that lead to cyber risk and reduced physical safety.

At the cyber-focused startup foundry where I work, DataTribe, our bet is on Code Dx. It offers a solution that integrates with, by far, the most tools in the ecosystem. In addition, its platform focuses on orchestration, integration, and prioritization in a way that maximizes the speed of the feedback loop from security test results and bug discoveries back to the developer who needs to fix them.

Also, a very cool benefit of using tools like this is that they allow organizations to more easily track security improving actions in the SDLC. These actions can be summarized in reports and dashboards for each development project. Unlike functional bugs, where customer satisfaction and feedback is a good measurement for whether software has too many bugs, organizations don’t want to wait for a breach or some other cataclysmic event to see if security bugs have been well mitigated. Proof of security testing best practices and adherence to industry compliance models are often demanded up front by executives and industry. As an example, by consolidating all security testing results, Code Dx provides a centralized system of record on all security testing, analyses, and bug-fixing activities with reports that show the security posture of each development project in an organization. So, not only does the platform enable development teams to reduce software security bugs, it provides a great solution for proving they’ve been reduced.

With everything becoming software, software bugs clearly are the root of most cybersecurity vulnerabilities in the wild. In today’s highly decentralized environment, the only way to mitigate these vulnerabilities is through fixing the bugs. It’s time for organizations that build software — big or small, regulated or not — to move to the next level of software development maturity and properly implement an automated, well-managed DevSecOps process.

Leo is the chief innovation officer at DataTribe, a cyber and data science startup foundry “Where the world’s best come to build dominant companies.”