Czy oprogramowanie open source jest bezpieczne?

Tytuł trochę przewrotny, zwłaszcza jak na serwis, który zwraca uwagę na błędy w aplikacjach, tytułując posty wedle schematu „łatajcie to”, „łatajcie tamto”. Wiadomo, iż nie ma bezpiecznego oprogramowania, a cyberbezpieczeństwo wymaga ciągłej czujności i obserwowania nowych wydań. Niemniej kiedy mamy jednego producenta, łatwiej dookreślić zakres odpowiedzialności niż w przypadku, kiedy nad aplikacją pracuje cała społeczność. A jednak – trudne nie znaczy niemożliwe.

W marcu amerykańska agencja ds. cyberbezpieczeństwa CISA określiła najważniejsze działania mające na celu zabezpieczenie systemu typu open source (OSS). Odbył się dwudniowy szczyt dotyczący bezpieczeństwa OSS, podczas którego dyskutowano z liderami społeczności.

Kroki, które CISA podejmie we współpracy ze społecznością open source, obejmują promowanie zasad bezpieczeństwa repozytoriów pakietów, ramy określające poziomy dojrzałości zabezpieczeń oraz nowe wysiłki mające na celu umożliwienie współpracy i wymiany informacji z operatorami infrastruktury systemu OSS.

Ponadto CISA opublikuje materiały z praktycznymi ćwiczeniami przeprowadzonymi na szczycie, aby społeczność open source mogła wykorzystać zdobyte doświadczenie do poprawy reagowania na zagrożenia i incydenty.

Poniżej kilka przykładów, jak społeczności podejmują próby podniesienia poziomu zabezpieczeń:

Fundacja Rust opublikowała model zagrożeń dla repozytorium pakietów Crates.io i zbudowała narzędzia do wykrywania złośliwej aktywności. Wdroży też infrastrukturę klucza publicznego dla Crates.io.

Python Software Foundation doda do PyPI więcej dostawców w celu publikowania bez poświadczeń, w tym GitLab, Google Cloud i ActiveState. Planowane jest również utworzenie interfejsu API i powiązanych narzędzi do raportowania i reagowania na złośliwe oprogramowanie, a PEP 740 (obsługa indeksu dla atestów cyfrowych) jest prawie ukończony, umożliwiając korzystanie z cyfrowo podpisanych atestów i metadanych dla repozytoriów pakietów Pythona.

Po wdrożeniu skanowania baz danych pod kątem podatności i zabezpieczeń przed nieautoryzowanym przejęciem pakietów, Packagist i Composer będą również pracować nad poprawą bezpieczeństwa zgodnie z zasadami dotyczącymi bezpieczeństwa repozytorium pakietów i planować dokładny audyt bezpieczeństwa istniejących baz kodów.

Uwierzytelnianie wieloskładnikowe jest w tej chwili wymagane od opiekunów projektów, którzy mają również dostępne nowe narzędzia do automatycznego generowania SBOM, czyli kompleksowego, uporządkowanego spisu wszystkich komponentów, bibliotek i zależności używanych w oprogramowaniu lub aplikacji. zwykle zawiera on informacje o nazwach, wersjach i szczegółach licencjonowania każdego komponentu. Dzięki temu konsumenci mogą śledzić i weryfikować zależności w procesie wytwórczym.

Maven Central, największe repozytorium pakietów językowych Java i JVM, obsługiwane przez Sonatype, przechodzi na nowy portal wydawniczy, który poprawi bezpieczeństwo repozytorium i będzie obsługiwał uwierzytelnianie wieloskładnikowe.

Wspierając od lat skanowanie podatności na zagrożenia, Maven Central planuje dodatkowe ulepszenia, w tym kontrolę dostępu do przestrzeni nazw, ocenę Trusted Publishing i wdrożenie Sigstore, a także porówna swoje procesy bezpieczeństwa z najlepszymi praktykami.

Te przykłady pokazują, jak istotne staje się bezpieczeństwo w przypadku tworzenia oprogramowania, jak bardzo trzeba zwracać uwagę na proces wytwórczy i jak od początku projektować środowiska, zakładając higienę produkcji.