Best practices voor een veilige softwareleveringsketen

Open Source is overal. Het is in veel exclusieve codebases en communityprojecten. Voor organisaties en personen is de vraag vandaag niet of u opensource-code wel of niet gebruikt, maar welke opensource-code u gebruikt en hoeveel.

Als u zich niet bewust bent van wat zich in de toeleveringsketen van uw software bevindt, kan een upstream-beveiligingsprobleem in een van uw afhankelijkheden fataal zijn, waardoor u en uw klanten kwetsbaar zijn voor een potentieel compromis. In dit document gaan we dieper in op wat de term 'softwareleveringsketen' betekent, waarom het belangrijk is en hoe u de toeleveringsketen van uw project kunt beveiligen met best practices.

Afhankelijkheden

De term software supply chain wordt gebruikt om te verwijzen naar alles wat in uw software gaat en waar deze vandaan komt. Het zijn de afhankelijkheden en eigenschappen van uw afhankelijkheden waarvan uw softwareleveringsketen afhankelijk is. Een afhankelijkheid is wat uw software moet uitvoeren. Dit kunnen code, binaire bestanden of andere onderdelen zijn en waar ze vandaan komen, zoals een opslagplaats of pakketbeheer.

Het bevat wie de code heeft geschreven, wanneer deze werd bijgedragen, hoe deze is beoordeeld op beveiligingsproblemen, bekende beveiligingsproblemen, ondersteunde versies, licentiegegevens en alles wat het op elk moment van het proces aanraakt.

Uw toeleveringsketen omvat ook andere onderdelen van uw stack buiten één toepassing, zoals uw build- en verpakkingsscripts of de software waarop de infrastructuur wordt uitgevoerd waarvan uw toepassing afhankelijk is.

Kwetsbaarheden

Tegenwoordig zijn softwareafhankelijkheden overal aanwezig. Het is gebruikelijk dat uw projecten honderden opensource-afhankelijkheden gebruiken voor functionaliteit die u niet zelf hoeft te schrijven. Dit kan betekenen dat de meeste van uw toepassing bestaat uit code die u niet hebt geschreven.

Mogelijke beveiligingsproblemen in uw externe of opensource-afhankelijkheden zijn waarschijnlijk afhankelijkheden die u niet zo nauwkeurig kunt beheren als de code die u schrijft, waardoor potentiële beveiligingsrisico's in uw toeleveringsketen kunnen ontstaan.

Als een van deze afhankelijkheden een beveiligingsprobleem heeft, is de kans groot dat u ook een beveiligingsprobleem hebt. Dit kan eng zijn omdat een van uw afhankelijkheden kan veranderen zonder dat u het weet. Zelfs als er momenteel een beveiligingsprobleem in een afhankelijkheid bestaat, maar niet kan worden misbruikt, kan dit in de toekomst worden misbruikt.

Als u gebruik kunt maken van het werk van duizenden opensource-ontwikkelaars en bibliotheekauteurs, betekent dit dat duizenden vreemden effectief kunnen bijdragen aan uw productiecode. Uw product, via uw software-toeleveringsketen, wordt beïnvloed door niet-gepatchte beveiligingsproblemen, onschuldige fouten of zelfs schadelijke aanvallen op afhankelijkheden.

Compromissen in de toeleveringsketen

De traditionele definitie van een toeleveringsketen komt van productie; het is de keten van processen die nodig zijn om iets te maken en te leveren. Het omvat planning, levering van materialen, productie en detailhandel. Een softwareleveringsketen is vergelijkbaar, behalve in plaats van materialen, het is code. In plaats van productie is het ontwikkeling. In plaats van erts uit de grond te delven, wordt code verkregen van leveranciers, commerciële of open-source leveranciers, en over het algemeen komt de open-source code uit repositories. Het toevoegen van code uit een opslagplaats betekent dat uw product afhankelijk is van die code.

