Ujawnienie kodu źródłowego mObywatel: Prawdziwa transparentność czy PR-owa iluzja?

Ujawnienie kodu źródłowego mObywatel: Prawdziwa transparentność czy PR-owa iluzja?

Pod koniec grudnia 2025 roku, polska sfera cyfrowa żyła jednym tematem: długo wyczekiwanym ujawnieniem kodu źródłowego aplikacji mObywatel. To wydarzenie, zapowiadane jako historyczny krok w kierunku transparentności administracji publicznej, miało odpowiedzieć na lata apeli ekspertów i spełnić ustawowy obowiązek. Jednak zamiast pełnego otwarcia i możliwości dogłębnej analizy, społeczność otrzymała coś, co wielu określiło mianem iluzji – starannie wyselekcjonowane fragmenty kodu, podane w formie uniemożliwiającej realną weryfikację.

Dla liderów biznesu, CISO i menedżerów IT, ta sytuacja to znacznie więcej niż tylko techniczna ciekawostka. To studium przypadku, które obnaża fundamentalne napięcie między deklaracjami o bezpieczeństwie a rzeczywistymi praktykami. W świecie, gdzie aplikacje mobilne są krwiobiegiem operacji biznesowych i przechowują najcenniejsze dane, historia mObywatela stawia kluczowe pytania: Czym jest prawdziwa transparentność w oprogramowaniu? Jakie ryzyka niesie za sobą strategia “bezpieczeństwa przez tajność”? I co najważniejsze – jakie lekcje możemy wyciągnąć, aby chronić nasze własne zasoby cyfrowe? W tym artykule przeprowadzimy dogłębną analizę faktów, mitów i konsekwencji związanych z publikacją kodu mObywatela, dostarczając praktycznych wniosków dla każdego, kto odpowiada za cyberbezpieczeństwo w Polsce.

Obowiązek ustawowy a zderzenie z rzeczywistością

Droga do publikacji kodu źródłowego mObywatela była długa i wyboista. Zobowiązanie zostało nałożone przez Ustawę o aplikacji mObywatel z 26 maja 2023 roku, która weszła w życie 14 lipca 2023 roku. Zgodnie z jej pierwotnym brzmieniem, kod miał zostać opublikowany w Biuletynie Informacji Publicznej Ministerstwa Cyfryzacji najpóźniej do połowy lipca 2024 roku, co było zgodne z postulatami środowisk dbających o cyfrowe prawa obywateli.

Jednak kluczowa zmiana nastąpiła wraz z nowelizacją przepisów, która wprowadziła nowy warunek: publikacja mogła nastąpić dopiero po uzyskaniu opinii od kluczowych zespołów reagowania na incydenty – CSIRT GOV (działającego w strukturach ABW), CSIRT MON oraz CSIRT NASK. Jak donosiły media, opinie te miały zagwarantować, że ujawnienie kodu „nie zagraża bezpieczeństwu tej aplikacji oraz jej użytkowników” Źródło. W praktyce zapis ten dał organom państwowym potężne narzędzie do decydowania, które fragmenty kodu i w jaki sposób zostaną pokazane światu.

Kulminacją oczekiwań i narastającego zamieszania komunikacyjnego był listopad 2025 roku. Polska Agencja Prasowa początkowo ogłosiła, że „kod źródłowy aplikacji mObywatel zostanie w całości opublikowany 29 grudnia 2025 roku”. Ta obietnica wywołała entuzjazm, sugerując pełne otwarcie. Radość była jednak przedwczesna. Kilka dni później wiceminister cyfryzacji Dariusz Standerski sprostował te doniesienia, precyzując, że opublikowane zostaną jedynie fragmenty kodu, zgodnie z rekomendacjami CSIRT-ów.

