Governance
Configure fix approvals, protected paths, and account settings in one place.
Research
Making vulnerability scanning faster without weakening evidence
A staged analysis design that reserves expensive reasoning and execution for the questions that need them.
Spend effort on unresolved questions
A scanner can waste substantial time repeatedly reconstructing context that is already available. Another common waste is applying an expensive analysis to every file even when the required evidence is a simple dependency version, an import relationship, or a known configuration property. Faster scanning starts with classifying the question, not reducing every task's reasoning budget.
Define which decisions can be made by deterministic inspection and which require deeper semantic analysis. For example, discovering a route declaration is different from deciding whether its authorization policy matches the intended business rule. A staged system should preserve that distinction in its outputs.
Build reusable context with explicit identity
Repository indexing, dependency graphs, and configuration summaries can reduce repeated work when they are tied to the correct revision and environment. A cached result is useful only if its inputs still match. Changes to generated code, build flags, or transitive dependencies may invalidate assumptions beyond the file directly edited.
Store evidence with its provenance: repository revision, relevant configuration, and the analysis that produced it. Prefer small context packages that answer an identifiable question over a large unstructured summary. If a summary omits a necessary boundary condition, downstream reasoning should be able to request the source rather than guessing.
Escalate based on missing evidence
Use a lightweight pass to identify candidate paths, then spend more effort where an important question remains unresolved. Escalation might request a cross-service trace, a configuration lookup, or an isolated runtime check. It should not depend solely on how alarming a model's prose sounds.
Keep uncertain findings separate from confirmed vulnerabilities and from verified benign paths. A low-cost pass that misses a condition should not suppress a later investigation silently. Sample rejected candidates and compare them with deeper analysis to estimate which kinds of issues the fast path fails to recognize.
Measure the whole operational cost
Token usage is only one component of cost. Repository checkout, builds, dependency installation, tool calls, repeated failures, and reviewer time can dominate the workflow. Measure elapsed time and useful confirmed findings across representative projects, including large repositories and configurations that do not build cleanly in a generic environment.
Compare designs on the same task set and evidence standard. Report how many candidates require human review and how many confirmed findings survive reproduction. An inexpensive system that floods a team with weak reports may be more costly than a slower system that produces a smaller, well-supported queue.
Protect correctness while optimizing
Treat a performance change like an experimental change to a security instrument. Replay known positive and negative cases, inspect failures, and verify that evidence artifacts remain complete. Keep a route for difficult tasks to reach a more capable analysis path rather than imposing a low ceiling on every investigation.
CyberGym and the NIST AI Risk Management Framework offer useful references for task definition and measurement discipline. This article proposes engineering principles, not a claimed scanner benchmark or a guaranteed cost reduction. Teams should publish their own tested tradeoffs, including missed cases and unresolved environmental limitations, before presenting a speed improvement as a security improvement.
