Attack Surface Change Detection: How Vexta Tracks What's New Since Last Scan

What is attack surface change detection, and why does a single scan never fully answer it? Attack surface change detection means comparing what a target looks like now against what it looked like on a previous scan, so new assets, removed assets, and shifted endpoints show up as explicit signals instead of getting lost in a fresh, undifferentiated report. Vexta, VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, builds this into three connected mechanisms: cross-scan asset diffing, an endpoint timeline with full lifecycle tracking, and JavaScript snapshot hashing that catches code changes between passes.

How does asset diffing work between two scans?

Every subdomain Vexta discovers gets enriched into a full asset record covering its host, IPs, status code, server header, page title, CNAME, technology stack, open ports, PTR records, and ASN and organization data. When a target is scanned again, Vexta compares the new asset list against the previous one and classifies each asset as new, removed, or changed, with a diff badge shown directly in the dashboard. A new asset is a subdomain or host that did not exist in the prior scan; a removed one no longer resolves or responds; a changed one is still there but something about it, its CNAME target, its technology fingerprint, its open ports, is different from before.

For a hunter re-testing a target on a recurring basis, or a team running scheduled scans against their own infrastructure, that classification turns a full re-scan from a wall of results back into a short list of what actually moved. A newly appeared subdomain is worth a look precisely because it's new; an asset that quietly changed its technology stack might have been through a migration that introduced a fresh bug class.

How does the endpoint timeline track change at the URL level?

Below the asset level, Vexta tracks individual endpoints through a full lifecycle: new, then active, then removed, each with first-seen and last-seen timestamps. An endpoint diff computes exactly which endpoints are new and which are removed between any two scans, and that diff powers the dashboard's Timeline tab, which shows an 'added and removed since last scan' view rather than requiring a hunter to manually compare two separate endpoint lists by eye.

This matters because endpoints churn faster than infrastructure does. A host can stay exactly the same while its application adds a new API route, deprecates an old one, or briefly exposes a debug endpoint during a deployment. The endpoint timeline is built to catch that kind of change even when nothing about the surrounding subdomain or asset record looks any different.

What does JS snapshot tracking add that endpoint diffing misses?

Vexta records a SHA-256 hash and the extracted endpoint list for every JavaScript file it encounters on a target, per target, and persists that history. Comparing hashes across scans shows exactly when a given JS file changed, which matters because front-end JavaScript is often where new API calls, new parameters, or new client-side logic show up well before any of it is documented anywhere else. A hunter watching JS snapshot history over several scans can catch a new endpoint the moment it appears in a bundled script, sometimes before the endpoint itself has been linked from anywhere a passive crawler would find it.

What does this look like across a series of scheduled scans?

Picture a target scanned once a week over a couple of months. Most weeks, the asset diff and endpoint timeline come back mostly quiet, the same hosts, the same routes, nothing worth a fresh look. Then one week a new subdomain appears in the asset diff, a handful of new endpoints show up in the timeline under that host, and the JS snapshot tracker flags a changed hash on the bundle those endpoints belong to. Read together, that's a single event, a new feature shipped, not three unrelated data points, and it's exactly the kind of moment a hunter re-testing from scratch every time would have to rediscover by re-crawling the entire site again.

The same pattern works in the other direction. An endpoint that disappears from the timeline after having been active for months might mean a feature was deprecated, or it might mean a permission check moved somewhere the finding no longer applies to, either way something a hunter would want to understand rather than silently treat as gone.

How do these three signals work together in practice?

Asset diffing, the endpoint timeline, and JS snapshot tracking answer different versions of the same question at different layers: what's new at the infrastructure level, what's new at the URL level, and what's new inside the client-side code that often reveals both before anything else does. Run together across a series of scheduled scans, they turn a target from something a hunter re-tests from scratch every time into something they can watch evolve, focusing fresh attention on exactly the parts that changed rather than re-covering ground that hasn't moved since the last pass.

That is especially valuable on programs that reward being first to a newly introduced bug. A feature that ships this week and gets tested by every hunter on the program eventually is far more valuable to find the day the endpoint timeline first flags it as new, before the rest of the program has caught up.

Key takeaways