Een voorbeeld van een software supply chain-aanval treedt op wanneer schadelijke code doelbewust wordt toegevoegd aan een afhankelijkheid, met behulp van de toeleveringsketen van die afhankelijkheid om de code naar de slachtoffers te distribueren. Toeleveringsketenaanvallen zijn echt. Er zijn veel methoden om een toeleveringsketen aan te vallen, van het rechtstreeks invoegen van schadelijke code als een nieuwe inzender, tot het overnemen van het account van een inzender zonder dat anderen hiervan opvallen, of zelfs een ondertekeningssleutel in gevaar brengen om software te distribueren die niet officieel deel uitmaakt van de afhankelijkheid.

Een software supply chain-aanval is op zichzelf zelden het einddoel, in plaats daarvan is het het begin van een kans voor een aanvaller om malware in te voegen of een backdoor te bieden voor toekomstige toegang.

Niet-gepatchte software

Het gebruik van open source is tegenwoordig aanzienlijk en zal naar verwachting niet snel vertragen. Gezien het feit dat we niet stoppen met het gebruik van opensource-software, is de bedreiging voor de beveiliging van de toeleveringsketen niet-gepatchte software. Weet u dat, hoe kunt u het risico aanpakken dat een afhankelijkheid van uw project een beveiligingsprobleem heeft?

• Weten wat er in uw omgeving is. Hiervoor moeten uw afhankelijkheden en eventuele transitieve afhankelijkheden worden ontdekt om inzicht te hebben in de risico's van deze afhankelijkheden, zoals beveiligingsproblemen of licentiebeperkingen.
• Beheer uw afhankelijkheden. Wanneer er een nieuw beveiligingsprobleem wordt gedetecteerd, moet u bepalen of dit van invloed is en zo ja, bijwerken naar de nieuwste versie en beveiligingspatch die beschikbaar is. Dit is vooral belangrijk om wijzigingen te bekijken die nieuwe afhankelijkheden introduceren of regelmatig oudere afhankelijkheden controleren.
• Bewaak uw toeleveringsketen. Dit doet u door de controles te beoordelen die u hebt om uw afhankelijkheden te beheren. Zo kunt u afdwingen dat aan meer beperkende voorwaarden wordt voldaan voor uw afhankelijkheden.

We behandelen verschillende hulpprogramma's en technieken die NuGet en GitHub bieden, die u vandaag kunt gebruiken om potentiële risico's binnen uw project aan te pakken.

Weten wat er in uw omgeving is

Pakketten met bekende beveiligingsproblemen

📦 Pakketgebruiker | 📦🖊 Pakketauteur

.NET 8 en Visual Studio 17.8 hebben NuGetAudit toegevoegd, waarmee wordt gewaarschuwd voor directe pakketten met bekende beveiligingsproblemen tijdens het herstellen. .NET 9 en Visual Studio 17.12 hebben de standaardinstelling gewijzigd om ook te waarschuwen voor transitieve pakketten.

NuGetAudit vereist een bron om een database met bekende beveiligingsproblemen op te geven. Als u dus niet nuget.org als pakketbron gebruikt, moet u deze toevoegen als een controlebron.

Op het moment dat NuGet u waarschuwt, is het beveiligingsprobleem openbaar bekend. Aanvallers kunnen deze openbaarmaking gebruiken om aanvallen te ontwikkelen voor doelen die hun toepassingen niet hebben gepatcht. Als u daarom een waarschuwing krijgt dat een pakket dat uw project gebruikt een bekend beveiligingsprobleem heeft, moet u snel actie ondernemen.

NuGet-afhankelijkheidsgrafiek

📦 Pakketgebruiker

U kunt uw NuGet-afhankelijkheden in uw project bekijken door rechtstreeks naar het respectieve projectbestand te kijken.

Dit vindt u meestal op een van de volgende twee plaatsen:

• packages.config – Bevindt zich in de hoofdmap van het project.
• <PackageReference> – Bevindt zich in het projectbestand.

Afhankelijk van de methode die u gebruikt om uw NuGet-afhankelijkheden te beheren, kunt u Visual Studio ook gebruiken om uw afhankelijkheden rechtstreeks in Solution Explorer of NuGet Package Manager weer te geven.

Voor CLI-omgevingen kunt u de dotnet list package opdracht gebruiken om de afhankelijkheden van uw project of oplossing weer te geven. U kunt ook de dotnet nuget why opdracht gebruiken om te begrijpen waarom transitieve pakketten (die niet rechtstreeks naar uw project worden verwezen) worden opgenomen in de pakketgrafiek van uw project.

