Continuous security testing

Ensuring software quality alongside delivery speed is always challenging. Maintaining quality requires double-checking code before release and generally being thorough. But you don't want to release a high-quality product two months after your competitor. And if you're under pressure to deliver, you might be inclined to skip some of these checks, which could result in buggy software. This need to balance quality and speed has led to an industry-wide adoption of continuous integration/continuous deployment or CI/CD pipelines, which automate recurring, tedious quality assurance tasks, so they don't slow down your delivery process. This also eliminates the risk of human error.

While these pipelines have traditionally been focused on automated QA testing, the ever-increasing number of vulnerabilities being discovered in software with public APIs has made them extremely valuable for security as well. Not only does a dependable security policy help build trust with your customers, but it can also save you from hefty fines resulting from GDPR and other compliance violations.

This reality has led to the practice of continuous security testing (CST). CST is part of the DevSecOps movement, an extension of the DevOps pipeline advocating the “shift left” model of introducing security tasks into the CI/CD pipeline as early as possible—prior to deployment, when they are still relatively cheap to fix.

What is continuous security testing?

Continuous security testing is the extension of the continuous testing (CT) practice for functional quality issues to security vulnerabilities. CST checks your code and that of third-party libraries for well-known and newly found security issues on an ongoing basis.

While CT verifies that your buttons work or your algorithm sorts correctly, CST monitors for sensitive data exposure or the use of unsafe implementations in open-source libraries.

In the CI/CD pipeline, CST consists of software composition analysis (SCA) and static application security testing (SAST). SCA checks which libraries your application uses and looks for vulnerabilities in their repositories. SAST performs static checks on the code without executing it. CST discovers and notifies of new vulnerabilities in public codebases included in your products.

While using traditional SAST tools can be time-consuming and yield a high number of false positives, Snyk Code makes the process fast and efficient, so you can run it on every PR.

By continually keeping security in check, you'll be able to respond to new vulnerabilities as they arise.

Integrating CST into your CI/CD pipeline

Threat modeling is a vital component of security. CST should therefore be planned in advance, at the inception of your software, so you can define the right security policies prior to implementing the checks. In order to ensure critical parts of your software are checked, quality assurance and security should be combined.

Moreover, everyone on the team should understand what constitutes a vulnerability. It may therefore be a good idea to start your journey from DevOps to DevSecOps by letting your team check for security issues manually with tools like OWASP Burp before you start automating security testing inside your pipeline.

Later, all of these tests—from simple unit tests to fully fledged test-driven development—can become part of your testing practice. You automate your security tests by running them alongside your functional ones.

Continuous penetration testing

Dynamic application security testing (DAST) checks your applications for security vulnerabilities while running. DAST is usually implemented at the end of the CI/CD pipeline because it requires a working, compiled version of your code. DAST, a form of black-box testing focusing on security, performs well-known penetration tests on your apps before every release.

While DAST might be more time-consuming than other kinds of tests, it finds externally visible vulnerabilities and is therefore a recommended addition to your automated testing suite. Obvious security vulnerabilities on your website are low-hanging fruit for malicious actors.

Another advantage of DAST is that it works independently of the programming language used to implement your app. This means you could have, for example, three web apps built by five different teams each using their favorite development tools and languages – and still be able to use DAST.

Automated remediation

Once you've identified vulnerabilities in your code, it's time to fix them. Automated remediation tools use the findings of your SCA, SAST and DAST checks to provide you with pull requests (PRs) for your code repositories. Even a large number of vulnerabilities can be broken down into just a few lines of code. They can then be easily and automatically fixed with code templates created by specialists.

Automated remediation means your team doesn't become overwhelmed with searching for vulnerabilities and implementing all these fixes themselves. Again, manual remediation can introduce new problems in the process due to human error, but vulnerability remediation can be as simple as accepting a pull request (PR) and deploying a new app version.

Third-party penetration testing

Third-party penetration testing can offer an added layer of security. Third-party testers try to break into your system from the outside. Though it is a manual process, having an external actor with no previous knowledge of your software attempting this can be enlightening. Seasoned penetration testers can find more complex vulnerabilities that stretch out over multiple modules, which may be overlooked by automated software.

Moreover, automated security testing and remediation software has to get its information from somewhere. So involving penetration testers in your process is an excellent way to keep your processes up to date in the long run and to integrate the results of such manual penetration tests into your CSTs.

Summary

Security testing should always be a priority when building new software. It is a crucial skill and one that should be practiced, even manually at first. Data poses serious risks if not handled correctly, especially in today's world of compliance policies and privacy laws. If you are collecting the information of thousands of users, a data leak could ruin your company overnight. Automating recurring tests allows you to focus on software quality and speed so you can protect your data and keep up with the market. Continuous security testing is an important part of the secure SDLC. CST helps you maintain awareness of your application’s overall security posture while allowing you to fix newly discovered vulnerabilities between tests and continuing to do vulnerability scanning long after your application has gone into production.