Software Composition Analysis Deep Dive

Editor's Notes

• #4: This chart was blatantly copied from Mark Curphey’s keynote for Hack in Box; link to original slide deck included – please watch that, it is great to grasp the open source component space challenges
• #5: Open source party code makes up to 90% of the code in modern applications, yet there is usually very little visibility outside of development teams on what goes in
• #6: left-pad was removed because its developer received an order to change the name of one of his modules, kik; he refused, and the company reached out to npm claiming brand infringement; the developer became enraged and removed ALL of his published modules – more than 250 of them
• #7: Unless you were living under a rock in 2017, you heard about the Equifax breach; it even triggered an official response from the Apache Struts project; if you were at Nina’s talk you already header enough about this stuff
• #8: Then Equifax happened, and the reason this is relevant to our story if because Equifax was breached through a vulnerable library, Apache Struts
• #9: The vulnerability in question is CVE-2017-5638, and is quite trivial to exploit -- unfortunately
• #10: OWASP has raised the risk involved in using vulnerable components for some time now
• #12: Obtaining visibility on vulnerable components is the first step; we do this by comparing application dependency manifests, artefacts and vulnerability data sources
• #13: NOT AN EXHAUSTIVE LIST, but the stuff I have the most experience with; these tools are more focused on identifying vulnerabilities in applications via their manifest files/builds – we will talk about artefact registries later
• #14: OWASP Dependency Check scanning OWASP Juice Shop, report is output to files, not to screen, and aside from HTML is mostly meant for machine consumption; OWASP Dependency Check does not provide much advice in terms of remediation
• #15: Lots of information here which might seem counter-intuitive at first sight; let’s start with the number of dependencies identified
• #16: Dependencies in npm manifest files are stored as JSON documents inside package.json files; similar patterns exist for most dependency management solutions, such as Maven, Rubygems or pip – all manifest files are machine-parsable
• #17: Introduce the idea of transitive dependencies, mentioning that libraries have dependencies of their own
• #18: Bunyan is a logging framework with few dependencies of its own; still, it relies on 4 direct dependencies of its own, which in turn add another 4 transitive dependencies
• #19: Jsonwebtoken is a more complex library and has a larger number of direct dependencies; our dependency resolution tree is now deeper and has multiple paths to some of the nodes, like safe-buffer, which is required by 3 different transitive dependencies
• #20: Explain the discrepancy in the numbers reported by npmgraph vs dependency check by explaining that it assumes the package is published in npm and fails to find metadata related to it
• #21: Software composition analysis needs to plug to dependency/package management solution used in build
• #22: Snyk reports vulnerable dependencies AND vulnerable paths, because the same dependency might be introduced to our dependency resolution tree via multiple paths; this will affect our remediation, but we will get to that later in this presentation
• #23: These are all the languages and dependency management/build tools supported by snyk and sourceclear; because different dependency management platforms often have different backend systems and index dependencies in slightly incompatible ways, SCA must understand how to extract the relevant information – at the very least the library/package name and version – there is no such thing as “language support” by itself, it must be linked to a dependency management tool
• #24: OWASP Dependency Check is all over the place, but it mostly relies on finding files which match supported file extensions and attaches itself to that; it can also be executed via plugins to ant, Maven, Gradle and Jenkins
• #25: Semantic versioning adds yet another dimension to the problem – instead of explicitly stating static versions in manifest files, developers can use ranges or wildcards, and the dependency resolution tool will try to find a version that meets the requirements at build time
• #26: Our manifest specifies version 4.16.0 or anything else that’s backwards compatible with that; after npm install we get 4.16.4; because transitive dependencies might also be affect across versions of the direct dependency, we might end up with a completely different dependency tree depending on the version that actually got installed; npm BY DEFAULT will use semantic versioning when the developer does not provide a strict match criteria when adding a dependency
• #28: CVE feeds use CPE to match dependencies against known vulnerable versions; vendor advisories are more accurate but require massaging and collecting data from all involved parties; commit log analysis is done by Sourceclear and uses machine learning to parse commit log messages and help identify changes to open source library repositories which might indicate a security fix
• #29: CVE data is free and publicly available but often not very precise and unless the vendor has a nicely structured vulnerability reporting process, a security bug in their code might not produce a CVE
• #30: At least 3 versions have vulnerabilities which do not seem to have CVEs linked to them; the ones that do have actually reference other packages – nodejs or serve-static
• #32: We match all the dependencies in the dependency tree against the vulnerability data sources; if a match is found, we know one of the nodes in our dependency resolution tree is vulnerable and we need to fix that
• #33: Sourceclear dashboard showing all vulnerabilities for the OWASP Juice Shop project; notice that most of the reported vulnerabilities do not have CVEs associated with them and come from SourceClear proprietary’s vulnerability feeds which include vendor data and machine learning on commit log analysis; Sourceclear also has the unique feature of filtering results by direct dependencies (i.e., the ones we can remediate directly) and the libraries that have vulnerable code actually being called by the application (the “vulnerable methods” checkbox) – this means Sourceclear will do some static analysis of the code
• #35: Despite all the complexities mentioned in the previous slides, remediation is often surprisingly easy and fast – as long as the updated packages do not break functional requirements, but you should have unit and integration tests for that… right?
• #36: [email protected] is vulnerable, and it can be reached from [email protected] from 6 different paths – our ability to fix the issue depends on removing each of those 6 different injection paths; thankfully, express does a proper job of keeping itself free of vulnerable dependencies of its own, and we fix the problem by just upgrading express itself
• #37: On a real world application with more dependencies changing one node might impact tens of other nodes, and remediation might introduce breaking changes; once again, if we have automated testing we might feel comfortable upgrading and checking if the later versions break functionality
• #39: Not really a security-focused paper but provides some great insight on why developers break compatibility in their APIs in the Java ecosystem, which tends to be one of the most conservatives ecosystems; things move much faster in the dynamically typed language space (Ruby, Python, Javascript)
• #40: Never blindly accept the risk linked to a vulnerable dependency; later vulnerabilities might be found in the same library, and what might seem like an acceptable risk today might not be tomorrow, particularly as we shift towards more iterative development models and the risk profile of applications change over time; aside from snyk, none of the existing SCA tools seem to do this properly…
• #41: Snyk has the best workflow solution for this; it will by default only allow whitelist/risk acceptance for 30 days, and will start to return the same vulnerability again once that deadline is up; it will also ask for a reason
• #42: Even better, if snyk finds out there is a fix for a vulnerable dependency it scanned in the past, it will proactively email the project owner and let them know they can now fix their software
• #43: Even better than that, if your project is open source, snyk will automatically create a pull request with fixes for your vulnerable dependencies
• #45: Even after you’ve done all the work of ensure your software has no vulnerable dependencies, new ones might be found regardless of any changes you made to the application
• #46: If we rebuild the software to find new vulnerabilities, we might end up with a different set of dependencies than the ones that are actually deployed, because semantic versioning means we get affected by temporal build dependency resolution; we need to constantly compare the manifest information we have for deployed versions of the application against updated vulnerability data source data
• #47: If we are using SaaS offerings, they can do the heavy lifting for us – whenever a new vulnerability is found, they can retroactively revisit all of the scanned application data we have and tell us about it
• #49: Artefact registries can do a lot more than just filter content, and their capabilities in that space are rather limited without the support of plugins/components
• #51: Nexus Firewall can identify resources which sit in the registry and are known to be vulnerable, preventing them from being used in builds