Zie de volgende documentatie voor meer informatie over het beheren van NuGet-afhankelijkheden.

GitHub-afhankelijkheidsgrafiek

📦 Pakketgebruiker | 📦🖊 Pakketauteur

U kunt de afhankelijkheidsgrafiek van GitHub gebruiken om de pakketten te zien waarop uw project afhankelijk is en de opslagplaatsen die ervan afhankelijk zijn. Dit kan u helpen bij het bekijken van eventuele beveiligingsproblemen die zijn gedetecteerd in de afhankelijkheden.

Zie de volgende documentatie voor meer informatie over afhankelijkheden van GitHub-opslagplaatsen.

Afhankelijkheidsversies

📦 Pakketgebruiker | 📦🖊 Pakketauteur

Om een veilige toeleveringsketen van afhankelijkheden te garanderen, moet u ervoor zorgen dat al uw afhankelijkheden en hulpprogramma's regelmatig worden bijgewerkt naar de nieuwste stabiele versie, omdat ze vaak de nieuwste functionaliteit en beveiligingspatches bevatten voor bekende beveiligingsproblemen. Uw afhankelijkheden kunnen code bevatten die u afhankelijk bent, binaire bestanden die u gebruikt, hulpprogramma's die u gebruikt en andere onderdelen. Dit kan omvatten:

• Visual Studio
• .NET SDK & Runtime
• NuGet
• NuGet-pakketten

Uw afhankelijkheden beheren

NuGet afgeschafte en kwetsbare afhankelijkheden

📦 Pakketgebruiker | 📦🖊 Pakketauteur

U kunt de dotnet CLI gebruiken om alle bekende afgeschafte of kwetsbare afhankelijkheden weer te geven die u mogelijk in uw project of oplossing hebt. U kunt de opdracht dotnet list package --deprecated of dotnet list package --vulnerable gebruiken om u een lijst met bekende afschaffingen of beveiligingsproblemen te geven. NuGetAudit kan u waarschuwen voor bekende kwetsbare afhankelijkheden en is standaard ingeschakeld wanneer een bron een database met beveiligingsproblemen biedt.

Kwetsbare GitHub-afhankelijkheden

📦 Pakketgebruiker | 📦🖊 Pakketauteur

Als uw project wordt gehost op GitHub, kunt u Gebruikmaken van GitHub Security om beveiligingsproblemen en fouten in uw project te vinden. Dependabot lost deze op door een pull-aanvraag te openen op basis van uw codebase.

Het vangen van kwetsbare afhankelijkheden voordat ze worden geïntroduceerd, is één doel van de beweging Shift Left . Als u informatie over uw afhankelijkheden kunt hebben, zoals hun licentie, transitieve afhankelijkheden en de leeftijd van afhankelijkheden, kunt u dat doen.

Zie de volgende documentatie voor meer informatie over Dependabot-waarschuwingen en beveiligingsupdates.

NuGet-configuratie

📦 Pakketgebruiker

Voeg een nuget.config bestand toe in de hoofdmap van uw projectopslagplaats. Dit wordt beschouwd als een best practice omdat het herhaalbaarheid bevordert en ervoor zorgt dat verschillende gebruikers dezelfde NuGet-configuratie hebben. We raden u aan elementen toe te voegen clear om ervoor te zorgen dat er geen specifieke gebruikers- of computerspecifieke configuratie wordt toegepast. Lees meer over hoe instellingen worden toegepast.

Voorbeeld:

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

NuGet-feeds

📦 Pakketgebruiker

Gebruik pakketbronnen die u vertrouwt. Wanneer u meerdere openbare en persoonlijke NuGet-bronfeeds gebruikt, kan een pakket worden gedownload van een van de feeds. Om ervoor te zorgen dat uw build voorspelbaar en veilig is tegen bekende aanvallen zoals Afhankelijkheidsverwarring, is het een best practice om te weten van welke specifieke feed(s) uw pakketten afkomstig zijn. U kunt een enkele feed of privéfeed gebruiken met mogelijkheden voor upstreaming ter bescherming.

