As the Internet of Things expands, software is being embedded in all manner of physical objects. This is boosting the demand for security testing, with automated processes integral to the development pipeline. But not all approaches are created equal. In order for DevSecOps practices to be properly integrated into a product lifecycle, with the right tests for potential risks and flaws, it’s important to assess the reliability of automated security testing.
The Challenges of Automated Security Testing
One factor is the thoroughness of the tests themselves. It can take a while to accumulate all the necessary data, which can be disruptive.
To mitigate against this, some organizations are tempted to run automated systems in parallel as “non-blocking” tests, which has some additional risk, as it requires additional manual oversight. A methodical test can also be inefficient in that, at times, it might detect vulnerabilities and dependency failures unrelated to the code itself.These kinds of disruptions can create a temptation to delay the testing process. Postponing might also be a hangover from an older view, when security sat in its own silo and problems were addressed later in the development process. It is now broadly acknowledged that there are benefits to testing throughout the lifecycle, given that security issues caught earlier could save significant disruption on the back end, making the initial delay worthwhile.
How to Effectively Implement Automated Security Testing
Automated security testing itself is most reliable when smaller processes are deployed within the larger production cycle. This way, the automation services can grow along with the software, and be linked to the overall build. With this approach, developers can adjust as they go, always working with security as a top priority. They can acquire a deeper understanding of how to manage false positives, and more importantly, the risk of false negatives.
Introducing automated tools individually at an early stage also supports training—a critical component to DevSecOps. In a proper test-driven development environment, developers write an automated test for the code before the code itself is written. This enhanced level of awareness makes an organization better equipped to address issues that automated security testing might discover later in the game. And because earlier engagement results in fewer large-scale issues, it makes more efficient use of valuable developer time.
To cover the bases, there are a number of good products out there, such as OWASP ZAP and Burp Suite, which are specifically designed for application security testing. There are also tools that can scan configurations of cloud-based infrastructures such as Amazon Web Services (AWS) and Microsoft Azure, ensuring that applications are running securely in these environments. Then, of course, there are analysis tools. Examples include Valgrind, which can detect memory leaks and memory management problems; and Veracode, which can automatically scan for problems early on, thus saving headaches at the quality assurance stage while also helping to train developers to program with security in mind. All of these are reliable but limited to their area of focus.
Given that automated security testing is more consistent than manual testing, with the same tests applied across applications and environments, its appeal is obvious. Once the technology is in place, and up and running, it is fast, inexpensive, and reliable. What it does, it does well, freeing up human resources to devote more time to the areas that require manual testing. And automated tests are becoming more sophisticated, with continuous integration helping to address a range of issues that diminish performance, from memory and input bugs to insecure and undefined behavior.
That said, there are still many areas where an over-reliance on automated testing might be risky. In these instances, humans are the best resource for the job. Examples include permissions and business rules, which are often specific to an enterprise and not identified with a more generic threat environment. Which is to say, automated security testing is most effective in those areas that are repetitive and non-intuitive, and is not intended to replace manual testing in unique areas.
Choosing the Right Automated Security Testing for Your Project
This brings us to a discussion of the relative merits of open-source and commercial automated testing solutions. Proprietary vendors offer value in terms of customer support for unique and advanced technologies. Open source is accessible and powerful but can require a higher level of internal expertise. It must also be acknowledged that custom scripting can be time-consuming, and therefore costly.
Organizations large and small are usually dependent, to some degree, on third-party code, which can inadvertently introduce vulnerabilities to an application. Automated security testing can help here. Along with utilities that can continuously scan databases for vulnerabilities, there are frameworks designed for specific languages, such as Mittn for Python and GauntIT for Ruby.
Given the complexity of many software environments, many organizations consider engaging with an Application Security Testing (AST) vendor. An AST can provide an expert take on where automated testing can be reliable, and how best to manage trade-offs when scanning an integrated development environment, ensuring that all security scanning tools and services are fully API-enabled.
At the end of the day, humans are still essential for addressing the viability of the internal logic of a specific application, and a third-party manual review is critical because a human eye can often see what a scan cannot. Automated security testing is reliable, and getting better, but it has its limits. Knowing those limits is critical to ensuring that DevSecOps covers all the bases, and gets the job done in a timely manner, with robust software that integrates the best security practices, from start to finish. For more info: https://www.pslcorp.com/
PSL CORP – USA
154 Grand St, New York, NY 10013, USA