k0nsult.cloud / ai-truth / ipIII / disclosure (CVD)

Coordinated Vulnerability Disclosure Policy

Polityka skoordynowanego ujawniania podatności (CVD) K0NSULT. To pierwsza rzecz, którą sprawdza rzetelny badacz bezpieczeństwa, oceniając powagę organizacji: czy jest dokąd zgłosić, czy działanie w dobrej wierze jest chronione, i co jest w zakresie. Zgodnie z ISO/IEC 29147 (ujawnianie) i ISO/IEC 30111 (obsługa podatności).

Disclosure (CVD) Bug bounty Threat intel Global ← ipIII hub

Zgłoś w dobrej wierze — nie ścigamy. Damy potwierdzenie w 72h.

Autoryzujemy testy bezpieczeństwa w granicach tej polityki i zobowiązujemy się do działania w dobrej wierze wobec badaczy, którzy działają w dobrej wierze wobec nas. Ta polityka jest realnym zobowiązaniem organizacji LIVE, nie deklaracją marketingową.

CVD: ZGŁOSZENIE→ACK 72h→TRIAGE→NAPRAWA→WALIDACJA→UZNANIE→SKOORDYNOWANE UJAWNIENIE

Zakres testów. Ta polityka autoryzuje testy tylko w zakresie in-scope opisanym niżej i tylko metodami nieinwazyjnymi (brak DoS, brak eksfiltracji danych, brak niszczenia). Szersze lub głębsze testy (np. red team, testy autoryzowane na danych, load) wymagają odrębnych zasad zaangażowania (Rules of Engagement) i pisemnej zgody — patrz engagement / RoE. Nagrody finansowe: patrz bug bounty ROADMAP.

1 · Nasze zobowiązanie LIVE

Przyjmujemy zgłoszenia podatności od każdego badacza i traktujemy je poważnie. Zobowiązujemy się do:

Reakcji. Potwierdzenie przyjęcia zgłoszenia w ciągu 72 godzin roboczych.
Dobrej wiary. Nie podejmujemy kroków prawnych ani zgłoszeń do organów ścigania wobec badaczy działających zgodnie z tą polityką.
Transparentności. Informujemy zgłaszającego o statusie triage, decyzji i planowanym terminie naprawy.
Uznania. Za zgodą badacza publikujemy podziękowanie w hall of fame po naprawie (bug bounty / credit).
Skoordynowanego ujawnienia. Ustalamy termin publicznego ujawnienia wspólnie, zwykle po naprawie — domyślnie do 90 dni.

Evidence-first. Każda przyjęta podatność otrzymuje status dowodowy i jest zamykana wyłącznie po dowodzie naprawy (walidacja). Ta sama doktryna claim ≤ proof, która rządzi całym portalem ipIII, rządzi obsługą zgłoszeń.

2 · Safe Harbor — ochrona prawna badacza LIVE

Jeżeli działasz w dobrej wierze i w granicach tej polityki, uznajemy Twoje działania za autoryzowane. W szczególności:

Autoryzacja testu

Testy w zakresie in-scope, wykonane zgodnie z zasadami niżej, traktujemy jako dozwolone — nie jako nieuprawniony dostęp.

Bez ścigania

Nie zgłosimy Cię do organów ścigania ani nie wytoczymy powództwa cywilnego za działanie zgodne z polityką.

Dobra wiara

Jeśli przypadkowo przekroczysz zakres, ale niezwłocznie przerwiesz, zgłosisz i nie wykorzystasz dostępu — potraktujemy to jako działanie w dobrej wierze.

Współpraca prawna

Jeśli osoba trzecia podejmie wobec Ciebie kroki za działania zgodne z tą polityką, poinformujemy, że były autoryzowane.

Granice safe harbor. Ochrona nie obejmuje: naruszenia prywatności realnych użytkowników, niszczenia lub modyfikacji danych, przerwania usług (DoS), wymuszeń, ujawnienia podatności przed naprawą bez uzgodnienia, ani działań poza zakresem. Safe harbor nie uchyla praw osób trzecich ani bezwzględnie obowiązujących przepisów.

3 · Zakres SCOPE

In-scope TAK

• Aplikacja webowa k0nsult.cloud i jej publiczne poddomeny

