Osvědčené postupy pro zabezpečený dodavatelský řetězec softwaru
Open Source je všude. Je to v mnoha vlastních základech kódu a komunitních projektech. Pro organizace a jednotlivce dnes není otázkou, jestli používáte nebo nepoužíváte opensourcový kód, ale jaký opensourcový kód používáte a kolik jich používáte.
Pokud nevíte, co je ve vašem softwarovém dodavatelském řetězci, může být nadřazená ohrožení zabezpečení v některé z vašich závislostí závažná, takže vy a vaši zákazníci jsou ohroženi potenciálním ohrožením. V tomto dokumentu se podrobněji podíváme na to, co znamená pojem "softwarový dodavatelský řetězec", proč je důležité a jak můžete pomoct zabezpečit dodavatelský řetězec projektu s osvědčenými postupy.
Závislosti
Pojem softwarový dodavatelský řetězec se používá k odkazu na vše, co jde do vašeho softwaru a odkud pochází. Jedná se o závislosti a vlastnosti závislostí, na které závisí váš softwarový dodavatelský řetězec. Závislostí je to, co váš software potřebuje ke spuštění. Může to být kód, binární soubory nebo jiné komponenty a jejich umístění, například úložiště nebo správce balíčků.
Obsahuje informace o tom, kdo kód napsal, když k němu přispěl, jak byl zkontrolován z hlediska problémů se zabezpečením, známých ohrožení zabezpečení, podporovaných verzí, informací o licencích a čehokoli, co se na něj v jakémkoli okamžiku procesu dotkne.
Váš dodavatelský řetězec zahrnuje i další části zásobníku nad rámec jedné aplikace, jako jsou vaše skripty sestavení a balení nebo software, na kterém vaše aplikace běží.
Ohrožení zabezpečení
V současnosti jsou softwarové závislosti přesvědčivé. Je docela běžné, že vaše projekty používají stovky opensourcových závislostí pro funkce, které jste nemuseli psát sami. To může znamenat, že většina vaší aplikace se skládá z kódu, který jste nevytvořili.
Možná ohrožení zabezpečení ve vašich závislostech třetích stran nebo opensourcových závislostech jsou pravděpodobně závislosti, které nemůžete řídit tak úzce jako kód, který píšete, což může způsobit potenciální bezpečnostní rizika ve vašem dodavatelském řetězci.
Pokud některá z těchto závislostí obsahuje ohrožení zabezpečení, je pravděpodobné, že máte také ohrožení zabezpečení. To může být děsivé, protože jedna z vašich závislostí se může změnit, aniž byste to ani věděli. I když dnes existuje ohrožení zabezpečení v závislosti, ale není zneužitelné, může být v budoucnu zneužitelné.
Schopnost využívat práci tisíců opensourcových vývojářů a autorů knihoven znamená, že tisíce cizích lidí můžou efektivně přispívat přímo do produkčního kódu. Váš produkt prostřednictvím softwarového dodavatelského řetězce je ovlivněn nepatchovanými chybami zabezpečení, nevinnými chybami nebo dokonce škodlivými útoky na závislosti.
Ohrožení dodavatelského řetězce
Tradiční definice dodavatelského řetězce pochází z výroby; jedná se o řetězec procesů potřebných k vytvoření a dodání něčeho. Zahrnuje plánování, dodávky materiálů, výroby a maloobchodu. Softwarový dodavatelský řetězec je podobný, s výjimkou materiálů, je to kód. Místo výroby je to vývoj. Místo kopání orí ze země je kód zdrojem od dodavatelů, komerčního nebo opensourcového zdroje a obecně jde o opensourcový kód pocházející z úložišť. Přidání kódu z úložiště znamená, že váš produkt využívá závislost na daném kódu.
K jednomu příkladu útoku softwarového dodavatelského řetězce dochází v případě, že se k závislostem záměrně přidá škodlivý kód pomocí dodavatelského řetězce této závislosti k distribuci kódu obětem. Útoky na dodavatelský řetězec jsou reálné. Existuje mnoho metod útoku na dodavatelský řetězec, od přímé vložení škodlivého kódu jako nového přispěvatele, až po převzetí účtu přispěvatele bez toho, aby ostatní nezasáhli, nebo dokonce ohrozit podpisový klíč pro distribuci softwaru, který není oficiálně součástí závislosti.
Útok softwarového dodavatelského řetězce je jen zřídka konečným cílem, spíše je to začátek příležitosti, kdy útočník vloží malware nebo poskytne zadní vrátka pro budoucí přístup.
Nepatchovaný software
Současné použití open source je významné a neočekává se, že se brzo zpomalí. Vzhledem k tomu, že nebudeme přestat používat opensourcový software, hrozba zabezpečení dodavatelského řetězce je nepatchovaný software. Víte, jak můžete vyřešit riziko, že závislost vašeho projektu má ohrožení zabezpečení?
- Znalost toho, co je ve vašem prostředí K pochopení rizik těchto závislostí, jako jsou ohrožení zabezpečení nebo licenční omezení, je potřeba zjistit závislosti a jakékoli přechodné závislosti.
- Spravujte závislosti. Když zjistíte nové ohrožení zabezpečení, musíte určit, jestli se vás to týká, a pokud ano, aktualizovat na nejnovější verzi a dostupnou opravu zabezpečení. To je zvlášť důležité ke kontrole změn, které zavádějí nové závislosti nebo pravidelně audituje starší závislosti.
- Monitorujte svůj dodavatelský řetězec. To je auditování kontrolních mechanismů, které máte k dispozici ke správě závislostí. To vám pomůže vynutit splnění více omezujících podmínek pro vaše závislosti.
Probereme různé nástroje a techniky, které Poskytuje NuGet a GitHub, které můžete použít dnes k řešení potenciálních rizik v rámci projektu.
Znalost toho, co je ve vašem prostředí
Balíčky se známými ohroženími zabezpečení
📦 Příjemce balíčku | 📦🖊 Autor balíčku
.NET 8 a Visual Studio 17.8 přidaly NuGetAudit, což upozorní na přímé balíčky se známými ohroženími zabezpečení během obnovení. .NET 9 a Visual Studio 17.12 změnily výchozí nastavení tak, aby se zobrazovaly upozornění na tranzitivní balíčky.
NuGetAudit vyžaduje, aby zdroj poskytoval známou databázi ohrožení zabezpečení, takže pokud nepoužíváte nuget.org jako zdroj balíčku, měli byste ji přidat jako zdroj auditu.
V době, kdy vás NuGet upozorní, je ohrožení zabezpečení veřejně známé. Útočníci můžou toto veřejné zveřejnění použít k vývoji útoků pro cíle, které své aplikace neopravily. Proto když se zobrazí upozornění, že balíček, který váš projekt používá, má známé ohrožení zabezpečení, měli byste rychle provést akci.
Graf závislostí NuGet
📦 Příjemce balíčku
Závislosti NuGet v projektu můžete zobrazit tak, že se podíváte přímo na příslušný soubor projektu.
Obvykle se nachází na jednom ze dvou míst:
packages.config– Nachází se v kořenovém adresáři projektu.<PackageReference>– Nachází se v souboru projektu.
V závislosti na tom, jakou metodu používáte ke správě závislostí NuGet, můžete také pomocí sady Visual Studio zobrazit závislosti přímo v Průzkumník řešení nebo Správce balíčků NuGet.
V prostředích rozhraní příkazového dotnet list package řádku můžete pomocí příkazu vypsat závislosti projektu nebo řešení.
Pomocí příkazu můžete také dotnet nuget why zjistit, proč se do grafu balíčků projektu zahrnou tranzitivní balíčky (na ty, na které váš projekt přímo neodkazuje).
Další informace o správě závislostí NuGet najdete v následující dokumentaci.
Graf závislosti GitHubu
📦 Příjemce balíčku | 📦🖊 Autor balíčku
Graf závislostí GitHubu můžete použít k zobrazení balíčků, na které projekt závisí, a na úložištích, která na něm závisejí. To vám může pomoct zobrazit všechna ohrožení zabezpečení zjištěná v jejích závislostech.
Další informace o závislostech úložiště GitHub najdete v následující dokumentaci.
Verze závislostí
📦 Příjemce balíčku | 📦🖊 Autor balíčku
Abyste zajistili zabezpečený dodavatelský řetězec závislostí, budete chtít zajistit, aby se všechny vaše závislosti a nástroje pravidelně aktualizovaly na nejnovější stabilní verzi, protože často obsahují nejnovější funkce a opravy zabezpečení známých ohrožení zabezpečení. Mezi závislosti můžou patřit kód, na který závisíte, binární soubory, které používáte, nástroje, které používáte, a další komponenty. Může to zahrnovat:
Správa závislostí
Zastaralé a zranitelné závislosti NuGet
📦 Příjemce balíčku | 📦🖊 Autor balíčku
Pomocí rozhraní příkazového řádku dotnet můžete zobrazit seznam všech známých zastaralých nebo ohrožených závislostí, které můžete mít v projektu nebo řešení.
Můžete použít příkaz dotnet list package --deprecated nebo dotnet list package --vulnerable zadat seznam všech známých vyřazení nebo ohrožení zabezpečení.
NuGetAudit vás může varovat před známými ohroženými závislostmi a je ve výchozím nastavení povolen, pokud zdroj poskytuje databázi ohrožení zabezpečení.
Ohrožené závislosti GitHubu
📦 Příjemce balíčku | 📦🖊 Autor balíčku
Pokud je váš projekt hostovaný na GitHubu, můžete využít GitHub Security k vyhledání ohrožení zabezpečení a chyb v projektu a Dependabot je vyřeší otevřením žádosti o přijetí změn proti základu kódu.
Zachycení ohrožených závislostí před jejich zavedením je jedním z cílů pohybu "Shift Left" . Schopnost mít informace o závislostech, jako jsou jejich licence, tranzitivní závislosti a věk závislostí, vám to pomůže.
Další informace o výstrahách a aktualizacích zabezpečení Dependabot najdete v následující dokumentaci.
Informační kanály NuGet
📦 Příjemce balíčku
Použijte zdroje balíčků, kterým důvěřujete. Pokud používáte několik veřejných a privátních zdrojových kanálů NuGet, můžete balíček stáhnout z libovolného informačního kanálu. Pokud chcete zajistit, aby vaše sestavení bylo předvídatelné a zabezpečené před známými útoky, jako je například záměna závislostí, je osvědčeným postupem vědět, jaké konkrétní kanály vaše balíčky pocházejí. Pro ochranu můžete použít jeden informační kanál nebo privátní kanál s upstreamovými možnostmi.
Další informace o zabezpečení informačních kanálů balíčků najdete v tématu 3 Způsoby zmírnění rizika při používání informačních kanálů privátních balíčků.
Při použití privátního informačního kanálu si projděte osvědčené postupy zabezpečení pro správu přihlašovacích údajů.
Zásady důvěryhodnosti klientů
📦 Příjemce balíčku
Existují zásady, ke kterým se můžete přihlásit, ve kterých potřebujete balíčky, které používáte k podepsání. To vám umožní důvěřovat autorovi balíčku, pokud je podepsaný autorem, nebo důvěřovat balíčku, pokud je vlastníkem konkrétního uživatele nebo účtu, který je úložištěm podepsaným NuGet.org.
Informace o konfiguraci zásad důvěryhodnosti klientů najdete v následující dokumentaci.
Uzamčení souborů
📦 Příjemce balíčku
Uzamčení souborů ukládá hodnotu hash obsahu balíčku. Pokud hodnota hash obsahu balíčku, který chcete nainstalovat, odpovídá souboru zámku, zajistí opakovatelnost balíčku.
Pokud chcete povolit zamykací soubory, prohlédněte si následující dokumentace.
Mapování zdroje balíčků
📦 Příjemce balíčku
Mapování zdrojů balíčků umožňuje centrálně deklarovat, ze kterého zdrojového balíčku v řešení by se měl obnovit ze souboru nuget.config.
Pokud chcete povolit mapování zdrojů balíčků, přečtěte si následující dokumentaci.
Zabezpečení počítačů
Oprávnění adresáře
📦 Příjemce balíčku
V systémech Windows a Mac a některé linuxové distribuce jsou domovské adresáře uživatelských účtů ve výchozím nastavení soukromé. Některé distribuce Linuxu ale ve výchozím nastavení umožňují čtení uživatelských adresářů jinými účty ve stejném počítači. Kromě toho existuje několik možností konfigurace pro přesměrování složky globálních balíčků NuGet a mezipaměti HTTP do jiných než výchozích umístění. Řešení, projekty a úložiště se můžou také vytvářet mimo domovský adresář uživatele.
Pokud používáte všechny balíčky, které nejsou na nuget.org, pak pokud jakýkoli jiný účet v počítači může číst globální balíčky NuGetu nebo adresáře mezipaměti HTTP nebo výstupní adresář sestavení projektu, mohou být tyto balíčky zpřístupněny lidem, kteří by k těmto balíčkům neměli mít přístup.
V Linuxu změní oprávnění souboru nuget.config tak, dotnet nuget update source aby byl jen čitelný vlastníkem souboru.
Pokud ale soubor nuget.config upravíte jiným způsobem a soubor je v umístění, kde ho můžou číst jiné účty, můžou být informace o zdrojové adrese URL balíčku nebo přihlašovacích údajích ke zdroji balíčku.
Měli byste zajistit, aby ostatní uživatelé stejného počítače nemohli číst jakýkoli soubor nuget.config.
Řešení v adresáři pro stahování
📦 Příjemce balíčku
Pokud pracujete na řešeních nebo projektech v adresáři pro stahování, je potřeba věnovat zvláštní pozornost. NuGet bude shromažďovat nastavení z více konfiguračních souborů a NÁSTROJ MSBuild obvykle importuje adresář.Build.props, Directory.NuGet.props, Directory.Build.targets a potenciálně i jiné soubory z jakéhokoli nadřazeného adresáře přímo do kořenového adresáře systému souborů.
Složka pro stahování má další riziko, protože je to obvykle výchozí umístění, ve kterých webové prohlížeče stáhnou soubory z internetu.
Agenti sestavení
📦 Příjemce balíčku
Agenti sestavení (agenti CI), kteří se nenulují do počátečního stavu po každém sestavení, mají více rizik, která je potřeba zvážit.
Informace o zabezpečených způsobech správy přihlašovacích údajů najdete v dokumentaci k využívání balíčků z ověřených informačních kanálů.
Další informace o úpravě adresářů, do které NuGet ukládá data, najdete v dokumentaci ke správě globálních balíčků, mezipaměti a dočasných složek. Tyto adresáře by měly být nakonfigurované na adresář, který agent CI po každém sestavení vyčistí.
Mějte na paměti, že všechny balíčky používané vaším projektem můžou zůstat ve výstupním adresáři sestavení projektu. Pokud váš projekt používá balíčky z ověřených zdrojů, můžou ostatní uživatelé stejného agenta CI získat neoprávněný přístup k sestavením balíčku. Proto byste také měli vyčistit úložiště na konci sestavení, i když se sestavení nezdaří nebo se zruší.
Monitorování dodavatelského řetězce
Kontrola tajných kódů GitHubu
📦🖊 Autor balíčku
GitHub prohledává úložiště klíčů rozhraní API NuGet, aby se zabránilo podvodnému použití tajných kódů, které byly omylem potvrzeny.
Další informace o kontrole tajných kódů najdete v tématu O kontrole tajných kódů.
Podepisování balíčků pro vytváření
📦🖊 Autor balíčku
Podepisování obsahu umožňuje autorovi balíčku razítek identity na balíčku a pro příjemce, aby ho ověřil, že pochází od vás. To vás chrání před manipulací s obsahem a slouží jako jediný zdroj pravdy o původu balíčku a pravosti balíčku. V kombinaci se zásadami důvěryhodnosti klientů můžete ověřit, že balíček pochází od konkrétního autora.
Pokud chcete balíček podepsat, přečtěte si téma Podepsání balíčku.
Reprodukovatelné buildy
📦🖊 Autor balíčku
Reprodukovatelné sestavení vytváří binární soubory, které jsou při každém sestavení identické bajty, a obsahují odkazy zdrojového kódu a metadata kompilátoru, které umožňují příjemci balíčku znovu vytvořit binární soubor přímo a ověřit, že prostředí sestavení nebylo ohroženo.
Další informace o reprodukovatelných buildech najdete v tématu Vytváření balíčků se zdrojovým propojením a specifikacemi reprodukovatelného ověření sestavení.
Dvojúrovňové ověřování (2FA)
📦🖊 Autor balíčku
Každý účet na nuget.org má povolené 2FA. Tím se při přihlašování k účtu GitHub nebo účtu NuGet.org přidá další vrstva zabezpečení.
Rezervace předpony ID balíčku
📦🖊 Autor balíčku
Pokud chcete chránit identitu balíčků, můžete si rezervovat předponu ID balíčku s příslušným oborem názvů, abyste přidružili odpovídajícího vlastníka, pokud předpona ID balíčku správně spadá do zadaných kritérií.
Další informace o rezervaci předpon ID najdete v tématu Rezervace předpon ID balíčku.
Vyřazení a zrušení seznamu ohrožených balíčků
📦🖊 Autor balíčku
Pokud chcete chránit ekosystém balíčků .NET v případě, že víte o ohrožení zabezpečení v balíčku, který jste vytvořili, je nejlepší balíček vypsat a zrušit jeho seznam, aby byl skrytý uživatelům, kteří hledají balíčky. Pokud používáte balíček, který je zastaralý a není v seznamu, měli byste se vyhnout použití balíčku.
Informace o vyřazení a zrušení zařazení balíčku najdete v následující dokumentaci k vyřazení a zrušení seznamu balíčků.
Zvažte také hlášení známé databáze Advisories GitHubu.
Shrnutí
Váš softwarový dodavatelský řetězec je cokoli, co přejde do kódu nebo ovlivňuje váš kód. I když jsou kompromisy v dodavatelském řetězci reálné a stále roste popularita, jsou stále vzácné; Nejdůležitější věc, kterou můžete udělat, je chránit váš dodavatelský řetězec tím, že si uvědomujete závislosti, spravujete závislosti a monitorujete dodavatelský řetězec.
Dozvěděli jste se o různých metodách, které NuGet a GitHub poskytují, které jsou pro vás dnes k dispozici, aby byly efektivnější při prohlížení, správě a monitorování dodavatelského řetězce.
Další informace o zabezpečení softwaru na světě naleznete v tématu Stav Octoverse 2020 Security Report.