One Article Review
| Source |  Veracode |
|---|---|
| Identifiant | 3677610 |
| Date de publication | 2021-11-18 19:25:13 (vue: 2021-11-19 01:05:33) |
| Titre | Part 2: Using Veracode From the Command Line in Cloud9 IDE |
| Texte | 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. T |
| Envoyé | Oui |
| Condensat | 2021 able about action add added adding adds again agent alias all allow allows already also analysis analytics analyze any anything app application applications approach architect are artifact artifacts aside assume authenticate available back based baseline basic basis because before begin being below better bill bit break breaking build but call called can candidate care cases certain champion chance check checked checks ci/cd clean clint cloud9 code com command compiled composition consultation consume continue copy could create creating credential cwe dash debt delete details determine developer developers development differently directory discuss docker does don done down downloaded drive each easier easy either entire environment even everything exact examples existing eye fail fairly far figure file files finally find finding findings first fit fix fixed flaw flaws flow folder folders forward four from functionality future gate generally generate get gets getting gitlab gives goal going good got governance great group gui had hadn hand handful happen happens has have help helping helps here high hopefully how ide idea image implementing importantly impossible inline inside instructions interact issues jar java javascript job join just keep learn least less let level leverage leveraging libraries library like likely likewise line list listing little look lot make makes matching means medium merge might minute minutes mitigations month more most moving much must name need net new newest next not notice now number okay onboarded once one only open optional options order out output parameter part particular party pass passed passing paste perspective pipeline plan platform plugin policy pollock potentially pre present pretty preview primary principal probably problem problems problems; process processes production project properly provide pull purposes put python quick quickly raise ran really regular release remediate remediating remove report request required rerun rest results returned review root run running same sandbox save sca scan scanner scanning scans section security see seems send series set sets setting severity should show shows simple simply software solutions some someone something sorts source start static step stop storing stripped submit submitted successful supported supportive sure system take taken talked teach team teams technical tells terminal than that them then there these things third those though three threshold through time together tracking traditional two types typically understand updates upgrade uploaded use using usually veracode verification version very video violate vulnerabilities wait want war way ways what when where which who why will work workflow working works would you your zip |
| Tags | |
| Stories | |
| Notes | |
| Move | 
|
L'article ne semble pas avoir été repris aprés sa publication.
L'article ne semble pas avoir été repris sur un précédent.