Naar de inhoud
ossscanner.org

Hoe het werkt

Van een repositorylink naar geverifieerde bevindingen

De pipeline volgt het model dat Anthropic beschreef voor zijn OSS Scanner — dreigingsmodel, audit, dubbele controle, hoofdoorzaak, patch — en is gebouwd op geavanceerde Claude-modellen die via een openbare API beschikbaar zijn.

  1. 1

    Veilig klonen

    We halen de branch op waar je om hebt gevraagd met een ondiepe, op blobs gefilterde git clone via HTTPS. Git-hooks zijn uitgeschakeld, symlinks worden als gewone bestanden uitgecheckt en elk transport behalve HTTPS wordt geweigerd. Privénetwerkadressen worden geblokkeerd, zodat de scanner niet op interne hosts kan worden gericht.

    Er wordt nooit iets uit de repository uitgevoerd: geen builds, geen pakketinstallaties, geen tests. De checkout wordt verwijderd zodra de scan is afgelopen.

  2. 2

    Inventarisatie en risicorangschikking

    Elk tekstbronbestand wordt vermeld met de taal en de grootte. Code van derden, gegenereerde bestanden, geminificeerde bundels en lockbestanden worden overgeslagen. Elk bestand krijgt een risicoscore op basis van gevaarlijke sinks — geheugenkopieën, shell-uitvoering, deserialisatie, SQL-opbouw, templates renderen, padcombinaties, cryptografie en authenticatiecode — en van kritieke codepaden, zoals parsers, protocolhandlers en routering van verzoeken.

  3. 3

    Dreigingsmodel

    Als de repository .oss-scanner/threat_model.md bevat (hetzelfde bestand dat de scanner van Anthropic leest), SECURITY.md bevat of een dreigingsmodel heeft dat je bij de aanmelding hebt opgegeven, volgt de scanner dat. Anders leest een model de README, de directorystructuur en de bestanden met het hoogste risico en stelt het een dreigingsmodel op: wat het project is, waar niet-vertrouwde invoer binnenkomt en wat buiten de scope valt.

    Het dreigingsmodel selecteert ook focusbestanden, zodat de audit zijn budget besteedt aan code die een aanvaller daadwerkelijk kan bereiken.

  4. 4

    Controleren

    De bestanden met het hoogste risico worden in grote batches, inclusief regelnummers, naar een redeneermodel gestuurd, samen met het dreigingsmodel. Het zoekt naar problemen die een zorgvuldige menselijke auditor zou melden:

    • geheugenveiligheid: bufferoverschrijdingen, use-after-free, integerafkapping
    • injectie: SQL, opdrachten, sjablonen, path traversal, SSRF
    • authenticatie, autorisatie en sessielogica
    • onveilige deserialisatie en verwarring bij parserverwerking
    • onjuist gebruik van cryptografie en omgang met geheimen

    Snelle scans gebruiken Claude Haiku met een gematigd budget. Diepgaande scans voor aangemelde projecten gebruiken Claude Sonnet en lezen tot vier keer zoveel code.

  5. 5

    Onafhankelijke verificatie

    Elke kandidaat-bevinding wordt naar een aparte verificatieagent gestuurd met een schone context. De taak van die agent is de bevinding te weerleggen: de gegevensstroom volgen, nagaan of er elders validatie plaatsvindt en controleren of de invoer volgens het dreigingsmodel daadwerkelijk door een aanvaller kan worden beheerst. Alleen bevindingen die de agent bevestigt of waarschijnlijk acht, blijven staan; de rest wordt als verworpen geteld.

    Voor bevindingen die overblijven, schrijft de verificatieagent de hoofdoorzaak, een reproducer en een minimale kandidaatpatch als unified diff.

  6. 6

    Introductiecommit en rapport

    Dubbele bevindingen met dezelfde hoofdoorzaak worden samengevoegd. Met git blame op de kwetsbare regels wordt de meest recente commit gevonden die ze heeft gewijzigd — meestal de commit waarin de bug is geïntroduceerd — zodat je een Fixes:-tag kunt toevoegen en kunt bepalen welke releases zijn getroffen.

    Het rapport wordt opgeslagen onder een willekeurige, niet te raden ID. Je kunt het exporteren als Markdown voor een advies, JSON voor tools of SARIF 2.1.0 voor GitHub-code scanning.

Wat de scanner niet doet

  • De scanner voert je code niet uit, bouwt die niet en haalt geen afhankelijkheden op.
  • De scanner publiceert geen bevindingen, maakt geen issues aan en neemt met niemand contact op, behalve met aangemelde maintainers.
  • De scanner bewaart na de scan geen kopie van je broncode. Rapporten bevatten korte fragmenten van de betreffende regels.
  • De scanner biedt geen garanties: modellen missen bugs en melden soms ten onrechte problemen. Een schoon rapport is geen beveiligingscertificering.

Waarom reproducers zijn afgeschermd

Iedereen kan een link naar een openbare repository plakken, ook mensen die geen maintainer zijn. De hoofdoorzaak en patch helpen verdedigers; een werkende proof of concept helpt vooral aanvallers. Daarom blijven reproducers verborgen totdat iemand een tokenbestand aan de repository toevoegt — bewijs dat die persoon een fix kan uitbrengen. Dit volgt de richtlijnen van de Linux-kernel, waarin staat dat reproducers voor door AI gevonden bugs op verzoek van de maintainer moeten worden gedeeld.

Hoe dit verschilt van de OSS Scanner van Anthropic

Anthropic voert zijn scanner uit in offline sandboxen, waarbij het project wordt gebouwd met een Dockerfile. Zo kunnen agents code compileren en uitvoeren om bugs dynamisch te bevestigen. De scanner gebruikt de krachtigste modellen, waaronder Claude Mythos, dat niet openbaar beschikbaar is. Wij analyseren code statisch met openbaar beschikbare Claude-modellen. Daar staat tegenover dat iedereen ossscanner.org binnen enkele minuten kan gebruiken, zonder aanvraag of Dockerfile.