Clint Pollock, Principal Solutions Architect at Veracode, details how to submit static pipeline scans using Veracode from the command line in the Cloud9 IDE in Part 2 of a four-part series. Check out the video below and step-by-step instructions.
This is Clint Pollock, Principal Solutions Architect, returning to Part 2 of a four-part series on using Veracode from the command line in the Cloud9 IDE. I hope you all have the opportunity to check out Part 1 of Static Policy Scans and Static Sandbox Scans. In Part 2 we will move on to the pipeline scanner.
Let’s first review the use cases for each type of static scan. Static policy scans are the only necessary scans from a governance perspective. This is something you should submit on a regular basis, at least once a month.
Sandboxing has been the traditional way of previewing new legislation to make sure developers haven’t added any new flaws. Pipeline scanners are a modern approach that supports inline scans, returns results in less than a minute, and allows very fast scanning of applications in CI/CD processes. It also helps break the build if it’s something you want to do in a merge or pull request.
And the IDE scan plugin provides a GUI that can be used to interact with static analysis results.
In general, for all teams that are onboarding going forward, they will most likely utilize static policy scans on a regular basis through their CI/CD process, and IDE based scans or pipeline scans on merge or break. pull request.
You should check the list of supported platforms for your pipeline scanner and make sure it’s right for your app. Otherwise, continue using the static policy and static sandbox detection options.
Let’s discuss how developers and teams can use Veracode features. At the developer level, you can use the IDE scanner, which is a plugin or pipeline scanner. You can submit sandbox scans, and you can also run SCA agents to check for third-party issues.
At the next level, when your code is checked into a group, you should run an SCA agent scan to check for third-party library issues. In general, pipeline scans can break the build when there are new discoveries or discoveries that violate certain thresholds. Then finally moving to a production release usually requires a verification step to re-run these checks. But most importantly, here you should do a policy scan that analyzes the entire app and reports that app for governance purposes.
Let’s take a look at the Veracode Docker image for the pipeline scanner. Here you can see that this can be run as an environment. Usually CI/CD uses this. And below here you can run this as a command or alias. It seems to work better when I’m in an IDE terminal. The pipeline scanner also uses the credentials file to authenticate to the Veracode platform.
The default parameter for sending to a file is to support a file for Java and compile it properly. You can send a JAR or WAR, but if it’s Javascript, Python.net, you’ll need to send a zip file for analysis. You can copy and paste this command again. It’s a good idea to have something in your project root folder set your current working directory to that folder. It’s easy to submit scans of files inside that folder.
After downloading the Docker image and running the alias command, you can run the help command to see the available options. Although this is optional, Veracode Analytics recommends at least providing a project name for tracking purposes. You can save the output file to a drive, create a GitLab issue, and use the reference file.
Using a baseline file can fail based on the new results you see. So, if a developer adds a new result, the build might fail or, depending on its severity, fail. It usually fails at very high or high and potentially medium. If you have a defect-free application, the goal is to have no defects of very high, high, or moderate severity. And it can also fail in CWE.
Now let’s discuss running the Veracode pipeline scan command. The dash f tells where the file is located and the dash P sets the application name for analysis. Now this works a bit differently than a static scan. Static policies for sandbox scans are submitted to the platform. There is a pre-scan to ensure that the artifacts have been uploaded properly. And the scan happens.
This can take several minutes and developers usually don’t want to wait for CI/CD to do this. That’s why pipeline scanners are perfect for that. You can scan files in exactly the same way as the Veracode static scanner and get the same results, but this is a removed version and doesn’t do anything like mitigation or flow matching. However, it helps to perform very fast scans on IDE or CI/CD systems. And this is something you can use to split or merge in a pull request if you really want to.
Now, what if a particular application has a lot of problems? Lots of security search results? Perhaps this team will find a security champion, make a Veracode helpline, understand more about how to fix these findings, and come up with a plan to address these issues with the rest of the team. .
Once this is done and the policy has passed, it’s time to start implementing the pipeline scanner in your CI/CD process and start breaking new discoveries. That way, if anything new is seen, the build will be aborted and the developer will be able to fix it. It is then processed before reaching a static policy scan or release candidate. Doing so will pass the static policy scan.
Next, let’s discuss the baseline file setup. So, pipeline scanners can help you fail new discoveries. In general, if your application already has a lot of consequences, it’s impossible for a developer to spend time fixing all of these issues. So the first goal is not to add new flaws. And if defects are added, take the time to learn about them and fix them. That will be step one.
From there, you can take a look at your technical debt and make a plan to start tackling the rest. I like to use a simple command to generate a baseline file, but you can find pipeline scan examples of all kinds of examples that create this baseline file and save it in the source code at help.veracode.com. Fix artifacts so that Veracode pipeline scans can utilize them in future scans.
The basic command is to simply add the dash JF followed by the filename. And this will create a baseline file that can be used in future scans to see if there are any new findings that will break the build.
Let’s say it returns in less than a minute and you have a baseline file. You can see a list of issues in this file, and if there is something you want to remove, you can simply delete that section. Similarly, if you want to add a defect to the baseline file, you can simply copy and paste it. Look for the 2021 update to enable the pipeline scanner to use the policy. But for now, set it to a severity threshold, CWE, or more than just helping developers avoid adding new flaws. Because this is the main goal and one of the ways to get through the policy. Knowing about some of these deficiencies makes resolving existing technical debt much easier.
Now run the pipeline scan command with dash BF to use the baseline file. Any defects in the baseline file will not be called as new or break the build. However, when new glitches appear, the process hangs or the build hangs. are you okay. And there it is. Assume that the analysis was successful and there are no new findings. It means passed.
If this is running on CI/CD, the work will continue and everything will be great. When a new problem arises, work is interrupted and someone else must take action to fix it before it can continue. This is where each development team raises their hands to become security champions, learns about and leverages these processes, and then tells the rest of the team how to use them and their existing workflows.
So far we have talked about its flaws. Static analysis helps you find first-party defects. Now what about open source and 3rd party libraries? This is a library that you normally don’t modify. All you need to do is upgrade and keep an eye on these libraries to make sure they don’t have any vulnerabilities. join me Part 3 About software configuration analysis.