Replayable Code Attack Review
Before merging high-risk code, security engineers can run an isolated attack simulation that returns rerunnable proof of exploitable vulnerabilities.
When a security engineer is about to merge a high-risk change involving login, payments, or external input, they provide the repository, target branch, and local startup command. The product launches the application in an isolated copy, reads the test accounts and permitted attack scope, then uses a cybersecurity model to look for exploitable paths across real pages, APIs, and permission relationships.
The result is not a generic risk summary. Each finding includes a rerunnable verification script, a terminal recording of the triggering process, affected code locations, and records of successful or failed requests. Engineers can open the evidence directly in the pull request, rerun it once, and decide whether to fix the issue, accept the risk, or close a false positive.
Confirmed issues can be converted into regression tests with one click. After a fix is committed, the product replays the original path in the same isolated environment and marks the check as passed only when the attack no longer succeeds. Teams can also save attack playbooks for a class of API so later changes continue to receive the same validation.
The initial scope focuses on authorization bypasses and input injection in web applications, and runs only against code and test environments authorized by the team. It does not scan public internet targets, perform destructive actions, or replace human security review.
Why now
On September 2, Google released Gemini 3.8 Flash Cyber, bringing autonomous vulnerability discovery and automated remediation into real code environments for trusted defenders. S1 As of September 3, the post ranked first on Hacker News’s new submissions feed, with 802 points and 477 comments, and security engineers are actively discussing this class of capability. S2
Target user
Platform teams with a security owner but no dedicated red team. The trigger is a pending merge affecting login, payments, uploads, or tenant permissions. Static alerts cannot show whether a flaw is truly exploitable, while manual penetration testing cannot keep up with every commit. Before approving the merge, engineers need rerunnable evidence and confirmation that the fix blocks the original path.
Minimal entry point
Use Docker to create an ephemeral copy and start the application with commands supplied by the repository. Begin authorization and injection testing with the OWASP ZAP Automation Framework, which supports active scanning, browser login, and scripted authentication. S3 The model chooses pages, mutates inputs, and interprets results, but never receives host-machine access. Limit the first release to common form logins, cookie or token sessions, SQL injection, and broken access control. Preserve every successful request as a script, network record, and code location. Generate standalone security test files for regression tests first, without automatically rewriting business test suites. Gemini 3.8 Flash Cyber is available only to trusted defenders, so it cannot be a foundational capability available to every customer. S1
Punching above its weight
Find initial users among open-source projects that maintain login, payment, or multi-tenant authorization flows. A rerunnable security test is more likely to earn maintainer feedback than a scan summary. Then package the verification flow as a GitHub App that runs only on pull requests carrying a security label. Publish redacted false-positive corrections and test examples to steadily build credibility and an attack-playbook library.
Competitors & gaps
- XBOWGoogle
- XBOW already performs automated penetration testing against targets. Confirmed findings include exploit details, reproduction steps, and evidence; after a fix, it can rerun the original exploit and try alternative paths. S4 Because it already covers the core discover-prove-retest loop, competing head-on is difficult. The opening is closer to the code merge: automatically build an isolated copy from a repository branch, use the code diff to narrow the attack surface, and attach evidence directly to the pull request. The more important distinction is producing maintainable, in-repository regression tests rather than merely updating a finding’s status in the platform. Tests should use the team’s existing framework and be reviewed alongside the code. If environment setup and test generation cannot be made reliable, that distinction does not hold.
How it makes money
Charge a monthly subscription per repository, including pull-request checks, evidence retention, and regression replays. Bill for sandbox runtime beyond the included allowance.
The case against
The isolated environment can easily become the real engineering bottleneck. Repositories may depend on private images, cloud services, asynchronous jobs, and complex seed data, causing automated startup to fail. Incorrectly provisioned test-account permissions can create false access-control findings or miss real paths. Generated attack scripts may also depend on timing, random data, and page structure, producing intermittent failures in CI. Terminal recordings and request logs can expose tokens or personal data, so they need redaction and access controls. Model calls and long-running jobs can also slow the merge process. If teams must frequently repair environments and scripts by hand, maintenance costs will erase the review time saved.