Eksplorowanie problemów firmowych ze składnikami oprogramowania typu open source

  • 8 min

Nowoczesne programowanie oprogramowania zasadniczo zależy od składników typu open source. Ta zależność wprowadza istotne obawy dotyczące organizacji tworzących oprogramowanie, zarówno w przypadku sprzedaży komercyjnej, użytku wewnętrznego, jak i usług publicznych. Chociaż open source zapewnia ogromne korzyści, organizacje muszą rozumieć powiązane zagrożenia i zarządzać nimi.

Podstawowe wyzwanie

Organizacje muszą zmierzyć się z krytycznym działaniem równoważenia podczas wdrażania oprogramowania open source:

Potrzeby deweloperów: Deweloperzy chcą korzystać ze składników open source, które umożliwiają szybsze opracowywanie, nowoczesne struktury, sprawdzone biblioteki i współczesne praktyki programistyczne. Ograniczanie użycia typu open source zmniejsza produktywność, frustruje deweloperów i utrudnia rekrutację utalentowanych inżynierów.

Ryzyko organizacyjne: Nieograniczone wdrożenie typu open source może uwidaczniać organizacjom luki w zabezpieczeniach, zobowiązania prawne, zakłócenia operacyjne i naruszenia zgodności. Firmy muszą chronić własność intelektualną, zachować bezpieczeństwo, zapewnić stabilność operacyjną i przestrzegać zobowiązań prawnych.

Rozwiązanie: Udane organizacje znajdą sposoby zwiększania możliwości deweloperów podczas zarządzania ryzykiem — umożliwiając użycie typu open source w ramach struktur ładu, które identyfikują i zmniejszają potencjalne problemy.

Obawy dotyczące zabezpieczeń

Zagrożenia bezpieczeństwa stanowią najbardziej natychmiastowe i poważne obawy dotyczące oprogramowania typu open source:

Znane luki w zabezpieczeniach

Składniki typu open source często zawierają luki w zabezpieczeniach:

  • Częstość występowania: Naukowcy zajmujący się bezpieczeństwem odkrywają tysiące nowych luk w zabezpieczeniach w składnikach typu open source każdego roku. Krajowa Baza Danych Luk w Zabezpieczeniach (NVD) kataloguje luki w zabezpieczeniach z identyfikatorami CVE.
  • Zakres ważności: Luki w zabezpieczeniach różnią się w zależności od problemów o niskim wpływie na krytyczne wady umożliwiające zdalne wykonywanie kodu, kradzież danych lub całkowite naruszenie zabezpieczeń systemu.
  • Czas ujawnienia: Luki w zabezpieczeniach są często obecne przez lata przed odnajdywaniem. Aplikacje korzystające z wersji, których dotyczy problem, pozostają narażone do momentu zastosowania aktualizacji.
  • Zależności przechodnie: Luki w zabezpieczeniach mogą nie istnieć w pakietach używanych bezpośrednio, ale w ich zależnościach, co sprawia, że wykrywanie jest trudniejsze.

Przykładowy wpływ: Luka w zabezpieczeniach programu Log4Shell (CVE-2021-44228) w popularnej bibliotece rejestrowania języka Java Log4j miała wpływ na miliony aplikacji na całym świecie. Organizacje pośpiesznie działały w celu zidentyfikowania wszystkich aplikacji korzystających z biblioteki Log4j i wdrożenia poprawek, co pokazuje, w jaki sposób luka w zabezpieczeniach typu open source może mieć ogromne rozległe skutki.

Wstrzyknięcie złośliwego kodu

