Meet Dave, the new CTO at WidgetCo. Dave is having a very bad start to his day, because his company does not do Software Composition Analysis (SCA).
Yesterday, Dave asked one of his developers to investigate WidgetCo’s exposure to the very serious “log4shell” vulnerability, and he just came back this morning with this “good news”:
Developer: “Looks like we dodged a bullet! The log4shell vulnerability affects all versions of log4j after 2.0, but we checked and we’re using log4j version 1.2 in our web application. Woohoo! We don’t have to do any emergency patching or update our code!”
Log4shell was one of the scariest vulnerabilities of 2021 , so why is Dave not happy at all to get back this report saying WidgetCo isn’t susceptible to it?
Because Dave knows the last update to log4j 1.2 was ten years ago !
For open source software, that’s absolutely ancient!
Dave has been around enough to know that any unmaintained, end-of-life software will very likely have countless other unreported problems lurking within it, possibly even more serious than the vulnerability they just avoided. WidgetCo may have gotten lucky with log4shell, but it sure seems like no one is keeping an eye on the much larger problem of managing all 3rd party software dependencies throughout their application. Dave has his work cut out for him getting this under control!
Old code is everywhere.
Dave and WidgetCo may be fictional, but believe it or not, the “log4j 1.2” story itself comes from multiple real-world examples we’ve witnessed at Fractional CISO. It may seem like common sense that application development companies should do a better job of managing the open source software they use, so why is this so often ignored?
Imagine this – let’s say you heard a news report that eggs from a local store may be contaminated with salmonella, and any cartons bought in the last week should be thrown out. So you check around, and in your second fridge in the garage, way in the back, you find a long-forgotten expired carton of eggs you bought 18 months ago.
Most people would throw the eggs out, and maybe make a resolution to clean out the fridge more often. You probably wouldn’t think “Yay! I don’t have to worry about the salmonella recall! Anyone want an omelet?” So, why do that with software?
SaaS companies who develop their own web applications may train their staff on secure coding practices, conduct threat modeling exercises, and test the code they write for vulnerabilities. But if you count up all the lines of code that are actually included in their application, it’s almost guaranteed that the majority of it came from open source libraries that were borrowed and included with their builds. This is just the way modern applications are built – no need to reinvent the wheel of course – but by some estimates that means that 75% of the code in the average application came from outside of the company that created it.
So why is it then that so many companies just choose to ignore the threat that old, out of date software dependencies bring to their application? Would you ignore 75% of your doors and windows if you’re trying to secure a building? Of course not!
The reason for this is simply that open source dependencies can be very hard to manage. Most company’s applications have layers upon layers of nested open source library dependencies. If you use one library, it may carry it’s own dependency on another library, and that one may require another, and on and on. If one of those nested libraries has a new version available to fix a known vulnerability, that may break functionality with anything else upstream that depends on it. Perhaps unsurprisingly then, many software companies simply don’t have an effective way to manage vulnerabilities in the “expired” open source software they’ve built their application around. Sometimes it may feel like the only option is to just ignore the vulnerabilities – hey, our app is working just fine the way it is, you may think – but that can be very shortsighted and lead to software decay. There must be a better way!
Software Composition Analysis
Software Composition Analysis (SCA) is an application security testing technique that aims to identify, prioritize, and remediate vulnerabilities with your open source software dependencies. Think of it as traditional network/OS vulnerability scanning and patch management, but for software. While it’s less well known than other techniques like Static or Dynamic Application Security Testing (SAST/DAST), it’s growing rapidly in popularity and is something nearly every software company should seriously consider incorporating into their Secure SDLC workflows.
Many developers and security engineers are first introduced to Software Composition Analysis through GitHub’s Dependabot feature. This tool can scan your code to find all open source library versions you’ve referenced, and then look up to see if there are known vulnerabilities in that code you should be made aware of. Optionally, you can have it automatically update your code to reference newer open source software versions, but most developers prefer to carefully check that upgrades don’t break anything. Dependabot can be a tremendous time saver compared to manual analysis and if used properly can lead to a much more secure application.
Dependabot has its limitations though. It does the basic identification well and can create an inventory or “bill of materials” (BoM) of your open source software, but as a vulnerability scanner it doesn’t help a whole lot with issue prioritization. It will make a nice list of everything you need to address, but if that list is a thousand items long, where do you start?
This is where the burgeoning market of other 3rd party Software Composition Analysis tools come in, and many of these products focus on helping companies with better issue prioritization. For example, some products can examine not just your open source library dependencies, but also the specific features in those libraries your code is using. This way, if there’s a known vulnerability in a library, but you don’t use the part of it that has the problem, you can deprioritize that update and focus on more immediate threats. Nifty!
Most products can also enforce security policies wherever they’re needed by directly integrating into your software build workflow. For example, you may decide to configure a policy to block production releases that use open source software with a CVSS vulnerability score greater than 6.0, or to alert the QA team if they’re about to test a build that’s using software with known exploits. These products also can assist with the surprisingly complex task of managing open source licensing requirements. If your legal team thinks it’s too onerous to use any open source software that carries a more restrictive “copyleft” license (AGPL, GPL, etc.), then just set up a policy to prevent it from ever being introduced into your application – problem solved! This takes the burden off your development team to micromanage the dizzying array of open source license models .
Gartner’s Peer Insights page for SCA shows several vendors clawing for market share, but considering the relatively low number of reviews it appears that most DevSecOps teams haven’t yet discovered the value of these tools. Fractional CISO doesn’t currently recommend any particular one, but WhiteSource, Black Duck, Snyk, and Veracode are some of the more well known SCA vendors that either have some market buzz or our clients are already evaluating. It is best to carefully consider your company’s own workflow requirements and security objectives before comparing vendors – the product a friend recommends because their company likes it may not be the best product for your company!
Finding the right tool might be a challenge, but at least SCA uses well known concepts – know what you have, understand your risks, and prioritize your response – so it shouldn’t be too hard for most organizations to adopt this basic security strategy to their management of open source software.
Back at WidgetCo, Dave knows that if they continue to ignore vulnerabilities in open source software it’s going to eventually lead to a security incident. But, he’s also realistic and knows that it’s just too big of a task to expect his teams to ever manage manually.
If you’re in the same situation as Dave, then you really should prioritize finding an SCA tool that works for your business as soon as you can. It’s not going to prevent zero day exploits like log4shell, but it will at least give you a fighting chance at finding and removing vulnerabilities that are hiding in plain sight in your open source software. You can be certain that the bad guys aren’t going to hesitate to look for vulnerabilities in the open source software you use, so neither should you!
Want to get great cybersecurity content delivered to your inbox? C lick here to sign up for our monthly newsletter, Tales from the Click.