29 grudnia 2025 roku stało się jasne, co to oznacza w praktyce. Opublikowano wyłącznie kod odpowiedzialny za interfejs użytkownika (UI) – warstwę wizualną aplikacji napisaną w języku Swift (dla iOS) oraz Kotlin (dla Androida). Ministerstwo Cyfryzacji w oficjalnym komunikacie stwierdziło, że udostępniony materiał „prezentuje filozofię oraz strukturę kodowania aplikacji”. Zabrakło jednak tego, co stanowi serce każdego systemu:

• Logiki biznesowej aplikacji
• Mechanizmów bezpieczeństwa i szyfrowania
• Sposobów komunikacji z systemami backendowymi
• Integracji z rejestrami państwowymi

Jak trafnie zauważyli eksperci techniczni na platformie Reddit, „udostępnili kod jakichś komponentów UI. (…) Na pierwszy rzut oka nie ma kodu jakiejkolwiek logiki”. Ministerstwo samo przyznało, że nieopublikowane części „mogą zawierać funkcje o kluczowym znaczeniu z punktu widzenia bezpieczeństwa aplikacji” CyberDefence24.pl. To jawne przyznanie się do ukrycia elementów, których analiza byłaby najbardziej wartościowa z perspektywy niezależnego audytu bezpieczeństwa kodu.

“Patrz, ale nie dotykaj”: Techniczne bariery w dostępie do kodu

Diabeł, jak zwykle, tkwi w szczegółach. Sposób, w jaki udostępniono nawet te ograniczone fragmenty kodu, skutecznie uniemożliwia jakąkolwiek pogłębioną i efektywną analizę. Zamiast standardowej praktyki, jaką jest publikacja w publicznym repozytorium (np. na GitHubie), stworzono system pełen barier.

Po pierwsze, dostęp wymaga silnego uwierzytelnienia za pomocą Profilu Zaufanego, e-Dowodu lub bankowości elektronicznej. Jak informuje CyberDefence24.pl, wymóg ten wynikał bezpośrednio z rekomendacji CSIRT MON, który nalegał na zapewnienie „pełnej rozliczalności użytkowników”. Oznacza to, że każda osoba przeglądająca kod jest w pełni zidentyfikowana i jej dostęp jest rejestrowany.

Po drugie, dostęp został ograniczony wyłącznie do obywateli Rzeczypospolitej Polskiej. Ta decyzja zamyka drzwi przed międzynarodową społecznością badaczy bezpieczeństwa, która odgrywa kluczową rolę w identyfikowaniu podatności w globalnych projektach typu open source.

Po trzecie, i być może najważniejsze, kod został zaprezentowany w formie statycznej strony HTML, działającej jak przeglądarka plików “tylko do odczytu”. Użytkownicy nie mogą:

• Pobrać kodu w postaci plików czy archiwum
• Skopiować fragmentów kodu do schowka
• Nawet zaznaczyć tekstu na stronie

Te ograniczenia sprawiają, że profesjonalna analiza jest praktycznie niewykonalna. Nowoczesny audyt bezpieczeństwa kodu opiera się na specjalistycznych narzędziach do analizy statycznej (SAST), które automatycznie przeszukują tysiące linii kodu w poszukiwaniu znanych wzorców podatności. Bez możliwości pobrania plików i uruchomienia ich w środowisku deweloperskim, badacze są skazani na żmudne, ręczne przeglądanie kodu linijka po linijce na ekranie przeglądarki. To skutecznie zniechęca do jakichkolwiek poważnych prób weryfikacji.

Wisienką na torcie jest paradoks licencyjny. Kod opublikowano na licencji MIT – jednej z najbardziej liberalnych licencji open source, która pozwala na niemal dowolne używanie, kopiowanie, modyfikowanie i redystrybucję kodu CyberDefence24.pl. W teorii, ktoś mógłby ręcznie przepisać cały udostępniony kod i legalnie opublikować go na GitHubie, omijając rządowe restrykcje. W praktyce jest to jednak zadanie tak pracochłonne, że stanowi kolejną, skuteczną barierę.

Bezpieczeństwo przez tajność? Debata o “Security by Obscurity”