Ataki łańcucha dostaw są przeznaczone dla oprogramowania open source:

  • Przejęcie pakietu: Osoby atakujące przejmują kontrolę nad popularnymi kontami konserwatorów pakietów i wprowadzają złośliwe aktualizacje, które kradną poświadczenia, instalują backdoory lub kopią kryptowalutę.
  • Typosquatting: Złośliwe pakiety o nazwach podobnych do popularnych pakietów umożliwiają deweloperom instalowanie naruszonego kodu (np. "python-dateutil" a "python-datutil").
  • Zamieszanie zależności: Osoby atakujące publikują złośliwe pakiety w publicznych rejestrach z nazewnictwem zgodnym z wewnętrznymi pakietami prywatnymi, wykorzystując zachowanie rozwiązywania menedżera pakietów.
  • Kompromitacja konta utrzymującego: Atakujący kompromitują konta osób odpowiedzialnych za utrzymanie poprzez phishing, kradzież poświadczeń lub inżynierię społeczną w celu wstrzyknięcia złośliwego kodu do zaufanych pakietów.

Przykładowe zdarzenia: Pakiet eventstream w narzędziu npm został naruszony w celu kradzieży poświadczeń portfela kryptowalut. Opiekun Colors.js i Faker.js celowo dodał nieskończone pętle, aby zaprotestować przeciwko korporacyjnemu użyciu bez wsparcia finansowego, co spowodowało awarię tysięcy aplikacji.

Niezamierzone i porzucone projekty

Wiele projektów typu open source nie ma aktywnej konserwacji:

  • Porzucenie projektu: Osoby odpowiedzialne za utrzymanie tracą zainteresowanie, zmieniają miejsca pracy lub brakuje czasu, aby kontynuować konserwację projektów. Porzucone projekty nie otrzymują aktualizacji zabezpieczeń nawet w przypadku wykrycia luk w zabezpieczeniach.
  • Ryzyko związane z pojedynczym konserwatorem: Wiele krytycznych projektów typu open source zależy od pojedynczych osób. Jeśli ta osoba stanie się niedostępna, projekt może praktycznie nieutrzymywany z dnia na dzień.
  • Wyzwania związane z finansowaniem: Wielu opiekunów pracuje dobrowolnie. Bez finansowania utrzymanie dużych projektów staje się nie do utrzymania, co prowadzi do ewentualnego porzucenia.
  • Opóźnienie konserwacji: Nawet aktywne projekty mogą mieć wolne czasy odpowiedzi na problemy z zabezpieczeniami, pozostawiając aplikacje podatne na zagrożenia podczas oczekiwania na poprawki.

Wpływ na organizację: Organizacje zależne od nieutrzymywanych pakietów muszą przełączyć się na alternatywy (wymagające znacznej refaktoryzacji), zforkować i utrzymywać pakiet samodzielnie (co dodaje obciążenie w utrzymaniu), lub nadal używać podatnego na zagrożenia kodu (akceptując ryzyko bezpieczeństwa).

Problemy związane z jakością i niezawodnością

Poza zabezpieczeniami jakość kodu wpływa na niezawodność aplikacji i łatwość konserwacji:

Zmienna jakość kodu

Składniki typu open source różnią się znacznie w jakości:

  • Brak standardów jakości: Projekty typu open source nie mają obowiązkowych wymagań dotyczących jakości. Jakość kodu zależy całkowicie od umiejętności, praktyk i priorytetów utrzymania.
  • Ograniczone testowanie: Mniejsze projekty mogą mieć minimalne zautomatyzowane testowanie, niewystarczające pokrycie przypadków brzegowych lub brak ciągłej integracji, co zwiększa prawdopodobieństwo błędów.
  • Luki w dokumentacji: Nieodpowiednia dokumentacja utrudnia prawidłowe używanie składników, zwiększając ryzyko błędów integracji i nieprawidłowego użycia.
  • Problemy z wydajnością: Składniki mogą nie być zoptymalizowane pod kątem wydajności, skalowalności ani wydajności zasobów, co wpływa na wydajność aplikacji.

