Security Automation: Where Does It Fit In Your Secure SDLC?

In the fast-paced environment of software development, teams are constantly finding themselves having to do more with less. 

The pressure to produce new features and push out new versions on a shortened time frame can feel overwhelming for software development teams, no matter if you are a small startup or part of an industry-leading enterprise.

One of the biggest challenges facing development teams today is to ensure that their products are free of security vulnerabilities that can be exploited by hackers, putting their customers’ data and the company’s future at risk. Whereas in a previous era the responsibility for securing the product may have fallen on security professionals, their attention is mainly directed into other security areas, leaving the brunt of vulnerabilities management on the developers’ shoulders.

So with their limited resources of time, how are developers meant to take on the heavy lift that is ensuring the security of their projects? With potentially millions of lines of code to manage for vulnerabilities, organizations have turned to automated technologies to test, poke, and of course, prod as their products move along through the Software Development Lifecycle (SDLC) and on out to deployment.

Security automation — The force multiplier

When it comes to figuring out complex, difficult to solve problems, there is nothing more potent than an experienced engineer who can bring creativity and hard-won know-how to the table. 

For everything else there’s automation.

We have arrived at the point where many of the tasks involved in vulnerability management can be delegated to automated AppSec tools. These technologies are capable of carrying out the grunt work of spinning up properly configured environments on servers, checking code for risk factors like common mistakes in code, identifying open source components with known security vulnerabilities, help with maintenance ops, and more, hopefully freeing up developers to deal with issues that are more in need of their human touch and expertise.

For now, at least, there is no one-size-fits-all solution that handles every security issue from every angle. This means that we need to have a diverse set of tools in our box that can each play a role in maintaining a secure SDLC at every stage along the line.

In hopes of providing some direction on which tool can do the job at various stages, I have pulled together a list of some of the most important tools that can help you and your team reach the security finish line and beyond.  

1. Creating your server environments

The first stop on our path to software security automation greatness is in creating server environments to run your code is the first step in introducing automation to your secure SDLC.

One of the most common opportunities for trouble at this stage comes from human error with a security misconfiguration that could cause vulnerabilities. For example, when you create a Linux EC2 instance in AWS, you have to update it to the latest version after you create it. If someone forgets to update the server, it could be compromised.

To avoid this pitfall, I recommend using automated security processes to create the servers in the exact same way each and every time, reducing the risk of mistakes from a manual setup. We can see a good example of how to put this advice into practice in setting up a LAMP server which can be automatically replicated with the push of a button.

CI pipeline automation tools such as Jenkins or Atlassian Bamboo are your best option for handling this task at scale. With the exception of servers for DEV, CI tools should be your only destination for creating test and production environments.

2. Automated security scanning and testing

The devil is in the details, but who has the time to look for vulnerabilities line by line?

The answer is Application Security Testing tools.

Static code analysis tools like Static Application Security Testing (SAST) scan your source code and find basic, common patterns that may lead to security vulnerabilities. The hope is that this testing will produce a (hopefully) manageable list that your team can investigate. 

You should run these vulnerability scanners with every build to find new vulnerabilities that might have been introduced with the new code.

Dynamic Application Security Testing (DAST) tools like Owasp Zed Attack Proxy (ZAP) can automate more complex security tests. ZAP’s scripting engine allows you to use several scripting languages to create complicated tests and run them repeatedly. ZAP’s Rest API is especially powerful. The REST API gives you the power to run ZAP scans in the build pipeline without manual intervention. The results can be output as CSV and consumed by another process to create support tickets in tools like Jira.

Pro tip: when manual tests find vulnerabilities against your applications, use ZAP to script the attack and run it against other applications in your environment to find other vulnerabilities without paying for more penetration tests.

A word to the wise. While these scanners can be essential for plowing through the code, they are known to produce plenty of false positives along with the legit vulnerabilities. This means that it is important for security practitioners to weed these out as quickly as possible and only give the best results to the development teams.

3. Automated security unit tests

Developers are long familiar with the need to perform unit testing in order to ensure that their products are functioning, hopefully squashing bugs when they find them. With this practice well established, it should not be too much of a stretch to extend these test-driven development principles to address our security concerns.

To save time here, find basic security tests that you can run automatically with every build. Common configurations like server headers and error pages being returned and other basic security problems can be found using simple tests that the developers can write themselves.

4. Open source automation

Open source components comprise the biggest chunk of code in modern applications, making up between 60-80% of the codebase in nearly all software. Given their substantial role in our products, open source components are a prime candidate for security automation.

One of the challenges that organizations face when it comes to working securely with open source is that while the components may be free, it is up to their developers to check for newly discovered security vulnerabilities and updates from the project maintainers. No patch Tuesdays when it comes to open source. 

Keeping track of all the open source components in your products, and of course, their dependencies is an impossible task to handle manually. Updating BoMs, checking multiple security databases for new vulnerabilities, and even checking for new versions of the components that you are using are all tasks that are better handled automatically.

These tasks can be one of the most time-consuming a checklist for developers, looking to see which versions are out of date, or even worse, may already be vulnerable. Mend Remediate is a new tool that helps to minimize the time spent on these updates by automatically creating pull requests for vulnerable versions of your open source components. The developers only have to accept the pull request and the vulnerable open source libraries are updated correctly.

Manually keeping track of your open-source libraries is a major headache and for the most part impossible while keeping up with the demands of development. Automated open source scanning will help you keep track of all your open source libraries so you can update them when necessary with the click of a button.

5. WAF/RASP

Concerns for security do not end once your software has passed through the development stage and made it into production. Thankfully here too we have automated security tools like Web Application Firewalls (WAF) and Runtime Application Self-Protection (RASP) technologies to keep your application protected.

WAFs inspect inbound traffic, detect attacks, and block them before they reach your application. They sit on your network as a physical server and act as a reverse proxy. WAFs generally work by looking for signatures of known attacks, although more are beginning to use machine learning to better detect attacks.

RASPs operate by placing instrumentation within your code’s runtime and watching how your application works in production, learning to block attacks when they occur. Some RASPs will replay the attacks in a safe environment to understand if the attempt would have been successful. This helps you to know which vulnerabilities are serious and need to be fixed immediately.

We should remember though that WAFs and RASPs are not silver bullets. They do not replace good vulnerability management practices. That said, they can provide a solid first line of defense for your applications as they run in production.

Security automation where it makes sense

Homeland Security Advisor Rob Joyce, a veteran of the National Security Agency, recently commented to the effect that if you want long term employment in the age of automation, then learn cybersecurity since it will never be fully replaced by machines.

However, security automation is an integral part of how we as an industry are working to keep our products secure, using it as a force multiplier to get more done efficiently.

As you build your security processes within your organization, we advise you to look for opportunities that an automated solution can save your team time and nerves, saving human insights and experience for those harder to solve problems that will inevitably come up along the way.