Let’s start with some figures 12:
44% of applications contain critical vulnerabilities in open source components.
88% of Java applications have at least one vulnerability in a component.
Pretty scary! Unless you have a tracking process of the vulnerabilities in your third parties, it is very likely that you have critical security vulnerabilities in your software.
The food ain’t that bad man!
Remember this scene from the Alien movie where you can see people eating around a table and one of the guy was feeling really really bad. All the people around him didn’t undestand what was going on. And suddenly an infant form of the Alien just burst his chest! Horrible, isn’t it?
You should see hidden vulnerabilities like an Alien embryo lurking inside the chest of your application. And when it will come out, it may hurt very badly.
To avoid that, here you’ll learn:
- how to know to identify those aliens and evaluates their dangerousness.
- how to detect if they have infested your dependencies and also how to track them.
Know your ennemy…
All publicly know vulnerabilities are published on the internet as Common Vulnerabilities and Exposures also called CVE. This is basically a structured report normalized by the MITRE Corporation which has an unique ID e.g. CVE-2014-0160.
In those reports you can find:
- The description of the vulnerability which also lists the impacted components with their vulnerable versions.
- Its criticity (we will talk about that later) and impact on the infected software – how bad it can hurt you.
- A list of hyperlinks giving more details on the vulnerability, it can be the analysis of the people who found it and/or an official advisory of the owner of the component which may include a fix.
The US government indexes those CVEs into the NIST National Vulnerability Database (totally public) and exposes it through the SCAP protocol. SCAP enables security tools like OWASP Dependency-Check & OWASP Dependency-Track to detect the vulnerabilities inside your third-parties.
The MITRE corporation also maintain a dictionary of software weakness types (Common Weakness Enumeration) e.g.:
In each CVE reports, you will have a list of CWE weaknesses the vulnerability is exploiting. It is also used by SASTs to provide you in a standard way the weaknesses of your application. For each weakness, the CWE website provides you a description and some demonstrative examples.
Reporting of vulnerabilities is great but how could you know how important a vulnerability is ?
The Richter Scale
In order to evaluate the criticity of a vulnerability, we have a kind of “Richter Scale” named Common Vulnerability Scoring System. CVSS is an open industry standard provided by first.org.
It uses some criteria – like do we need to be authenticated to exploit the vulnerability or how confidential are the disclosed information – to compute a vulnerability score between 0 and 10. Where 0 means “that’s nothing” and 10 means “you got big troubles”.
A CVSS calculator is available on internet.
The tactical backpack
Now you know everything on “how to identify those aliens and evaluates their dangerousness”. Let’s see now how to build our first #DevSecOps Continuous-Security pipeline using OWASP Dependency-Check, OWASP Dependency-Track and Jenkins, in order to detect those aliens and track them down!
All of those tools are open-source software, so fork them on github!
Dependency-Check is a tool dedicated in the analysis of your dependencies. For each of them, it queries the National Vulnerability Database in order to verify if some CVEs have been reported. Dependency-Check currently supports Java and .NET dependencies analyzis and has experimental analyzers for Python, Ruby, PHP and Node.js applications. This tool is available in different forms: a command line, an Ant task, a Maven/Graddle plugin and a Jenkins plugin. To build our first Continuous-Security pipeline, we will focus here only on the Jenkins plugin which is really easy to use and to setup.
DependencyCheck reports can be published to SonarQube or Dependency-Track. We will also focus on Dependency-Track, a brand new tool dedicated – like you can imagine – to tracking the detected vulnerabilities inside your application.
Introducing Dependency-Track
Dependency-Track is a Software Composition Analysis (SCA) tool. For the short story, it brings you visibility on all the open-source components (vulnerabilities and licenses) your porfolio of application uses. We will focus here only on his vulnerabilities management system. This system integrates with multiple vulnerability databases suc as the National Vulnerability Database and the NPM Public Advisories used for the javascript-based projects. The homepage of Dependency-Track is a global Dashboard summaring the indicators and the analysis trends of the whole portfolio. What will interest us the most is the Projets page.
Here you’ll find all the analyzed applications of your portfolio. For each of them you got a sum-up of the potential vulnerabilities found. In red you have the number of the critical ones, orange for the highs and yellow for the mediums.
Let’s click on an application name to discover its related dashboard.
On this page dedicated to a single application, you got a view on all its Dependencies and also an Audit view to manage the vulnerabilities. When visiting theDependencies tab you’ll get all the libraries with their version used in your software.
For each of them, the version embedded inside your application is displayed with the number of known vulnerabilities. One cool feature here is the yellow warning symbol which appears when a newer version of the dependency is available. As you can noticed, the analyzed project in the screenshot is a maven one, Dependency-Track is querying the maven central repository to retrieve the last published version of an artefact.
The sinews of war is the Audit view.
All known vulnerabilities of the versions of your dependencies are listed here with their CVE identifier and their criticity. You have to know this is not because a known vulnerability exist on a component that you are actually vulnerable. You have to review each of them to determine if the vulnerability is exploitable in your own case.
By clicking on a vulnerability line, you are starting the review process. The description of the vulnerability is displayed and after your review you can set a status in the Analysis. You can choose between the analysis states documented here.
When you have determined a vulnerability is a false positive or doesn’t affect your software, you can suppress it by clicking the Suppress button. As a result this will no longer be taken into account in the different dashboards.
In your application, if you update a dependency to a version which is fixing a vulnerability, this vulnerability will no longer be reported by Dependency-Check and will disappear from Dependency-Track.
You can as well get more information on the vulnerability if you click on its CVE identifier.
That’s mainly the information of the CVE report. The CVSS score is displayed as the Base Score on the right.
Dependency-Track also offers an aggregated view of all the dependencies used of the whole portfolio inside the Components tab.
The main feature of this view is the ability to review a vulnerability for the entire portfolio. This is really helpful when you want to suppress false positive/not affected vulnerabilities which are reported on several applications. For that, click on the name of the dependency, go to the Vulnerabilites tab and activate the Audit Mode
But be careful of what you are doing to avoid any scaled false negative! Note that you cannot choose the projects on which the analysis status will be set, the status will be set globally for the entire portfolio. The Projectstab will show you all the projects on which this vulnerability has been found.
Dependency-Track is updating regularly its mirror of the NVD database. As a result it will automatically update the vulnerabilities report of a software if a new vulnerability has been reported. Obviously, if a new dependency or a dependency version has changed in your code base, Dependency-Track will not know about it. A new Dependency-Check analysis will be required to notify Dependency-Track.
Need some ChatOps capabilities ? Dependency-Track can notify your favorite chat tool!
Review Tips & Tricks
False Positive ? You might have seen that you can set a vulnerability as false positive, but how can it be possible? Well sometimes the CVE report is not enough precise regarding the impacted components. As a result a vulnerability regarding a database server can be reported on your software because you are using the related database driver.
Struggling with the vulnerabilities. You’ll see that sometimes this is really hard to figure out if a vulnerability is actually exploitable on your software. Instead of investing a lot in the investigation, you can simply update your dependency to the version where the vulnerability is fixed. In fact, it should be the default behavior to adopt if the new version doesn’t require to rewrite large parts of your application. The older a dependency is, higher is the risk.
*A vulnerability has been found, but you got the very last version of the impacted component. * The first thing to do, is to look for the criticity and the exploitability of the vulnerability, this is basically given by Dependency-Track on the CVE dedicated page.
You might risk waiting for the new version of the component if the vulnerability has a low score, low impact and is difficult to exploit. But if this is critical, you may be able to find a workaround in the links of the CVE report.
You should also reconsider the use of frameworks that are no longer maintained or are not responsive enough to correct known vulnerabilities.
Do your first step into the #DevSecOps!
Install this plugin in your Jenkins instance. If you don’t have any Jenkins yet, you can easily set up one using docker.
By default, Dependency-Check will download a local copy of the NVD database for every Jenkins job. This process can be long (>10 minutes) so it is recommended to configure a dedicated job to download and update a shared database. You can skip the shared database setup for testing purpose.
In Manage Jenkins > Configure System > Dependency-Check > Global Data Directory , Set the path of a shared directory by all your jobs to store the database.
Setup a dedicated NVD database update job using a free-form jenkins job , and configure it like this:
The build trigger will ensures the job will be launched nightly only once a day. It is not required to update the local NVD database more frequently. Now add a new build step Invoke Dependency-Check update only.
This build step will only update the local NVD database. You don’t need to specify the _Data directory _containing the database dump since you have previously set it globally.
Run it manually to initiate the database.
Thanks to this you have a local NVD database instance which is shared among all your jobs.
Now you can create your first analysis job! Here you just need a job which gather all the dependencies of your application, you can directly download them using the maven-dependency-plugin using mvn dependency:copy-dependencies or by unpacking your Spring Boot jar.
Even better: you don’t have to specify anything if you are using a NPM or a Maven based application. The plugin will automatically detects and scan the package.jsonor the pom.xml file.
Assuming all yours dependencies are gathered inside target/deps/lib/ , simply add the following *post-build step * to specify the path to be scanned by Dependency-Check.
Note: If you are building a SpringBoot application, you can unpack your jar and your dependencies will be bundled inside the BOOT-INF/lib/ (spring-boot-maven-plugin ≥ 1.4) or directly *lib/ * (spring-boot-maven-plugin < 1.4).
As an alternative, you can use the dependency-check-maven-plugin which requires a bit more configurations. Additional Dependency-Check integrations are available here.
At the end of the analysis, dependency-check-report.xml will be generated. You can ask the Dependency-Check plugin to publish it inside the jenkins job by adding this following Post-build Action :
As a result, you’ll get a new menu *Dependency-Check Vulnerabilities * inside your job. You will be able to see here which dependencies have known vulnerabilities.
We won’t dig much about it here, since the Jenkins view is a lite version of what Dependency-Track offers. In Jenkins you can only explore the content of the report. With Dependency-Track, you’ll be able to triage those vulnerabilities.
Dependency-Track provides a docker image:
Dependency-Track container requires 4GB of memory , make sure to configure docker accordingly (2GB by default).
docker pull owasp/dependency-track
docker volume create --name dependency-track
docker run -d -p 8080:8080 --name dependency-track -v dependency-track:/data owasp/dependency-track
This docker image allows Dependency-Track to be ran in a standalone mode using an embedded h2 database. This is pretty handy for testing purpose but you should not use it for a real continuous-security pipeline. Dependency-Track offers several database integrations for production mode.
Dependency-Track also requires a local copy of the NVD database. So during the first run, the initial download of the database may take a while.
You can now integrate Dependency-Track with Jenkins by installing this OWASP Dependency-Track Plugin.
Connect to Dependency-Track using http://your-container-ip:8080 and login with admin:admin.
To create a new project in Dependency-Track, click on the second icon on the left and then on the button + Create Project.
A Create Projectpopup should appear. As project name, enter the name of the software you want to analyze; the other fields are optional.
The Jenkins plugin requires an API Key, to generate one, go to the Administration > Access Management > Teams page (the gears icon on the left). In this page you’ll be able to manage the users of Dependency-Track with their permissions. You can also setup Teams of users with specific permissions, by default an Automation team is provided for the external tools that needs to interact with Dependency-Track.
Click on the Automation team, and copy the existing API Key (or generate a new one).
You will be able to generate API Keys for every teams but not all of them share the same permissions. For example, by default, the Automation team provides enough rights to upload a scan to Dependency-Track (SCAN_UPLOAD), which is not the case of the Portfolio Managers team. As a result, an api key of this last team won’t enable an scan upload.
Go back to Jenkins and navigate to Manage Jenkins > Configure System > Dependency-Track , fill there the URL of Dependency-Track and the API Key.
Tips: If you are running both Dependency-Track and Jenkins inside docker containers, make sure they are connected to the same docker network.
To create a network between two docker containers, create first your network:
docker network create <network-name>Then connect your containers to it
docker network connect <network-name> <container-name>
Now update your Dependency-Check job to add a post-build action in order to publish the vulnerability report to Dependency-Track.
In Dependency-Track project , select the name of the project you just created.
Inside Artifact put the path of the Dependency-Check report, usually dependency-check-report.xml and make sure the Artifact Type is set to Dependency-Check Scan Result (XML).
Run your analysis job and go back to the projects view of Dependency-Track. You should now see the result of the report in the Vulnerabilities column.
Dependency-Track also offers a NVD mirroring feature, which helps to optimize the Dependency-Check database download process.
*Congratulation!!! You just set-up your first Continuous-Security pipeline, #devSecOps FTW! * And now you can be compliant with one of the best practices of the OWASP TOP103 A9-Using Components with Known Vulnerabilities.
Special thanks to Axel Ayigbede from highergroundz who has made the illustrations!
Top comments (0)