The React2Shell vulnerability that surfaced in early December 2025 is only the latest in a long series of high-profile software supply-chain flaws in recent years. Like Log4Shell in 2021 or Spring4Shell in 2022, it affects a widely-used package rather than one specific application. Such weaknesses exploit trusted open-source dependencies, spread rapidly through automated build systems, and enable devastating remote code execution with little or no authentication required.

When a new global threat like this hits, chaos is often the default response – unless you already have an organized and centralized system in place and set up to prevent exposure. The system that can do this is an application security posture management (ASPM) platform that gives security and development teams the visibility, automation, and enforcement they need to respond quickly, remediate thoroughly, and prevent recurrence.

Here is a step-by-step playbook that ASPM users, and Invicti ASPM users in particular, can use to head off supply-chain security threats like React2Shell or Log4Shell and build a reliable system to future-proof their application environments.

Step-by-step response and prevention with Invicti ASPM

The moment a new vulnerability is disclosed, the first question is always: Are we affected? All too often, organizations have no immediate and accurate answer, especially when it comes to making use of vulnerable components. As these words are written, many security and engineering departments worldwide are still scrambling to answer the deceptively simple question: Are we using a vulnerable version of React anywhere in the company?

Step 1: Exposure discovery with SBOM Radar

Getting immediate and reliable answers starts with setting up and using software bills of materials (SBOMs) that list all the components used by an application. With Invicti ASPM, you can generate and maintain SBOMs for applications and services as part of security scans that are executed within the platform using the commercial or open-source tools of your choice. The SBOM Radar feature automatically cross-references your SBOM against the latest data in public vulnerability databases so you don’t have to run new scans to find new vulnerabilities.

Following an initial scan, your SBOM is automatically updated with the latest vulnerability data every 12 hours, regardless of the last time you scanned. Within minutes, you can see exactly which builds, repositories, and production environments contain bad components that you need to look at – anything from React Server Component or Next.js versions affected by React2Shell to malware-laced npm packages affected by Shai-Hulud.

Any projects that have never been scanned can be easily triggered in bulk to ensure there is nothing that falls through the cracks. The Asset Management tool is designed specifically for this purpose.

With all those results in place, you can filter by environment, business criticality, internet exposure, or data classification to know what must be fixed first.

The result is a precise, prioritized list of exposed assets that automatically updates and alerts you to new risks as they emerge. No more blind scrambling or guesswork once exploitation is already widespread – now you’re the first to know what needs fixing.

Step 2: Centralized triage and orchestrated remediation

After identifying where vulnerable components appear, the next step is organizing all related findings so you can remediate efficiently. Invicti ASPM provides a single place to aggregate and normalize results from SCA, proof-based DAST, container scanning, and other tools that may detect React2Shell-affected versions or related weaknesses. This eliminates conflicting severities, duplicate issues, and manual reconciliation.

To streamline response, the platform automatically applies your routing rules so each issue goes to the right repository or service owner with the relevant context included. For DAST findings, this often includes proof-of-exploit, which helps developers understand exactly why the issue matters. Policy-based triage rules let you escalate, suppress, or auto-close issues based on criteria like environment, business criticality, or exploit status, keeping teams focused on the work that actually reduces risk.

Because all affected components and applications now appear in a central view, you can track remediation progress without spreadsheets or cross-team check-ins. As fixes land, Invicti ASPM updates the exposure status automatically based on incoming scanner data and SBOM changes.

The result is a structured, predictable workflow for driving fixes during a supply-chain event, with a full audit trail.

Step 3: Verifying fixes and checking for signs of compromise

Once patches or dependency updates are applied, you need to confirm that the vulnerable component is gone or that the fix behaves as expected. From Invicti ASPM, you can trigger proof-based rescans for any affected applications. When available, proof provides high-confidence confirmation that the exploit path is no longer accessible, which speeds up verification and reduces rework.

SBOM Radar adds another checkpoint by continuously re-evaluating your software inventory against updated vulnerability data. If a vulnerable version reappears because of dependency drift, a stale container image, or an overlooked service, you will see it immediately without rerunning scans.

If official advisories recommend checking for indicators of compromise, ASPM helps narrow the scope: you can see exactly which applications, builds, and environments were using the affected component and when. This provides a clear starting point for any manual investigation.

Finally, the platform can generate reports showing the original finding, the fix event, and the validation result, simplifying internal review and external reporting.

This step gives you confidence that the fix worked and no attackers slipped through during the potential window of exposure. And for an n-day rather than zero-day vulnerability like React2Shell, where you can respond before working attacks emerge, you can eliminate your exposure by patching before exploitation even begins.

Step 4: Lock the door with CI/CD enforcement rules

The crucial step for long-term security is making sure known-bad components can never make it back into your applications (or get into them in the first place). This can cover vulnerable dependencies, as with React2Shell or Log4Shell, but it can also catch malware-laced packages like npm dependencies tainted by Shai-Hulud. 

You can do this by defining mandatory CI/CD policies in Invicti ASPM:

