The rate at which open source vulnerabilities are being discovered continues to escalate:

Source = F5 Labs

While some of this trend may be attributable to the fact that more and more organizations have been working with (and reporting on) open source over the past few years, there’s no denying that vulnerabilities continue to plague the industry. High risk vulnerabilities in particular have increased by at least 42% across all industry sectors since 2019 according to Synopsys’ Open Source Security and Risk Analysis (OSSRA) Report 2023. 

Worse, most organizations continue to struggle with remediating vulnerabilities:

Source: slim.ai

This inability to keep up with vulnerabilities is a common problem for a number of reasons:

• False Positives – organizations that are serious about monitoring for vulnerabilities are often inundated with vulnerability alerts. In fact, an average of half of all alerts may turn out to be false positives. Alert fatigue is very real, and can result in vulnerabilities going unaddressed. 
• Opportunity Cost – time and resources spent dealing with vulnerabilities is time and resources not spent creating differentiators or closing feature gaps with your competitors. For product managers, the choice is an easy one when it’s between “maybe getting hacked” or definitely falling behind in the market. 
• Volume – there simply isn’t enough IT resources on the planet to investigate and fix every vulnerability discovered. Instead, the focus typically shifts from vulnerability remediation to risk management. 

The result is growing technical debt in the form of vulnerability backlogs that can result in everything from hampering innovation to disrupting application performance to violating uptime service levels.

While there is no silver bullet to the vulnerability problem, you can at least ensure that your projects starts with a secure codebase.

Securing Your Codebase Before You Start Coding

As I discussed in my New Year’s Resolutions blog, one of the worst bad habits we continue to indulge in is creating our projects with vulnerable codebases:

• In both 2022 and 2023, developers downloaded 2.1B open source dependencies with known vulnerabilities despite the fact that a fixed version was available. 

In some cases, that’s because an organization is stuck on an outdated dependency they can’t remove or substitute, but in most cases it’s simply because developers install their environment from manifest files (i.e, Python requirements.txt, Ruby gemfile.lock, Perl meta.json, etc) that provide no vulnerability information.

Unfortunately, when it comes to gaining that information, Slim.ai’s 3rd Annual Container Report shows 75% of organizations resort to sharing vulnerability spreadsheets among stakeholders – a process that more often than not just gets in the way. 

Instead, there are a number of best practices that can be followed to better secure your codebase before you begin writing new code, including: 

• Minimize the size of the codebase. Too many projects use a “one size fits all” bundle of dependencies that’s been approved for use. While this approach saves time and effort for security, compliance and other managers, it can also be a driver of false positives (e.g., vulnerabilities that exist in dependencies unused by the application). Instead, each project should employ a codebase that incorporates just the dependencies that are needed, which also has the benefit of shrinking the application’s attack surface.
• Use a centralized collaboration platform. Rather than sharing spreadsheets, centralizing the vulnerability information in a platform available to all stakeholders can ensure all of a project’s dependencies are compliant with licensing and regulation requirements, and also conform to maintainability and supportability criteria.

This is exactly what ActiveState provides: a centralized platform to manage and monitor each of your project’s codebases. For example, when you upload a manifest file for a new project, the ActiveState Platform will automatically:

• Resolve all dependencies and transitive dependencies
• Show the vulnerability status of the codebase as a whole
• Show the vulnerability status of the language version, as well as each dependency and  transitive dependency

To secure the codebase BEFORE you build it, simply click on the dropdown next to the vulnerable component and see if a newer, non-vulnerable version exists. ActiveState maintains an extensive, regularly updated catalog that includes older, as well as the most recent version of all components.

In this way, you can ensure that your project starts with the least number of vulnerabilities possible. 

Next week, I’ll discuss how ActiveState can help you monitor vulnerabilities over time, as well as how you can remediate them in a streamlined manner, minimizing time to remediation.

Next Steps:

Discover the ultimate solution for language version management with ActiveState’s Get Current, Stay Current. Say goodbye to dependency pains and hello to seamless coding. Click here to explore Get Current, Stay Current now!