Jak pracujemy

Metodologia

Wynik, którego nie da się sprawdzić, nie jest wynikiem. Ta strona opisuje, skąd bierzemy każde twierdzenie, czego nie twierdzimy i kiedy przestajemy odpowiadać za to, co napisaliśmy.

Ostatnia aktualizacja: 21 sierpnia 2026

Czym jest dowód

Większość narzędzi miesza cztery różne rzeczy w jedną liczbę. My je rozdzielamy, bo każda z nich ma inną wagę i inne konsekwencje.

Pojęcie	Co to znaczy	Przykład
Obserwacja	Surowy fakt ze źródłem i czasem. Nie ocenia.	Adres zwrócił kod 200 i treść zawierającą klucz.
Twierdzenie	Cudze zdanie, najczęściej dostawcy albo dokumentu. Ma cytat i miejsce w źródle.	„Nie używamy danych klienta do trenowania modeli”, punkt 7.2 umowy.
Ustalenie	Stwierdzony problem poparty dowodem, który da się odtworzyć.	Konto A odczytało dane konta B na tabeli faktur.
Ryzyko	Skutek ustalenia w Twoim konkretnym zastosowaniu.	Wyciek danych rozliczeniowych 34 klientów agencji.
Decyzja	Werdykt dla określonego zakresu i daty, z warunkami.	Warunkowo, po domknięciu polityki odczytu.

Każdy z tych elementów niesie źródło, czas, autora, pewność, zakres i datę, po której przestaje być aktualny. Element bez źródła i daty nie wchodzi do decyzji, nawet jeśli brzmi sensownie.

Poziomy upoważnienia

Nie każde sprawdzenie wolno wykonać na podstawie samej chęci. Im głębiej sięgamy, tym więcej potrzeba zgody. Poziom jest przypisany do każdego testu, a nie do klienta, i bez aktywnego upoważnienia test się nie uruchamia.

Poziom	Co wolno	Czego wymaga
L0	To, co system pokazuje publicznie: nazwy domen, certyfikaty, nagłówki, opublikowane dokumenty, publiczna dokumentacja.	Akceptacja warunków i wskazanie celu.
L1	Dokumenty, które nam przekazujesz: umowa, powierzenie danych, wyeksportowana konfiguracja.	Potwierdzenie, że masz prawo je przekazać.
L2	Odczyt z podłączonych systemów: repozytorium, schemat bazy, konfiguracja chmury.	Zgoda właściciela, jawny zakres uprawnień, wyłącznie odczyt.
L3	Testy, które wykonują realne zapytania do działającego systemu, w tym testy granic danych na kontach testowych.	Pisemne upoważnienie: asset, środowisko, okno czasowe, limity, kontakt awaryjny.
L4	Powtarzalne testy i obserwacja zmian w czasie.	Stałe upoważnienie z harmonogramem i możliwością natychmiastowego zatrzymania.

Nie omijamy logowania, zabezpieczeń przed automatami ani limitów po stronie sprawdzanego systemu. Jeśli coś da się ustalić wyłącznie przez ich obejście, wynik brzmi „nie ustalono”, a nie „bezpieczne”.

Jak liczymy pewność

Podajemy cztery wielkości osobno, bo sklejenie ich w jedną liczbę ukrywa najważniejszą informację: czy wynik jest niski dlatego, że system jest słaby, czy dlatego, że zabrakło danych.

Ryzyko: jak dotkliwy jest skutek w Twoim zastosowaniu i jak łatwo go wywołać.
Siła dowodów: jakość źródła, świeżość, kompletność, możliwość odtworzenia i to, czy różne źródła mówią to samo.
Ekspozycja: kto w ogóle może dotknąć tej powierzchni. Inaczej liczy się coś dostępnego z internetu, a inaczej coś wewnętrznego.
Decyzja: wynik biznesowy, czyli akceptuj, warunkowo, zatrzymaj albo brak danych.

Siła dowodów spada z czasem. Ten sam dowód sprzed tygodnia i sprzed roku nie waży tyle samo, i widać to w raporcie.

Czego nie sprawdzamy

To jest część, którą większość narzędzi pomija, a która decyduje o tym, czy raport da się komukolwiek pokazać.

Brak dowodu nie znaczy „bezpieczne” i nie znaczy „krytyczne”. Znaczy: nie wiemy. Każda decyzja wymienia obszary, których nie dotknęliśmy, i mówi, czego trzeba, żeby je zamknąć.

Standardowo poza zakresem, jeśli nie umówiliśmy się inaczej:

środowisko produkcyjne, o ile nie ma osobnego upoważnienia;
procesy w firmie: kto ma dostęp, jak wygląda odejście pracownika, jak przechowywane są hasła;
fizyczne bezpieczeństwo i sprzęt;
zgodność z konkretną normą albo certyfikacją;
ocena prawna zapisów umowy, poza wskazaniem, co znaczą dla Twojego zastosowania;
podatności, które ujawniono po dacie naszego sprawdzenia.

Ponowny test i wygasanie

Ustalenie zamykamy dopiero wtedy, gdy poprawka przechodzi ten sam test, który wcześniej go wykrył. Zmiana w kodzie bez potwierdzenia nie zamyka niczego.

Każda decyzja ma datę, po której przestaje obowiązywać. Nie dlatego, że wtedy system nagle staje się gorszy, tylko dlatego, że po tym czasie nie mamy podstaw, żeby coś twierdzić. Zmiana istotna, na przykład nowa lista podprocesorów albo zmiana polityki dostępu, otwiera decyzję wcześniej.

Prawo dostawcy do odpowiedzi

Jeśli sprawdzenie dotyczy cudzego produktu, dostawca ma prawo odnieść się do wyniku, zanim ten trafi gdziekolwiek dalej niż do osoby, która o niego poprosiła.

Dostawca widzi ustalenia, które go dotyczą, wraz ze sposobem odtworzenia.
Może dodać własne stanowisko. Publikujemy je razem z ustaleniem, nie zamiast niego.
Może zgłosić błąd w ustaleniu. Sprawdzamy to i poprawiamy, jeśli miał rację.
Nie może usunąć ustalenia ani zmienić jego treści.

Nie publikujemy list wstydu ani rankingów bezpieczeństwa firm. Wynik dotyczy zakresu, daty i konkretnego zastosowania, więc nie nadaje się na tabelę z pozycjami od najlepszej do najgorszej.

Rola modelu językowego

Używamy modeli językowych do czytania dokumentów, streszczania, grupowania i proponowania pytań. Nie używamy ich do wydawania werdyktu.

Model proponuje, człowiek zatwierdza. Propozycja jest oznaczona jako propozycja.
Każde twierdzenie wyprowadzone z dokumentu ma cytat i miejsce w źródle.
Treść sprawdzanego dokumentu albo strony traktujemy jako dane, nigdy jako polecenie dla modelu.
Model nie nadaje żadnego statusu ani nie zmienia decyzji.
Nie wysyłamy do modelu sekretów ani całych repozytoriów bez Twojej wyraźnej zgody.

Odpowiedzialne ujawnianie

Jeśli w trakcie sprawdzenia znajdziemy problem w cudzym produkcie, informujemy najpierw jego dostawcę i dajemy czas na naprawę. Szczegóły techniczne nie trafiają do nikogo poza zleceniodawcą i dostawcą.

Jeśli znalazłaś problem w naszym systemie, opisz go na stronie zgłaszania podatności.