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ń.

Stan Octoverse 2020 — Open Source

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, a ich pochodzenie może być 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.

The State of the Octoverse 2020 — Zależności

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 dziś w zależności, ale nie jest podatna na wykorzystanie, może być podatna na wykorzystanie w przyszłości.

Możliwość wykorzystania pracy tysięcy deweloperów i autorów bibliotek open source oznacza, że tysiące osób mogą skutecznie przyczynić się bezpośrednio do twojego kodu produkcyjnego. Twój produkt w łańcuchu dostaw oprogramowania jest podatny na niezałatane 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 sam w sobie rzadko jest celem końcowym; jest raczej początkiem możliwości dla atakującego w celu wstawienia złośliwego oprogramowania lub zapewnienia tylnego wejścia dla przyszłego dostępu.

The State of the Octoverse 2020 - Vulnerability LifecycleStan octoverse 2020 — cykl życia luk w zabezpieczeniach

Oprogramowanie niezałatane

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żeniem dla bezpieczeństwa łańcucha dostaw jest oprogramowanie bez poprawek. Wiedząc to, jak można zaradzić ryzyku, że zależność projektu jest podatna na zagrożenia?

  • 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. To osiąga się poprzez kontrolę mechanizmów, które masz w celu zarządzania zależnościami. Pomoże to nałożyć bardziej restrykcyjne warunki dla zależności.

Raport Octoverse 2020 - Ostrzeżenia

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

.NET 8 i Visual Studio 17.8 dodały 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, które dostarcza znaną bazę danych luk w zabezpieczeniach, więc jeśli nie używasz nuget.org jako źródła pakietów, powinieneś dodać je jako źródło audytu.

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 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:

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 wiersza polecenia możesz użyć polecenia dotnet list package, aby wyświetlić listę zależności projektu lub rozwiązania. Możesz również użyć polecenia , aby zrozumieć, dlaczego pakiety przechodnie (te, które nie są bezpośrednio referencjonowane przez twój projekt) 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 następującą 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

Możesz użyć interfejsu wiersza polecenia dotnet (dotnet CLI), aby wyświetlić listę wszelkich znanych, przestarzałych lub podatnych na zagrożenia zależności, które mogą znajdować się w twoim projekcie lub rozwiązaniu. Możesz użyć polecenia dotnet list package --deprecated lub dotnet list package --vulnerable aby uzyskać listę wszelkich znanych wycofań lub luk w zabezpieczeniach. NuGetAudit może ostrzegać o znanych podatnych zależnościach i jest domyślnie włączone, gdy źródło udostępnia bazę 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ć GitHub Security, aby znaleźć luki w zabezpieczeniach i błędy w projekcie, a narzędzie Dependabot naprawi je, otwierając pull request względem twojego kodu.

Przechwycenie wrażliwych zależności, zanim zostaną one wprowadzone, jest jednym z celów ruchu "Shift Left". 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 następującą dokumentację.

Konfiguracja narzędzia NuGet

📦 Odbiorca pakietu

Dodaj plik nuget.config w katalogu głównym repozytorium projektu. Jest to najlepsze rozwiązanie, ponieważ promuje powtarzalność i zapewnia, że różni użytkownicy mają tę samą konfigurację NuGet. Zalecamy dodanie clear elementów, aby upewnić się, że nie zastosowano konfiguracji specyficznej dla użytkownika ani maszyny. Dowiedz się więcej o sposobie stosowania ustawień.

Przykład:

<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
  <packageSourceMapping>
    <clear />
  </packageSourceMapping>
</configuration>

Wskazówka

Jeśli organizacja blokuje dostęp do api.nuget.org, rozważ poproszenie administratora sieci o zezwolenie na https://data.nuget.org/v3/index.json i skonfigurowanie go jako źródła inspekcji dla NuGet Audit. Ten punkt końcowy obsługuje tylko dane o lukach w zabezpieczeniach, a nie pakiety, więc może być dostępny nawet wtedy, gdy api.nuget.org jest zablokowany.

Ź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 twoja kompilacja jest przewidywalna i bezpieczna przed znanymi atakami, takimi jak Dependency Confusion, świadomość konkretnych źródeł, z których pochodzą twoje pakiety, jest dobrą praktyką. Do ochrony można użyć pojedynczego źródła danych lub kanału informacyjnego prywatnego z funkcjami nadrzędnymi.

Podczas konfigurowania zarówno publicznego, jak i prywatnego źródła, polecenia klienta, które wysyłają zapytania o metadane pakietu (na przykład dotnet package add i dotnet list package --outdated/--deprecated/--vulnerable) wysyłają żądane identyfikatory pakietów do każdego skonfigurowanego źródła, w tym publicznych. Mapowanie źródła pakietów nie zapobiega temu, ponieważ ma zastosowanie tylko wtedy, gdy pakiet NuGet pobiera pakiety podczas przywracania, instalowania i aktualizowania. Informacje o bieżącym stanie tych braków funkcjonalnych można znaleźć w następujących zgłoszeniach śledzących:

