Mula sa link ng repository hanggang sa mga na-verify na finding

Kinukuha namin ang branch na hiniling mo gamit ang shallow, blob-filtered na git clone sa HTTPS. Naka-disable ang mga Git hook, kinukuha ang mga symlink bilang mga ordinaryong file, at tinatanggihan ang lahat ng transport maliban sa HTTPS. Bina-block ang mga address ng pribadong network para hindi maituro ang scanner sa mga internal host.

Hindi kailanman ine-execute ang anumang mula sa repository: walang build, pag-install ng package, o test. Binubura ang checkout kapag natapos ang scan.

Inililista ang bawat source file na teksto kasama ang wika at laki nito. Nilalaktawan ang naka-vendor na code, mga generated file, minified bundle at lockfile. Binibigyan ang bawat file ng risk score batay sa mga mapanganib na sink — pagkopya ng memory, pag-execute ng shell, deserialization, pagbuo ng SQL, pag-render ng template, pagsasama ng path, crypto at auth code — at sa mga kritikal na path gaya ng mga parser, protocol handler at pagruruta ng request.

Kung mayroon ang repository ng .oss-scanner/threat_model.md (ang parehong file na binabasa ng scanner ng Anthropic), SECURITY.md o threat model na ibinigay mo noong nagpatala ka, susundin ito ng scanner. Kung wala, babasahin ng isang modelo ang README, layout ng mga directory at mga file na may pinakamataas na panganib, at gagawa ito ng draft: kung ano ang proyekto, saan pumapasok ang hindi pinagkakatiwalaang input at ano ang hindi saklaw.

Pinipili rin ng threat model ang mga file na pagtutuunan, para ituon ng audit ang budget nito sa code na maaabot talaga ng attacker.

Pinagsasama-sama sa malalaking batch ang mga file na may pinakamataas na panganib, kasama ang mga numero ng linya, at ipinapadala sa isang reasoning model kasama ang threat model. Hinahanap nito ang mga isyung iuulat ng isang masusing auditor na tao:

• kaligtasan ng memorya: mga overflow, use-after-free, integer truncation
• injection: SQL, command, template, path traversal, SSRF
• lohika ng authentication, authorization at session
• hindi ligtas na deserialization at kalituhan sa parser
• maling paggamit ng cryptography at pangangasiwa ng mga lihim

Gumagamit ang mga mabilisang scan ng Claude Haiku na may katamtamang budget. Gumagamit naman ang mga malalim na scan para sa mga naka-enroll na proyekto ng Claude Sonnet at nagbabasa ng hanggang apat na beses na mas maraming code.

Ipinapadala ang bawat candidate finding sa hiwalay na verifier agent na may bagong context. Tungkulin nitong pabulaanan ang finding: sundan ang daloy ng data, hanapin kung may validation sa ibang bahagi, at tiyakin kung kontrolado talaga ng attacker ang input ayon sa threat model. Nananatili lamang ang mga finding na kinukumpirma nito o tinataya nitong malamang na totoo; binibilang bilang tinanggihan ang iba.

Para sa mga finding na nananatili, isinusulat ng verifier ang root cause, isang reproducer at isang minimal na candidate patch bilang unified diff.

Pinagsasama ang mga duplicate na may iisang root cause. Ginagamit ang git blame sa mga bulnerableng linya para hanapin ang pinakahuling commit na nagbago sa mga ito — karaniwan, ito ang commit na nagpasok ng bug — para maidagdag mo ang Fixes: tag at matukoy kung aling mga release ang apektado.

Iniimbak ang ulat gamit ang random at imposibleng mahulaang ID. Maaari mo itong i-export bilang Markdown para sa advisory, JSON para sa mga tool, o SARIF 2.1.0 para sa GitHub code scanning.