Using GitHub Actions to Automate Web App Vulnerability Scanning
Securing a web application that deals with sensitive data is a must. Vulnerabilities in web applications can be dangerous, since this is the primary way a user interacts with your environment. How do you know where to start looking?
Vulnerability Scanning
Typically, you’ll begin by running a tool locally on your computer that scans a web app for security vulnerabilities, such as OWASP ZAP or Burp Suite. These tools profile an application by “spidering” or “crawling” a site. Basically, this means following each link on a given “root” page and following their associated links, so on and so forth, until you have a map of the site or web application.
From here, a vulnerability scanner will typically passively scan the site by looking at the page source and responses generated by the web app, searching for patterns that could be indicative of a security vulnerability. Scanners can also run an active scan, where it sends the application malformed requests. These requests can attempt to exploit vulnerabilities such as SQL injection, cross-site scripting, and more (such as those listed in the OWASP Top 10). This is the same technique penetration testers use when starting assessments, later validating their findings manually.
All of this can be done in-house in a reasonably straightforward manner. However, running these scans locally on your machine takes time. Additionally, while active scans are handy, they can be very noisy. Sometimes a scanner might hit an interesting endpoint repeatedly with garbage data in an attempt to exploit a vulnerability. This in turn creates a lot of alerts and errors, which then get attention from various engineering teams. To mitigate this, active scans should always be announced in advance. It’s just common courtesy.
Automating Scans, Minus The Noise
Here at Ro, we’re utilizing GitHub Actions for automation. GitHub Actions are an awesome way to create custom automation workflows directly in a GitHub repository. OWASP ZAP now has a GitHub Action we can use to automate these scans all in GitHub! The baseline scan action will spider a given application for 1 minute, to get a profile of the app. Then it will passively scan the scoped app for any vulnerabilities or information disclosure using a provided ruleset. It will not send malformed requests, avoiding the noise of active scans.
We have a repository in our GitHub organization where the OWASP ZAP action is stored and runs. We run the baseline scan action on a routine cadence against our production web applications. Each web application scan runs in its own separate job simultaneously during the workflow. The scan is typically completed in about 2–3 minutes. Once the scan completes, an HTML report is generated and stored as an artifact for each job. If a new vulnerability is found on any web app, a job will fail and a ticket will be created automatically for us on the security team. From there we can take a look at it as soon as possible and determine what action should be taken.
Scaling this workflow for new apps in scope for testing is very easy. We can create a new job by copying the YAML configuration of an existing job and changing the URL being scanned.
That’s it.
Furthermore, this can be extended into the build and testing process using the active scan action. This way, active scans can be completed without generating production or staging environment alerts.
What Are The Benefits?
Automating these scans reduces the time spent on setting up scans to run locally. Since projects like OWASP ZAP are open source, it gives us an opportunity to craft it to our needs. As a result, ZAP is now usable as a customizable GitHub Action we can use for free. Similar paid solutions for web application scanning can cost tens of thousands of dollars per year. With a lot of these solutions, you are paying for a fancy wrapper around a core that’s essentially OWASP ZAP. We try to use the open-source tools we already have available to us to their full potential, rather than buy a pre-made solution.
A potential attacker will run scans like this to get a rough idea of an application’s security posture, so this serves as a good periodic check of your application. Disclaimer: This is not a replacement for a penetration test, nor is it a replacement for a full assessment with an active scan. These scans are meant to “knock on the front door”, so to speak.
Having an automated process for finding and reporting new web app vulnerabilities should help you focus more on finding the fixes. Combining automation with GitHub actions and OWASP ZAP can make for a fun and insightful security project, as it has here at Ro.
