Home | Bug Bounty | Threat Modeling | SAST | Services | About me | Blog
Triage is all the rage with the overwhelming volume of AI assisted security findings. But it still is purely reactive: defining how to find a needle in a haystack.
Economics have taught us that value comes from scarcity. And blockchains proved technology alone could create such scarcity.
How could we proactively design scarcity in vulnerability management? That is what I tried to explore by designing those 3 open source tools, AI making it possible by compressing the implementation effort from weeks to days.
By following a Less Is More approach (flagADA and TSAS), some bandwidth is made available for Security By Design (lovelyTM). This should help identify and prioritize the most important security requirements, reducing the probability of impactful bug bounty reports. Extra attention can then be given to the remaining findings, with a thorough post incident review plan including custom SAST rules and threat model update.
But data is more valuable than a theoretical flywheel effect. That is why I am looking for feedback: do not hesitate to share it directly via issues in the corresponding Github repositories.
If I had to pick up only one topic where AI has the potential to reshape the security industry, it would be a controversial one: celebrating offense less.
When Trail of Bits say “Finding the bugs is now the easy part”, this is not a marketing stunt: it used to be their core activity where they excel at.
Defending is boring, attacking was sexy. Great offensive work allowed to build your reputation by talking at security conferences, climbing the leaderboard of bug bounty programs or adding CVEs on your CV. And in some security organizations shielded you from the tiring operational work as it would be nonsense wasting rare skills to manage tickets.
Redirecting some of this brain power to defensive efforts could bring in much needed help, but it has to be used wisely to keep the flame of creativity alive. Current best practices need innovation more than ever, not just extra labor, to be relevant in a world running at AI speed.
Over the last decade I have been tweaking the STRIDE threat modeling methodology to make it less verbose. I am delighted to release the lovelyTM tool that captures those lessons learned.
AI has made it possible: what required days of front-end work is now doable in hours. Time to ditch the battle-tested spreadsheets and propose something both efficient and appealing.
Its concept is built on strong differentiators:
You can use directly the hosted version: no need to worry about sensitive information, all the processing is handled by the browser (no backend nor database). But you can also self-host it with the web server of your choice.
While the Zero Trust for AI agents security framework from Anthropic is thorough, its base level (Foundation) is probably too demanding for many organizations.
Most required items are best practices and not rocket science, but they rely on the assumption of properly staffed security teams. In real life, implementing all of the baseline recommendations could represent a multi-year roadmap. A delay clearly not suited for AI agents that the business wants to be deployed now, or at the latest in the next few weeks.
A Bare Minimum entry level, with far less requirements, would really help getting started.
The Agents Rule of Two guidance from Meta is far more practical. One diagram and nothing more:
What has been happening with Tokenmaxxing, and now with capping employee use of AI coding tools, is fascinating from a change management perspective. It shows what happens when combining top-down mandates with extreme speed.
This is nothing new: even in the old and ideal world of Control Theory, you have to balance speed vs overshoot with Second-Order systems. (Or wait for First-Order systems to slowly converge). And with the assumptions that you can:
But it is a key learning opportunity for application security practitioners:
It is refreshing to read a QA article where security is a first class citizen, specifically those 2 recommendations:
Those are security invariants. Getting them right reduces ambiguity and vulnerabilities are born of confusion. However listing them is challenging both from a theoretical and practical point of view:
But don’t let perfect be the enemy of good. Lightweight threat modeling is enough to make significant progress in identifying the most important security invariants, particularly if you filter first on business impact.
This blog post by Cloudflare is a gold mine for security engineers trying to assess the real life potential of AI scanners like Mythos.
TLDR:
From Behind the Scenes Hardening Firefox with Claude Mythos Preview:
Observing such direct payoff from previous hardening work was even more rewarding than finding and fixing more bugs
Not only does it confirm that previous security efforts had a measurable impact in reducing risk, it also brings relief to engineers: getting back some control on what was otherwise an endless stream of vulnerabilities.
Benchmarking AI powered security scanning tools is absolutely challenging:
At the end of the day, rather than over-engineering benchmarks that cannot be reproduced by design, what matters is: can it identify vulnerabilities in real-life more efficiently and more effectively than non-AI tools?
To answer this question we can
If you are a company having access to Claude Security in beta, would you be open to sharing anonymously some of your findings? The goal is to start a vendor-neutral survey with data points from complex/legacy codebases of various programming languages.
I am volunteering triage time against confidential access to pristine findings: I am really curious to see how the default Claude Security harness performs in real-life conditions.
The only current data points easily available today are about Mythos on codebases where security is state-of-the-art:
There has been a lot of discussions recently about bug bounties being overwhelmed by AI capabilities, particularly open source projects.
I am exploring in this article how following a Less Is More strategy could help move forward, rather than just suspending programs.
I released the flagADA tool to make it easy enough to experiment with this approach. I am now looking for volunteer projects to be able to gather real world data.
Because fixing has historically been slow/expensive/painful/boring, prioritization was the obvious path for vulnerability management. And with low volumes somehow “good” enough for the business to survive (if you are not a cryptocurrency exchange worst-case scenario is the Equifax example).
With volumes several orders of magnitude bigger, relying on obvious solutions is not going to cut it. No matter how smarter prioritization can become, there will still be more and more fixes to be produced. And a security finding that is not fixed, no matter how critical it is, will still generate noise and make AI scanners burn tokens (e.g. trying to chain many very low vulnerabilities).
The priority should not be prioritization, it should be how to Just Fix It with minimal effort and business impact. Levering AI to automatically produce fixes would highly likely help, but it is a more general People/Process/Tool challenge that requires thinking outside the box. My 2 cents: observability will have a key role to play to keep business disruption under control.
The Software Development Lifecycle Is Dead is a fascinating read for security professionals who have “embed security in the SDLC” in their job description.
Not only because it contains just once the word security, “security scans” as an item in the code review checklist, and does not mention it in any other stage. (Don’t ask me if DevSecOps has been a success). But most importantly because it could solve the vulnerability management headaches: have agents automatically handle security patches and an observability loop ensuring reliability.
I am convinced this an expirement absolutely worth running and I am happy to help:
Over the past few days I have looked in detail at 2 outstanding documents that are a must-read for any Product Security enthusiast in 2026:
What strikes me the most is the disconnect between the two. Most of the Mythos readiness recommended actions should happen in the next few weeks, including the capability to patch within hours as suggested by the Zero-Day Clock. Whereas in 2025, the top 15% high performing teams in the Semgrep report took an average 43 days to remediate a SAST finding from a full scan (and only fixed 39.6% of them, but 62.7% of the Critical ones). And 36 days for a SCA item.
And that’s the best case scenario: organizations that could invest in top-notch tooling but also have enough maturity to drive process changes. Automation undoubtedly has been top of mind when defining their security strategy.
To have a chance to bridge the gap in such a short timeframe, it is not optional anymore to get rid of any activity that is not effective, nor efficient enough. It is high time for the security industry to focus first on performance per watt.
NB: I am deliberately not including in this list the blog post Preparing your security program for AI-accelerated offense. Its recommendations can somehow be summarized as “have a mature security program”. But a timeline in months is probably not realistic given many multi-year security roadmaps have not really moved the needle.