VICE 3.5: a security model built on evidence
Deeper application discovery, stronger proof and a clearer path from an observation to a security decision.
By Luca Deguin
VICE 3.5 is available in the open source engine and powers new audits on the platform. This release expands what the engine can observe inside an application and tightens the evidence behind its findings.
Our long term direction is to make VICE a security model for web applications. By model, we mean a consistent way to connect an observed surface, a controlled test, its evidence, a confidence level and a useful next action. Version 3.5 is a concrete step toward that goal.
Follow the application that is actually there
A scanner that only tries familiar paths can miss the most relevant part of an application. VICE 3.5 builds a bounded inventory from routes, forms, parameters, JSON responses and read only GraphQL requests it observes. Those surfaces can guide later checks, including on routes outside a conventional /api directory.
Login checks now start from the form the application presents, rather than assuming its address. They use a limited set of synthetic submissions. Discovery stays within scope and within a budget, so a richer view of the application does not mean unbounded probing.
Ask for evidence before raising the alarm
A reflected string alone does not establish XSS. In 3.5, browser XSS findings require a unique execution marker in Chromium. Injection checks compare the suspicious response with controls. For a possible file exposure, the response content matters more than the status code.
The engine also recognizes Supabase publishable keys as public configuration and inspects accessible storage content before reporting an exposure. These changes share one rule: describe what a test demonstrated and keep weaker signals at the appropriate confidence level.
What the local comparison shows
We compared 3.5 with the unchanged 3.4.1 engine on 13 synthetic local scenarios. The new version found all 11 expected defects in this corpus, versus two for 3.4.1. Three targeted false positives fell to zero. Across three repetitions, median time for the complete corpus decreased by 36.2%.
These scenarios deliberately cover the defects we worked on. They do not establish a general detection rate, a global false positive rate or a speed gain on customer sites. The changed scoring policy is reported separately from improved detection. Existing reports keep their original scores; new reports identify the scoring version used.
Thirteen synthetic local scenarios. These results describe this test corpus, not detection rates on production sites.
The model keeps learning from reproducible cases
The next work is to add reproducible scenarios, improve how the engine separates confirmed results from plausible leads, and explain why each classification was made. A proposed fix should be testable. When the context allows it, a later scan should check its effect.
Automated checks still have limits. Authorization rules, business logic and the meaning of an unusual response can require human review. A useful model makes those limits visible, so builders can spend attention where the evidence calls for it.
VICE 3.5 is available now. You can inspect the open source release, run the engine yourself or review a new audit in the platform. The aim is simple: every security conclusion should be understandable, reproducible and proportionate to its evidence.