Wpływ składników o niskiej jakości:

  • Łatwość konserwacji: Słaba struktura kodu sprawia, że debugowanie i dostosowywanie jest trudne.
  • Niezawodność: Niewystarczające testowanie prowadzi do błędów, które powodują błędy aplikacji.
  • Wydajność: Nieefektywne implementacje wpływają na czasy odpowiedzi aplikacji i użycie zasobów.

Zgodność i stabilność

Składniki typu open source nie zawsze ustalają priorytety zgodności z poprzednimi wersjami:

  • Zmiany powodujące niezgodność: Aktualizacje wersji głównej często powodują zmiany powodujące niezgodność wymagające modyfikacji aplikacji.
  • Niestabilność interfejsu API: Młodsze projekty mogą często zmieniać interfejsy w miarę dojrzewania projektów.
  • Konflikty zależności: Składniki mogą wymagać określonych wersji zależności, które powodują konflikt z innymi składnikami.
  • Zgodność platformy: Nie wszystkie składniki działają na wszystkich platformach, przeglądarkach lub środowiskach.

Licencje typu open source tworzą zobowiązania prawne, które organizacje muszą przestrzegać:

Obowiązki dotyczące zgodności licencji

Każda licencja typu open source nakłada wymagania:

  • Wymagania dotyczące rozwiązania Copyleft: Niektóre licencje (takie jak GPL) wymagają, aby pochodna korzystała z tej samej licencji, co potencjalnie zmusza organizacje do stosowania zastrzeżonego kodu open source.
  • Wymagania dotyczące autorstwa: Większość licencji wymaga obsługi powiadomień o prawach autorskich i tekstu licencji, który musi występować w oprogramowaniu rozproszonym.
  • Ujawnienie kodu źródłowego: Niektóre licencje wymagają dostarczenia kodu źródłowego każdemu, kto otrzymuje pliki binarne.
  • Granty patentowe: Niektóre licencje obejmują patenty lub klauzule zakończenia, które współdziałają ze strategiami patentowymi organizacji.

Błędy zgodności mogą spowodować:

  • Działania prawne: Posiadacze praw autorskich mogą pozwać o naruszenie licencji, domagając się odszkodowania i nakazów.
  • Uszkodzenie reputacji: Naruszenia licencji stają się publiczne, szkodząc reputacji organizacji w społecznościach deweloperów.
  • Ograniczenia dystrybucji: Rozwiązywanie naruszeń może wymagać wstrzymania dystrybucji produktów do momentu osiągnięcia zgodności.
  • Wymuszone udostępnianie kodu źródłowego: W skrajnych przypadkach organizacje mogą być zmuszone do ujawnienia kodu zastrzeżonego jako open source, który narusza licencje copyleft.

Proliferacja licencji i zgodność

Nowoczesne aplikacje obejmują setki składników z różnymi licencjami:

  • Spis licencji: Organizacje muszą śledzić, które licencje mają zastosowanie do każdej zależności w swoich aplikacjach.
  • Analiza zgodności: Niektóre licencje są niezgodne — oprogramowanie w ramach GPL nie może być łączone z oprogramowaniem w ramach niektórych innych licencji.
  • Interpretacja postanowień licencyjnych: Zespoły prawne muszą interpretować postanowienia licencyjne i określać obowiązki dotyczące określonych przypadków użycia.
  • Zmienianie licencji: Osoby odpowiedzialne za projekt czasami zmieniają licencje między wersjami, co wymaga ponownej oceny zgodności.

Skala wyzwania: Aplikacja dla przedsiębiorstw może przechodnio zależeć od 500–1000 pakietów typu open source z 20–40 różnymi licencjami. Ręczne śledzenie zgodności jest niepraktyczne i wymaga zautomatyzowanych narzędzi i procesów.

Problemy operacyjne

Poza bezpieczeństwem i ryzykiem prawnym platforma open source wprowadza wyzwania operacyjne:

Zależność od infrastruktury zewnętrznej