• Block builds that contain known-bad versions.
• Fail pipelines that attempt to install bad packages or their transitive dependencies.
• Optionally, use a tool like kntrl to enforce allow-list or deny-list rules in your CI/CD software, including GitHub Actions, GitLab CI, Jenkins, and Azure DevOps.

From there, the SBOM Radar continuously monitors dependency drift in production and will alert you the moment a forbidden component reappears.

Building protection right into your pipeline minimizes the risk of regressions because bad components are blocked or eliminated long before they reach production.

Practical examples of setting up supply-chain security with Invicti

Using Software Bills of Materials (SBOMs)

If you are systematically generating SBOMs and associating them with your deployed applications, your SBOM index can give you a full list of applications and versions that are in production. When a new vulnerability in a dependency like React or Next.js is announced, you can query your SBOM index to immediately identify every application that uses the affected version. This is critical for rapid patching and targeted remediation.

Uploading existing SBOMs into Invicti ASPM can also be done from the command line and automated using scripts. Here’s an example of using the command line to import an SBOM for an application called hello-world-next-js:

kdt sbom import -p hello-world-next-js -f sbom-report.json -b main

Invicti ASPM will automatically scan the uploaded SBOMs and store the SBOM list as follows:

Because Invicti ASPM stores all the uploaded SBOMs, you can then simply filter by the vulnerable package name and all the applications or projects that are using this package will appear:

Integrating SCA scanning into CI/CD pipelines

Preventing vulnerable code from ever reaching your production environment is the most efficient security measure. This is where software composition analysis (SCA) tools are indispensable.

Running an SCA scan directly in the CI/CD pipeline is the best approach to preventing vulnerable application components from making it into production releases. SCA tools automatically check open-source libraries and packages against extensive vulnerability databases to flag components such as React or Next.js versions that are vulnerable to React2Shell. You can fail the build when a high-severity vulnerability is detected, which lets you enforce security policy early to dramatically reduce risk exposure.

Invicti ASPM can run a default scan after you upload an SBOM, or you can use a specific tool (like Google’s osv-scanner) to orchestrate a scan operation for a given SBOM file. As you can see, the scan fails:

kdt scan -p hello-world-next-js -t osvscannersca -b main --params-sbom-file-scan:true -f sbom-report.json

You can also run an SCA scanner on your own and then push the results to Invicti ASPM:

When Invicti ASPM is set up as the release gatekeeper, it will block the release if a security scan fails. In this example, the release is stopped due to a failed SBOM check:

kdt release -p hello-world-next-js

Of course, the same information can be viewed in the UI. Here’s a project/application view that shows there is a vulnerable artifact that causes the CI/CD pipeline to break:

Using proof-based DAST for detection and prioritization

Static SCA focuses on code components and known vulnerabilities, but dynamic application security testing (DAST) examines the running application from an attacker’s perspective. Running a DAST scan can show you immediately exploitable endpoints that you need to prioritize. 

For many vulnerabilities, including React2Shell, Invicti’s proof-based DAST tool will not only flag a security issue but also confirm if a vulnerable dependency is actually exposed through an application endpoint. This context is invaluable for your security and development teams as it allows them to focus their remediation efforts on flaws that pose the most immediate and direct threat to users or data.

Here is an example of Invicti DAST reporting React2Shell in a vulnerable application:

By implementing these three levels of checks in Invicti ASPM, you can establish a robust and deeply integrated defense against current and future supply-chain vulnerabilities:

• SBOM for inventory
• SCA for prevention in CI/CD
• DAST for detection and prioritization

Conclusion: Why ASPM is non-negotiable in the era of supply-chain attacks

It’s no accident that threat actors are increasingly focusing on the software supply chain. By exploiting the trust in and reliance on common packages used in thousands of applications, they can massively amplify their reach and the return on their efforts. And even if your application as a whole was secure yesterday, it can still be attacked tomorrow if one of its many dependencies is compromised.

In this climate, organizations need centralized visibility into application security posture at every level, from components to frontends to exposed APIs. Without a unified ASPM platform, teams waste days or weeks correlating data from half a dozen disconnected tools, arguing over ownership, and praying they didn’t miss an affected service during manual checks.

A centralized platform like Invicti ASPM replaces chaos with order by giving you:

• One source of truth for all application risk
• Full coverage and accuracy when isolating and mitigating supply chain issues
• Proactive visibility with SBOM Radar
• Automated workflows that scale across thousands of applications
• Hard enforcement gates that turn best practices into guaranteed behavior

The SBOM Radar and CI/CD enforcement steps described in this guide to help you contain React2Shell today are the same workflow that would have countered Log4Shell and Spring4Shell in past years. Most importantly, the same steps will prepare your organization for the next inevitable supply-chain threat when (not if) it arrives – and monitoring the entire application supply chain is fast becoming an AppSec necessity.

So don’t wait for the next worm or “-Shell” to force a fire drill. Organize your defense now with Invicti ASPM and turn reactive panic into repeatable, calm confidence.

Not yet an Invicti customer? Schedule a demo today and discover how quickly you can achieve true application security posture management.