Co robimy.

Strukturalny wewnętrzny przegląd względem ustalonej listy kontrolnej, co kwartał, plus natychmiast po każdej nietrywialnej aktualizacji zależności lub zmianie powierzchni uwierzytelniania. Lista podąża za ramami OWASP ASVS Level 2 + OWASP API Security Top 10 — nie roszczemy sobie certyfikacji, ale stosujemy pytania frameworka dosłownie tam, gdzie to użyteczne. Każdy przebieg produkuje datowany raport commitowany do repozytorium, poparty ścieżkami plików i plikami testów; ustalenia są albo naprawiane w referencjonowanym commicie, albo akceptowane jako ryzyko rezydualne z uzasadnieniem.

  • Główna lista kontrolna — osiem obszarów: uwierzytelnianie i sesja, publiczny widok + endpoint JSON-LD, ścieżki zapisu w panelu, magazyn, własne domeny, zależności, sekrety, logowanie i monitorowanie.
  • Kwartalny przegląd — każdy wiersz poparty w pliku ścieżkami i plikami testów; pass / częściowy / błąd na wiersz. Ustalenia naprawiane w referencjonowanym commicie lub akceptowane jako ryzyko rezydualne z wyraźnym uzasadnieniem.
  • Higiena zależności — pip-audit przy każdym przebiegu. Przypięty requirements.txt bez zakresów wersji; aktualizacje są celowe i przetestowane.

Kontrole nośne.

Konkretne, weryfikowalne stwierdzenia — każde to właściwość kodu lub konfiguracji, którą recenzent może sprawdzić.

  • Szyfrowane w tranzycie. TLS na każdej publicznej powierzchni (qrregistry.io, qrregistry.eu, viewery na własnych domenach) przez Caddy z wystawianiem certyfikatów na żądanie. Cookie sesyjne to HttpOnly + Secure + SameSite=Lax.
  • Szyfrowane w spoczynku. PostgreSQL + MinIO na sprzęcie UE z szyfrowaniem dysku.
  • Bez haseł. Tylko magic-link. Surowy token to ~256 bitów entropii CSPRNG, wygasa w 15 minut i jest konsumowany przy pierwszym użyciu; baza danych przechowuje tylko hash SHA-256, więc samo odczytanie bazy nie zaloguje nikogo.
  • Zróżnicowane uwierzytelnianie odbiorców. Poświadczenia audytora / recyklera / naprawcy / jednostki notyfikowanej to krótkotrwałe JWT odwoływalne z jednej konsoli administracyjnej; odwołanie obowiązuje od następnego żądania, nie od wygaśnięcia JWT.
  • Ścieżki zapisu ze sprawdzeniem własności. Każdy zapis na paszportach, atestach, domenach i zasobach jest serwerowo strzeżony przez row.user_id == user.id. Wiersze innych użytkowników zwracają 404 zamiast 403 — nie ujawniamy istnienia.
  • Filtr Restricted-tier. Pojedyncza funkcja (strip_to_visible) rządzi każdą powierzchnią paszportu — viewer HTML, endpoint JSON-LD, feed audytu, PDF. Żadne pole nie może wyciec przez jedną gałąź, gdy inne je ukrywają.
  • Łańcuch audytu append-only. Każdy zapis zapisuje wiersz passport_revisions z hash_before / hash_after / strukturalnym diffem. DELETE /dashboard/passports/{id} zwraca bezwarunkowo 403 — artykuł 10(4) trwałość dożywotnia.
  • Allowlist własnych domen. Endpoint „ask” TLS na żądanie Caddy jest powiązany z loopbackiem i konsultuje tabelę zweryfikowanych domen; tylko zweryfikowane i zaprovisionowane hostnames otrzymują certyfikat. Niezmiennik pojedynczego roszczenia — hostname może należeć tylko do jednego właściciela.
  • Dyscyplina sekretów. Brak sekretów w kodzie źródłowym. .env to jedyny inwentarz; zmienne na usługę (baza, Stripe, Resend, MinIO) są niezależne.
  • Analityka szanująca prywatność. Zdarzenia skanowania rejestrują kod kraju ISO (wyprowadzony z nagłówka, nigdy surowe IP) i zgrubną klasę urządzenia — nigdy plik cookie śledzenia, nigdy tożsamość poświadczenia. Udokumentowane i widoczne pod /privacy.

Czego wyraźnie nie robimy.

Nie płacimy za zewnętrzny test penetracyjny, dopóki bramka zakupowa klienta nie uczyni tego uzasadnionym kosztem. Artykuł 11(h) ESPR nie definiuje ścieżki certyfikacji ani nie wymaga testów stron trzecich; zlecenie warte 15-30 tys. € kupuje wiarygodność, ale żadnego regulacyjnego <code>✅</code>, a datowany przegląd wewnętrzny dokumentuje te same dowody niższym kosztem, dopóki firma jest mała.

Nie roszczemy certyfikacji SOC 2 ani ISO 27001. Postawa naszego dostawcy infrastruktury stoi za linią stopki <em>„ISO 27001 aligned”</em>; certyfikacja należy do nich, nie do Contenza K/S.

Nie udajemy, że czysty przegląd to brak ustaleń. Przegląd z 2026-04-30 wskazuje pięć wierszy 🟡 częściowo — cztery to CVE zależności z dostępnymi wersjami naprawczymi śledzonymi jako kolejny bump, a jeden to odłożone ograniczenie szybkości na poziomie aplikacji. Uczciwość jest bardziej użyteczna niż aspiracja.

Co możecie przeczytać.

  • Główna lista znajduje się w docs/security-review-checklist.md w repozytorium źródłowym — każdy wiersz to pytanie, na które kolejny przegląd musi odpowiedzieć dowodami.
  • Każdy datowany przegląd znajduje się w docs/security-review-{YYYY-MM-DD}.md — ścieżki plików, pliki testów i ustalenia, w pliku. Historia git pokazuje, co zmieniło się między przebiegami.
  • Każde publiczne stwierdzenie na tej stronie odnosi się do wiersza w najnowszym przeglądzie.

Zgłaszanie podatności.

Proszę napisać do zespołu ze szczegółami. Traktujemy zgłoszenia bezpieczeństwa priorytetowo i odpowiadamy w ciągu jednego dnia roboczego. Nie ma jeszcze formalnego programu bug bounty — w naszej skali uznaniem jest serdeczne podziękowanie i miejsce w changelogu.

Pytania dotyczące tej polityki? Skorzystajcie z formularza kontaktowego — lub napiszcie do zespołu, używając danych ze strony kontaktowej.