Imagine a future world in which every software vendor can simply download open source packages from public repositories and incorporate them into their software with minimal security checks because open source security is a solved problem. 

Actually, you don’t really need much imagination to envision such a world, since this scenario is exactly how the vast majority of software vendors operate today, despite the fact that open source security is most definitely not a solved problem. Not even close:

But without the ability to envision how open source security would differ from today, the reality is that absolutely nothing will change, except:

  • Cybersecurity insurance will just keep getting more and more expensive.
  • Hiring CTOs/CISOs will get harder and harder as more of them are personally sued when their company suffers a cyberattack.
  • Cybersecurity experts will become unicorns due to burnout, as well as the dearth of >4M positions unfulfilled globally today.

Clearly, we’ve gotten complacent when it comes to using open source software–we trust it implicitly as it’s free, saves us time, and is readily available.

As Eric Brewer, VP of Infrastructure at Google said in a recent OSSF podcast “Lots of times people would include packages directly off the Internet like you don’t even know what’s in there. My friend Kelsey Hightower often said it’s kind of like picking up a USB drive off the street, sticking it in your laptop. It’s like everyone knows not to do that, but we don’t know not to take random packages off the Internet, even though it’s a very apt analogy.”

Aka, using open source software without truly thinking about how to secure it is detrimental to both your company and your customers.

So you’re probably thinking, stop the jibber-jabbering and help me figure out what could be better than picking up a free USB drive off the street? Well lots of things, but when it comes to managing open source safely let’s start with:

  1. Secure by design – making sure the open source you do use is safe before it enters your software development lifecycle (SDLC). 
  2. Improving observability – mitigating the “more dependencies = more problems” predicament.
  3. Getting current and staying current – continually updating language and dependency versions to eliminate vulnerabilities.

Secure By Design: Building From Source

Secure by design encourages a security-first approach to creating software, and emphasizes proactive measures over reactive responses. One of the most proactive measures you can take is ensuring that you’re using open source packages that are free from malicious code and CVEs BEFORE you start coding.

In the latest Jfrog Software Supply Chain State of the Union report this becomes increasingly imperative as companies:

  • Shift the security burden left: Security scans are performed during coding (59%), at build time (59%) and finally at runtime (57%). 
  • Stitch together point solutions: Nearly half (47%) of organizations use between 4 and 9 application security solutions, however 33% use 10 or more!

So although it feels easier today to deal with security issues further up the SDLC, it actually creates more work for your Engineering teams. It’s also more costly, requiring a minimum of 4 tools to achieve a level of security you are happy with.

A more direct approach to consider is dealing with the open source code packages before they even enter your SDLC, effectively shifting the burden down onto a third party, rather than left onto your overworked developers.
ActiveState Platform

A platform like ActiveState can help by enabling safe acquisition, secure builds, and comprehensive tracking of open source elements across all stages of the SDLC, from inception to production. But we stand on the shoulders of the community, whose source code is our starting point.  Specifically, ActiveState takes the following steps:

  1. We fork the source code for each package, as well as all of its dependencies from the original source.
  2. We store the source code in our own internal, secure AWS S3 environment where it is quarantined until it passes automated security scans and manual scrutiny. 
  3. We build that source code using a SLSA Build Level 4 hardened build service in a reproducible manner.
  4. Finally, the result is packaged for deployment on Windows, Mac and Linux, ready to deploy to your team(s) from a central source of truth that you manage. 

With such a highly secure build process, the odds of incorporating malicious code in your SDLC is infinitely smaller compared to when downloading open source from public repositories. Software attestations are also provided to ensure you have peace of mind about its origins, and can focus on coding rather than finding the fox you may have just let into the henhouse. 

Enterprise-Wide Dependency Observability

Clarity creates calm. This is a little harder to achieve when each of your applications has an average of 526 dependencies and you’re working with multiple repositories and a big team that may span time zones and even countries. 

Suddenly, your 526 dependencies seem more like 526 potential problems that need to be identified before they derail your release date. To take a more proactive approach in managing dependencies, organizations should consider a solution that can help them visualize in-use open source, where it’s deployed and where it came from. This would include:

  • Enriching open source data
    • A curated collection of open source dependencies, build, licensing and CVE data
    • A complete dependency graph and build plan
    • Auditable changelogs so you can always revert back to your previous environment.
  • Visibility into security impacts
    • Package scoring, datedness, vulnerability information and licensing data
    • A usage report of what’s being used, where, by whom and how far behind ideal configuration
    • An impact report that shows the outcome of a change, both in terms of dependencies and CVEs.

When all of this is presented via an up-to-date, interactive dashboard, you can gain comprehensive insight into the risks posed by all your dependencies in every project, enterprise-wise. And you can certainly resolve them a lot quicker than what you’re probably doing, such as passing around spreadsheets.

Want to learn more? Read our Datasheet: Enterprise-Wide Vulnerability Dashboard 

Getting Current and Staying Current

You’re not likely secure if you’re using outdated code. And you’re not alone. A recent report shared that “91% of codebases assessed for risk contained components that were 10 versions or more behind the most current version of the component.”

Using older open source code not only increases your risk of an attack but also increases the amount of time you’ll end up spending on tech debt. And ignoring updates means that eventually the codebase will become end-of-life (EOL), forcing an upgrade process that can be far more complex and resource intensive than applying ongoing updates.

Cost of Upgrading

As figure 3 shows, the further the upgrade target is from the original codebase, the more expensive the upgrade will be. This is primarily due to the fact that while a codebase’s components change minimally between patch versions for any open source language, they will typically introduce breaking changes between minor versions of the language (to say nothing of differences between major versions), meaning that a greater portion of application code will need to be rewritten/refactored. 

But it doesn’t need to be like this. By leveraging the automation offered by ActiveState, organizations can minimize the time and resources required to perform upgrades/updates, and thus minimize opportunity cost.

Want to learn more? Download our whitepaper: Tech Debt Best Practices 

Next Steps

If you’ve read this far, you really care about taking action to secure the open source you use. It requires you to secure the code before it comes into your SDLC, add an additional layer of visibility across your projects and dependencies, and finally make continuous updates to your codebases to minimize vulnerabilities and tech debt. 

Talk to our product team to learn more about how ActiveState can help you achieve this at scale, using a single intuitive platform.