Zie drie manieren om risico's te beperken bij het gebruik van privépakketfeeds voor meer informatie over het beveiligen van uw pakketfeeds.

Wanneer u een privéfeed gebruikt, raadpleegt u de aanbevolen beveiligingsprocedures voor het beheren van referenties.

Beleid voor clientvertrouwen

📦 Pakketgebruiker

Er zijn beleidsregels waarmee u zich kunt aanmelden waarvoor u wilt dat de pakketten die u gebruikt, zijn ondertekend. Hiermee kunt u een auteur van een pakket vertrouwen, zolang deze is ondertekend of een pakket vertrouwen als het eigendom is van een specifieke gebruiker of account die is ondertekend door NuGet.org.

Raadpleeg de volgende documentatie om beleidsregels voor clientvertrouwen te configureren.

Bestanden vergrendelen

📦 Pakketgebruiker

Lockbestanden slaan de hash van de inhoud van uw pakket op. Als de inhoudshash van een pakket dat u wilt installeren overeenkomt met het vergrendelingsbestand, zorgt dit ervoor dat pakket herhaalbaar is.

Raadpleeg de volgende documentatie om vergrendelingsbestanden in te schakelen.

Pakketbrontoewijzing

📦 Pakketgebruiker

Met pakketbrontoewijzing kunt u centraal declareren welke bron elk pakket in uw oplossing moet herstellen vanuit uw nuget.config-bestand.

Raadpleeg de volgende documentatie om pakketbrontoewijzing in te schakelen.

Computers beveiligen

Mapmachtigingen

📦 Pakketgebruiker

Op Windows en Mac en sommige Linux-distributies zijn basismappen voor gebruikersaccounts standaard privé. Sommige Linux-distributies maken gebruikersmappen echter standaard leesbaar voor andere accounts op dezelfde computer. Daarnaast zijn er meerdere configuratieopties voor het omleiden van de globale pakketmap van NuGet en de HTTP-cache naar niet-standaardlocaties. Oplossingen, projecten en opslagplaatsen kunnen ook worden gemaakt buiten de basismap van de gebruiker.

Als u pakketten gebruikt die zich niet op nuget.org bevinden, dan kunnen deze pakketten worden vrijgegeven aan personen die geen toegang tot deze pakketten hebben, als een ander account op de computer de globale pakketten of HTTP-cachemappen van NuGet, of de outputmap van de build van het project kan lezen.

Op Linux worden bestandsmachtigingen van dotnet nuget update source gewijzigd zodat deze alleen door de bestandseigenaar kan worden gelezen. Als u het nuget.config bestand echter op een andere manier bewerkt en het bestand zich op een locatie bevindt waar andere accounts het bestand kunnen lezen, kan er informatie openbaar worden gemaakt over pakketbron-URL of pakketbronreferenties. Zorg ervoor dat elk nuget.config bestand niet kan worden gelezen door andere gebruikers van dezelfde computer.

Oplossingen in de map Downloads

📦 Pakketgebruiker

Er moet extra zorg worden besteed bij het werken aan oplossingen of projecten in uw downloadmap. NuGet verzamelt instellingen van meerdere configuratiebestanden en MSBuild importeert doorgaans Directory.Build.props, Directory.NuGet.props, Directory.Build.targets en mogelijk andere bestanden, vanuit elke bovenliggende map, tot aan de hoofdmap van het bestandssysteem.

De map Downloads heeft extra risico, omdat dit meestal de standaardlocatie is waar webbrowsers bestanden van internet downloaden

Agents bouwen

📦 Pakketgebruiker

Bouwagents (CI-agents) die na elke build niet worden teruggebracht naar een oorspronkelijke staat, brengen meerdere risico's met zich mee die in overweging moeten worden genomen.

Zie de documentatie over het gebruik van pakketten van geverifieerde feeds om meer te weten te komen over veilige manieren om referenties te beheren.

Zie de documenten over het beheren van de globale pakketten, cache en tijdelijke mappen voor meer informatie over het wijzigen van de mappen waarin NuGet gegevens opslaat. Deze mappen moeten worden geconfigureerd voor een map die na elke build door de CI-agent wordt opgeschoond.