Decyzja o ukryciu kluczowych z perspektywy bezpieczeństwa fragmentów kodu jest podręcznikowym przykładem podejścia znanego jako security by obscurity (bezpieczeństwo przez tajność). To filozofia opierająca się na przekonaniu, że system jest bezpieczny, dopóki jego wewnętrzne działanie pozostaje tajemnicą dla potencjalnych atakujących. Współczesna inżynieria oprogramowania i eksperci od cyberbezpieczeństwa od dawna uznają tę strategię za błędną i niebezpieczną.

Głównym argumentem przeciwko security by obscurity jest fakt, że tajność jest krucha. Zdeterminowany atakujący – czy to z zewnątrz, czy wewnątrz organizacji – w końcu znajdzie sposób, aby poznać ukryte mechanizmy. Gdy to nastąpi, brak zewnętrznych audytów i recenzji kodu sprawia, że system jest bezbronny, a istniejące luki pozostają niezałatane przez lata.

Podejście otwarte, którego orędownikiem jest społeczność open source, opiera się na przeciwstawnym założeniu: „wiele oczu sprawia, że wszystkie błędy stają się płytkie” (zasada Linusa). Publiczna dostępność kodu pozwala niezależnym ekspertom z całego świata na jego analizę, znajdowanie słabości i zgłaszanie ich twórcom. To proces, który, choć bywa niewygodny, w długiej perspektywie prowadzi do znacznie solidniejszego i bezpieczniejszego oprogramowania.

Doskonałym przykładem kontrastującego podejścia jest ukraińska aplikacja Diia – odpowiednik mObywatela. Jak zauważa Spider’s Web, Ukraina zdecydowała się na pełne otwarcie kodu swojej aplikacji. Ta transparentność nie tylko zbudowała zaufanie obywateli i ekspertów, ale także przekształciła Diia w produkt eksportowy, wdrażany obecnie m.in. w Estonii i testowany w krajach Afryki i Ameryki Łacińskiej. Oskar Klimczuk, ekspert ds. cyberbezpieczeństwa, wprost rekomendował, aby Polska poszła za przykładem Ukrainy, co pozwoliłoby oprzeć bezpieczeństwo aplikacji mobilnych nie tylko na zapewnieniach rządu, ale także na weryfikacji niezależnych specjalistów.

Praktyczne zagrożenia i konsekwencje dla biznesu

Pozorna debata o modelu publikacji kodu ma bardzo realne konsekwencje dla bezpieczeństwa ponad 11 milionów Polaków i działających w Polsce firm.

Po pierwsze, brak transparentności podważa zaufanie publiczne, co stwarza idealne warunki dla cyberprzestępców. Ministerstwo Cyfryzacji samo ostrzegało przed kampaniami phishingowymi, w których oszuści, podszywając się pod markę aplikacji, promowali fałszywą wersję „mObywatel 3.0”, obiecując możliwość zarabiania pieniędzy Gov.pl, Focus.pl. W rzeczywistości celem była kradzież danych osobowych i nakłanianie ofiar do przelewania oszczędności na konta przestępców. Kiedy obywatele nie mogą ufać oficjalnym komunikatom i nie mają pewności co do bezpieczeństwa aplikacji, stają się znacznie bardziej podatni na ataki oparte na inżynierii społecznej.

Po drugie, ukrywanie kodu nie gwarantuje braku fundamentalnych wad projektowych. Badacze bezpieczeństwa już wskazali na potencjalnie poważną lukę w procedurze wykorzystania mObywatela do identyfikacji wyborców. Jak wykazano, ponieważ weryfikacja odbywa się na smartfonie wyborcy – urządzeniu, nad którym ma on pełną kontrolę – możliwe jest przygotowanie fałszywej aplikacji, która wyświetli podrobiony ekran z danymi innej osoby, umożliwiając oszustwo wyborcze. Ta podatność istnieje niezależnie od tego, czy kod jest tajny, czy nie, i pokazuje, że zamknięty proces tworzenia oprogramowania może prowadzić do przeoczenia kluczowych ryzyk.

