SCA tools are an essential part of your AppSec toolkit, because free and open source software—just like free puppies—comes with hidden costs and risks.
This entry in our BSIMM Monthly Insights series was contributed by guest author Stacy Monroe with Principal.
I was recently reminded of a quote that went something like, “Think of open source like you would a ‘free puppy’: both come with a lot of responsibility.” Everyone likes puppies; they’re cute, cuddly, and soft … sign us up! But there’s definitely a “catch” to getting a free puppy, and it’s the ongoing responsibility and cost of owning a pet. The same is true of open source software: it might seem like a great deal at first glance because someone else has already figured out the functionality in the code you’re using, but the ongoing cost of maintaining it is definitely a “catch”!
Open source is an increasingly popular option for software design’s various development stages. In fact, some statistics indicate that it’s not unusual for modern applications to consist of more than 50% open source components. This makes sense; open source has its advantages, such as flexibility, cost-effectiveness, and shared maintenance costs. However, with these pluses come some pretty big minuses, too, such as the more than 7,000 new vulnerabilities discovered in open source components from 2014 to 2016. Just like our free puppy needs training and baths and food and walks (or on the extreme end, emergency vet visits, expensive surgery, and intensive rehab), open source needs to be monitored for vulnerabilities from updates and researched for licensing gotchas. Turns out our free puppy isn’t all that free after all.
As security practitioners, we have to worry just a little bit more about open source and the risks involved in taking it on. If I’m developing something, and over half the application consists of code authored by other parties—AND I’m a proponent of secure software—I probably should worry. How am I to know if what I’m using is safe “enough”? On top of that, I can’t slow down; our DevOps, speed-to-market culture requires me to be a productive application developer!
This is where software composition analysis (SCA) tools can help. SCA tools analyze open source and third-party software components for potential license issues and known security vulnerabilities. Organizations often scale this type of analysis by integrating SCA tools as part of automated build pipelines and processes to find and fix issues before production releases (see SR3.1: Control open source risk). SCA tools can also help organizations get a better handle on inventorying the software component versions deployed in their production environments (see SE3.6: Enhance application inventory with operations bill of materials).
I work for a large financial services company with four business areas, all of which are in different spots in terms of DevOps culture. The company recently adopted an SCA tool, and to assist with its adoption, our team felt that it was important to involve our business partners in the tool selection process. As we compared SCA tools, our extended group had to consider the following:
We’re still “training our puppy,” so to speak, meaning we aren’t yet in production with our SCA tool, but we look forward to working with our application developers as we get up and running in their build chains. Have you explored a similar avenue? How has your company adopted SCA tooling, and how has the tooling enabled DevOps?