Houd er rekening mee dat alle pakketten die door uw project worden gebruikt, mogelijk in de builduitvoermap van uw project worden achtergelaten. Als uw project gebruikmaakt van pakketten van geverifieerde bronnen, kunnen andere gebruikers van dezelfde CI-agent onbevoegd toegang krijgen tot de pakketassembly's. Daarom moet u uw opslagplaats ook aan het einde van de build opschonen, zelfs wanneer de build mislukt of wordt geannuleerd.

Uw toeleveringsketen bewaken

Scannen van GitHub-geheimen

📦🖊 Pakketauteur

GitHub scant opslagplaatsen voor NuGet-API-sleutels om frauduleus gebruik van geheimen te voorkomen die per ongeluk zijn doorgevoerd.

Raadpleeg Informatie over het scannen van geheimen om meer te leren over het scannen van geheimen.

Ondertekening van auteurspakket

📦🖊 Pakketauteur

Met auteursondertekening kan een pakketauteur hun identiteit in een pakket stempelen en kan een consument controleren of deze van u afkomstig is. Dit beschermt u tegen manipulatie van inhoud en fungeert als één bron van waarheid over de oorsprong van het pakket en de echtheid van het pakket. In combinatie met clientvertrouwensbeleid kunt u controleren of een pakket afkomstig is van een specifieke auteur.

Zie Een pakket ondertekenen voor instructies over het ondertekenen van een pakket.

Reproduceerbare builds

📦🖊 Pakketauteur

Reproduceerbare builds maken binaire bestanden die byte-for-byte identiek zijn telkens wanneer u deze bouwt, en bevatten broncodekoppelingen en compilermetagegevens waarmee een pakketgebruiker het binaire bestand rechtstreeks kan maken en controleert of de build-omgeving niet is aangetast.

Zie voor meer informatie over reproduceerbare builds, Producing Packages with Source Link en de Reproducible Build Validation specificatie.

Two-Factor verificatie (2FA)

📦🖊 Pakketauteur

Voor elk account op nuget.org is 2FA ingeschakeld. Hiermee wordt een extra beveiligingslaag toegevoegd wanneer u zich aanmeldt bij uw GitHub-account of uw NuGet.org-account.

Reservering voor pakket-id-voorvoegsel

📦🖊 Pakketauteur

Als u de identiteit van uw pakketten wilt beveiligen, kunt u een pakket-id-voorvoegsel reserveren bij uw respectieve naamruimte om een overeenkomende eigenaar te koppelen als het voorvoegsel van uw pakket-id juist onder de opgegeven criteria valt.

Voor meer informatie over het reserveren van id-voorvoegsels, zie Reservering voor pakket-id-voorvoegsels.

Een kwetsbaar pakket uit- en uit de lijst verwijderen

📦🖊 Pakketauteur

Als u het .NET-pakketecosysteem wilt beveiligen wanneer u op de hoogte bent van een beveiligingsprobleem in een pakket dat u hebt gemaakt, kunt u het beste het pakket verwijderen en de lijst ervan opheffen, zodat het verborgen is voor gebruikers die naar pakketten zoeken. Als u een pakket verbruikt dat is afgeschaft en niet wordt weergegeven, moet u het gebruik van het pakket vermijden.

Zie de volgende documentatie over het afkeuren en het niet-lijsten van pakketten voor meer informatie over het uit de lijst halen van pakketten.

Overweeg ook om de bekende gegevens te rapporteren aan de GitHub Advisories-database.

Samenvatting

Uw softwareleveringsketen is alles wat uw code ingaat of beïnvloedt. Hoewel toeleveringsketencompromitts echt zijn en steeds populairder worden, zijn ze nog steeds zeldzaam; Het belangrijkste wat u kunt doen, is uw toeleveringsketen beschermen door op de hoogte te zijn van uw afhankelijkheden, het beheren van uw afhankelijkheden en het bewaken van uw toeleveringsketen.

U hebt geleerd over verschillende methoden die NuGet en GitHub bieden die vandaag beschikbaar zijn om effectiever te zijn bij het bekijken, beheren en bewaken van uw toeleveringsketen.

Zie The State of the Octoverse 2020 Security Report voor meer informatie over het beveiligen van de software ter wereld.