The Veracode CLI: End to End Testing with Static, Container, and Dynamic Scanning

In this blog, we’re going to examine the Veracode CLI tool. Available for Windows, MacOS, and Linux, the imaginatively named binary veracode can perform a variety of functions across the SDLC.

Installing the tool is easy, just follow the steps in the documentation. Once installed, you can explore all the cli the functions yourself using:

To get started, you’ll need to configure the authentication using:

You need to input your Veracode API ID and API secret (you can generate these in the Veracode Web UI or using API calls).

Assuming we have some application code, the most obvious first step might be to perform a Static Analysis scan. To get the most accurate results, Veracode scans deployment artifacts, rather than source code (there are some really good reasons for this that are beyond the scope of this blog). So the first job is to package the code for scanning.

In our example, we’re going to use a demo Java application called verademo. It’s freely available to clone if you’s like to follow along with this example.

To package the code for scanning use the package subcommand and specify the source and output folders:

This will upload the code to Veracode, perform the scan, and then return results to the results.json file. There are also options to specify a particular profile ID to use, to specify a baseline file, and several other options. To see them all, use:

The command also outputs results to the terminal grouped by severity, along with an (unsurprising) message that the scan has failed policy.

e.g.

You can see from the output that the results contain the CWE ID, the path to the source code, and the line number with the flaw, making it easy to find.

The next obvious step might be to try and correct some of these flaws. This is where Veracode Fix comes into play. Taking the example output above we can see what solutions Fix can offer us for the problems in UserController.java.

To do this we use the veracode fix subcommand with the full path to the file and the results file:

This will output all the detected CWE’s and prompt us to select one to address. Picking issue 1 will result in Veracode Fix supplying a proposed solution to apply and displaying the fixes in a ‘diff’ style syntax. Fix will supply up to three solutions to pick from (in this example there is only 1 viable solution) and prompt for the fix to apply. The remediation is applied directly to the code, which can then be committed back to a source control system, or repackaged and rescanned for additional flaws (only one remediation should be applied to any single source file at a time)

If you’d rather code this into some kind of automated system, fix also offers an –apply option whereby you supply the source code file, the results file, and the issue ID (as –issue-id) extracted from the results.json file. Extracting the Issue ID is best done programmatically, and some sample python code to do this is available.

e.g.

To apply the first suggested fix for this issue to the file use:

Now we have resolved that issue, we can go on and resolve other issues in the file (there is also a –type directory flag we can use to resolve all possible flaws within a project).

Once this work is complete, we might want to build a container from the project to run the app. The repo includes a Dockerfile and instructions to build the app.

But is our resulting container secure? To find out we can use veracode scan to assess the container image.

This is going to give us a table output of the (many) things wrong with the container image, including CVE’s for the base image components, problems with the Dockerfile etc.

Let’s assume we fix all our issues, and now we want to run the container as a web app. To run the container on an AWS service, for example, we might want to use an AWS CloudFormation Template to automate the deployment. Not being Infrastrucure as Code experts, we did a Google search and found an example on GitHub. But will it be a secure configuration? Let’s find out.

veracode scan can also scan several IaC file formats:

This CFT seems to have some problems:

Since we’re keen just to get this app up and running so we can test it it seemed easier to just run it locally and expose it to the world using ngrok to create an ephemeral https URL for our container.

Now with a running app, it’s time to scan with Veracode DAST Essentials. While the initial DAST configuration is easiest to do via the Veracode platform UI, subsequent scans can now be done via the veracode CLI using a webhook ID that the platform creates for each target.

In our example, the webhook UUID is 7af15ee0-ad6e-4aba-b1db-2f727169c980.

Since the default is to fail on any findings, including informational it might be better to add a –fail-on-severity modifier to specify what level of issues to fail on, e.g.

The command outputs the progress of the scan (which can also be tracked within the platform and by using the veracode dynamic status command), then the results, and finally the scan status:

This is hardly surprising given the many uncorrected flaws and problems that the other scan types have reported!

Summary

In this blog we have used the Veracode CLI to: