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

In part three 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 software composition analysis (SCA) scan. Check out the video and step-by-step instructions below.

It’s Clint Pollock, principal solutions architect, back again for part three of our four-part series on using Veracode from the command line in Cloud9 IDE. If you haven’t done so already, please check out part one on static policy scans and static sandbox scans and part two on the pipeline scanner.  
For part three, we will dive into open source and third-party libraries. Those are libraries that you don’t generally fix. You just need to upgrade and keep an eye on these libraries to make sure that they don’t have vulnerabilities. Now, inside of the Veracode application profile, there are results on static analysis and software composition analysis. In addition, if you had manual tests or dynamic scanning, you’ll see those results there as well.
When you run a static scan, you get a report for the first-party problem. And inside of software composition analysis, you get alerted to to any libraries that have vulnerabilities. You’ll also be alerted to newer versions that you can upgrade to so that you don’t have those vulnerabilities within your application. This happens automatically.
And by default, there’s also an SCA agent which gives additional information during your bill job or within your IDE about the third-party library and open source components that are out of date or have vulnerabilities.
To set up an agent on your desktop or within your build server, you want to go to software composition analysis, and then agent-based scan. If you don’t have these tabs, talk to the application security team. This section of our portal is dedicated to open source findings and problems within. You’ll notice you can set up a workspace and then inside of that workspace, you can deploy agents. Agents can be installed on your desktop or in your CI/CD system so that you can get some additional functionality around third-party and open source library issues in your application.
Go to agents, create a new agent, and choose your platform. You’ll see there are lots of instructions for integrating with other build systems. There is an API token that you have to generate. And then basically just run the command. For installing my cloud nine IDE, choose that option. Once activated, go into the project folder and type in SRC:CLR scan.
Now you see all this information that comes out into the actual terminal. There’s a lot of problems here, and this application will require some real work to resolve all these issues. That’s why you typically start with the very high and high severity items, but in the case of the SCA agent, you are getting one additional data point that is critical here. It’s called vulnerable methods. Now the SCA agent is able to detect vulnerable methods, but just by uploading a static scan where you actually get the additional SCA results, it does not give us vulnerable methods. A vulnerable method is where you’re actually calling the set of code, where the vulnerability exists in a given library. Therefore this would be considered something extremely high risk, and you should remediate any vulnerable methods as soon as possible by upgrading the library to a version that does not have the problem or replacing it with something else.
Assume this particular app has a bunch of problems known as CVEs. This is data coming from the NIST database. Generally, if an open source library gets a problem, there’ll be a NIST entry. The issue though is that this can be months after the initial problem has been discovered. So the second area that Veracode offers great value is the premium database. Use machine learning to go out and scour the GitHubs of the world to look at release notes for open source software. If there’s any sort of security issues, our system will route that to humans to then be entered into our database. Therefore, you get a big advantage with any type of zero-day vulnerabilities that may have been months delayed in getting into the NIST database.
You can also get license information. And here inside of the SCA.analysiscenter.veracode.com, you’ll see there’s some additional information like Veracode Vera demo link. You can see all sorts of additional information about the open source software status in this particular application.
At this time, the SCA agent can be run in the CI/CD workflow, but it will not break the build based on any sort of thresholds. So it’s a good idea to simply continue running this on a regular basis so that you can detect any sort of problems. You want to minimize this list to have as few issues as possible. And then start to bring in the requirement to upgrade these open source and third-party libraries as part of your project planning, because it’s critical to keep these things up to date in the event that there is some sort of issue, and if you’re a few versions behind it may take a lot of work to get that problem resolved. So make it a goal to stay ahead of this, keep these libraries updated. It will make things a lot easier for you in the event that some sort of zero-day comes out.
In the case of the SCA agent, it depends on the package manager to properly identify the libraries at use and determine if those libraries have any vulnerabilities. Static analysis depends on the language, the version, and any frameworks used. For part four, we will take a look at the Veracode API signing, Docker image.
 

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