- Published on
The security team that never sleeps: 0.security and the end of the annual pentest
- Authors
- Name
- AbnAsia.org
- @steven_n_t
Listen to this article · The security team that never sleeps: 0.security and the end of the annual pentest
0:00 / 0:00
Watch this article · The security team that never sleeps: 0.security and the end of the annual pentest
Security testing has always run on a calendar. Once a year, sometimes twice, an external firm spends a week with the application, writes a report, and the team spends a quarter working through it. By the time the last finding is closed, the codebase has changed underneath it.
That model assumed software changed slowly. It does not any more. A team using coding agents ships in a week what used to take a quarter, and every one of those changes is a new surface. An annual test now describes a system that no longer exists.
0.security is one of the companies in Y Combinator's Fall 2026 batch (F26) built on that gap. Its description is blunt: an autonomous cybersecurity team. The product runs security tests on pull requests, keeps a continuous pentest going against live systems, watches dependencies against newly disclosed vulnerabilities, and — the part that matters commercially — delivers a fix in the same pull request, applied with one click.
Index the codebase
A graph of repositories, dependencies and infrastructure, plus the conventions the team already writes in.
Send agents to find and fix
Parallel agents investigate like an attacker, then prepare a patch rather than a ticket.
Verify in isolation
Findings are reproduced in sandboxed environments so only confirmed issues reach the team.
Carry the context forward
Architecture and past findings feed the next investigation, which is what makes it cheaper over time.
Why the verification step is the whole product
Scanning is cheap and has been for a decade. What has never been cheap is knowing which of the alerts matter. A scanner that reports two hundred findings and is wrong about half of them does not reduce risk; it consumes the attention of the one person who could have fixed the real one.
So the interesting claim here is not that AI can find bugs. It is that AI can be made to prove them. 0.security says agents reproduce findings in isolated environments and verify the fix before it is offered, and that this is how it filters false positives. If that holds up, it changes the unit of work from "a report to triage" to "a patch to review".
The company's public research is the evidence it leans on. Its site lists disclosed vulnerabilities across the Linux kernel and a long set of vendor stacks — AMD, Qualcomm, Cisco, Arm, Google, Meta, IBM, NVIDIA, Intel, Red Hat — with the kind of review trail that security engineers recognise. It also publishes its harness as open source and says more than three billion devices run software it has helped secure. Those are company claims, not independently audited numbers, but the disclosure links are checkable in a way marketing copy usually is not.
The arms race nobody asked for
The uncomfortable context is that the same capability exists on the other side. Attackers use models to read code, find weaknesses and write exploits, at the same speed defenders can now use them to close them. A company that adopts AI for engineering and keeps an annual security review has automated one half of the equation.
That is the argument for continuous testing in one sentence: if the code changes daily, the security posture has to be evaluated daily, or the gap between what you shipped and what you checked widens every week.
Annual test
A snapshot of one week, priced per project, valid until the next release cycle.
Test with every change
The pull request becomes the unit of review, so the check happens where the risk is introduced.
Fix in the same place
A patch in the PR beats a PDF in a shared drive, because it is reviewed by the person who wrote the code.
Keep the memory
What was found last month should make next month’s investigation shorter — otherwise you are renting the same work twice.
What a buyer should still ask
Three questions, and none of them is about model quality.
Who owns the result? A tool that files findings is a scanner. A tool that patches code is making changes to production systems, and someone inside the company has to own that decision. In a company without a security executive, that owner is usually missing — which is the same gap that makes a fractional CSO worth retaining.
What is the false-positive rate on our code? Ask for a trial against a repository you already know the flaws in. Verification claims are easy to make and expensive to prove.
What happens when the model is wrong in the other direction? A missed vulnerability is worse than a noisy one, and no vendor will guarantee recall.
0.security is early: a Fall 2026 batch company, a small team, and claims that will be tested by customers rather than by a press release. But the shape of the argument is right, and it is the shape the whole batch is pointing at — AI creates the problem at machine speed, so the response has to run at machine speed too.
The annual pentest is not dead because it was bad. It is dead because it describes a codebase that stopped existing in February.
Source: Y Combinator F26 company listing and 0.security's public site and research disclosures, November 2026. Company claims are attributed as such.
Contact: [email protected]