Mozilla shipte op 30 april 271 AI-gevonden security fixes in Firefox 150 — 151 daarvan ontdekt door één Claude Mythos-pass. AI-security is geen aankondiging meer, maar werkende code. Vier vragen die elke MKB'er nu aan zijn software-leverancier hoort te stellen.
Op 30 april 2026 verscheen Firefox 150. In die release zaten 271 security fixes — een aantal dat zelfs Mozilla's eigen team verraste. Honderdvijftig daarvan ontdekt door één enkele AI-doorgang met Anthropic's Claude Mythos Preview. Niet door een team van vijftig pentesters. Niet door tien jaar fuzzing.
Dit is geen aankondiging meer. Dit is geleverde, gepatchte code. En dat verandert wat een redelijke MKB'er van zijn software-leverancier mag verwachten.
Wat er werkelijk gebeurde
Drie maanden eerder, in Firefox 148, fixte Mozilla samen met Anthropic's Frontier Red Team al 22 CVE's na een scan met Claude Opus 4.6. Een proof of concept. Indrukwekkend, maar nog vroege fase.
In Firefox 150 was het andere koek: 271 bugs in één evaluatie, 14 high-severity en 22 CVE's, en — het belangrijkste — logica-fouten die fuzzers per definitie niet kunnen vinden. Fuzzing schiet random input op een programma; logica-redenering vereist begrip van wat de code probeert te doen.
Mozilla's eigen woorden in de aankondiging: "Computers were completely incapable of doing this a few months ago, and now they excel at it."
De Firefox-codebase is twintig jaar oud en behoort tot de meest geanalyseerde code ter wereld. Toch zaten er 271 ontdekbare bugs in. Dat zegt niets slechts over Mozilla — het zegt iets over wat AI-analyse blootlegt in elke ouder geworden codebase.
Het asymmetrie-spel kantelt
Cybersecurity heeft jaren gewerkt onder één wet: de aanvaller hoeft één gat te vinden, de verdediger moet ze allemaal vinden. Die ongelijkheid maakte aanvallen goedkoper dan verdediging.
AI-gestuurde code-analyse breekt dat. Mozilla noemt het "defenders finally have a chance to win, decisively." Voor het eerst kunnen verdedigers in dezelfde tijd dezelfde technieken inzetten als aanvallers — en hebben ze er meer aan, omdat ze de hele aanvalsoppervlakte willen afdekken.
Voor Mozilla werkt dat. Het is een organisatie met honderden engineers en een security-team dat 271 bugs in één release kan absorberen. Een open source library die door één vrijwilliger wordt onderhouden, kan dat niet — en datzelfde geldt voor de leverancier die jouw bedrijfssoftware bouwde en sindsdien geen versie meer heeft uitgebracht.
Als dezelfde AI-tooling beschikbaar komt voor aanvallers (en dat is een kwestie van maanden, niet jaren), wordt het verschil tussen onderhouden en verlaten code ineens een veiligheidsverschil.
Wat dit betekent voor jouw software-stack
Als jij een custom CRM, klantportaal of interne tool laat bouwen of inkoopt, zit je in één van deze drie situaties:
1. Je hebt actieve software-leveranciers. Vraag wanneer en hoe ze hun code op security toetsen. Een leverancier die zegt "we schrijven schone code" geeft het verkeerde antwoord — code-kwaliteit op het moment van bouwen voorkomt geen lekken die later via dependencies binnensluipen. Vraag concreet: gebruiken jullie geautomatiseerde scans? Welke? Hoe vaak?
2. Je leunt op SaaS-tooling. Vraag de SaaS-leverancier hun security disclosure beleid. Hoe lang duurt het tussen melding en fix? Hebben ze een responsible disclosure programma? Stille leveranciers — die geen security-advisories publiceren — zijn niet veilig, maar onwetend.
3. Je hebt verlaten software in productie. Dit is de gevaarlijkste categorie: een leverancier die niet meer bestaat, een freelancer die niet meer reageert, of een interne tool die niemand meer onderhoudt. Bij honderden nieuwe ontdekbare lekken per release in elk groot codebase, is "geen contact meer met de bouwer" een houdbaarheidsdatum, geen status quo.
Vier vragen voor je software-leverancier
Bij elk volgend leverancier-overleg horen deze vier vragen op tafel:
1. Wanneer is deze code voor het laatst gescand op security-issues, en met welke tools? Een datum binnen het laatste kwartaal is acceptabel. "Bij oplevering" is dat niet.
2. Welke dependencies zitten erin, en hoe houden jullie die up-to-date? Een lijst die niet automatisch wordt gemonitord, is een ondergrondse tijdbom.
3. Wat is jullie SLA bij een ontdekt lek? "We patchen zo snel mogelijk" is geen SLA. Concrete uren of dagen wel.
4. Wat gebeurt er met de code als de samenwerking stopt? Bezit jij de repository, is de code gedocumenteerd, en kan een andere ontwikkelaar die overnemen? Continuïteit zit in eigenaarschap en overdraagbaarheid — niet in team-grootte.
Een leverancier die struikelt op deze vragen, levert geen onderhoud — die levert alleen oplevering.
Waarom continue oversight goedkoper wordt dan jaarlijkse pentests
De traditionele aanpak — één keer per jaar een externe pentester inhuren — werd betaald door dat het de enige manier was. Een handmatige audit van een middelgrote codebase kostte €10.000 tot €25.000 en leverde een momentopname.
AI-gedreven scanning verandert die rekensom. Wat eerder duizenden uren menselijk werk vereiste, kan nu in dagen — met menselijke validatie achteraf. Dat brengt kosten omlaag, maar ook frequentie omhoog.
Doorlopende code-kwaliteitscontrole hoort niet langer bij "enterprise-only" — ook het MKB krijgt er voor het eerst toegang toe. Bij Datapad's Development as a Subscription is doorlopende oversight onderdeel van het maandbedrag, niet een aparte regel achteraf. Dat past in dit nieuwe tempo.
De bredere les
Mozilla's 271 bugs zijn geen Firefox-nieuws. Het zijn een marker: vanaf nu is "we hebben er nooit klachten over gehad" geen geldige securitystrategie meer voor software die jouw bedrijf draait.
Wie verder wil lezen over Anthropic's onderliggende technologie en de defensieve alliantie die eromheen werd opgebouwd: zie het artikel over Project Glasswing en Claude Mythos. En over wat AI-gegenereerde code betekent voor het begrip van je eigen software, zie Dark code: niemand begrijpt zijn eigen software meer.
---
Wil je weten of jouw eigen software-stack klaar is voor dit nieuwe tempo? Plan een gesprek — we kijken samen naar je dependencies, code-eigendom en update-cadans.