As developers, we love using open source libraries to turbocharge our projects. There's no need to reinvent the wheel, right? Just npm install and you're off to the races! But hold your horses - those handy libraries can come with some nasty security vulnerabilities that put your whole application at risk. Never fear though, with some smart processes and tools, you can harness the power of open source without compromising security.

Where did this come from?

This sage advice comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. Specifically, control TVM-05 which focuses on managing the security risks that come with using third-party and open source libraries in your applications.

The CSA CCM provides a comprehensive set of cloud security best practices. It's kind of like the Ten Commandments for keeping your cloud assets safe.

Who should care?

Any developer or DevOps engineer building cloud applications that leverage open source libraries should sit up and pay attention. If you're responsible for choosing which libraries to use, or keeping them patched and up-to-date, this control is talking directly to you my friend.

Application security managers will also want to make sure this control is implemented properly across all development teams. Nobody wants to be the one answering uncomfortable questions about why the company is getting pwned through known vulnerabilities in old library versions.

What is the risk?

Open source libraries are an attacker's best friend. They know that developers will pull in libraries willy-nilly without always checking them for security issues. It's like trick-or-treating - except instead of candy you get RCE exploits and cryptominers.

The biggest risk is an attacker finding a vulnerability in a library you use and waltzing right into your application. From there they could steal data, install malware, deface your site, or worse.

Some recent high profile examples include the Log4Shell exploit in the ubiquitous Log4j library and a spate of malicious packages uploaded to the popular NPM registry. Attackers look for projects using vulnerable versions and have a field day.

What's the care factor?

On a scale of "meh" to "we gotta drop everything and fix this now" I'd rate this risk a solid 8. Maybe a 9 if you're dealing with sensitive data or operating in a high-threat environment.

Exploitable vulnerabilities in your application's dependencies are some of the easiest ways for attackers to compromise your systems. So I'd put this in the top tier of security issues to care about. Ignoring it is just asking for trouble.

When is it relevant?

This control applies any time your application uses open source or third party libraries. Which, let's be honest, is pretty much always these days. Even if you're not pulling them in directly, they could be dependencies of your dependencies.

I'd say it's especially critical for:

• Public-facing web applications
• Applications handling sensitive data
• Highly-regulated industries like finance and healthcare
• Companies with valuable intellectual property to protect

The only time you might get away with worrying about this less is for purely internal applications in a very low-risk environment. But even then, it's better to be safe than sorry.

What are the trade offs?

As with most security controls, implementing this means investing some extra time and effort. Specifically you'll need to:

• Keep an accurate inventory of all the third-party libraries you use (harder than it sounds!)
• Continuously monitor those libraries for new vulnerabilities
• Test new library versions before rolling them out
• Schedule regular maintenance to apply security patches and updates

That all takes work that could otherwise be spent writing new features. There's your classic security vs speed tradeoff.

You also have to be a bit careful with how aggressively you update things. Jumping to a new major version of a library can sometimes break your application if APIs have changed. So you need robust testing to make sure patches don't impact stability.

How to make it happen?

Here's a battle-tested game plan for wrangling your open source library risks:

1. Use dependency scanning tools like OWASP Dependency Check, Snyk, or GitHub's Dependabot to automatically detect vulnerabilities in your libraries. Run these frequently, either in your CI/CD pipeline or as a daily scheduled job.
2. Fail your builds if any new vulnerabilities are found above a certain severity threshold. This enforces fixing issues quickly. You can tweak the threshold based on your risk tolerance.
3. Keep all library versions fully up-to-date unless you have a really good reason not to. Tools like Renovate or Dependabot can automate a lot of this for you by submitting pull requests to bump versions.
4. If you can't update to a patched version for some libraries, document the exceptions and get management sign-off on the risk. Put extra monitoring in place for those components.
5. Use a software composition analysis (SCA) tool to get an accurate inventory of all third-party code in your applications, including indirect dependencies. FOSSA and WhiteSource are popular options.
6. Feed vulnerability data from your scanning tools into a central dashboard for visibility across all teams and projects. You should be able to quickly see what % of your apps have known vulnerabilities.
7. Include third-party security reviews in your procurement process for any critical components. Require an SBOM (software bill of materials) to know exactly what you're getting.

What are some gotchas?

You're going to need some specific permissions in your build systems to really implement this well:

• Read access to all your application source code and dependencies
• Ability to run scanning tools during builds (e.g. docker run for containers)
• Write access to fail builds that don't meet policy (e.g. status checks power on GitHub)
• Notifications to developers about new vulnerabilities (via email, Slack, Jira issues etc)

For the really fancy automated patching workflows you'll need additional write permissions, like the ability to modify codebases and submit pull requests. Tread carefully with those.

One other "gotcha" is the language-specific package managers like NPM, PyPi, Maven etc all have slightly different ways of expressing dependencies and versions. So your scanning tools need to understand the quirks of each ecosystem. Using Infrastructure-as-Code for your builds (Docker, K8s manifests, Terraform etc) helps a lot here by standardizing things.

What are the alternatives?

Honestly, there's not really any good alternatives to actively managing your third-party library risks. Sticking your head in the sand and hoping for the best is a recipe for disaster.

The only other approach I can think of is to strictly limit which third-party libraries and versions teams are allowed to use, kind of like an approved software catalog. Then you only have to stay on top of a smaller set of components. But this can really slow down development velocity and stifle innovation. Most organizations are better off allowing more flexibility and relying on good processes and tools to manage the risk.

Explore further

Here are some great resources to dive deeper on this topic:

• The OWASP Top 10 covers using components with known vulnerabilities as the #9 web app security risk
• CIS Control 2.5 gets into detail on tools and practices for inventorying and securing third party software
• This Snyk guide walks through a lot of the best practices covered here
• The OpenSSF Scorecard project defines security health metrics for open source projects to help you pick ones that are well-maintained

That should give you plenty to chew on! The key thing is to put some real thought and discipline around your open source use so you're not making life easy for attackers.

Happy (and secure) coding!

‍