dependency-check is ppt from owasp to test dependecies

Editor's Notes

• #4: Why should we care? Depending on how Apache POI is used, an attacker can read arbitrary files on your server. Same goes for Adobe XMP Toolkit. If you are using Struts with dynamic method invocation an attacker can execute arbitrary code on your server… seriously an attacker can run code on your server. Hopefully, everyone is aware of CVE-2015-8103 – this highlights the exact problem we are here to discuss today. While there was a lot of debate around this vulnerability (who’s code was really at fault – Jenkins or Apache Commons-Collections); in the end it was decided that the blame was really Jenkins, but the fix was implemented in Apache Commons Collection. Issues like these are not uncommon. We see things like this crop up all the time; vulnerable dependencies like these make our applications vulnerable.
• #5: Black Duck completed an analysis of open source software titled “The State of Open Source Security in Commercial Applications”. Its an eye opening read. 95% of applications include open source 67% of applications contained one or more vulnerabilities due to the open source components The average age of a “known” vulnerability was 1,894 days… Think about that – on average 67% of the applications included in the study had a vulnerability in their application due to a known vulnerability for 1,894 days. You will see the same trend in other papers covering this topic such as those by Aspect Security and Sonatype; the issue is that when we put a 3rd party component in our application – unless we have a problem with its functionality we are likely not going to touch the component for fear of breaking something and causing us to miss a deadline. This results in using really old libraries in our applications.
• #6: For those that are not aware, OWASP publishes a list of the most critical web application risks, commonly referred to as the OWASP top 10. In 2013 OWASP updated the Top 10 to include A9 – Using components with known vulnerabilities. This was one of the pivotal events that really helped bring awareness to the problem. The top 10 project indicated that the issue is widespread; we can see this from the previously mentioned Black Duck paper and many other articles covering this problem. OWASP goes on to say that the detectability of the issue is difficult. I feel the detectability of the problem is difficult for four primary reasons. The first and foremost reason is awareness; while the security groups are trying to highlight this risk – we still have a long way to go. Second, is visibility into the problem. Our IDEs are great at letting us know when we do something stupid in code; using a deprecated function, creating an endless loop, etc. We get immediate, or at least nightly, feedback from our IDE and/or CI. Third, when A9 – using components with known vulnerabilities was added to the top 10 there was very little tooling available; most of it was nascent and very few development (or security teams) were using the tools. All due to a lack of awareness. So what is the fourth reason?
• #7: Patching programs do not cover application dependencies; in most cases patching programs are not even aware of the problem that exists with application dependencies. Many organizations do not even have a “bill of materials” for their applications (aka an inventory of what dependencies an application uses). Even if an organization’s patching program is aware of the problem, the patching teams cannot push patches to application dependencies. Patching application dependencies may require code changes and full regression testing. Unfortunately, these activities are fully in the hands of the application team and QA.
• #8: OWASP dependency-check was started in December of 2011; 5 months before the first paper I have been able to find covering this topic. Dependency-check performs Software Composition Analysis; this is the term you want to look up to find other tools in this space. As part of the software composition analysis dependency-check will report on known vulnerabilities. As such, this is an easy solution to the OWASP 2013 Top 10 A9 risk of using components with known vulnerabilities. The tool works as a maven, gradle, Jenkins, or SBT plugin, an Ant task, or as a command line tool.
• #9: Dependency-check fully supports Java and .NET dependencies. Additionally, experimental analyzers have been contributed for CocoaPods, Swift Package Manager, Python, PHP (composer), Node.js, Ruby. Node and Ruby already have other FOSS tools that help solve the problem. Over the next few months work will be done to promote CocoaPods, Swift Package Manager, and Python support to a fully supported status.
• #11: The first thing to know about how dependency-check works is understanding the data source of vulnerabilities. Dependency-check uses the National Vulnerability Database’s listing of Common Vulnerability and Exposures – known as CVEs. There are other commercially available vulnerability databases that contain more vulnerabilities then the NVD, but dependency-check being a free tool – we are using a freely available data source. Each CVE has an identifier, a description of the vulnerability, a risk rating based on the Common Vulnerability Scoring System (CVSS), and a list of the affected platforms – identified by their Common Platform Enumeration (CPE).
• #12: Obviously, in order to identify and report on known/published vulnerabilities one must correctly identify the library used.
• #13: The biggest problem with correctly identifying known vulnerable libraries is that development and security use different identifiers. Development uses the group, artifact, and version coordinates that are used in binary repos like Maven Central, Nexus, Artifactory, etc. Security uses, as previously mentioned, the Common Platform Enumeration. A CPE looks like this for Spring Framework. One of the real problems is that security may not use a single identifier for a given library. Because security is big into laying blame on the vendor – if the ownership of a library changes over time, a new CPE is created and any previously published CVEs will not be updated to use the new vendor, rather you end up with situations where you have to look for vulnerabilities in multiple places within the NVD CVE data. Lastly, there is no publicly available mapping between the GAV coordinates and CPEs. So how does dependency-check solve this problem?
• #14: Dependency-check uses evidence based identification. Any and all text data is extracted from the dependency. Information from the file name, package names, manifest, pom, etc. are gathered and put into vendor, product and version collections. The evidence is put into each of these collections with a confidence score based on where the data was obtained. We keep a local copy of the NVD CVE data, build a Lucene index of the vendor and publisher information from the CPE identifiers, and dependency-check cycles through the collection of evidence – starting with the highest confidence evidence, searching for matches within the index. This has turned out to be a fairly good way of identifying dependencies.
• #15: One of the problems with evidence based identification is false positives. However, these are really easy to deal with. The other problem is of course false negatives; if the textual evidence extracted from the dependency does not create a match to the CPE information we end up with un-reported risk. I’ve seen false negatives occur in both dependency-check and commercial tools in this space – library identification is difficult. Tools that use hashes may fail to identify a library if it was compiled from source. False negatives may also occur due to having multiple CPEs for a single library – the tool may match one, but not both and as such will not report on some known vulnerabilities. If you use dependency-check and run into either of these scenarios please let the project know via a github issue; we are trying to make the platform better.
• #16: Dealing with false positives is really simple. A suppression file can be generated to tell the tool about the false positives. This is an example of a suppression that is used for Spring Security – if the group and artifact match spring-security, then we suppress any of the listed CPEs which dependency-check flags. The HTML report generated by dependency-check assists in generating the suppression file; in most cases the false positives generated are really obvious and it only takes a few minutes to generate a suppression file for an application.
• #18: Onboarding an application is really a fairly simple task involving the steps listed here. Configure the plugin – you may need to configure a proxy as dependency-check does pull down data from the Internet, such as a local copy of the NVD CVE data. If you are in an environment that does not allow direct access to the Internet from your build servers other options are outlined in the dependency-check documentation. You then run the initial scan, review the results, determine if a suppression file needs to be generated, and plan the upgrade for any identified vulnerable components.
• #20: So what are the most common uses cases for dependency-check? Dependency-check has been used by many organizations to prove that the problem of insecure components exists within their organization; the tool is free, if you are doing nothing in this space use it. In some organizations the use of FOSS tools like this is frowned upon; company culture dictates the use of vendor supported tools. In this case, some teams have used dependency-check to show that the problem exists and the company then looks at commercial vendors in this space. When doing a POC with a vendor, use dependency-check as a benchmark – hopefully the commercial tool is doing better then the freely available tools. Lastly, I know of many organizations that are using OWASP dependency-check as the primary tool to identify known vulnerable components.
• #21: In large enterprise deployments here are a few things teams have done when adopting dependency-check. One of the pain points is that dependency-check needs to maintain a local copy of the NVD CVE data. Some organizations have opted to use a centralized database server, with a single instance of dependency-check performing the updates. The other instances are configured to skip the update phase. This makes the individual instances that are scanning applications perform faster. If you organization uses a Nexus repo internally, you can configure dependency-check to use the internal repo instead of searching Maven Central. By default, dependency-check queries Maven Central for additional evidence that is used during library identification. Organizations also tend to integrate dependency-check into their CI so that they can perform continuous security scanning for known vulnerable components. The scan results can then be pushed to OWASP dependency-track, ThreadFix, or even to SonarQube via the OWASP dependency-check sonar plugin.
• #22: The continuous scanning and reporting really fits nicely into a DevOps environment – it allows one to treat security as just another aspect of quality. The maven, gradle, and ant plugins can be configured to fail a build if a sever enough vulnerability is identified. The Jenkins plugin can be configured to put the build into warning or failed states depending on job-defined thresholds. So when a developer makes a change that adds vulnerable components, the build goes into one of these states and the team is made aware. As previously mentioned you can push the scan results to sonar so that vulnerable dependencies are treated no differently then other quality metrics.
• #23: Lastly, I wanted to touch on a governance of FOSS within an organization. Entire talks could be given on this topic as there are many more issues with using FOSS, or even other commercial libraries, then just the possibility that vulnerabilities exist within the library. In most cases, the driver for governance around FOSS comes from legal. Ensuring that the organization is willing to accept and adhere to the various licenses. At an very high level organizations need to control what dependencies are allowed. Dependencies should be cleared by architecture, legal, and security reviews. The process an organization uses to control the use of FOSS must be easy for development teams to engage and quick to get a decision.