The hidden costs and risks of free puppies (and open source)

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.

The hidden costs and risks of free puppies

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.

Gaining visibility into software composition risks

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).

Selecting the right tool for your organization’s culture

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:

• Policy creation and enforcement. How flexible and customizable can the rules be, and at what level can they be set? We decided to start simple and create an environment in which our business partners wouldn’t be resistant to using a new security tool from the get-go. We knew we couldn’t come in and start breaking builds and expect there to be widespread enthusiasm about tool adoption.
• IDE support. In the world of DevOps, a tool that can be used across a multitude of IDEs to meet developer needs is key. However, we knew the largest use case for the tool would be in our build environment and that developers would need it for component research prior to
• Build infrastructure. Knowing which build environments a tool supports is key to DevOps speed. We use multiple build tools, so we started our integration with Jenkins, which has gone smoothly. We didn’t experience any problems specific to our tool that we hadn’t already run into with our static code analysis software.
• Reporting. Every company has heard this cry: make compliance easy, please! Accordingly, our new tool needed to provide out-of-the-box reports that can be shared with business partners as we move into production. Ultimately, these reports will enable decisions that prioritize fixes.
• Language support. In the world of DevOps, you can’t support too many languages. We’re primarily a Java and .NET shop, so the tool we selected met our needs, but we’ll have a few challenges ahead of us as our application engineers experiment with new languages and toolsets.
• Performance. Fast is a requirement! This is probably one of the larger concerns that we’re still getting a handle on and that we need to continue to work on.

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?

Join the BSIMM Community for more insights.