When developing with open source languages the simplest and quickest solution is to grab whatever reputable packaged runtime environment you can find, where a runtime environment is defined as the language itself + popular third party packages + an interpreter (if required). That way you can avoid having to:
- Assess which third party libraries can be trusted
- Compile the libraries from scratch
- Resolve all the dependencies
In the Python world, for example, you might download Anaconda or ActiveState’s Python, ActivePython, both of which come with hundreds of pre-compiled and pre-verified popular Python libraries. Of course, for any one project you’ll probably end up using less than half of the included libraries. However, a bloated runtime is a much smaller price to pay than having to build and maintain multiple runtimes for each of your projects.
Or is it?
Security & Compliance Decay Over Time
The latest report from Synopsys, 2018 Open Source Security and Risk Analysis shows the kind of risks that can result from large runtime environments, including bloat, large attack surface and lack of license governance. For more details, see Figure 1 below.
Figure 1: Consequences of “One Size Fits All” Runtime Environments
| Bloated Runtimes in Production | Large Attack Surfaces | Lack of License Governance |
 |
 |
 |
| Black Duck audits found open source components in 96% of the applications scanned, with an average 257 components per application | 78% of the codebases examined contained at least one vulnerability, with an average 64 vulnerabilities per codebase. | 74% of audited codebases contained components with license conflicts |
The issues detailed in the figure above aren’t (or at least shouldn’t) be news to anyone. Every year the data proves there’s an ever-escalating number of open source vulnerabilities reported against an ever-growing number of third party libraries. And, as Figure 2 illustrates, the number of breaches is also growing.
Figure 2: Data Breaches by Industry
But even in the face of overwhelming evidence as illustrated in Figures 1 and 2, we continue to do the same things in our software development process that we’ve always done in the hope that things will (somehow) get better.
For example, enterprises are rife with applications created to automate business workflows. Once deployed these applications are rarely updated since they’re rarely revenue generating, and thus the business case to update them is poor. Consequently, in-house applications are prone to security decay over time. Just ask Equifax.
Even with applications that are regularly updated, security updates have to vie with new features and bug fixes for precious velocity points in any development sprint. As a result, security tasks typically get deprioritized and pushed to the next sprint, where they have to vie for velocity points all over again. In fact, a recent study shows that the median time from when a vulnerability is found until it’s fixed is over 2 years. Why? The thinking goes something like this:
I might get hacked, but I will miss out on revenue.
“Best Practices” May No Longer be in our Best Interest
We get it. After all, we’re software developers too. We’re intimately familiar with the amount of work it takes to create and maintain multiple runtime environments (it’s what we do for a living). We’ve also heard from many of our customers that whenever they want to make changes to their existing runtime environment (let alone create a new one), the lawyers need to get involved to review the open source licenses, delaying time to market.
In other words, our runtime best practices are based on the fact that it’s just too costly for all but a few of the largest enterprises to create tailored runtimes for each project, let alone runtimes tailored for:
- Development – including all those packages developers want to experiment with, but will never ship.
- Testing – including all the functional and integrated test instances (in which the runtime needs to include all the test harnesses), plus all the security and performance testing instances (in which the runtimes should feature only those packages being deployed to production).
- Production – which should contain the smallest runtime environment that will support the application in order to minimize the potential attack surface.
This kind of “tailored runtime per environment” strategy has just been far too costly to even begin to consider.
Until now.
ActiveState Platform Minimizes Runtime Management
We designed the ActiveState Platform to make it simple for anyone – not just build engineers – to be able to automatically create open source runtime environments for any project on any platform. Just:
- Pick a language1 (such as Python or Perl) and a version
- Pick a platform2 to deploy on (including Linux, Windows or Mac), and
- Choose the third party packages3 you want to include
The ActiveState Platform automatically pulls in all dependencies, resolves them, and builds your runtime environment for you while you wait. In other words, a single person, in about an hour, can create runtimes for each environment – dev, test and production – that their project will get deployed to. This same task might take a team of dedicated build engineers weeks to accomplish.
More importantly, the ActiveState Platform will identify vulnerabilities in your projects, allow you to point-and-click to update vulnerable components, and then automatically rebuild your runtime environment, reducing your workload to just verifying it against your CI/CD pipeline.Want to see how it works? Schedule a demo of the Security & Compliance functionality.
You can also sign up for a free account on the ActiveState Platform to try out some of the other features.