• Publiczne API k0nsult.cloud/api/*

• Uwierzytelnianie, autoryzacja, kontrola dostępu (IDOR/BOLA)

• Wstrzyknięcia (SQLi, XSS, SSRF, wstrzyknięcie promptu do funkcji AI)

• Ujawnienie danych, błędna konfiguracja, ekspozycja sekretów

Out-of-scope NIE

• Ataki wolumetryczne / DoS / DDoS, stress i load testy

• Socjotechnika pracowników, phishing, vishing, pretexting

• Ataki fizyczne na biura, sprzęt, personel

• Testy na kontach / danych realnych użytkowników bez zgody

• Spam, automatyczne skanery generujące szum bez weryfikacji

• Podatności wyłącznie w zależnościach osób trzecich bez wpływu na nas

Zasada minimalnego wpływu. Jeśli test może naruszyć dostępność, integralność danych lub prywatność użytkowników — nie wykonuj go. Zatrzymaj się i zapytaj przez kanał kontaktowy.

4 · Jak zgłosić LIVE

Kanał kontaktowy jest publikowany w standardzie security.txt (RFC 9116):

# https://k0nsult.cloud/.well-known/security.txt
Contact: mailto:security@k0nsult.cloud
Policy: https://k0nsult.cloud/ai-truth/ipIII/disclosure
Preferred-Languages: pl, en
Canonical: https://k0nsult.cloud/.well-known/security.txt

Preferowany szablon zgłoszenia (im pełniej, tym szybszy triage):

Tytuł — jednozdaniowy opis (typ podatności + komponent).

Kroki reprodukcji — ponumerowane, deterministyczne, od zera do efektu.

Impact — co realnie umożliwia podatność (poufność / integralność / dostępność).

PoC — minimalny dowód: request/response, zrzut, wideo. Bez pełnej eksploatacji, bez eksfiltracji.

CVSS — propozycja wektora i wyniku (v3.1/v4.0); my zweryfikujemy.

Kontakt + credit — jak Cię uznać (nick/imię/anonimowo).

5 · Nasze SLA LIVE

Zegary reakcji spójne z playbookiem podatności (severity → czas naprawy):

Faza	Cel czasowy	Priorytet
Potwierdzenie przyjęcia (ACK)	≤ 72 h robocze	wszystkie
Triage i wstępna klasyfikacja	≤ 5 dni roboczych	wszystkie
Naprawa krytyczna / aktywnie wykorzystywana (KEV)	24–48 h	P0
Naprawa wysoka	≤ 7 dni	P1
Naprawa średnia	≤ 30 dni	P2
Naprawa niska / hardening	≤ 90 dni	P3
Skoordynowane ujawnienie	uzgodnione, domyślnie ≤ 90 dni	wszystkie

Klasyfikacja severity wg wektora CVSS i faktycznej eksploatowalności. KEV = Known Exploited Vulnerability. Szczegóły procesu: playbook podatności.

6 · Zasady dla badacza RULES

Nie eksfiltruj

Nie pobieraj, nie kopiuj i nie przechowuj danych wykraczających poza minimum konieczne do udowodnienia podatności.

Nie niszcz

Nie modyfikuj, nie usuwaj i nie szyfruj danych. Nie zakłócaj dostępności usługi.

Minimalny PoC

Zatrzymaj się na dowodzie koncepcji. Nie eskaluj, nie pivotuj, nie utrwalaj dostępu.

Prywatność

Napotkane dane osobowe zgłoś i usuń natychmiast. Nie przeglądaj cudzych kont.

Poufność do naprawy

Nie ujawniaj publicznie przed naprawą i bez uzgodnienia terminu. Ujawnienie skoordynowane.

Jedno konto testowe

Testuj tylko na własnych kontach testowych. Zero payloadów ofensywnych na produkcji.

Powiązane zasoby

security.txt

/.well-known/security.txt — kanoniczny kanał kontaktu (RFC 9116).

Bug bounty ROADMAP

Uznanie i nagrody — hall of fame, kryteria, poziomy.

Playbook podatności

Proces obsługi — triage, severity, zegary naprawy (ISO 30111).

Threat intel

Wywiad o zagrożeniach — kontekst KEV/CVE dla priorytetyzacji.

Uczciwie o statusie. To jest polityka i zaproszenie. Zobowiązanie do przyjmowania zgłoszeń, safe harbor i SLA są LIVE — realne od chwili publikacji. Testy w zakresie in-scope są autoryzowane tą polityką; testy szersze, głębsze lub inwazyjne wymagają odrębnych zasad zaangażowania (RoE / engagement). Program nagród finansowych jest w przygotowaniu ROADMAP — uznanie (credit) jest dostępne od razu.

Zakres — in-scope / out-of-scope / zabronione

Obszar	Status
`k0nsult.cloud` — publiczne strony statyczne	in-scope (pasywne / low-impact)
`/ai-truth/ipIII/sentinel` i strony ćwiczeń	in-scope (tylko demo)
`/api/*`	out-of-scope (o ile nie zaproszono wprost)
Panele logowania / admin	out-of-scope
Dane produkcyjne / dane osób	out-of-scope
Usługi stron trzecich	out-of-scope
DoS / testy obciążeniowe	ZABRONIONE
Socjotechnika (pracownicy)	ZABRONIONE
Ataki fizyczne	ZABRONIONE
Eksfiltracja danych	ZABRONIONE
Naruszenie prywatności	ZABRONIONE

Safe harbor — warunkowo. Ochrona prawna dotyczy wyłącznie działań prowadzonych zgodnie z tą polityką: bez szkody, bez eksfiltracji, bez naruszenia prywatności i bez przekroczenia zakresu. Przekroczenie zakresu lub użycie technik zabronionych znosi safe harbor. Szersze testy — wyłącznie po podpisanym RoE.