Tagabuo ng modelo ng banta
Sabihin sa mga AI scanner kung ano ang mahalaga sa proyekto mo
Nagkakaroon ng karamihan sa mga maling positibo kapag hindi nauunawaan ng scanner kung sino ang attacker. Maaayos ito sa pamamagitan ng maikling modelo ng banta. Lagyan ng tsek ang mga kahon, kopyahin ang file sa .oss-scanner/threat_model.md, at susunod dito ang ossscanner.org at Anthropic OSS Scanner.
Mga kandidatong patch
Pag-aalis ng mga duplicate
.oss-scanner/threat_model.md
# Threat model ## About the project _Describe what the project does and who runs it._ ## Untrusted input (treat as adversarial) - Bytes received over the network (sockets, protocol messages, peers). - Files that users open or upload (documents, images, media, fonts). ## Out of scope (do not report) - Test code, fixtures and fuzzing harnesses. - Examples, demos and documentation snippets. - Build scripts, CI configuration and developer-only tooling. - Denial of service that needs very large inputs or sustained traffic. ## Severity rubric - **critical**: Remote code execution or full authentication bypass on a default configuration. - **high**: Memory corruption, privilege escalation or exposure of other users' data with a realistic attack path. - **medium**: Limited impact, or significant preconditions such as non-default settings or an authenticated attacker. - **low**: Hardening issues with no demonstrated security impact. ## Report format - Keep reports short: one-paragraph summary first, then affected file and lines, impact, reproducer and fix. - Candidate patches: minimal, enough to show the root cause and how to fix it. - Deduplicate by root cause: one report per underlying bug even if it is reachable from several places.
I-commit ang file na ito bilang .oss-scanner/threat_model.md sa iyong repository. Nasa English ang nabuong file para mabasa ito ng bawat scanner at contributor. Maaari mo rin itong i-paste sa mga setting ng naka-enroll mong proyekto sa ossscanner.org.
Bakit mahalaga ang modelo ng banta
Mahusay ang mga AI scanner sa pagtukoy ng code na maaaring magdulot ng problema, pero hindi nila malalaman kung kontrolado ng attacker ang isang input sa proyekto mo. Operator ba ang nagsusulat ng config file o hindi kilalang user? Pribilehiyadong setuid binary ba ang CLI o tool para sa developer? Kung wala ang kontekstong iyon, nag-uulat sila ng mga bug na hinding-hindi mo aayusin at mali ang pagtatasa nila sa kalubhaan.
Inirerekomenda ng Anthropic ang paggamit ng file ng modelo ng banta para mismo sa kadahilanang ito, at ayon sa mga maintainer na sumubok sa scanner nito, ang pinakakaraniwang mga pagkakamali ay ang labis na pagtaya sa kalubhaan at maling pagkaunawa sa modelo ng banta.
Ano ang isasama
- Ano ang ginagawa ng proyekto at sino ang nagpapatakbo nito.
- Saan pumapasok ang hindi pinagkakatiwalaang data: network, mga file, request, plugin.
- Ano ang pinagkakatiwalaan: config ng operator, mga lokal na user, kapaligiran ng build.
- Ano ang wala sa saklaw: mga test, halimbawa, mga isyung lokal lang, DoS na may napakalalaking input.
- Paano tasahin ang kalubhaan, para magkapareho ang kahulugan ng kritikal para sa iyo at sa scanner.
- Ano ang dapat hitsura ng mga ulat: estilo ng patch, mga kapaki-pakinabang na proof of concept, pag-aalis ng mga duplicate.
Panatilihin itong maikli. Sapat na ang isang pahina.
Kung saan ilalagay ang file
Bilang default, binabasa ng parehong scanner ang .oss-scanner/threat_model.md mula sa root ng iyong repo. Para sa scanner ng Anthropic, maaari ka ring magtakda ng ibang path sa project.yaml, o ilagay ang threat_model.md katabi ng project.yaml sa kanilang repo. Sa ossscanner.org, maaari mo itong i-paste sa mga setting ng naka-enroll mong proyekto. Magkakabisa ang mga pagbabago sa susunod na scan.