Ekosystemy typu open source zależą od infrastruktury publicznej:

  • Dostępność rejestru: Aplikacje pobierają zależności z publicznych rejestrów pakietów (npm, PyPI, NuGet). Awarie rejestru uniemożliwiają kompilacje i wdrożenia.
  • Usuwanie pakietu: Autorzy mogą wycofać publikację pakietów, powodując awarie aplikacji, które są od nich zależne. Zdarzenie "left-pad" uwidoczniło to ryzyko, gdy usunięcie małego 11-wierszowego pakietu złamało tysiące aplikacji JavaScript.
  • Dostęp geograficzny: Niektóre organizacje działają w regionach z ograniczonym dostępem do rejestrów pakietów publicznych.
  • Niezawodność sieci: Wolne lub zawodne połączenia sieciowe wpływają na czasy kompilacji i mogą powodować błędy kompilacji.

Strategie ograniczania ryzyka obejmują:

  • Rejestry prywatne: Odwzorowanie publicznych pakietów w ramach prywatnych rejestrów pod kontrolą organizacji.
  • Pakiety dostawcy: Uwzględnij zależności w kontroli źródła, aby wyeliminować zależności zewnętrzne podczas kompilacji.
  • Buforowanie: Buforowanie pakietów, aby zmniejszyć wielokrotne pobieranie i zwiększyć niezawodność kompilacji.

Obciążenie związane z zarządzaniem aktualizacjami

Utrzymywanie bieżących zależności wymaga ciągłego wysiłku:

  • Ciągłe aktualizacje: Nowe wersje pakietów są stale wydawane. Organizacje muszą oceniać aktualizacje, testować zgodność i wdrażać zmiany.
  • Pilność zabezpieczeń: Krytyczne luki w zabezpieczeniach wymagają natychmiastowych aktualizacji, potencjalnie zakłócających planowaną pracę.
  • Zmiany potencjalnie powodujące niezgodność: Główne aktualizacje mogą wymagać zmian w kodzie, co zwiększa obciążenie związane z konserwacją.
  • Wymagania dotyczące testowania: Każda aktualizacja zależności wymaga testowania regresji, aby upewnić się, że nic się nie zepsuje.

Bez systematycznego procesu aktualizacji:

  • Dryf zależności: Aplikacje pozostają w tyle za obecnymi wersjami, gromadząc dług techniczny.
  • Narażenie na zabezpieczenia: Luki w zabezpieczeniach bez poprawek pozostają możliwe do wykorzystania.
  • Lawina aktualizacji: Opóźnienie aktualizacji powoduje utworzenie dużych zaległości, które stają się coraz trudniejsze i bardziej ryzykowne do wdrożenia.

Równoważenie swobody i kontroli

Organizacje muszą opracowywać strategie równoważące możliwości deweloperów dzięki zarządzaniu ryzykiem:

Podejścia do zapewniania ładu

Udane organizacje implementują zrównoważony ład:

Procesy wstępnego zatwierdzania:

  • Ocena pakietu: Zespoły ds. zabezpieczeń i prawnych przeglądają pakiety przed pierwszym użyciem, oceniając historię zabezpieczeń, zgodność licencji i jakość.
  • Zatwierdzone listy pakietów: Obsługa wyselekcjonowanych list wstępnie zatwierdzonych pakietów, których deweloperzy mogą swobodnie używać.
  • Procesy wyjątków: Zezwalaj deweloperom na żądanie zatwierdzenia pakietów, które nie znajdują się na zatwierdzonych listach, przy użyciu oceny przez odpowiednie zespoły.

Automatyczne skanowanie:

  • Skanowanie luk w zabezpieczeniach: Automatycznie skanuj zależności pod kątem znanych luk w zabezpieczeniach, natychmiast ostrzegając deweloperów.
  • Wykrywanie licencji: Zidentyfikuj licencje dla wszystkich zależności i oznacz niezgodne lub budzące zastrzeżenia licencje.
  • Metryki jakości: Użyj zautomatyzowanej analizy kodu, aby ocenić jakość zależności.

