Part 2: Using Veracode From the Command Line in Cloud9 IDE

In part two 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 to submit a static pipeline scan. Check out the video and step-by-step instructions below.

It’s Clint Pollock, principal solutions architect, back for part two of our four-part series on using Veracode from the command line in Cloud9 IDE. Hopefully you all had a chance to check out part one on static policy scans and static sandbox scans. For part two, I will be moving on to the pipeline scanner.  
First, let’s review the use cases for each of the types of static scans. The static policy scan is the only required scan from a governance perspective. This is something that should be submitted on a regular basis once a month, hopefully, or more.
The sandbox was the traditional way that developers would preview a new bill to make sure they hadn’t added any new flaws. The pipeline scanner is our newest approach, helping you scan inline, getting results back in less than a minute, and being able to scan applications very quickly in your CI/CD process. And it also helps you to break a build if that’s something you want to do on a merge or a pull request.
And the IDE scan plugin gives you a GUI that you can use to interact with the results for static analysis.
Generally, for any teams that are being onboarded going forward, they will be leveraging the static policy scan on a regular basis through their CI/CD process, and more than likely leverage the pipeline scan for IDE-based scanning or breaking on a merge or a pull request.
You should check the supportive platform list for the pipeline scanner and make sure it’s a good fit for your app. If not, you just continue using the static policy and static sandbox scanning options.
Let’s discuss how a developer and team might be using the Veracode functionality. At the developer level, they can use the IDE scanner, which is either a plugin or the pipeline scanner. They can submit sandbox scans and they can even run the SCA agent to check for third-party problems.
At the next level, when code is checked in as a group, you’re going to want to make sure you run the SCA agent scan to check for any third-party library problems; typically, the pipeline scan, which could break the build if there was any new findings or findings that violate a certain threshold. And then finally, as you go to your production release, you typically want to have a verification step there that will rerun these checks. But most importantly, this is where you have to do the policy scan, which will analyze the entire app and report that app for governance purposes.
Let’s take a look at the Veracode Docker image for pipeline scanner. You’ll notice here that this can be run as an environment. Typically, you’ll use this in your CI/CD. And then down below here, you can run this as a command or an alias, which seems to work out better when you’re in your IDE terminal. The pipeline scanner will also use the credential file in order to authenticate to the Veracode platform.
As a basic parameter to send as the file, the file must be supported and properly compiled for Java. You could send a JAR or WAR, but if it’s Javascript, Python.net, you’re going to have to send the zip file up for analysis. You can pretty much copy and paste this command again. It’s a good idea to be on your project root folder so it sets the present working directory to that. It makes it easy to submit scans on files inside of those folders.
Once you’ve downloaded the Docker image and ran the alias command, you can run the help command to see what options are available. This is optional, but it’s a good idea to provide at least the project name for tracking purposes in Veracode Analytics. You can save the output file to the drive, you can create GitLab issues, and you can use the baseline file.
The baseline file allows you to fail based on any new findings that show up. So if a developer adds a new finding, it will then fail to build, or you can fail it based on severity. Typically, you’re going to fail it on very high or high and potentially medium. If you’ve got an application that’s fairly clean from flaws, that would be your goal to not have any very high, high, or medium severity flaws. And you can also fail on a CWE.
Now we’re going to discuss running the Veracode pipeline scan command. Dash f tells you where the file is, and dash P is going to set the application name for analytics. Now this works a little bit differently than the static scan. The static policy in sandbox scans you submit to the platform. There’s a pre-scan to make sure that you’ve uploaded the artifact properly. And then the scan happens.
This can take a handful of minutes and usually developers don’t want to wait for that to happen in their CI/CD. That’s why the pipeline scanner is a great fit for that. It scans the file the exact same way as the Veracode static scanner and you’ll get the same results, but it is a stripped-down version and does not do things like mitigations or flow matching. But it does help you get a very quick scan either in your IDE or in your CI/CD system. And this is really what you can use to break or merge on a pull request if you would like to do that.
Now, what if a particular application has a lot of problems in it? And a lot of security findings? What you probably want to do is find a security champion on this team, who’s going to set up a Veracode consultation call, understand more about how to remediate these findings, and put together a plan to get these problems fixed with the rest of the team.
Once that’s done and you have passed the policy, that’s a great time to start implementing the pipeline scanner in your CI/CD process and begin breaking on any new findings. That way, if there’s anything new that shows up, it would break the build and developers would likely fix that. And then before it gets up to a static policy scan or your release candidate, that will be taken care of. That way the static policy scan will pass.
Next, let’s discuss setting up a baseline file. So the pipeline scanner can help you fail on new findings. Generally, if an application has a lot of findings that are there already, it’s going to be impossible for developers to set aside time to fix all those problems. So goal number one is to stop adding new flaws. And if a flaw is added, take the time to learn about that flaw and remediate it. That would be step one.

From there, you can take a look at your technical debt and figure out a plan to start remediating the rest of the issues. To generate the baseline file, you’ll want to use a simple command, but you can look at the help.veracode.com and find the pipeline scan examples for all sorts of examples for creating this baseline file and storing it in source code or your artifacts so that the Veracode pipeline scan can leverage that in future scans.
The basic command though is to simply add on a dash JF and then the file name. And this is going to generate a baseline file that you can use in future scans to determine if there are any new findings which will then break the build.
Let’s assume that it returned in less than a minute and that we have a baseline file. In this file, you can see a listing of the issues, and if there’s something you want to remove, you can simply delete that section. Likewise, if you want to add a flaw to your baseline file you can simply copy and paste it. Look for updates in 2021 to allow the pipeline scanner to be able to consume the policy. But for now, set it to a threshold of the severity, the CWE, or more than likely you would simply help developers not add new flaws because that’s the primary goal, and one of the ways you’re going to get to passing policy. Once you learn about some of these flaws, it’ll make it a lot easier to go back and remediate any of the existing technical debt.
Now you run the pipeline scan command with dash BF, which is going to consume the baseline file. Any flaws that are in the baseline file will not be called out as new or break the build. But if there are any new flaws that show up, it will break the process or break the build. Okay. And there you have it. Assume that the analysis was successful and there are no new findings. That means it passed.
If this were running in a CI/CD, the job would continue, and everything would be great. If there was a new problem, the job would break and someone would have to take action to fix that before you could continue. This is why out of the gate each development team should have a handful of developers that raise their hand to be a security champion, to go learn about these processes, leverage them, and then teach the rest of the team about how to use them and their existing workflow.
So far, we’ve talked about first-party flaws. Static analysis will help you find first-party flaws. Now what about the open-source and third-party libraries? Those are libraries that you don’t generally fix. You just need to upgrade, and you need to keep an eye on these libraries to make sure that you don’t have something that’s got vulnerabilities. Join me for part three on software composition analysis.

*** This is a Security Bloggers Network syndicated blog from Application Security Research, News, and Education Blog authored by [email protected] (cpollock). Read the original post at: https://www.veracode.com/blog/secure-development/part-2-using-veracode-command-line-cloud9-ide