Application security (AppSec) risks are well known. Forrester research found that applications are the leading attack vector in security breaches. To help reduce risk, leading organizations have begun to shift security left by adding automated AppSec testing to CI/CD.
This shift is helping! Veracode found that teams using a combination of automated security scan types including static analysis (SAST), dynamic analysis (DAST), and software composition analysis (SCA) improve fix rates for security vulnerabilities.
But if you are new to the idea of DevSecOps or are trying to figure out how to put application security testing into your CI/CD pipeline you may be feeling lost as to where to begin.
So, we have put together a quick how-to guide for introducing Application Security testing into your CI/CD lifecycle.
Start with One App
There are both cultural and technical barriers that prevent engineering teams and security teams from working together efficiently.
Often, engineers see security as “The Department of No” while security teams see engineers as reckless. These preconceived perceptions prevent the two groups from working together effectively.
When it comes to inserting application security into the CI/CD pipeline, developers face a huge knowledge gap since most security tools on the market are made for security teams and pen testers.
That is a lot of inertia to overcome if you are a developer looking to start searching for application security bugs as part of the development process.
So we recommend making this process as simple as possible by starting with a single app or service in your pipeline. There will be plenty of time to build upon the momentum and start testing other applications and services once you have a strong foundation in place.
Step 1: Secrets Detection
Once you have your app or service selected, the best first step is to implement secrets detection. Secrets detection is a tool that allows you to test for sensitive information like keys, API tokens or passwords living in your repo.
Secrets can be an easily exploitable point of weakness in otherwise secure code so it is of the utmost importance that you safely store your private information and only inject them at runtime. The amount of time and effort it takes an Engineering/Ops team to rotate secrets if they are disclosed is measured in days, not hours. Tools from Git Guardian, GitLab and Knightfall allow you to scan for unintentional exposure of secrets with every pull request.
In the event that your secrets are deployed in your repo and identified by a secrets detection tool, you can use secrets management tools like SecretHub or HashiCorp Vault to help keep your code more secure in the future. Almost every CI/CD platform has some type of secrets management system built in. Refer to your CI/CD provider for best options.
Step 2: Software Composition Analysis (SCA)
Once secrets management is in place, the next step is to begin investing in Software Composition Analysis (SCA) tools to identify vulnerabilities in your open source dependencies.
SCA tools work by looking for common vulnerabilities and exploits, or CVE. Open source data vulnerabilities are reported to and cataloged by a nonprofit called MITRE (thank goodness there is another acronym) and catalogued into the free CVE database. The strength of MITRE comes in that it standardizes the way vulnerabilities are identified.
By comparing the open source code versions that you are running against the CVE database, SCA tools help prevent you from deploying exploitable code into production.
SCA is a relatively new category of AppSec and the tools tend to be built with the end user developers in mind. Known players in the space include FOSSA, Snyk and Dependabot which all have CI/CD integrations that make it simple to manage open source code before applications go live.
The only drawback of SCA tools is that they can identify vulnerabilities that aren’t exposed in your given service or application, and therefore aren’t relevant to you. In the case that you are only using a small subset of an open source library that isn’t exposing the known vulnerabilities, the SCA scanner will still tell you an update is required because it has no visibility into your specific application. Further, SCA tools don’t test code that was written internally, only the libraries used to build the application.
Step 3: Dynamic Application Security Testing (DAST)
If you have roots in security, you are likely familiar with DAST. If you are a developer, you have probably never used a DAST tool. There’s a reason for that – these tools can be incredibly complicated and have historically been difficult to configure in an automated fashion.
DAST scanners look at the running services behind an application. These tools work by actively trying to exploit a running service and capture evidence that it has found vulnerabilities introduced by you or your team. This allows you to overcome the nuances of your specific service that SCA tools can miss.
By scanning API driven services as they would live in production, you get a much better view into which vulnerabilities are exposed in your specific environment.
DAST tools have most commonly been used by pen testers to find vulnerabilities in applications once they are live. There are a lot of problems with how DAST scanners have been used in the past. The first being that they only find vulnerabilities once they are live in production. Another being the tools typically find value in the number of findings, not helping organizations prioritize and fix the right findings. And lastly, there is a lengthy process required to fix problems once they are found.
More recently, there has been a shift to developer-friendly DAST solutions that don’t require a security background to run and operate. This allows the tools to be integrated into the CI/CD pipelines and be part of automated testing.
By modernizing the DAST scanners, AppSec tests can be run locally on a service that is in development. This gives you as a developer the power to find vulnerabilities in your applications before they are pushed into production so you can avoid security incidents.
Modern DAST tools come in both open source and proprietary flavors with scanners like OWASP ZAP and the one we are building here at StackHawk. Proprietary tools come with benefits like simplified integrations into the CI/CD pipeline, findings management, and workflow tools.
DAST v SAST
Unlike DAST, Static Analysis Security Testing (SAST) looks at the source code for your specific application. According to Gartner, SAST looks at coding and design conditions that are indicative of security vulnerabilities. Essentially these tools compare source code to a predetermined set of rules that define the parameters for vulnerabilities.
While these tools can be helpful, they do come with drawbacks for users.
The most notorious flaw in SAST tools is false positives or noise of things that are not risks. Because SAST tools only look at your code at rest as opposed to how the application or service actually runs, they are prone to noisy findings. This causes developer frustration and wasted time as developers try to figure out what truly is a vulnerability and what isn’t.
In that same vein, SAST tools are unable to prioritize findings so you know where to focus first. Since the scan is comparing your code to a set of rules, there is no way for the tool to know what is a huge, critical vulnerability and what is a lower priority finding. The outputs of SAST scans are essentially binary findings.
All of this equates to teams and developers spending too much time trying to remediate code problems when they could be working on pushing out features.
Shipping More Secure Code
Automating AppSec testing in CI/CD is an absolute necessity for shipping more secure code. By testing an application or services before they are pushed into production you get the dual benefit of secure code and a more efficient development process. Breaking builds before they go live means developers can fix bugs while they are writing code and resolve them faster.
Best of all, these modern AppSec technologies can be implemented into your CI/CD pipeline quickly. At StackHawk our average time to run your first scan on your first application is about 20 minutes. Modern SCA tools have similar lead times.
Within an hour, you can start getting true visibility into the applications you are building and start shipping secure code faster.
If you are looking for more help automating AppSec in CI/CD checkout our webinar with CircleCi, FOSSA and SecretHub.