Aby uzyskać więcej informacji na temat zabezpieczania strumieni pakietów, zobacz 3 sposoby ograniczania ryzyka podczas korzystania z prywatnych strumieni pakietów.

Korzystając z prywatnego kanału informacyjnego, skieruj się do najlepszych praktyk bezpieczeństwa w zarządzaniu poświadczeniami.

Zasady zaufania klienta

📦 Odbiorca pakietu

Istnieją zasady, do których możesz się zapisać, wymagające, aby używane przez Ciebie pakiety były podpisywane. 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

Pliki blokady 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, zobacz 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.

Mapowanie źródła pakietów ma obecnie zastosowanie tylko wtedy, gdy pakiet NuGet pobiera pakiety podczas przywracania, instalowania i aktualizowania. Obecnym ograniczeniem jest to, że nie filtruje jeszcze źródeł, które inne polecenia klienta odpytują o metadane pakietów. Aby uzyskać więcej informacji, zobacz Kanały informacyjne NuGet.

Aby włączyć mapowanie źródła pakietu, zobacz 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. Dodatkowo, istnieją wiele opcji konfiguracji umożliwiających przekierowanie folderu pakietów globalnych NuGet oraz pamięci podręcznej HTTP do lokalizacji poza 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 dotnet nuget update source zmieni uprawnienia pliku nuget.config tak, aby był on tylko do odczytu przez właściciela 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 pobranych plików

📦 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 konfiguracyjnych, a program MSBuild zazwyczaj importuje pliki takie jak Directory.Build.props, Directory.NuGet.props, Directory.Build.targets i potencjalnie inne z dowolnego katalogu nadrzędnego aż do głównego katalogu 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

Agenty budowania

📦 Odbiorca pakietu

Programy kompilacji (agenci ciągłej integracji), które nie są resetowane do stanu początkowego po każdej kompilacji, mają wiele ryzyk, które trzeba rozważyć.

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 przechowuje dane, zobacz dokumentację dotyczącą zarządzania globalnymi pakietami, pamięcią podręczną i folderami tymczasowymi (../consume-packages/managing-the-global-packages-and-cache-folders). Te katalogi należy skonfigurować jako katalog, który agent CI czyści po każdym zbudowaniu.

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 tajnych danych GitHub

Autor pakietu

pl-PL: GitHub skanuje repozytoria pod kątem kluczy API NuGet, aby zapobiec nieuczciwemu użyciu tajnych danych, które zostały przypadkowo zatwierdzone.

Aby dowiedzieć się więcej na temat skanowania tajnych danych, zobacz Informacje o skanowaniu tajnych danych.

Podpisywanie pakietów przez autora

Autor pakietu

Podpisywanie przez autora pozwala autorowi pakietu na umieszczenie swojej tożsamości na pakiecie, a użytkownik końcowy może zweryfikować, czy pochodzi on 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 podpisać pakiet, 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 z użyciem Source Link oraz specyfikację Weryfikacja Powtarzalnych Kompilacji.

Uwierzytelnianie dwuskładnikowe (2FA)

Autor pakietu

Każde konto na nuget.org ma włączoną uwierzytelnianie 2FA. Dodaje to dodatkową warstwę zabezpieczeń podczas logowania się do Twojego konta GitHub lub konta NuGet.org.

Rezerwowanie prefiksów identyfikatorów pakietów

Autor pakietu

Aby chronić identyfikację swoich pakietów, możesz zarezerwować prefiks identyfikatora pakietu, używając odpowiedniej przestrzeni nazw, aby przypisać 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 utworzyłeś, zrób wszystko, co w Twojej mocy, aby wycofać pakiet i usunąć go z listy, aby pakiet był ukryty przed użytkownikami szukającymi pakietów. 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ąć pakiet z listy, zapoznaj się z następującą dokumentacją na temat wycofania i wyrejestrowania pakietów.

Rozważ również zgłoszenie znanego problemu do bazy danych GitHub Advisories.

Podsumowanie

Łańcuch dostaw oprogramowania to wszystko, co wchodzi w twój kod lub na niego wpływa. Mimo że kompromisy w łańcuchu dostaw są prawdziwe i rosnące na popularności, nadal są rzadkie, więc najważniejszą rzeczą, jaką można zrobić, jest ochrona łańcucha dostaw przez świadomość zależności, zarządzanie nimi i monitorowanie łańcucha dostaw.

Poznałeś różne metody, które oferują narzędzia NuGet i GitHub, dostępne obecnie, aby skuteczniej wyświetlać, zarządzać i monitorować łańcuch dostaw.

Aby uzyskać więcej informacji na temat zabezpieczania oprogramowania na świecie, zobacz Raport bezpieczeństwa 2020: Stan Octoverse.

  • Last updated on