Automated security testing for DevSecOps

Vanessa Wegner ·
Jul 8, 2020 · 4 min read · Leave a comment

This is the third in our five-part series on getting started with DevSecOps. Part one gives you nine ways to shift security left. Part two outlines the steps needed to create silo-free collaboration.

Nearly 83% of developers in GitLab’s 2020 DevSecOps survey say they’re releasing code faster today than ever before thanks to DevOps. About 65% also say security is shifting left in their organizations. How far left is that shift? Not that far: Over 60% of developers don’t actually run static application security testing (SAST) scans, and 73% don’t conduct dynamic application security testing (DAST) scans.

This needs to change.

Security is often a bottleneck to faster releases but it is much too risky to minimize or ignore. DevSecOps promises to bring security forward in the software development lifecycle (SDLC). This can be done a number of ways but automated security testing streamlines adoption and scalability. A respondent to this year’s DevSecOps Survey summarized it nicely:

Automated testing and continuous integration have made our deployments safer and more optimized. Now everyone in the team has the permission to deploy the code.

4 Ways to automate security in software development

Automation comes in all shapes and sizes. Scans and policies can be programmed manually or come as set operations out of the box; scans can be triggered automatically at code commit or manually initiated; and these scans can result in automated remediation and reports or they can require human intervention. Here are four ways automated security testing can be integrated into your software development practices:

  1. Automate security scans for every code change by running SAST scans. For ease of assessment, results should be sorted by the priority level of the vulnerability.

  2. Scan results should automatically initiate a work ticket or issue, or may stop a build depending on the policy in place. These results should be presented to the developer – in the workspace or IDE in use to avoid context switching – for instant remediation.

  3. Policies are automatically applied upon code commit with the option to capture and approve exceptions as needed.

  4. Analyze running web applications for known vulnerabilities using DAST scans. In GitLab, DAST scans can be automated by including the CI job in your existing .gitlab-ci.yml file, or by using Auto DAST.

5 Benefits of automated security

In addition to making jobs easier across development, security, and operations, automated security testing will help your team produce a safer and better-quality result.

  1. Reduced human error. Across all functions, automation reduces human error by taking the manual work out of tedious processes that rely on excessive attention to detail.

  2. Early security intervention. By placing security earlier in the SDLC, threats and vulnerabilities can be detected and addressed faster – hopefully before there’s even a chance that they’re exposed.

  3. Streamlined vulnerability triage. Automated scan reports can present the threat level of any vulnerability so that developers and security engineers alike can decide which must be addressed immediately and who is responsible for resolving the problem.

  4. Repeatable security checks. Any automated task should be repeatable, which means that all code can be reviewed and assessed the same way every time. This creates a trusted and secure environment and code base, and also helps reviewers identify patterns when results are presented in a consistent manner.

  5. Responsibility clarification. Automation takes uncertainty out of DevSecOps. Shifting security can cause confusion about who is responsible for what. But automated scans can present remediation options for the party responsible at that stage of development.

But it is also important to find a productive balance between automated security testing and manual work. For example, trying to automate overly rigorous policies may prove detrimental to business objectives and may not be realistically achieved – it’s important to find a balance between policy compliance and efficiency. It’s also key that automation doesn’t obstruct visibility. Make sure there is still a trail of operations to review if necessary – automated processes should still generate reports of what was done, when, and why the action was triggered. Last, but certainly not least: Automation is not meant to replace human beings. It is a tool meant to make their work more efficient and help them produce better results for the team, the business, and the customer.

Read more about DevSecOps:

Cover image by Daniele Levis Pelusi on Unsplash

10 Steps Every CISO Should Take to Secure Next-Gen Software

Understand three software shifts impacting security, and the steps CISOs can take to protect their business.

Get the eBook
Open in Web IDE View source