Błędne jest przekonanie, iż zamknięty kod jest bardziej bezpieczny niż kod open source – co pokazują przykłady licznych incydentów. Hakerzy nie potrzebują dostępu do kodu oprogramowania, aby zrozumieć jego działanie. Poprzez testowanie metodą prób i błędów są w stanie znaleźć słabość, podatność aplikacji na różnego rodzaju defekty, które nie zostały rozpoznane w procesie powstawania aplikacji. Dodatkowo do ujawnienia lub wycieku kodu systemu może dojść wskutek cyberataku na serwery dewelopera lub jednego z jego partnerów (supply-chain attack). Brak kodu open source nie sprawi, iż nie usłyszymy o incydentach różnego rodzaju podatności i luk w oprogramowaniu.
Rozwiązania open source budzą większe społeczne zaufanie niż oprogramowanie z niejawnym kodem. Za przykład weźmy komunikatory Singnal, Threema, Briar, Element, Matrix i inne. Ich deweloperzy w różny sposób udostępniają kod (lub część kodu) i sami używają bibliotek programistycznych open source, frameworków, różnych protokołów, które są niezbędne do prawidłowego funkcjonowania oprogramowania. Podobnie jest z platformą social media open source, taką jak Mastodon, która pozbawiona jest wad Facebooka, Instagrama i im podobnych.
Można postawić tezę, iż kod open source sprawia, iż oprogramowanie może być lepiej kontrolowane, na większą skalę, dlatego wzbudza większe zaufanie, podobnie jak pochodzenie kodu (kraj, gdzie powstaje) niż alternatywne oprogramowanie o zamkniętym kodzie tego samego typu lub oprogramowanie podobnie funkcjonujące.
Szwajcaria idzie w open source
To wprowadzenie musiało się pojawić jako wstęp do szwajcarskiej ustawy, która 1 stycznia 2024 r. została umocowana w prawie.
Zmierzanie Szwajcarii w open source to rok jeszcze 2011. Historię wdrożenia i korzystania z publicznego kodu przez agencje rządowe Szwajcarii wyjaśnia ten materiał wideo.
W roku ubiegłym (2023) szwajcarski parlament przyjął ustawę EMBAG (tłum.: „o wykorzystaniu środków elektronicznych do wykonywania zadań urzędowych”, tutaj link), która w art. 9. na temat open source nakłada obowiązek na instytucje rządowe publikowania używanego kodu open systemu np. na GitHub na odpowiedniej licencji (do ponownego użycia), o ile nie stoi to w sprzeczności z bezpieczeństwem publicznym. Dodatkowo art. 10 nakłada też prawo publikowania danych nieosobowych, niemających charakteru wrażliwego, które można wykorzystać do testowania różnego rodzaju rządowych i publicznych aplikacji, systemu itp.
Obowiązek nie wymaga ujawniania całego kodu oprogramowania, ale fragmentów kodu źródłowego, który został dla agencji rządowych opracowany przez strony trzecie, lub jeżeli dana instytucja rządowa/kantonu we własnym zakresie opracowała kod, który jest wykorzystywany do celów publicznych. Takie podejście sprawia, iż cokolwiek zostanie „wyprodukowane” dla agencji rządowych lub przez agencje rządowe musi być dostępne dla społeczeństwa do wglądu. Przy czym niektórzy eksperci zwracają uwagę, iż to, w jakim stopniu ustawa zostanie wdrożona, pozostaje w rękach konkretnego kantonu (województwa).
„Publiczne pieniądze, publiczny kod” – warto przyklasnąć polityce, która zwiększa transparentność.
Unia Europejska zmienia zdanie co do open source
W roku 2014 została zapoczątkowana piękna inicjatywa Audytu Wolnego i Otwartego systemu (FOSSA, Free and Open Source Software Audit) przez Julię Reda z Partii Piratów. Julia sama wtedy komentowała, iż Parlament Europejski, Rada i Komisja Europejska opierają się na oprogramowaniu, takim jak Drupal, aby zarządzać stronami internetowymi.
Projekt okazał się sukcesem i został gwałtownie odnowiony na kolejne 3 lata do roku 2017. Następnie ponownie wznowiono finansowanie w ramach programów bug bounty, organizowania hackatonów i konferencji. Udało się m.in. znaleźć 20-letnią lukę w Putty, znaleziono 70 podatności w innych aplikacjach, zgłoszono ponad 600 bugów i innych drobnych błędów, wypłacono ponad 200 tys. euro nagród. Projekt „FOSSA 2” dysponował zaledwie 2 milionowym (euro) budżetem, więc był ogromnie niedoszacowany. Pomimo tego udało się wiele dobrego zrobić dla społeczności i systemu open source.
W 2020 r. projekt FOSSA 2 nie otrzymał kolejnego finansowania na kolejne lata. Wygląda na to, iż środki publiczne nie są warte, by inwestować w open source w takim zakresie. Projekt upadł.
W roku 2023 pojawił się nowy projekt FOSSEPS, co też zostało opisane na polskiej stronie rządowej. FOSSEPS (Free Open Source Solutions for European Public Services) ma trochę inne zadanie – podobnie jak w Szwajcarii rozpatrywane jest bezpieczeństwo instytucji unijnych poprzez audytowanie, sprawdzenie, testowanie systemu open source używanego do realizacji celów unijnych. W założeniach projektu czytamy (PDF), iż powstanie publiczny katalog rozwiązań open source dla instytucji rządowych i rozpocznie się kooperacja z podmiotami prywatnymi na rzecz zwiększenia cyberbezpieczeństwa. Na razie jest to pieśń przyszłości.
Polska ≠ open source
W Polsce przez cały czas nie doczekaliśmy się, aby mObywatel był open source i wygląda na to, iż się to nie stanie, ponieważ kod miał być dostępny publicznie od 14 lipca 2024 r., jednak rząd przepchnął poprawki do ustawy w innej ustawie – o pomocy obywatelom z Ukrainy – podaje cyberdefence24.pl.
Teoretycznie wprowadzone zmiany są na plus, ponieważ rząd będzie czekał na decyzję kompetentnych i podległych mu podmiotów, takich jak CSIRT GOV, CSIRT MON i CSIRT NASK w zakresie udostępnienia kodu aplikacji, jeżeli nie będzie to zagrażało bezpieczeństwu użytkownikom aplikacji. Taki zapis, w założeniach słuszny, jest jednak nieprecyzyjny, ponieważ decyzję o udostępnieniu kodu można odwlekać w nieskończoność, argumentując to nieodpowiednimi zabezpieczeniami.
W Polsce wiele agencji rządowych i podległych im resortów korzysta z systemu open source w ten lub w inny sposób: na stronach internetowych, w aplikacjach wewnętrznych. To, na ile korzystają one z open source, może być zawiłe z perspektywy technicznej oraz prawnej, licencyjnej. Już niedługo opublikujemy dodatkowy materiał na temat bezpieczeństwa polskich publicznych jednostek, które korzystają z open source.