Response shaping

The database is built for machines with disks. A single record for CVE-2021-44228 is 2,606,571 bytes, roughly 650,000 tokens. No context window holds that, and no useful answer requires it.

Every tool reduces its response on the server, before anything reaches you.

Where the weight sits

Measured on the Log4Shell record:

affected  127 KB   200 of 676 entries, most with empty version ranges
crit       43 KB   33 cloud resource locator records
purls      28 KB   499 package URLs
everything else ~9 KB   every field a decision rests on

That is the finding that shapes the whole design: the decision-grade content is already small. The bulk is enumeration.

Three views

summary keeps every decision field verbatim (threat exposure, attack surface, SSVC, KEV with its due date, EPSS, exploitation maturity, remediation timeline, affected routines, attack paths and reachability) and replaces the three enumerations with counts, groupings and samples, each carrying a pointer to where the rest can be paged.

Nothing you would act on is dropped. What is dropped is the 476th affected package for an ecosystem you do not use.

The rule everywhere

Counts and structure survive; enumerations are sampled.

Detection rules are the one exception. vulnetix_detection_rules returns fewer whole rules instead of many truncated ones, because you cannot deploy a Snort rule from a summary of it.

How the port is held correct

The shaping layer is a TypeScript port of the filters the Pix plugin has used in production. A port is only trustworthy if it agrees with the original, and the failure mode here is silent: no crash, no error, just different references and different exploit samples for the same input, discovered months later by someone comparing outputs.

So the port is held to byte-for-byte parity by a differential test that runs both the original filters and the port over recorded fixtures and asserts they agree.

That test found two real bugs in the originals, since fixed upstream:

• One filter read a response shape the endpoint does not return, turning an 84 KB response into 83 bytes of nulls.
• Another invented four fields that do not exist while dropping the timeline, SSVC decision, severity and KEV entries, all of which drive the decision.

There is also a byte-budget assertion per tool, so an upstream schema change that reintroduces bloat fails the build instead of quietly blowing out your context window.

Where we differ on purpose

One divergence, recorded in the repository’s DIVERGENCES.md:

The original vuln filter’s own header claims it produces about 80 KB. Measured, it produces 207,646, off by 2.6×. The port matches it exactly, so the problem lies in the filter for a tool that has to deliver its answer in one shot. The default view is therefore the summary projection, and detail: "full" still returns exact parity for anyone who wants it.

Reading the reduction

Every result reports what happened:

"vulnetix/shaping": { "rawBytes": 2606569, "shapedBytes": 10613, "ratio": 0.00407 }

If a shaped response ever looks like it is missing something you need, check ratio, then ask for detail: "full" or use vdb_request to reach the endpoint unshaped.