Europejskie instytucje właśnie uświadomiły sobie skalę zależności od amerykańskich dostawców. Cytat z Brukseli oddaje sedno problemu: kluczowe systemy administracji – od poczty elektronicznej po narzędzia biurowe – opierają się na infrastrukturze Microsoftu, podatnej na decyzje geopolityczne lub regulacyjne zza oceanu. W odpowiedzi Komisja Europejska uruchomiła EU Open Source Solutions Catalogue, zawierający ponad 640 zweryfikowanych rozwiązań – od platform chmurowych jak Nextcloud, przez narzędzia biurowe LibreOffice i Collabora, po systemy komunikacji Matrix/Element. To nie jest tylko lista oprogramowania; to sygnał dla państw członkowskich, by budowały suwerenność cyfrową na otwartym kodzie.
Polska administracja wpisuje się w ten kierunek z pełną determinacją. Projekt Strategii Cyfryzacji Państwa jasno określa priorytety: szersze wykorzystanie programów open source w urzędach centralnych i lokalnych, utworzenie centralnego repozytorium koordynowanego przez wyznaczony podmiot rządowy, wsparcie techniczne i szkoleniowe przy wdrożeniach. Oznacza to konkretne zmiany na poziomie operacyjnym: stopniowe odchodzenie od pakietów Microsoft 365 i Exchange na rzecz kombinacji LibreOffice do edycji dokumentów, Nextcloud lub Collabora do współpracy zespołowej, Matrix/Element do komunikacji wewnętrznej oraz innych rozwiązań z unijnego katalogu. Dla przedsiębiorstw obsługujących administrację nie jest to odległa przyszłość – to już ewoluujący standard wymiany informacji i integracji systemowych.
Przykładem z sąsiednich struktur jest land Schleswig-Holstein, który jako jeden z pierwszych w Europie dokonał kompleksowej migracji. Zastąpił Outlook i Exchange platformą Open-Xchange oraz Thunderbirdem, wprowadził Matrix/Element do komunikacji i Nextcloud do współdzielenia plików. LibreOffice zagościło na większości stacji roboczych, choć system operacyjny Windows pozostał w użyciu ze względu na złożoność pełnej zmiany. Polska rzeczywistość będzie podobna, lecz wzbogacona o lokalne uwarunkowania: integrację z Rządową Chmurą Obliczeniową (RChO), usługi chmurowe zgodne z ustawą chmurową oraz nacisk na europejskie alternatywy dla globalnych chmur publicznych. Firmy IT, które dostarczają rozwiązania dla urzędów, muszą przygotować się na ten miks – od migracji danych po długoterminowe utrzymanie systemów bez centralnego wsparcia vendorów.
Tu pojawia się kontrariański punkt widzenia, który odróżnia perspektywę praktyka od branżowych dogmatów. Open source nie oznacza automatycznie „tańszego i bezpieczniejszego” – wręcz przeciwnie, przenosi ciężar odpowiedzialności za bezpieczeństwo, aktualizacje i zgodność licencyjną na użytkownika końcowego. Raport Synopsys „2024 Open Source Security and Risk Analysis” (OSSRA) analizuje tysiące codebase’ów komercyjnych aplikacji i wykazuje alarmujące statystyki: średnio ponad 500 komponentów open source na aplikację, 84 procent z co najmniej jedną znaną podatnością, 74 procent z lukami wysokiego ryzyka. Ponad połowa projektów miała konflikty licencyjne, co w kontekście kontraktów publicznych otwiera drzwi do sporów prawnych i kar regulacyjnych. Te dane nie pochodzą z teoretycznych symulacji – to analiza rzeczywistych środowisk produkcyjnych.
Dla firm współpracujących z administracją implikacje są bezpośrednie. Wyobraźmy sobie integrator dostarczający systemy do gminy przechodzącej z Microsoft 365 na Nextcloud i Collabora. Na poziomie podstawowym pojawiają się standardowe wymagania: przetwarzanie danych osobowych zgodne z RODO, rejestracja w Krajowym Systemie Cyberbezpieczeństwa (KSC), umowy powierzenia przetwarzania danych, precyzyjne SLA. Jednak prawdziwe ryzyko kryje się głębiej: w pluginach Collabory, dodatkach do LibreOffice czy skryptach migracyjnych znajdziesz łańcuchy zależności z repozytoriów NPM, Composer czy PyPI, których nikt nie zweryfikował pod kątem bezpieczeństwa. Jeśli twoja aplikacja zawiera bibliotekę z wysokim priorytetem CVE pozostawionym bez aktualizacji, odpowiedzialność spada nie tylko na urząd, ale i na dostawcę – nowelizacja KSC nie wybiera między sektorem prywatnym a publicznym.
Z perspektywy doświadczeń z incydentami, widziałem podobne scenariusze wielokrotnie. W jednym z projektów dla sektora publicznego self-hosted instancja GitLaba synchronizowała mirror z GitHubem popularnych bibliotek JavaScript. DevOps nie zmienił domyślnej konfiguracji „mirror every 30 minutes” i nie wymusił podpisanych tagów release’ów. W efekcie złośliwa wersja biblioteki z poprawnym numerem semver mogła automatycznie trafić do builda CI/CD. Rozwiązanie praktyczne? W pipeline ustaw „only: tags” z egzekwowaniem „protected tags” na mirrorze i blokadą automatycznego podbijania minor/patch bez ręcznego review. To techniczny detal, który decyduje o przetrwaniu w realnych operacjach – nie algorytmy, lecz konfiguracje.
Polskie instytucje dodają warstwę złożoności. NASK zapewnia ochronę przed atakami DDoS dla podmiotów publicznych, ale nie skanuje twoich zależności open source. Ministerstwo Cyfryzacji promuje repozytorium rozwiązań, Komisja europejski katalog, lecz za brak kontroli w łańcuchu dostaw odpowiada zarząd firmy. Branża uwielbia narrację o „suwerenności cyfrowej”, ignorując fakt, że prawdziwe zagrożenie płynie z niekontrolowanych bibliotek z GitHuba. ISACA podkreśla konieczność formalnej polityki „open source ingestion”: bez narzędzi do skanowania (Snyk, OWASP Dependency-Check, OpenSSF Scorecard) i procesów oceny ryzyka, zarządzanie staje się loterią.
Dodatkowym czynnikiem ryzyka jest centralizacja wokół GitHuba. Większość ekosystemów – JavaScript, Maven, Python – ciągnie zależności z tego źródła. Ten sam mechanizm „kill switch”, który niepokoi w kontekście Office 365, istnieje w pipeline’ach: sankcje eksportowe czy awarie geopolityczne mogą zablokować dostęp do registry.npmjs.org lub github.com. Dla firm zależnych od ciągłości dostaw aktualizacji bezpieczeństwa oznacza to przestój w deploymentach poprawek krytycznych. Jeśli twoje systemy dla urzędów nie mają alternatywnych mirrorów lub polityk offline builds, suwerenność jest iluzją.
Aspekt finansowy pogłębia problem. OSSRA wskazuje, że open source przenika niemal każdy produkt komercyjny, a wysoki odsetek podatności wpływa na wyceny przy transakcjach M&A. W polskim kontekście firma IT zarabiająca na kontraktach publicznych wygląda stabilnie z zewnątrz, lecz ukryte CVE i konflikty licencyjne stają się miną pod modelem biznesowym. Pierwszy incydent lub audyt inwestorski uruchamia efekt Rogów: jedna luka niszczy reputację latami budowaną poprzez referencje i kontrakty. KSC i regulacje chmurowe nie wybaczają – kary finansowe i utrata zaufania sektora publicznego to realne koszty.
W szerszym ujęciu organy takie jak ISACA, OWASP czy OpenSSF Scorecard dostarczają frameworki risk managementu dostosowane do open source. ISACA w swoich zaleceniach akcentuje politykę ingestion jako element dojrzałego governance: ocena aktywności projektu (ilość commitów, fork ratio), wiarygodności maintainerów (SBOM, PGP signing), historii CVE i zgodności licencji. Wdrożenie tego w średniej firmie wymaga integracji narzędzi z CI/CD i dashboardów dla zarządu – metryki typu „percentage of high-risk components” stają się KPI bezpieczeństwa na równi z przychodami.
Dla dostawców open source w Polsce kluczowi gracze to podmioty jak NASK (infrastruktura bezpieczeństwa), instytuty badawcze typu WAT (rozwój rozwiązań specjalistycznych) oraz komercyjni integratorzy specjalizujący się w self-hosted deploymentach (np. Nextcloud partners). Ministerstwo Cyfryzacji koordynuje repozytorium, lecz brakuje jeszcze mapy certyfikowanych dostawców. Firmy muszą same weryfikować track record partnerów – liczba wdrożeń w sektorze publicznym, compliance z KSC i doświadczenie w audytach OSS.
Plan działania
Krok 1: Przeprowadź pełny inwentaryzację komponentów open source we wszystkich aplikacjach kontaktujących się z administracją – OWASP Dependency-Check lub Snyk dostarczą raport z CVE, licencjami i ryzykiem.
Krok 2: Wdroż politykę „open source ingestion” na poziomie zarządu: obowiązkowa ocena każdej nowej biblioteki pod kątem aktywności, maintainerów, CVE i licencji przed akceptacją w repozytorium.
Krok 3: Zintegruj skanowanie z CI/CD – zero builda dla komponentów z high-risk CVE powyżej progu ryzyka; mirroruj kluczowe zależności poza GitHubem dla odporności na zakłócenia.
Krok 4: Uzgodnij z partnerami publicznymi (urzędy, NASK) zakres odpowiedzialności za OSS w łańcuchu – kto skanuje pluginy Nextcloud, kto aktualizuje LibreOffice.
Krok 5: Monitoruj zmiany regulacyjne – nowelizacja KSC i unijne katalogi definiują nowe standardy compliance dla integratorów.
