Full disclosure (z ang. całkowita jawność) – pogląd, funkcjonujący wśród wielu hakerów zajmujących się zabezpieczeniami, zgodnie z którym opinia publiczna powinna poznawać wszystkie szczegóły dotyczące nowo odkrytych błędów zabezpieczeń w systemach teleinformatycznych. Jest to odwrotność doktryny security through obscurity.
Full disclosure to podejście kontrowersyjne. Argumentacja przywoływana przez zwolenników mówi, że dzięki takiemu postępowaniu badaczy każdy użytkownik może poznać szczegóły dotyczące jakości oprogramowania danego producenta, samodzielnie chronić się przed atakami, a także ustalić, czy jego systemy są prawidłowo chronione. Publiczne ujawnianie szczegółów podatności ułatwia też programistom otwartego oprogramowania tworzenie nieodpłatnych systemów wykrywania ataków. Dodatkowo publiczna rozliczalność dostawców miałaby wywierać na nich silną presję, by tworzyli kod o wyższej jakości oraz szybko reagowali na problemy. Zdaniem ekspertów wiele firm, w tym Microsoft czy Oracle Corporation, wielokrotnie próbowało zatajać błędy, nie łatać usterek przez miesiące lub lata, czy wręcz grozić badaczom, którzy planowali powiadomić opinię publiczną o niedociągnięciach.
Kontrargumentem przeciw full disclosure jest przede wszystkim fakt, że w ten sposób wiedzę o błędach otrzymują także crackerzy i że w związku z tym z dużym prawdopodobieństwem zostanie ona wykorzystana do łamania zabezpieczeń, zanim wszyscy użytkownicy będą w stanie zabezpieczyć swoje systemy.
Mniej dyskusyjnym wariantem tego procesu jest responsible disclosure (odpowiedzialne ujawnianie), nazywane też skoordynowanym ujawnianiem podatności (ang. coordinated vulnerability disclosure, CVD). Polega ono na wcześniejszym powiadomieniu twórców oprogramowania i daniu im określonego czasu na usunięcie błędu oraz opublikowanie poprawek, zanim informacja o podatności zostanie podana do wiadomości publicznej. Proces ten opisuje norma ISO/IEC 29147. W praktyce przyjmuje się zwykle termin 90 dni od zgłoszenia do publikacji, choć bywa on różny w zależności od złożoności poprawki. Po upływie ustalonego terminu, niezależnie od reakcji dostawcy, dochodzi do publikacji informacji o błędzie. Taki sposób postępowania promują m.in. komercyjni dostawcy oprogramowania.
Wcześniejsze powiadomienie nie jest jednak warunkiem koniecznym procesu full disclosure, a zdaniem niektórych stoi z nim w sprzeczności. Jest bowiem korzystne dla użytkownika tylko wtedy, gdy przyjmie się, że błąd nie został nigdy wcześniej znaleziony i nie jest już, bez wiedzy opinii publicznej, wykorzystywany przez osoby o złych intencjach.
Dyrektywa NIS2 z 2022 roku zobowiązuje państwa członkowskie Unii Europejskiej do wyznaczenia jednego z zespołów CSIRT na koordynatora skoordynowanego ujawniania podatności. Działa on jako zaufany pośrednik między zgłaszającym podatność a producentem lub dostawcą produktu albo usługi, a zgłoszenia można dokonać anonimowo. Nakłada też na Agencję Unii Europejskiej ds. Cyberbezpieczeństwa (ENISA) obowiązek prowadzenia europejskiej bazy danych dotyczących podatności. ENISA uruchomiła tę bazę, nazwaną European Vulnerability Database (EUVD), w maju 2025 roku. Jest ona dostępna bezpłatnie dla wszystkich. W motywach dyrektywy wskazano, że państwa powinny w miarę możliwości dążyć do wyeliminowania problemów, z którymi mierzą się badacze podatności, w tym ich potencjalnego narażenia na odpowiedzialność karną.
W Polsce funkcję koordynatora pełni CSIRT NASK, któremu powierzyła ją nowelizacja ustawy o krajowym systemie cyberbezpieczeństwa, obowiązująca od 3 kwietnia 2026 roku (art. 26a).
Przepisy karne dotyczące testowania zabezpieczeń zmieniono w 2017 roku. Zgodnie z art. 269c Kodeksu karnego nie podlega karze za uzyskanie dostępu do systemu informatycznego (art. 267 § 2) ani za zakłócenie jego pracy (art. 269a), kto działa wyłącznie w celu zabezpieczenia systemu albo opracowania metody takiego zabezpieczenia, niezwłocznie powiadomi dysponenta systemu o ujawnionych zagrożeniach, a jego działanie nie naruszy interesu publicznego lub prywatnego i nie wyrządzi szkody. Z kolei według art. 269b § 1a nie popełnia przestępstwa ten, kto wytwarza, pozyskuje lub udostępnia narzędzia służące do popełniania przestępstw komputerowych wyłącznie w celu zabezpieczenia systemu albo opracowania metody takiego zabezpieczenia.
Według autorów analizy opublikowanej w 2026 roku przez NASK polskie przepisy, podobnie jak rozwiązania przyjęte w większości państw członkowskich, nie ustanawiają jednak wyraźnej „bezpiecznej przystani” (ang. safe harbour), chroniącej działającego w dobrej wierze badacza przed odpowiedzialnością prawną za czynności podjęte w toku identyfikacji podatności, co może zniechęcać do ich zgłaszania.