Edukacja dla deweloperów:

  • Świadomość zabezpieczeń: Szkolenie deweloperów w celu rozważenia zabezpieczeń podczas wybierania zależności.
  • Opis licencji: Pomóż deweloperom zrozumieć implikacje licencji dla różnych przypadków użycia.
  • Najlepsze rozwiązania: Udostępnij wskazówki dotyczące oceniania składników typu open source.

Ciągłe monitorowanie:

  • Nowe luki w zabezpieczeniach: Monitoruj nowo ujawnione luki w zabezpieczeniach w istniejących zależnościach.
  • Zmiany licencji: Śledź, kiedy projekty zmieniają licencje.
  • Stan konserwacji: Zidentyfikuj, kiedy zależności stają się nieobsługiwane.

Obawy dotyczące organizacji publikujących open source

Organizacje publikujące własne oprogramowanie typu open source stoją przed dodatkowymi wyzwaniami:

Zagadnienia dotyczące modelu biznesowego

Zarabianie na oprogramowaniu open source wymaga starannej strategii:

  • Model open-core: Oferuje podstawową funkcjonalność jako open source, sprzedając zastrzeżone rozszerzenia lub funkcje dla przedsiębiorstw.
  • Pomoc techniczna i usługi: Bezpłatne udostępnianie oprogramowania typu open source, ale sprzedaż umów pomocy technicznej, konsultacji lub szkoleń.
  • Hostowane usługi: Oprogramowanie typu open source, ale sprzedaje zarządzane usługi hostingu.
  • Podwójne licencjonowanie: Oferowanie oprogramowania w ramach licencji typu open source dla projektów open source i licencji komercyjnych dla oprogramowania własnościowego.

Zarządzanie wkładami

Opublikowane projekty open source otrzymują wkład zewnętrzny:

  • Przegląd udziału: Organizacje muszą przeglądać wkład społeczności w celu zapewnienia jakości, bezpieczeństwa i dostosowania do kierunku projektu.
  • Licencjonowanie współautora: Ustanów procesy zapewniające współautorom przyznanie niezbędnych praw do udziału.
  • Zasoby konserwatora: Reagowanie na problemy, przeglądanie próśb o zmiany i zarządzanie społecznością wymaga dedykowanych zasobów.
  • Konflikty kierunku: Pragnienia społeczności mogą być w konflikcie z priorytetami organizacyjnymi, co wymaga dyplomatycznego podejścia do zarządzania.

Zamknięte podejście open source: Niektóre organizacje publikują kod publicznie, ale ograniczają osoby, które mogą wprowadzać zmiany. Członkowie społeczności mogą sugerować zmiany za pośrednictwem zgłoszeń lub próśb o ściągnięcie, ale tylko opiekunowie organizacji wprowadzają zmiany. Zapewnia to przejrzystość przy zachowaniu kontroli nad jakością i kierunkiem kodu.

Ochrona własności intelektualnej

Organizacje muszą dokładnie rozważyć, co udostępnić jako open source:

  • Przewaga konkurencyjna: Unikaj kodu typu open source, który zapewnia konkurencyjne różnice.
  • Obawy dotyczące zabezpieczeń: Nie publikuj kodu, który uwidacznia mechanizmy zabezpieczeń ani luki w zabezpieczeniach.
  • Decyzje dotyczące czasu: Czasami jest strategicznie korzystne początkowo utrzymać kod jako własnościowy, a później udostępnić go jako otwartoźródłowy.
  • Zagadnienia dotyczące patentów: Upewnij się, że licencje typu open source obejmują odpowiednie granty patentowe lub ochronę.

Zrozumienie tych kwestii firmowych jest niezbędne do efektywnego implementowania oprogramowania open source. Następne lekcji szczegółowo eksplorują licencje typu open source, pomagając zrozumieć obowiązki prawne, jakie tworzą różne licencje i jak ocenić implikacje licencji dla organizacji.