This release is about getting more out of every scan. Findings got better: gestalt now spells out the end-to-end attack path in each finding it confirms, severities are more honest, and test scaffolding no longer generates noise, so scans you run today report sharper results than earlier ones could, even on code they already looked at. Results are ordered by real impact, projects can scan several repositories at once on a rebuilt queue, and working with private repositories no longer asks for any scary GitHub permissions.
Higher-signal findings
Several improvements landed in what scans report and how findings are written up:
- gestalt findings now tell the whole attack story. Our cross-file analysis flow writes the full exploit path into each finding it confirms: the untrusted entry point, the checks the input slips past, and what an attacker reaches at the end. Findings read as an end-to-end attack rather than an isolated observation, and the later proof-of-concept work builds on that traced path instead of starting over.
- Severities you can trust. Finding titles now lead with the security consequence, what breaks or what an attacker gains, rather than the mechanism. And an issue whose impact only holds under a hypothetical the codebase does not exhibit can no longer be rated above medium. High means high.
- No more noise from scaffolding. Tests, mocks, stubs, and example code are no longer treated as audit targets. Scans still read them to understand intended behavior, but a weakness in a mock is expected, not a finding, so reports stay focused on code that actually ships.
- Every finder starts with the full picture. Analysis steps now always run with the project-wide overview and threat model in hand before hunting for bugs, instead of occasionally starting cold.
Findings ordered by impact
Scan results are now ordered by how much each finding actually matters, not just by severity label. During triage, findings are weighed against each other and the most impactful ones surface at the top of the scan and its public report. Triage also spends its verification effort on the highest-impact findings first, so the findings most worth your attention are confirmed earliest.
Parallel scans across your repositories
Projects are no longer limited to one running scan at a time. Scans on different repositories in the same project can now run in parallel, while scans of the same repository still run one after the other so results stay consistent. Launch scans across your whole project and let them work through the queue on their own.
A smarter scan queue
Behind the scenes, scan scheduling has been rebuilt:
- Queued scans start faster: a finished scan hands its slot to the next one within seconds.
- Scheduling is fair across projects, so one busy project cannot crowd out everyone else.
- Capacity now scales with demand, so busy periods clear the queue quicker.
- Queued scans now clearly show as waiting in the queue instead of looking like they are in progress.
Private repositories without scary permissions
Working with private repositories no longer involves granting zkao broad access to your GitHub account. Read access to the code comes from the zkao GitHub App, which the repository owner installs and scopes to exactly the repositories they choose. Connecting your own GitHub account is now a plain sign-in that requests no repository permissions at all: it only proves who you are.
That identity is what authorizes scans. Before a private repository is added or scanned, zkao checks that a current member of your project actually has access to it on GitHub, so nobody can scan a private repository that no one on the team can see. And when that check cannot pass, the app now tells you exactly what is missing and how to fix it, instead of a generic error.
README badges that prove themselves
The "zkao | monitored" README badge grew up. Badges now come in three flavors, selectable from the project dashboard: the classic monitored badge, one showing the month of your last completed scan, and one showing how many scans the project has completed.
More importantly, badges are now verifiable. Every badge links to a public verification page on zkao.io that names the project behind it and lists exactly which repositories it covers, along with their scan history. A badge copied into a repository we do not scan no longer borrows your credibility: you can scope a badge to a specific repository, and a scoped badge only lights up for repositories the project actually covers, while the verification page clearly flags a repository the badge was not issued for.
A clearer, friendlier dashboard
Your dashboard now opens with a single "Plans & credits" overview of every project you belong to: your credit balance, when credits renew, how many carry over versus expire at renewal, and a heads-up with a one-click fix when a plan is about to end.
Scan activity lives in one place. Running and recent scans sit together, each showing its findings count and how long ago it ran, and you can start a new scan from the same card without leaving the page. The dashboard also keeps you current on zkao itself, with recent releases and their highlights alongside the latest posts from the zkSecurity blog.
The whole experience got a friendlier look, with a hand-drawn assistant that turns up across the dashboard and while a scan is running.
Other Changes
- When our support team replies to one of your tickets, the reply now also lands in your email inbox, not just in the app.
- The plan card on your project dashboard now shows when your monthly credits renew.
- Completed scans in the dashboard activity feed now show their confirmed findings and the credits they used, including any credits refunded.
- Any project member can now leave a project on their own, and a project admin can step down or leave as long as another admin remains.