Home » Security Bloggers Network » Using Veracode From the Command Line in Cloud9 IDE

Using Veracode From the Command Line in Cloud9 IDE

by [email protected] (hgoslin) on November 4, 2021

In part one of a four-part series, Clint Pollock, principal solutions architect at Veracode, details how to use Veracode from the command line in the Cloud9 IDE. Check out the video and step-by-step instructions below.

Hello, Clint Pollock, principal solutions architect here to explain how to use Veracode completely from a command prompt in your IDE or CI/CD system. I’m going to teach you how to submit a static policy scan and a static sandbox scan. Then, I’m going to clean up some builds using the API, submit a static pipeline scan, a software composition analysis scan, and a dynamic scan … all from the command prompt. Let’s get started!
The environment I typically work with is an Amazon Cloud9 IDE. I also leverage Docker and a cloned Java app called Vera demo Java from github.com/veracode/verademo. Maven is also useful to have installed to help build the project. Since my IDE already has Docker installed, I can pull down all the necessary images.
The first thing I do is make sure the project properly builds. (You want to check out help.veracode.com for the supported languages and frameworks and be sure you’re properly packaging your application for a Veracode scan.) Once I upload the application, Veracode’s pre-scan process lets me know if there are any compilation problems that need to be addressed. I can see if my verademo.war file was properly built, and – if it was – move on to the next step. (It’s a good idea to check your release notes from time to time. In my case, I noticed that back in November, new Docker hub images were released.)
In the Docker hub, I start with the API wrapper. (Now in Veracode, you want to submit a static policy scan. That is the only basic requirement. From there if you want to ship left, you can leverage something called the sandbox or the pipeline scanner.) I start by submitting a static policy scan. Then I do some build cleanup and download the report. From there, I have a couple of options. I can run it as an environment, which makes sense if I’m running this within a pipeline; or, if I want to run this in my IDE, I use the Aliases approach. Now I can pull down the API wrapper Docker image to my IDE environment. It’s going to set the present working directory that I’m in so that the wrapper can access files from that directory location.
I stay on my project route when I run this command. It maps the credentials file from my host operating system so the Docker image can invoke that information. First, I run the help command to see what options are available. Most of the tasks I need to accomplish will fall under these actions. To see all the options, I go to the help center type in API wrapper parameters. It gives me a list of everything the wrapper is capable of. Veracode offers the wrapper to simplify processes around calling the API, but I can certainly call the API directly. Now I go ahead and use the upload and scan option. (The “create” profile is a required parameter.)
If the application profile is already created, it will not cause an error. (This is a good default value if you’re going to let developers create application profiles on their own. If the application already exists, you can just set this to “false”. And of course, make sure the app name is correct.) From here, I add the version for the scan and the actual file that I want to upload. And if the application was not created, I add the team AWS to that profile. And that’s all there is to it for submitting a static policy scan!
Now I will walk you through how to submit a sandbox. To start, I add in “create sandbox.” I set that to “true.” (If it’s already there, nothing will happen, but if it’s not, it will get created.)
I add the sandbox name and take note of the app ID, sandbox ID, and the analysis ID or build ID. Now I check and see if the application passed or failed the policy. (A static scan can take a few minutes to complete, depending on the size of the application. A pipeline scan is designed to give you feedback in under a minute. Pipeline scanner is what you’ll use to integrate into your CI/CD process for breaking on pull requests, merges, etc., but you still need to have a static policy scan for governance purposes. So make sure at some point in your process, you are submitting a static scan of the complete application and hopefully it’s passing policy so that the people monitoring governance will be happy with your application development efforts.) In this case, I purposely leave out a parameter so that the wrapper will come back and tell me what I’m missing.
The app name itself is required, and these are the optional parameters. It wants me to add in the app names, so I do that. I get a, “did not pass.” Now, this is giving me information on the latest policy scan that is complete. I know that since it did not pass policy, I have additional actions I need to take, whether it be remediating and rescanning or mitigating flaws. First, I look at getting results for a sandbox. I added in dash sandbox ID and this pass/fail is telling me that the status of this particular sandbox could not pass. Now, l download the XML file. (You could also download a PDF.) I go to the platform to review the results. (You can use an IDE plugin to see all of the flaw data.)
There’s some information in here telling me what items are not passing policy. I filter on that and go to those particular problems to see what Veracode tells me is a flaw. (If you’ve got a lot of findings, best practice is to set up a Veracode consultation call, so you can put together a plan of how you want to remediate these findings. Generally, you’re going to start with very highs and highs first, and then you’ll work your way through the mediums. The bulk of flaws are definitely in the medium category.) I have a long line of flaws, but it’s got all the data that I need.
It shows the line number of the issue in source code and the issue ID tracks this particular issue for this application uniquely from scan to scan, this way I can tell if the flaw has been closed, if it’s been reopened, or perhaps it’s been mitigated. Each flaw has a unique flaw ID inside of each application profile. I can use the GetCallStacks to find out more information about flaws based on ID. This feature is not available in the pipeline scanner.
It is a good idea to be familiar with the Veracode UI to better understand the data that comes back within API calls. If you look at a report for a sandbox, you’ll notice that each flaw has a unique ID. There is a severity and exploitability likelihood, a negative one means that it is less likely to be exploitable. And the reason for that is because the source of the tainted data is not a web request. If that were to be flipped and the source of the tainted data was a web request, you would actually see this move up to a plus one. And that would be an indication that this should be fixed right away. Just because the data is not a web request doesn’t mean you shouldn’t try and fix an issue.
You can also get access to the CallStacks, also known as the data path, inside of the platform. That way you can understand where the data was taken and where the data was used. Sometimes these CallStacks can be 10 or 20 long, even intersecting other CallStacks. That will help you figure out how best to fix more complicated issues. If you’ve got a lot of remediation needs, I highly recommend that you set up a consultation call or series of calls to help you prioritize remediation. It’s probably best to designate a few team members to handle these issues out of the gate, and then they can educate the rest of the team on some of the problems they found and fixed and begin to enable the rest of the team with some of these tools to make sure they don’t add any new flaws. Remember that the goal is to get applications into a passing state of policy.
One of the ways to get applications into a passing state of policy is to not add new flaws. Integrate with your IDE environment to help prevent new flaws and check that your CI/CD to make sure nothing new was introduced. From there, obviously make sure you remediate or mitigate anything that falls into the very high and high categories. If your organization does call out medium severity and you have quite a few medium severities, you might want to set up a conversation with your application security and Veracode to figure out how to pass your policy.
Here’s a scenario that occasionally happens: For some reason or another, a scan did not complete and publish the results. You can go into the UI and delete the scan, but you can also do it through a command prompt. To delete that build from the command prompt, use the app ID and the build ID, which you got from the previous output. If you don’t have it, simply run GetAppList, which will give you all the applications you have permission to access. And then it will show you the app ID. Now, if it didn’t write down the build ID, you can get that by running, GetBuildList against the app ID. Also, if you run GetBuildInfo, it will give you an additional set of information, including whether or not the application has passed policy.
Assume that the application status is incomplete and that the scan is hung up and you need to get rid of it so that you can continue submitting automated scans. Run the DeleteBuild action with the app ID and the build ID. That will delete the hung build so that you can continue submitting scans in your IDE or CI/CD processes. Again, this happens very rarely, but occasionally you will have to go in and delete scans, which you can do through the admin UI or in your command line.
Ready to move on to the pipeline scanner? Check out part two of our YouTube series HERE.