Instead, consider using the ActiveState Platform to automate these tasks for you, decreasing costs while improving Perl environment security, compliance & portability — and you’ll also gain better dev tooling as a side effect.
As an experienced Perl developer, you probably have a preferred way to manage your core language and dependencies (ie., your Perl environment) whenever you start a new project. Unfortunately, your individual preferences can result in pain downstream when the production Perl environment doesn’t exactly match the one in your development environment or even your test / CI/CD environment.
There are any number of reasons for this, but most commonly:
- Enterprise Production environments typically use a Perl environment that features a set of verified, secure Perl modules, which are licensed in compliance with corporate policy, and which may differ from a developer’s Perl environment.
- DevOps has to account for all the differences between each developer’s individual Perl environment, resulting in an environment that features a superset of all dependencies.
The trend these days is to standardize on containers, which provide for identical Perl environments across dev, test, and production by delivering a common environment every faction can use. But whether you use containers or not, a production Perl environment that contains a superset of all required modules/dependencies can lead to:
- More vulnerabilities
- More license compliance issues
- More out of date components
All of which translates into increased risk. This post examines how security and compliance risks increase with larger Perl environments, and what you can do to mitigate them.
Perl Environment Size vs Risk
Synopsys conducts thousands of open source audits each year, and delivers the anonymized results in their annual “Open source Security & Risk Analysis” report. The 2020 report is typical of what they continue to find, year after year:
This time around, the study included 1,250 commercial codebases, 30% of which included Perl. While the report does not provide a breakdown by codebase, it’s still instructive in showing that open source code bases are highly prone to vulnerabilities, licensing conflicts and staleness.
Our hypothesis is that the larger your Perl environment (i.e., the more dependencies included), the more vulnerabilities and licensing conflicts will occur, and the more difficult it will be to keep up to date.
Larger Perl Environments Lead to More Vulnerabilities
While adding more third-party dependencies to your Perl environment does not necessarily mean you’re adding more vulnerabilities, the software does decay over time. The larger your Perl environment, the larger the footprint of that decay. As a related side effect, larger Perl environments also mean an increase in the surface area for attack vectors.
Of course, if you keep your Perl environment up to date, and consistently patch or upgrade it in response to vulnerabilities, you can maintain a large Perl environment without sacrificing security. Unfortunately, as the Synopsys report points out, most organizations are unable to keep things up to date, with >80% of the codebases they examined having components 4 or more years out of date or having no development activity in the past 24 months.
There a number of reasons for codebases to go stale, but some of the most common ones are:
- The application is non-revenue generating, and therefore has a weak business case for spending time and resources to update it.
- The application has a vulnerability, but it’s located on an internal network segment not exposed to the internet, and therefore deemed at low risk of being attacked.
- The application is regularly updated, but security updates are consistently deprioritized in favor of implementing new features in an effort to catch up or surpass the competition.
Whatever the reason, the result is the same: the larger the Perl environment, the more potential for dependency vulnerabilities to crop up, which are unlikely to be resolved in a timely manner. Application security suffers.
Larger Perl Environments Lead to More Compliance Issues
Again, adding more dependencies does not necessarily result in more license issues since some organizations strictly enforce the dependencies you can add to a Perl environment by license. Unfortunately, this would seem to be a minority of organizations given the Synopsys report results, which indicated that two-thirds of codebases across 1,250 software, healthcare, and financial services organizations have license conflicts.
License conflicts occur when a codebase contains one or more modules whose licensing terms appear to be at odds with the overall license of the codebase. Adding more modules can lead to a proliferation of different licenses, each of which needs to be identified and verified compatible with the application in which it’s included. Software vendors need to be especially cautious, as they may find themselves in situations where they need to release the source code for an application.
License conflicts typically result in one of three major impacts:
- Software shipping is delayed as lawyers become involved at the end of the process to review licenses, delaying time to market.
- Software is shipped on time, and license reviews are scheduled as an end-of-year audit, exposing organizations to risk.
- Ongoing work is interrupted by emergency licensing reviews needed to meet customer, regulatory, or due diligence requirements.
Secure, Compliant Perl Environments for Less
It takes work to create and maintain a Perl environment for every project in an organization, eating up development time to deal with something that’s really just “plumbing.” Worse, many organizations require their lawyers to review the open source licenses every time a new Perl environment is created or a change is made, significantly delaying time to market. As a result, some organizations have created dedicated teams that do nothing other than build, maintain, and update Perl environments. But that’s a luxury most organizations simply can’t afford.
That’s where the ActiveState Platform comes in. When you use the ActiveState Platform to add dependencies to your Perl environment, it:
- Automatically builds all dependencies, including linked C libraries
- Automatically resolves all dependencies, including transitive and OS/architecture-specific dependencies
- Automatically packages the Perl environment for Linux and/or Windows (Mac support is also planned)
- And is supported by enterprise-grade support and maintenance for cases where an important dependency can’t be automatically managed.
As a result, no dependency or OS expertise is required – a junior developer can, in about an hour, configure and build the Perl environment for a project. This Perl environment then acts as a single source of truth for the entire organization to pull into their development environments, CI/CD containers, and production workloads, ensuring consistency and reliability.
When updates are made (either to add new/new versions of dependencies or else remove them), the Perl environment can be rebuilt and redeployed with a single command using the State Tool, a command-line interface (CLI) tool for the ActiveState Platform. If something goes wrong, you can always roll back to a previous version of your Perl environment because the ActiveState Platform retains copies of older dependencies, including transitive dependencies. You’ll never find yourself in a “can’t reproduce the build” situation again.
In this way, organizations can easily and cheaply (in terms of time and resources) create Perl environments on a per-project basis, ensuring that each Perl environment contains the minimum amount of dependencies required to run the project.
Maintainability of Perl Environments
The ActiveState Platform pulls Perl modules from standard repositories like CPAN on a regular basis, ensuring that dependency versions are always up to date. Where required, vulnerabilities will be patched on import.
Today, you need to manually update your Perl environment to pull in the latest versions of dependencies. On our roadmap is the ability to automatically update a branch of your Perl environment with the latest dependency versions/patches whenever a vulnerability is detected, ensuring you always have an up-to-date, secure Perl environment on demand. As a result, you never have to spend dev cycles to investigate, patch and rebuild your Perl environment since the ActiveState Platform will automatically take care of it for you.
License Issues with Perl Environments
Today, the ActiveState Platform offers an indemnification option that indicates which dependencies/versions of dependencies:
- Are licensed appropriately for inclusion in commercial products
- Have a track record of frequent updates
So you can make better decisions about which dependencies (or version of a dependency) to add to your Perl environment.
On our roadmap is the ability to programmatically enforce which dependencies developers are allowed to add to their Perl environment based on which licenses are permitted by corporate policy. Eliminate license conflicts.
Next Steps
You can try out the ActiveState Platform’s capabilities today by creating a free account, which will allow you to:
Install Perl 5.32 on Windows by running the following command at a CMD prompt:
powershell -Command "& $([scriptblock]::Create((New-Object Net.WebClient).DownloadString('https://platform.activestate.com/dl/cli/install.ps1'))) -activate-default ActiveState/Perl-5.32"
Install Perl 5.32 for Linux:
sh <(curl -q https://platform.activestate.com/dl/cli/install.sh) --activate-default ActiveState/Perl-5.32
You can then run “state install <modulename>”. See our CLI Quick Start Guide for more commands.
Related Blogs:
