Another Slack alert. “Critical vulnerability detected: CVE in package X.” You pull up the advisory…and unfortunately, it’s legit: publicly known and actively exploited. You check the version running in production, and there it is. The advisory mentions the CVE is resolved in the next major version, but you know you’re lagging; it’s going to be a big jump. While you could solve the issue by upgrading to the latest version, you know things are rarely that simple. What could have been an easy day has quickly transformed into a complex research project.

Your checklist reads as follows: 

• Read over the changelog and compare the version commits 
• Look for API changes, deprecated flags, and other updates 
• Review the codebase for functions touched by the upgrade
• Think about alternate approaches for patching the CVE 
• Track down and ask the devs if they think it will break

All this just to answer the question: If I patch this vulnerability by upgrading a package, what will break, and how much will be affected as a result?

When working with our customers to support vulnerability management, questions regarding breaking changes arise more often than not. To help solve this, we’ve introduced a new set of features that enable near-instantaneous analysis of version upgrades for Python and Perl components. 

How it Works 

To help our customers understand and assess the impact of potential breaking changes, the ActiveState platform streamlines this process into four easy steps. 

Step 1: Intelligent SBOM Ingestion – Uploaded SBOMs provide a breakdown of all included components and their dependencies within a project. These dependencies are then scanned for vulnerabilities, providing a comprehensive risk assessment. 

Step 2: Convert Your Project to a Runtime and Fix Vulnerabilities – SBOMs are then transformed into an editable set of packages pulled from our component catalog. Newer versions of a component can be selected to reduce your vulnerability count while automatically resolving all dependencies.

Step 3: Review the Impact and Breaking Changes – Before committing to the change, an automated impact report provides a detailed breakdown of changes made to your dependencies. This includes an AI-powered breaking change analysis providing a clear overview of all the breaking changes across languages and dependencies, a risk assessment, and a suggested path forward before you choose to build and deploy. 

Step 4: Remediate and create a secure build- Rebuild your updated packages from source for the required platform and deployment methods your environment needs. 

See it in action!