Podsumowanie
W tym module przedstawiono sposób, w jaki nowoczesne programowanie oprogramowania zależy od składników open source i poznanych strategii wdrażania oprogramowania typu open source podczas zarządzania skojarzonymi zagrożeniami bezpieczeństwa, prawami i operacyjnymi. Zrozumienie tych pojęć pozwala wykorzystać korzyści typu open source, jednocześnie chroniąc organizację przed potencjalnymi zobowiązaniami.
Jak tworzone jest nowoczesne oprogramowanie
Wiesz już, że współczesne aplikacje są tworzone na podstawie składników , a nie tworzone całkowicie od podstaw:
- Kompozycja składników: Nowoczesne aplikacje składają się z około 80% istniejących składników utrzymywanych poza projektem, a tylko 20% jest oryginalnym kodem logiki biznesowej.
- Open source a zamknięte źródło: Składniki typu open source udostępniają publicznie dostępny kod źródłowy, który każdy może sprawdzać, modyfikować i dystrybuować, podczas gdy składniki zamkniętego źródła rozpowszechniają tylko pliki binarne bez dostępu źródłowego.
- Ekosystemy pakietów: Składniki są dystrybuowane za pośrednictwem menedżerów pakietów, takich jak npm, PyPI, NuGet i Maven Central, które automatyzują zarządzanie zależnościami.
- Zalety programowania opartego na składnikach: Ponowne korzystanie ze sprawdzonych składników przyspiesza opracowywanie, poprawia jakość poprzez weryfikację społeczności, zmniejsza koszty, unikając opłat licencyjnych i zapewniając dostęp do najnowszych innowacji.
- Szybkość opracowywania: Korzystanie ze składników typu open source znacznie skraca czas na rynek, umożliwiając zespołom skupienie się na unikatowej wartości biznesowej, a nie odbudowaniu wspólnej infrastruktury.
Obawy firmowe dotyczące oprogramowania open source
Podczas wdrażania składników open source zbadano istotne zagrożenia, przed którymi stoją organizacje :
Obawy dotyczące zabezpieczeń:
- Znane luki w zabezpieczeniach: Tysiące luk w zabezpieczeniach jest wykrywanych co roku w składnikach typu open source, co wymaga ciągłego monitorowania i szybkiego stosowania poprawek.
- Ataki na łańcuch dostaw: Atakujący przejmują konta użytkowników zajmujących się pakietem, stosują technikę podobieństwa nazw (typosquatting) lub wykorzystują zamieszanie związane z zależnościami, aby wstrzyknąć złośliwy kod.
- Nieutrzymywane projekty: Wiele projektów typu open source nie ma aktywnej konserwacji, pozostawiając luki w zabezpieczeniach bez łatania, gdy osoby utrzymujące porzucają projekty.
Problemy związane z jakością i niezawodnością:
- Jakość zmiennej: Składniki typu open source wahają się od profesjonalnych projektów po słabo przetestowany kod hobbystyczny.
- Zmiany wpływające na zgodność: Komponenty nie zawsze priorytetowo traktują zgodność z wcześniejszymi wersjami, co wymaga zmian w kodzie podczas aktualizacji.
- Luki w dokumentacji: Nieodpowiednia dokumentacja zwiększa błędy integracji i nieprawidłowe użycie.
Problemy związane z prawem i licencjonowaniem:
- Zobowiązania dotyczące zgodności licencji: Każda licencja typu open source nakłada wymagania od prostego przypisania do obowiązkowego open source prac pochodnych.
- Propagacja copyleft: Silne licencje copyleft, takie jak GPL, mogą wymagać udostępnienia kodu źródłowego całej aplikacji, jeśli nie są odpowiednio zarządzane.
- Proliferacja licencji: Aplikacje mogą zależeć od setek pakietów z dziesiątkami różnych licencji, tworząc złożone obciążenia związane ze zgodnością licencyjną.
Problemy operacyjne:
- Zależność infrastruktury zewnętrznej: Aplikacje korzystają z publicznych rejestrów pakietów, które mogą powodować awarie lub usuwanie pakietów.
- Obciążenie związane z zarządzaniem aktualizacjami: Utrzymywanie bieżących zależności wymaga ciągłego nakładu pracy, testowania i wdrażania.
Co to jest oprogramowanie typu open source
Poznaliśmy podstawowe cechy oprogramowania open source:
- Definicja: Oprogramowanie, którego kod źródłowy jest publicznie dostępny do inspekcji, modyfikacji i dystrybucji, z zastrzeżeniem licencji typu open source.
- Programowanie zespołowe: Projekty typu open source obejmują współautorów rozproszonych na całym świecie, którzy dobrowolnie uczestniczą, a programowanie dzieje się w sposób niewidoczny w repozytoriach publicznych.
- Powszechne przyjęcie: Ponad 90% przedsiębiorstw korzysta z oprogramowania open source w środowisku produkcyjnym, a technologie open source zasilają infrastrukturę internetową, platformy w chmurze i urządzenia przenośne.
- Transformacja firmy Microsoft: Firma Microsoft przeszła od postrzegania open source jako zagrożenia do pełnego jego przyjęcia, udostępniając .NET jako open source, wnosząc wkład w Linux i Kubernetes oraz tworząc popularne narzędzia open source, takie jak Visual Studio Code i TypeScript.
- Uzasadnienie strategiczne: Organizacje wybierają open source na potrzeby oszczędności kosztów, elastyczności i kontroli, przejrzystości i zabezpieczeń dzięki inspekcji kodu, unikając blokady dostawcy, pomocy technicznej społeczności i wczesnego dostępu do innowacji.
Podstawy licencji typu open source
Wyjaśniono , jak licencje typu open source zarządzają użyciem oprogramowania:
Cel licencji:
- Definiowanie uprawnień: Licencje przyznają prawa do używania, modyfikowania i rozpowszechniania oprogramowania, którego prawo autorskie w przeciwnym razie uniemożliwiłoby.
- Nakładanie zobowiązań: Licencje wymagają atrybucji, ujawnienia kodu źródłowego, zachowania licencji, a czasami zgodności copyleft.
- Brak odpowiedzialności: Autorzy nie są odpowiedzialni za szkody, a oprogramowanie jest udostępniane "tak, jak jest" bez gwarancji.
Kryteria definicji open source:
- Bezpłatna redystrybucja: Brak ograniczeń dotyczących sprzedaży lub rozdania oprogramowania.
- Dostępność kodu źródłowego: Musi zawierać źródło w preferowanej formie w przypadku modyfikacji.
- Dozwolone prace pochodne: Musi zezwalać na modyfikacje i prace pochodne.
- Brak dyskryminacji: Nie można dyskryminować osób, grup lub dziedzin wysiłku.
- Neutralna technologia: Nie można wymagać określonych technologii ani interfejsów.
Kategorie licencji:
- Licencje permisywne: Zezwalają na dołączanie kodu do oprogramowania własnościowego z minimalnymi ograniczeniami (MIT, Apache 2.0, BSD).
- Licencje copyleft: Wymagają, aby dzieła pochodne korzystały z tej samej licencji, zapewniając, że oprogramowanie pozostaje typu otwartego źródła (GPL, AGPL).
- Słabe licencje copyleft: Wymagaj modyfikacji typu open source do składnika, ale zezwalaj na używanie własności (LGPL, MPL).
Typowe licencje typu open source
Zbadałeś popularne licencje i ich kluczowe cechy:
Licencje permissive:
- Licencja MIT: Najprostsza permisywna licencja wymagająca tylko atrybucji, maksymalizująca adopcję i użycie komercyjne.
- Licencja apache 2.0: Licencja permissywna z wyraźnymi grantami patentowymi i defensywnym zakończeniem, zapewniając jasność patentu.
- Licencje BSD: Podobnie jak MIT, z 3-klauzulową licencją BSD dodającą ograniczenia użycia nazw dla ochrony znaków towarowych.
Licencje copyleft o silnym charakterze:
- GPL v2 i v3: Wymagają, aby pochodne dzieła były licencjonowane na GPL i dystrybuować kod źródłowy wraz z plikami binarnymi. GPL v3 dodaje ochronę patentową i ulepszenia dotyczące kompatybilności międzynarodowej.
- AGPL: Rozszerza GPL w wersji 3 o klauzulę korzystania z sieci, wymagającą ujawnienia kodu źródłowego w przypadku ofert SaaS.
Słabe licencje copyleft:
- LGPL: Umożliwia łączenie bibliotek z aplikacjami własnościowymi, jednocześnie wymagając, aby zmiany w samej bibliotece były open source.
- MPL 2.0: Zapewnia funkcję copyleft na poziomie plików, która wymaga ujawnienia źródła tylko dla plików licencjonowanych na platformie MPL, a nie zastrzeżonego kodu w tej samej aplikacji.
Zgodność licencji:
- Zgodne kombinacje: MIT + Apache 2.0, MIT + GPL v3, Apache 2.0 + GPL v3, LGPL + GPL.
- Niezgodne kombinacje: GPL v2 + Apache 2.0, GPL + Własnościowa, różne licencje copyleft stosowane razem.
Implikacje dotyczące licencji i oceny ryzyka
Wiesz już, jak oceniać czynniki ryzyka licencji i implementować zgodność:
Struktura ryzyka licencji:
- Niskie ryzyko (zielony): Licencje permisywne, takie jak MIT, BSD, Apache 2.0 są bezpieczne dla każdego użytku komercyjnego.
- Średnie ryzyko (żółty): Licencje copyleft o słabszym rygorze, takie jak LGPL, MPL, pozwalają na korzystanie o charakterze zastrzeżonym z ograniczeniami dotyczącymi modyfikacji.
- Wysokie ryzyko (czerwony): Silne licencje copyleft, takie jak GPL, AGPL są niezgodne z zastrzeżoną dystrybucją oprogramowania.
- Nieznane ryzyko (pomarańczowy): Licencje niestandardowe lub niejasne wymagają przeglądu prawnego przed użyciem.
Implikacje dotyczące oprogramowania komercyjnego:
- Licencje liberalne: Umożliwiają dystrybucję zastrzeżoną tylko z wymaganiami dotyczącymi przypisywania autorstwa.
- Słaby copyleft: Zezwala na używanie bibliotek w zastrzeżonych aplikacjach, ale wymaga, aby modyfikacje bibliotek były typu open source.
- Silna copyleft: Wymagaj prac pochodnych typu open source, dzięki czemu są one niezgodne z zastrzeżonym oprogramowaniem.
Zagadnienia dotyczące własności intelektualnej:
- Ochrona zastrzeżonego IP: Licencje permistywne zachowują zastrzeżony kod; licencje copyleft wymagają ujawnienia.
- Przepisy patentowe: Apache 2.0 i GPL v3 obejmują jawne dotacje patentowe; MIT/BSD nie ma jasności patentowej.
- Utrata tajemnicy handlowej: Ujawnienie kodu źródłowego eliminuje ochronę tajemnic handlowych.
Implementacja zgodności:
- Spis zależności: Obsługa kompleksowego śledzenia materiałów zawiera wszystkie komponenty open source i ich wersje.
- Weryfikacja zgodności licencji: Używanie zautomatyzowanych narzędzi do identyfikowania niezgodności licencji.
- Zgodność atrybucji: Generowanie plików agregacji licencji, dołączanie ich do okien dialogowych Informacje i utrzymanie w dokumentacji.
- Aprowizacja kodu źródłowego: W przypadku licencji copyleft podaj kompletny kod źródłowy z instrukcjami kompilacji.
Zabezpieczenia łańcucha dostaw oprogramowania:
- Skanowanie luk w zabezpieczeniach: Stale skanuj zależności pod kątem znanych luk w zabezpieczeniach przy użyciu narzędzi, takich jak Snyk, Dependabot lub WhiteSource.
- Ograniczanie ryzyka ataku łańcucha dostaw: Zweryfikuj podpisy pakietów, preferuj wiarygodne źródła, użyj prywatnych rejestrów i przypnij wersje zależności.
- Ocena jakości: Ocena stanu konserwacji, rozmiaru społeczności, jakości dokumentacji i praktyk zabezpieczeń.
Zasady organizacyjne:
- Procesy zatwierdzania: Zanim przyjmiesz nowe zależności, przeprowadź ocenę bezpieczeństwa, licencjonowania i jakości.
- Zatwierdzone listy pakietów: Zachowaj wyselekcjonowane listy wstępnie zweryfikowanych składników, których deweloperzy mogą używać natychmiast.
- Edukacja dla deweloperów: Szkolenie deweloperów na temat implikacji licencji, praktyk zabezpieczeń i procesów zgodności.
- Ciągłe monitorowanie: Śledzenie aktualizacji zależności, zmian licencji i ujawniania luk w zabezpieczeniach.
Kluczowe wnioski
Podczas implementowania oprogramowania open source w organizacji należy pamiętać o następujących podstawowych zasadach:
Strategicznie przyjmij rozwiązania open source: Open-source zapewnia ogromne korzyści, w tym szybkość rozwoju, jakość, oszczędności kosztów i dostęp do innowacji. Zamiast unikać typu open source ze względu na zagrożenia, zaimplementuj procesy ładu, które umożliwiają bezpieczne wdrażanie.
Poznaj zależności: Zachowaj kompleksowe spisy wszystkich składników typu open source, w tym zależności przechodnie. Nie możesz zarządzać ryzykiem, o którym nie wiesz, dzięki czemu widoczność zależności jest podstawą efektywnego zarządzania typu open source.
Omówienie implikacji licencji: Różne licencje mają znacznie różne konsekwencje dla oprogramowania komercyjnego. Licencje permissywne, takie jak MIT, są bezpieczne dla oprogramowania własnościowego; Licencje copyleft, takie jak GPL, wymagają prac pochodnych typu open source. Dopasuj wybór licencji do modelu biznesowego.
Ocena zgodności licencji: Sprawdź, czy licencje różnych składników można połączyć legalnie. Niezgodne licencje mogą powodować problemy prawne, które wymagają kosztownego korygowania, w tym zamiany składników lub ponownego zapisywania kodu.
Implementowanie automatycznej zgodności: Ręczne śledzenie licencji nie skaluje się do nowoczesnych aplikacji z setkami zależności. Użyj zautomatyzowanych narzędzi do skanowania zależności, wykrywania licencji i monitorowania luk w zabezpieczeniach.
Określanie priorytetów zabezpieczeń: Luki w zabezpieczeniach w zależnościach wpływają na aplikację niezależnie od tego, skąd pochodzą. Zaimplementuj ciągłe skanowanie luk w zabezpieczeniach i ustanów szybkie procesy aktualizacji dla krytycznych poprawek zabezpieczeń.
Zarządzanie ryzykiem łańcucha dostaw: Poza znanymi lukami w zabezpieczeniach należy chronić przed atakami łańcucha dostaw za pośrednictwem weryfikacji pakietów, oceny reputacji źródła, prywatnych rejestrów i przypinania zależności.
Zrównoważ kontrolę z swobodą: Deweloperzy potrzebują swobody korzystania z nowoczesnych narzędzi i struktur. Zamiast blokować wdrażanie typu open source, zaimplementuj przepływy pracy zatwierdzania i zatwierdzone listy pakietów, które umożliwiają bezpieczne korzystanie.
Edukuj swój zespół: Świadomość deweloperów związanych z licencjonowaniem i zabezpieczeniami jest niezbędna. Programy szkoleniowe ułatwiają deweloperom podejmowanie dobrych decyzji dotyczących wyboru składników i zrozumienia zasad organizacyjnych.
Monitoruj w sposób ciągły: Zarządzanie typu open source nie jest jednorazowym działaniem. Nowe luki w zabezpieczeniach są stale ujawniane, licencje czasami się zmieniają, a projekty mogą zostać porzucone. Ciągłe monitorowanie zapewnia ciągłą zgodność i bezpieczeństwo.
Stosując te zasady i wdrażając systematyczne rozwiązania w zakresie zarządzania open source, możesz umożliwić organizacji wykorzystanie ogromnych korzyści związanych z oprogramowaniem typu open source przy jednoczesnym efektywnym zarządzaniu zabezpieczeniami, prawem i ryzykiem operacyjnym.