Shaping the future of DevSecOps with automated security testing

Key takeaways:

 

• A key goal of automating security testing is to make fixing security defects a routine part of application development.
• Manual security testing can’t keep pace with releases in agile development.
• Incorporating automated security testing tools into existing development pipelines is a critical best practice for making security a part of software quality.

Software development has changed over recent years to enable the continuous delivery of new features and enhancements in constantly changing web and cloud environments. But when development teams continually push new code to production – often including libraries and frameworks they didn’t create and don’t control – it’s easy for exploitable security flaws to go live, too. With bad actors relentlessly probing these environments, systematically integrating security checks and practices into DevOps processes across the full application life cycle becomes paramount.

In the resulting agile environments, manual security testing is simply too slow and labor-intensive. It creates bottlenecks, increases security debt over time, and tempts teams to let problematic code slip into production. The better solution is to extensively automate security testing so that security issues are caught earlier and treated like any other code issue – fix immediately, breathe deeply, move on. This article defines security testing automation, explains why automating security throughout the software development life cycle (SDLC) is so important, and walks through key considerations for automating security testing in your environment.

What is security testing automation?

Security testing automation involves implementing tools and processes for automatically checking software code and its behavior to identify potential security-related problems as quickly as possible after the code is written, integrated, or run in a test or production environment. As with all automated tools, the point is to eliminate human error and make the entire process more efficient and effective.

Automated tests exist to identify a wide spectrum of security issues and vulnerabilities across the entire attack surface of a web or cloud application, including memory leaks, undefined behavior, vulnerabilities in JavaScript or web API code, problems with authentication and other access controls, misconfigured cloud or server configurations, and much more. The best of these tools offer comprehensive coverage, can be run on a schedule and/or whenever code is pushed, deliver convenient and actionable insight to help developers fix problems, and use advanced technology to prevent false positives.

Types of automated security testing

Testing automation has come a long way since the earliest lint-type tools for automatically identifying programmatic and stylistic errors in source code, and security testing is no exception. Several approaches to security testing automation now exist. The most prominent include:

• Software composition analysis (SCA): SCA tools identify known vulnerable components in open-source code you integrate, and also help you monitor code quality and manage license compliance.

• Static application security testing (SAST): SAST tools directly analyze source code in a non-running state (before it’s compiled), flag potential vulnerabilities, and recommend solutions. Since the source code must be visible to them, they are sometimes called “white-box” tools.

• Dynamic application security testing (DAST): DAST tools probe an application from the outside as it runs, detecting potential vulnerabilities in context. The same DAST tool can be used on any web-based application because they are independent of the programming language. They search for opportunities for injections and other attacks by first mapping out the application and then testing all identified input vectors.

• Interactive application security testing (IAST): IAST tools inspect the internal workings of an application as it runs (before or after release), providing feedback about your own code as well as linked libraries and frameworks. Various IAST types exist, some requiring code instrumentation.

Of course, implementing multiple new tools can introduce complexity and management challenges. That’s why some automated security testing solutions bring together multiple testing methods in a single package, as with Invicti’s combination of DAST, IAST, and SCA. Depending on the approach and extensibility, security tools can be incorporated into integrated development environments (IDEs) and existing development workflows.

The role of integrated security testing in DevSecOps

Automated security testing should fit smoothly into existing development and testing workflows to deliver timely and relevant insights within the tools developers are already using. Invicti’s Distinguished Architect Dan Murphy puts it this way: “When security tests are automated and run on every check-in, developers can find and fix issues much more efficiently. The goal is to treat the introduction of a critical security vulnerability just like a code change that causes unit tests to fail – something that is fixed quickly, without requiring the overhead of meetings and internal triage.” 

Achieving that goal may require broader cultural change in many DevSecOps organizations. Developers, testers, operations teams, and security professionals should be encouraged to collaborate closely in promoting continuous integration and delivery of secure application code updates. For example, Invicti’s tools enable DevSecOps teams to monitor their results constantly and gain regular feedback – but all involved still need to close the loop, using those insights to address immediate issues and improve the way they manage vulnerabilities going forward. (To learn more about getting DevSecOps right and – just as importantly – not getting it wrong, see 5 mistakes to avoid when building DevSecOps.)

Security testing automation best practices

As more organizations automate security testing throughout their SDLCs, best practices are emerging. We’ve already mentioned a few: recognize the centrality of culture in making DevSecOps work, leverage existing processes and ticketing systems, and close the feedback loop to fully utilize the insights your tools provide. Here are three more:

• Eliminate false positives: Before implementing tools, do your due diligence to ensure accuracy not just in principle but in practice. If tools can’t be trusted to report only real issues, developers won’t use them and they won’t deliver security value – in fact, they may even be counterproductive.

• Test the entire attack surface: Maximizing test coverage can include data protection, scripts, session management, error handling, third-party/open-source code, and access control, including problematic internal interfaces that may create vulnerabilities to insider threats.

• Integrate with cloud workload protection: As you deploy more cloud-native applications, integrate AppSec security testing with cloud workload protection capabilities such as scanning container images and infrastructure-as-code (IaC). Make sure your teams collaborate across functions to support more comprehensive and holistic enterprise security automation. 

For more application security testing best practices, see the Invicti white paper: Enterprise Web Application Security Best Practices: How to Build a Successful AppSec Program.

The benefits of automating application security

At the risk of using a cliché, security testing automation and DevSecOps are journeys in which you continuously learn new ways to improve, and your team members become progressively more effective as individuals and collaborators. The benefits of taking a common road with automated security testing and DevSecOps include faster deployment of new code and features, greater repeatability and consistency to help you scale your environments, higher overall code quality, less downtime, more productivity in resource-constrained environments, and, crucially, lower security risk. These benefits aren’t just worth the effort – they are indispensable.