Dla firm konsekwencje są dwojakie. Z jednej strony, pracownicy korzystający z potencjalnie niezweryfikowanej aplikacji rządowej do przechowywania swoich najważniejszych dokumentów stanowią wektor ryzyka. Skompromitowanie ich tożsamości cyfrowej może mieć przełożenie na bezpieczeństwo firmowych systemów. Z drugiej strony, niska świadomość i podatność na phishing związany z mObywatelem może być łatwo przeniesiona na grunt firmowy, gdzie celem staną się dane korporacyjne. Stawką jest więc nie tylko prywatność, ale także realna ochrona danych osobowych w kontekście biznesowym.

Wnioski dla liderów biznesu: Jak nawigować w nowej rzeczywistości?

Historia mObywatela to cenna lekcja dla każdego, kto zarządza technologią i bezpieczeństwem w organizacji. Oto cztery kluczowe wnioski:

1. Podchodź krytycznie do oficjalnych deklaracji. Rządowe komunikaty o „pełnym bezpieczeństwie” i „transparentności” nie zawsze odzwierciedlają stan faktyczny. Zaufanie powinno być budowane na weryfikowalnych dowodach, a nie na zapewnieniach. Podobnie należy oceniać dostawców oprogramowania dla własnej firmy – żądaj dowodów bezpieczeństwa w postaci raportów z niezależnych testów.
2. Wykorzystaj ten przypadek do edukacji pracowników. Trwająca kampania phishingowa związana z mObywatelem to doskonały, aktualny przykład do wykorzystania w wewnętrznych szkoleniach z security awareness. Pokaż pracownikom, jak działają oszuści i jak ważna jest zasada ograniczonego zaufania, zarówno w życiu prywatnym, jak i zawodowym.
3. Zadaj sobie pytanie o własne aplikacje. Czy krytyczne systemy w Twojej firmie są bezpieczne, bo ich kod jest tajny? Czy opierasz się na wierze w kompetencje deweloperów? Sprawa mObywatela to idealny moment, aby zainicjować przegląd własnego podejścia do cyklu życia oprogramowania (SDLC) i upewnić się, że bezpieczeństwo jest jego integralną częścią, a nie tylko dodatkiem.
4. Inwestuj w niezależną weryfikację. Najważniejsza lekcja płynąca z tej historii jest taka, że wewnętrzne zapewnienia i ograniczone audyty to za mało. Prawdziwą odporność i zaufanie buduje się poprzez poddanie swoich systemów rygorystycznym, niezależnym testom. Regularne testy penetracyjne aplikacji oraz dogłębny audyt bezpieczeństwa kodu przeprowadzony przez zewnętrznych ekspertów to dziś nie luksus, a konieczność. Tylko w ten sposób można zidentyfikować luki, których nie widzą wewnętrzne zespoły.

Jak możemy pomóc?

Sprawa mObywatela dowodzi, że w dzisiejszym krajobrazie cyfrowym pozory mogą mylić, a prawdziwe bezpieczeństwo wymaga głębokiej wiedzy i bezkompromisowej weryfikacji. W VIPentest od lat pomagamy polskim firmom budować realną odporność cyfrową, opartą na faktach, a nie na założeniach.

Jeśli chcesz mieć pewność, że Twoje aplikacje mobilne i webowe nie powielają błędów security by obscurity i są solidnie zabezpieczone przed realnymi zagrożeniami, nasz zespół ekspertów jest do Twojej dyspozycji. Specjalizujemy się w zaawansowanych testach penetracyjnych i audytach kodu źródłowego, które dają pewność i spokój ducha.

Skontaktuj się z nami, aby omówić, jak możemy wzmocnić bezpieczeństwo Twojej organizacji. Odwiedź: VIPentest Kontakt

FAQ