Kreator modelu zagrożeń
Powiedz skanerom AI, co jest ważne w Twoim projekcie
Większość fałszywie dodatnich wyników wynika z niezrozumienia przez skaner tego, kim jest atakujący. Krótki model zagrożeń rozwiązuje ten problem. Zaznacz odpowiednie pola, skopiuj plik do .oss-scanner/threat_model.md, a ossscanner.org i OSS Scanner firmy Anthropic będą się do niego stosować.
Proponowane poprawki
Usuwanie duplikatów
.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.
Zapisz ten plik w repozytorium jako .oss-scanner/threat_model.md. Wygenerowany plik jest w języku angielskim, aby każdy skaner i współtwórca mógł go odczytać. Możesz też wkleić go w ustawieniach zarejestrowanego projektu na ossscanner.org.
Dlaczego model zagrożeń ma znaczenie
Skanery AI dobrze wykrywają kod, który może działać nieprawidłowo, ale nie wiedzą, czy dane wejściowe w danym projekcie są kontrolowane przez atakującego. Czy plik konfiguracyjny zapisuje operator, czy anonimowy użytkownik? Czy CLI to uprzywilejowany plik binarny setuid, czy narzędzie dla programistów? Bez tego kontekstu skanery zgłaszają błędy, których naprawa nie miałaby sensu, i nieprawidłowo oceniają ich poziom ważności.
Anthropic zaleca plik z modelem zagrożeń właśnie z tego powodu, a opiekunowie projektów, którzy testowali ten skaner, stwierdzili, że najczęstsze błędy to zawyżona ocena poziomu ważności i błędne rozumienie modelu zagrożeń.
Co uwzględnić
- Co robi projekt i kto go uruchamia.
- Skąd wchodzą niezaufane dane: sieć, pliki, żądania, wtyczki.
- Co jest zaufane: konfiguracja operatora, lokalni użytkownicy, środowisko budowania.
- Co jest poza zakresem: testy, przykłady, problemy ograniczone do środowiska lokalnego, DoS wymagający ogromnych danych wejściowych.
- Jak oceniać poziom ważności, aby krytyczny oznaczał to samo dla Ciebie i skanera.
- Jak powinny wyglądać zgłoszenia: format poprawek, przydatne PoC, usuwanie duplikatów.
Pisz zwięźle. Wystarczy jedna strona.
Lokalizacja pliku
Oba skanery domyślnie odczytują plik .oss-scanner/threat_model.md z katalogu głównego repo. W przypadku skanera Anthropic możesz też ustawić inną ścieżkę w pliku project.yaml lub umieścić threat_model.md obok project.yaml w repo tego skanera. Na ossscanner.org możesz wkleić go w ustawieniach zarejestrowanego projektu. Zmiany zaczną obowiązywać podczas następnego skanowania.