Najlepsze rozwiązania dotyczące bezpiecznego łańcucha dostaw oprogramowania
Open Source jest wszędzie. Jest on w wielu zastrzeżonych bazach kodu i projektach społeczności. W przypadku organizacji i osób fizycznych obecnie pytanie nie dotyczy tego, czy używasz kodu open source, ale jakiego kodu typu open source używasz i jak bardzo.
Jeśli nie wiesz, co znajduje się w łańcuchu dostaw oprogramowania, luka w zabezpieczeniach nadrzędnych w jednej z zależności może być śmiertelna, co sprawia, że ty i twoi klienci są narażeni na potencjalne naruszenie zabezpieczeń. W tym dokumencie dowiesz się, co oznacza termin "łańcuch dostaw oprogramowania", dlaczego ma to znaczenie i jak można pomóc w zabezpieczeniu łańcucha dostaw projektu przy użyciu najlepszych rozwiązań.
Zależności
Termin łańcuch dostaw oprogramowania służy do odwoływania się do wszystkiego, co wchodzi w oprogramowanie i skąd pochodzi. Jest to zależności i właściwości zależności, od których zależy łańcuch dostaw oprogramowania. Zależność jest tym, czego potrzebuje oprogramowanie do uruchomienia. Może to być kod, pliki binarne lub inne składniki, z których pochodzą, takie jak repozytorium lub menedżer pakietów.
Zawiera on informacje o tym, kto napisał kod, kiedy został dodany, w jaki sposób został przejrzyszony pod kątem problemów z zabezpieczeniami, znanych luk w zabezpieczeniach, obsługiwanych wersji, informacji o licencjach oraz o wszystkim, co dotyka go w dowolnym momencie procesu.
Łańcuch dostaw obejmuje również inne części stosu poza pojedynczą aplikację, takie jak skrypty kompilacji i pakowania lub oprogramowanie, na których działa infrastruktura, na którą opiera się aplikacja.
Luki w zabezpieczeniach
Obecnie zależności oprogramowania są wszechobecne. Często zdarza się, że projekty używają setek zależności typu open source dla funkcji, których nie trzeba pisać samodzielnie. Może to oznaczać, że większość aplikacji składa się z kodu, którego nie utworzono.
Możliwe luki w zabezpieczeniach w zależnościach innych firm lub open source są prawdopodobnie zależnościami, których nie można kontrolować tak ściśle, jak kod, który piszesz, co może powodować potencjalne zagrożenia bezpieczeństwa w łańcuchu dostaw.
Jeśli jedna z tych zależności ma lukę w zabezpieczeniach, prawdopodobnie masz również lukę w zabezpieczeniach. Może to być przerażające, ponieważ jedna z zależności może się zmienić, nawet nie wiedząc. Nawet jeśli luka w zabezpieczeniach istnieje obecnie w zależności, ale nie jest dostępna do wykorzystania, może być wykorzystywana w przyszłości.
Możliwość wykorzystania pracy tysięcy deweloperów i autorów bibliotek typu open source oznacza, że tysiące obcych może skutecznie przyczynić się bezpośrednio do kodu produkcyjnego. Twój produkt, za pośrednictwem łańcucha dostaw oprogramowania, ma wpływ na niezaznaczone luki w zabezpieczeniach, niewinne błędy, a nawet złośliwe ataki na zależności.
Kompromisy w łańcuchu dostaw
Tradycyjna definicja łańcucha dostaw pochodzi z produkcji; jest to łańcuch procesów wymaganych do tworzenia i dostarczania czegoś. Obejmuje ona planowanie, dostarczanie materiałów, produkcji i sprzedaży detalicznej. Łańcuch dostaw oprogramowania jest podobny, z wyjątkiem materiałów, jest to kod. Zamiast produkcji, jest to rozwój. Zamiast kopać rudę z ziemi, kod jest pozyskiwany od dostawców, komercyjnych lub open source, a ogólnie kod open source pochodzi z repozytoriów. Dodanie kodu z repozytorium oznacza, że produkt przyjmuje zależność od tego kodu.
Jeden z przykładów ataku łańcucha dostaw oprogramowania występuje, gdy złośliwy kod jest celowo dodawany do zależności przy użyciu łańcucha dostaw tej zależności w celu dystrybucji kodu do jego ofiar. Ataki łańcucha dostaw są prawdziwe. Istnieje wiele metod ataku na łańcuch dostaw, od bezpośredniego wstawiania złośliwego kodu jako nowego współautora do przejęcia konta współautora bez zauważenia przez innych, a nawet naruszenie klucza podpisywania w celu dystrybucji oprogramowania, które nie jest oficjalnie częścią zależności.
Atak łańcucha dostaw oprogramowania jest rzadko celem końcowym, a raczej na początku szansy na wstawienie złośliwego oprogramowania lub zapewnienie backdoor na potrzeby przyszłego dostępu.
Oprogramowanie niezaznaczone
Korzystanie z oprogramowania open source jest obecnie znaczące i nie powinno spowalniać w najbliższym czasie. Biorąc pod uwagę, że nie przestaniemy korzystać z oprogramowania typu open source, zagrożenie dla bezpieczeństwa łańcucha dostaw nie jest oprogramowaniem niezaznaczone. Wiedząc, że jak można rozwiązać ryzyko, że zależność projektu ma lukę w zabezpieczeniach?
- Znajomość tego, co znajduje się w twoim środowisku. Wymaga to odnalezienia zależności i wszelkich przejściowych zależności w celu zrozumienia ryzyka tych zależności, takich jak luki w zabezpieczeniach lub ograniczenia licencjonowania.
- Zarządzanie zależnościami. Po wykryciu nowej luki w zabezpieczeniach należy określić, czy ma to wpływ, a jeśli tak, należy zaktualizować do najnowszej dostępnej wersji i poprawki zabezpieczeń. Jest to szczególnie ważne, aby przejrzeć zmiany, które wprowadzają nowe zależności lub regularnie przeprowadzają inspekcję starszych zależności.
- Monitoruj łańcuch dostaw. Jest to spowodowane inspekcją kontrolek, które są używane do zarządzania zależnościami. Pomoże to wymusić bardziej restrykcyjne warunki, które będą spełnione dla zależności.
Omówimy różne narzędzia i techniki zapewniane przez narzędzia NuGet i GitHub, których można użyć dzisiaj w celu rozwiązania potencjalnych zagrożeń w projekcie.
Wiedza na temat tego, co znajduje się w twoim środowisku
Pakiety ze znanymi lukami w zabezpieczeniach
📦 Odbiorca pakietu | 📦🖊 Autor pakietu
Programy .NET 8 i Visual Studio 17.8 dodały pakiet NuGetAudit, który ostrzega przed bezpośrednimi pakietami ze znanymi lukami w zabezpieczeniach podczas przywracania. Programy .NET 9 i Visual Studio 17.12 również zmieniły wartość domyślną, aby ostrzegać o pakietach przechodnich.
Narzędzie NuGetAudit wymaga źródła, aby zapewnić znaną bazę danych luk w zabezpieczeniach, więc jeśli nie używasz nuget.org jako źródła pakietu, należy dodać ją jako źródło inspekcji.
Gdy narzędzie NuGet ostrzega Cię, luka w zabezpieczeniach jest publicznie znana. Osoby atakujące mogą użyć tego publicznego ujawnienia w celu opracowania ataków na obiekty docelowe, które nie zastosować poprawek swoich aplikacji. W związku z tym po wyświetleniu ostrzeżenia o tym, że pakiet, którego używa projekt, ma znaną lukę w zabezpieczeniach, należy szybko podjąć działania.
Wykres zależności Narzędzia NuGet
📦 Odbiorca pakietu
Zależności NuGet można wyświetlić w projekcie, przeglądając bezpośrednio odpowiedni plik projektu.
Zazwyczaj znajduje się to w jednym z dwóch miejsc:
packages.config— znajduje się w katalogu głównym projektu.<PackageReference>— znajduje się w pliku projektu.
W zależności od metody używanej do zarządzania zależnościami NuGet można również użyć programu Visual Studio, aby wyświetlić zależności bezpośrednio w Eksplorator rozwiązań lub Menedżer pakietów NuGet.
W przypadku środowisk interfejsu dotnet list package wiersza polecenia możesz użyć polecenia , aby wyświetlić listę zależności projektu lub rozwiązania.
Możesz również użyć dotnet nuget why polecenia , aby zrozumieć, dlaczego pakiety przechodnie (nie odwołujące się bezpośrednio do projektu) są uwzględniane w grafie pakietów projektu.
Aby uzyskać więcej informacji na temat zarządzania zależnościami NuGet, zobacz poniższą dokumentację.
Wykres zależności usługi GitHub
📦 Odbiorca pakietu | 📦🖊 Autor pakietu
Możesz użyć grafu zależności usługi GitHub, aby wyświetlić pakiety, od których zależy projekt, oraz repozytoria, które od niego zależą. Może to pomóc w wykryciu wszelkich luk w zabezpieczeniach wykrytych w jego zależnościach.
Aby uzyskać więcej informacji na temat zależności repozytorium GitHub, zobacz poniższą dokumentację.
Wersje zależności
📦 Odbiorca pakietu | 📦🖊 Autor pakietu
Aby zapewnić bezpieczny łańcuch dostaw zależności, należy upewnić się, że wszystkie zależności i narzędzia są regularnie aktualizowane do najnowszej stabilnej wersji, ponieważ często będą zawierać najnowsze funkcje i poprawki zabezpieczeń do znanych luk w zabezpieczeniach. Zależności mogą zawierać kod, od których zależysz, używane pliki binarne, używane narzędzia i inne składniki. Mogą to być na przykład:
Zarządzanie zależnościami
Przestarzałe i podatne na zagrożenia zależności narzędzia NuGet
📦 Odbiorca pakietu | 📦🖊 Autor pakietu
Interfejs wiersza polecenia dotnet umożliwia wyświetlenie listy znanych przestarzałych lub podatnych na zagrożenia zależności, które mogą znajdować się w projekcie lub rozwiązaniu.
Możesz użyć polecenia dotnet list package --deprecated lub dotnet list package --vulnerable podać listę znanych wycofań lub luk w zabezpieczeniach.
Narzędzie NuGetAudit może wyświetlić ostrzeżenie o znanych zależnościach podatnych na zagrożenia i jest domyślnie włączone, gdy źródło udostępnia bazę danych luk w zabezpieczeniach.
Zależności podatne na zagrożenia w usłudze GitHub
📦 Odbiorca pakietu | 📦🖊 Autor pakietu
Jeśli projekt jest hostowany w usłudze GitHub, możesz użyć zabezpieczeń usługi GitHub, aby znaleźć luki w zabezpieczeniach i błędy w projekcie, a narzędzie Dependabot naprawi je, otwierając żądanie ściągnięcia względem bazy kodu.
Przechwytywanie wrażliwych zależności przed ich wprowadzeniem jest jednym z celów ruchu "Shift w lewo". Możliwość posiadania informacji o zależnościach, takich jak ich licencja, zależności przechodnie i wiek zależności, pomaga to zrobić.
Aby uzyskać więcej informacji na temat alertów i aktualizacji zabezpieczeń dependabot, zobacz poniższą dokumentację.
Źródła danych NuGet
📦 Odbiorca pakietu
Użyj zaufanych źródeł pakietów. W przypadku korzystania z wielu publicznych i prywatnych źródeł źródłowych NuGet można pobrać pakiet z dowolnego źródła danych. Aby upewnić się, że kompilacja jest przewidywalna i bezpieczna przed znanymi atakami, takimi jak Błąd zależności, wiedza o konkretnych kanałach informacyjnych, z których pochodzą pakiety, jest najlepszym rozwiązaniem. Do ochrony można użyć pojedynczego źródła danych lub kanału informacyjnego prywatnego z funkcjami nadrzędnymi.
Aby uzyskać więcej informacji na temat zabezpieczania kanałów informacyjnych pakietów, zobacz 3 sposoby ograniczania ryzyka podczas korzystania z prywatnych kanałów informacyjnych pakietów.
W przypadku korzystania z kanału informacyjnego prywatnego zapoznaj się z najlepszymi rozwiązaniami w zakresie zabezpieczeń dotyczącymi zarządzania poświadczeniami.
Zasady zaufania klienta
📦 Odbiorca pakietu
Istnieją zasady, do których można wyrazić zgodę, w których wymagane są pakiety, których używasz do podpisania. Dzięki temu można ufać autorowi pakietu, o ile jest podpisany przez autora lub ufać pakietowi, jeśli jest własnością określonego użytkownika lub konta podpisanego przez NuGet.org.
Aby skonfigurować zasady zaufania klientów, zapoznaj się z następującą dokumentacją.
Blokowanie plików
📦 Odbiorca pakietu
Zablokuj pliki przechowują skrót zawartości pakietu. Jeśli skrót zawartości pakietu, który chcesz zainstalować, jest zgodny z plikiem blokady, zapewni powtarzalność pakietu.
Aby włączyć pliki blokady, zapoznaj się z następującą dokumentacją.
Mapowanie źródła pakietu
📦 Odbiorca pakietu
Mapowanie źródła pakietów umożliwia centralne deklarowanie źródła, z którego każdy pakiet w rozwiązaniu powinien zostać przywrócony w pliku nuget.config.
Aby włączyć mapowanie źródła pakietu, zapoznaj się z następującą dokumentacją.
Zabezpieczanie komputerów
Uprawnienia do katalogu
📦 Odbiorca pakietu
W systemach Windows i Mac oraz w niektórych dystrybucjach systemu Linux katalogi główne konta użytkownika są domyślnie prywatne. Jednak niektóre dystrybucje systemu Linux sprawiają, że katalogi użytkowników są domyślnie czytelne dla innych kont na tym samym komputerze. Ponadto istnieje wiele opcji konfiguracji umożliwiających przekierowanie folderu pakietów globalnych NuGet i pamięci podręcznej HTTP do lokalizacji innych niż domyślne. Rozwiązania, projekty i repozytoria mogą być również tworzone poza katalogiem głównym użytkownika.
Jeśli używasz pakietów, które nie znajdują się na nuget.org, to jeśli jakiekolwiek inne konto na komputerze może odczytać pakiety globalne NuGet lub katalogi pamięci podręcznej HTTP lub katalogi wyjściowe kompilacji projektu, te pakiety mogą zostać ujawnione osobom, które nie powinny mieć dostępu do tych pakietów.
W systemie Linux zmieni uprawnienia pliku nuget.config, dotnet nuget update source aby umożliwić jego odczyt tylko właścicielowi pliku.
Jeśli jednak edytujesz plik nuget.config w jakikolwiek inny sposób, a plik znajduje się w lokalizacji, w której inne konta mogą odczytać plik, może istnieć ujawnienie informacji o adresie URL źródła pakietu lub poświadczeniach źródła pakietu.
Upewnij się, że nie można odczytać żadnego pliku nuget.config przez innych użytkowników tego samego komputera.
Rozwiązania w katalogu pobierania
📦 Odbiorca pakietu
W przypadku pracy z rozwiązaniami lub projektami w katalogu pobierania należy zachować szczególną ostrożność. Program NuGet gromadzi ustawienia z wielu plików konfiguracji, a program MSBuild zazwyczaj importuje katalog.Build.props, Directory.NuGet.props, Directory.Build.targets i potencjalnie inne pliki z dowolnego katalogu nadrzędnego bezpośrednio do katalogu głównego systemu plików.
Folder pobierania ma dodatkowe ryzyko, ponieważ zazwyczaj jest to domyślna lokalizacja, w przypadku których przeglądarki internetowe pobierają pliki z Internetu
Agenci kompilacji
📦 Odbiorca pakietu
Agenci kompilacji (agenci ciągłej integracji), którzy nie są resetowane do stanu początkowego po każdym kompilacji, mają wiele czynników ryzyka, które należy wziąć pod uwagę.
Aby dowiedzieć się więcej o bezpiecznych sposobach zarządzania poświadczeniami, zobacz dokumentację dotyczącą korzystania z pakietów z uwierzytelnionych źródeł danych.
Aby dowiedzieć się więcej o modyfikowaniu katalogów, w których nuGet są przechowywane dane, zobacz dokumentację dotyczącą zarządzania globalnymi pakietami, pamięcią podręczną i folderami tymczasowymi. Te katalogi należy skonfigurować do katalogu, który agent ciągłej integracji czyści po każdej kompilacji.
Pamiętaj, że wszystkie pakiety używane przez projekt mogą pozostać w katalogu wyjściowym kompilacji projektu. Jeśli projekt używa pakietów z uwierzytelnionych źródeł, inni użytkownicy tego samego agenta ciągłej integracji mogą uzyskać nieautoryzowany dostęp do zestawów pakietów. W związku z tym należy również wyczyścić repozytorium na końcu kompilacji, nawet jeśli kompilacja zakończy się niepowodzeniem lub zostanie anulowana.
Monitorowanie łańcucha dostaw
Skanowanie wpisów tajnych usługi GitHub
📦🖊 Autor pakietu
Usługa GitHub skanuje repozytoria kluczy interfejsu API NuGet, aby zapobiec fałszywym użyciu wpisów tajnych, które zostały przypadkowo zatwierdzone.
Aby dowiedzieć się więcej na temat skanowania wpisów tajnych, zobacz About secret scanning (Informacje o skanowaniu wpisów tajnych).
Tworzenie podpisywania pakietów
📦🖊 Autor pakietu
Podpisywanie autorów umożliwia autorowi pakietu sygnaturę tożsamości w pakiecie, a użytkownik może zweryfikować, czy pochodzi od Ciebie. Chroni to przed manipulowaniem zawartością i służy jako jedno źródło prawdy o pochodzeniu pakietu i autentyczności pakietu. W połączeniu z zasadami zaufania klienta można sprawdzić, czy pakiet pochodzi od określonego autora.
Aby utworzyć podpis pakietu, zobacz Podpisywanie pakietu.
Odtwarzalne kompilacje
📦🖊 Autor pakietu
Odtwarzalne kompilacje tworzą pliki binarne, które są bajtami dla bajtów identyczne przy każdym kompilowaniu i zawierają linki kodu źródłowego i metadane kompilatora, które umożliwiają użytkownikowi pakietu ponowne utworzenie pliku binarnego bezpośrednio i sprawdzenie, czy środowisko kompilacji nie zostało naruszone.
Aby dowiedzieć się więcej na temat powtarzalnych kompilacji, zobacz Tworzenie pakietów za pomocą linku źródłowego i specyfikację weryfikacji powtarzalnej kompilacji .
Uwierzytelnianie dwuskładnikowe (2FA)
📦🖊 Autor pakietu
Każde konto na nuget.org ma włączoną uwierzytelnianie 2FA. Spowoduje to dodanie dodatkowej warstwy zabezpieczeń podczas logowania się do konta usługi GitHub lub konta NuGet.org.
Rezerwowanie prefiksów identyfikatorów pakietów
📦🖊 Autor pakietu
Aby chronić tożsamość pakietów, możesz zarezerwować prefiks identyfikatora pakietu z odpowiednią przestrzenią nazw, aby skojarzyć pasującego właściciela, jeśli prefiks identyfikatora pakietu prawidłowo mieści się w określonych kryteriach.
Aby dowiedzieć się więcej o rezerwowaniu prefiksów identyfikatorów, zobacz Rezerwacja prefiksu identyfikatora pakietu.
Oznaczanie i usuwanie listy pakietów podatnych na zagrożenia
📦🖊 Autor pakietu
Aby chronić ekosystem pakietów platformy .NET, gdy masz świadomość luki w zabezpieczeniach pakietu, który został utworzony, wykonaj najlepsze czynności, aby wycofać i usunąć listę pakietu, aby był ukryty przed użytkownikami wyszukującymi pakiety. Jeśli korzystasz z pakietu, który jest przestarzały i nie ma go na liście, należy unikać korzystania z pakietu.
Aby dowiedzieć się, jak wycofać i usunąć listę pakietów, zobacz następującą dokumentację dotyczącą przestarzałego i wyrejecjonowania pakietów.
Rozważ również raportowanie znanej bazy danych usługi GitHub Advisories.
Podsumowanie
Łańcuch dostaw oprogramowania to wszystko, co wchodzi w kod lub wpływa na twój kod. Mimo że kompromisy w łańcuchu dostaw są prawdziwe i rosnące popularności, nadal są rzadkie; najważniejszą rzeczą, jaką można zrobić, jest ochrona łańcucha dostaw przez informowanie o zależnościach, zarządzanie zależnościami i monitorowanie łańcucha dostaw.
Wiesz już o różnych metodach, które zapewniają narzędzia NuGet i GitHub , które są dostępne dla Ciebie dzisiaj, aby być bardziej skuteczne w wyświetlaniu, zarządzaniu i monitorowaniu łańcucha dostaw.
Aby uzyskać więcej informacji na temat zabezpieczania oprogramowania na świecie, zobacz The State of the Octoverse 2020 Security Report (Raport o stanie październikowego 2020 r.).