Wanneer drie Amerikaanse overheidsinstanties samenkomen om ontwikkelaars “sterk aan te moedigen” om bepaalde praktijken toe te passen, moet u opletten. De CISA, NSA en ODNI hebben, als erkenning van de dreiging van cyberhackers en in de nasleep van de SolarWinds-aanval, aangekondigd dat zij gezamenlijk een verzameling aanbevelingen zullen publiceren voor het beveiligen van de softwaretoeleveringsketen om dergelijke kwetsbaarheden in de toekomst te voorkomen. . De aankondiging maakte duidelijk dat het doel van het document is om ontwikkelaars aan te moedigen best practices toe te passen, en stelt dat “Deze principes omvatten het plannen van beveiligingsvereisten, het ontwerpen van softwarearchitectuur vanuit een beveiligingsperspectief, het toevoegen van beveiligingsfuncties en het handhaven van de beveiliging van software en de onderliggende infrastructuur."
Deze richtlijnen zijn georganiseerd als een driedelige serie en zullen samenvallen met de levenscyclus van de softwaretoeleveringsketen. Deel 1 van de serie, dat zich richt op aanbevelingen voor softwareontwikkelaars, is in augustus 2022 uitgebracht. De overige twee delen zullen in de nabije toekomst verschijnen: deel 2 zal zich richten op de softwareleveranciers en deel 3 zal zich richten op de klanten die de software ontvangen. Het uiteindelijke doel is dat deze serie de communicatie tussen deze drie belangrijkste belanghebbenden en tussen cyberbeveiligingsprofessionals zal helpen bevorderen om een grotere veerkracht te vergemakkelijken en de algehele veiligheid te verbeteren. beveiliging van de toeleveringsketen van software.
Hoewel het niet altijd duidelijk is wiens verantwoordelijkheid het is om de softwarebeveiliging te garanderen, ongeacht wie de algehele verantwoordelijkheid draagt in uw specifieke organisatie, kan dit nieuwe gids maakt heel duidelijk dat alle ontwikkelaars vertrouwd moeten raken met deze nieuwe best practices en dat ze allemaal een rol spelen bij het beveiligen van de softwaretoeleveringsketen. Of, als ik botter mag zijn: Ontwikkelaars, jullie spelen een cruciale rol bij het beveiligen van de softwaretoeleveringsketen van uw organisatie! En om die reden dachten we dat je het misschien handig zou vinden om speciaal voor jou een (relatief) korte samenvatting van dit eerste deel van de gids te lezen. Hier komt het.
De gids in een notendop:
Onder de uitgebreide lijsten met potentiële bedreigingen waarnaar in deze praktische gids voor ontwikkelaars wordt verwezen, zijn er enkele belangrijke kwetsbaarheden geïdentificeerd. Zorg ervoor dat u deze aanpakt en erop voorbereidt:
- Functies die niet goed zijn gedocumenteerd of die risicovolle functionaliteit implementeren
- Onder de radar voorkomende verschuivingen in de belangrijkste aannames op het gebied van beveiliging tussen het moment van de beveiligingsbeoordeling en de levering van de code
- Bedrijfsveranderingen voor belanghebbenden in de toeleveringsketen
- Ondermaatse coderings- of beveiligingspraktijken
Management, financiën en programmamanagers hebben allemaal de verantwoordelijkheid om de veiligheid van de softwaretoeleveringsketen aan te pakken, maar ook de integriteit ervan beveiliging van de toeleveringsketen van software hangt vaak af van de waakzaamheid van softwareontwikkelaars en het bewustzijn onder alle belanghebbenden in de toeleveringsketen. Deel 1 van de gids richt zich op de rol van ontwikkelaars en de bedreigingen die inherent zijn aan elke fase van het ontwikkelingsproces, en biedt aanbevelingen voor mitigatiestrategieën die standaardpraktijken zouden moeten worden.
Fase # 1: Veilige productcriteria en -beheer
Veilige ontwikkeling begint met de erkenning van het belang van de beveiliging van de softwaretoeleveringsketen door alle belangrijke belanghebbenden in de product- en ontwikkelingsteams. De dreigingsscenario’s zijn gebruikelijk en wellicht voor iedereen duidelijk; de uitdaging is om iedereen op één lijn te krijgen met betrekking tot het mitigatiebeleid waartoe is besloten. Dit beleid moet het hele proces bestrijken: het ontwerp en de architectuur, de dreigingsmodellering, de codering, de beveiligingstestplannen, de releasecriteria en de manier waarop kwetsbaarheden in de toekomst kunnen worden beheerd. Een deel hiervan omvat ook het beoordelen van de capaciteiten van de teams en het garanderen dat ze goed zijn opgeleid voor hun taken, en vervolgens het definiëren van documentatiepraktijken en periodieke beveiligingsbeoordelingen en dreigingsbeoordelingen.
Fase #2: Veilige codeontwikkeling
Als het gaat om codeontwikkeling, zijn de juiste praktijken voor veilige codering al uiteengezet in de SSDF. Dit is de reden dat, voor zover de programmeertaal niet vooraf is bepaald, ook veiligheidsoverwegingen deel moeten uitmaken van die beslissing. De gids levert nuttige begeleiding op voor ontwikkelaars, waarbij een breed scala aan scenario's wordt behandeld, zoals het inbrengen van schadelijke broncode door 'insiders' (bijvoorbeeld ontwikkelaars), open-sourcesoftware en de beste praktijken om hiermee om te gaan. Hoe u een veilige omgeving voor codering kunt creëren (inclusief veilige bouwconfiguraties en softwaretools van derden) en vervolgens de beveiliging van een geïntegreerd product kunt testen. Omdat het waarschijnlijk is dat er ook na de oplevering kwetsbaarheden zullen optreden, zijn er ook aanbevelingen voor het omgaan met gemelde kwetsbaarheden en het garanderen dat toekomstige externe software-uitbreidingen de beveiligingsintegriteit van het product niet in gevaar brengen.
Fase 3: verhard de bouwomgeving
Zodra de code veilig is ontwikkeld, vereist de beveiliging van de softwaretoevoerketen dat de bouwomgeving wordt gehard volgens dezelfde normen als de software zelf. Het compromitteren van het buildsysteem is een aantrekkelijke manier om de code te infiltreren, omdat dit in een fase van het ontwikkelingsproces komt die uiteraard minder onder de loep wordt genomen door ontwikkelaars.
Fase # 4: Levering van code
De laatste zwakte die in de gids aan de orde komt, heeft betrekking op de laatste fase van de softwaretoeleveringsketen: de levering van code. Zelfs als de code tot nu toe goed is beveiligd, zijn er nog steeds twee belangrijke kwetsbaarheden in de toeleveringsketen die moeten worden verholpen. De eerste is de uiteindelijke pakketvalidatie, die kan worden misbruikt door bijvoorbeeld onbedoeld metadata, ontwikkelaarsreferenties of de open-source-inventaris bloot te leggen. De andere stap die vaak op zwakke punten wordt onderzocht, is het distributiesysteem, dat in gevaar kan worden gebracht door een man-in-the-middle-aanval die een of meer fasen van de levering kan overnemen.
Door deze risicobeperkende praktijken op softwareontwikkelingsniveau toe te passen, kunnen softwareleveranciers zwakke punten vermijden die bijvoorbeeld kunnen leiden tot de infiltratie van updates, manipulatie van codeondertekening en ‘verrassingen’ die verborgen zijn in open source-code.
Er bestaat niet zoiets als een gratis lunch: de verborgen kosten van software van derden
Een sleutel bijdrage aan de snelheid van ontwikkelaars is de mogelijkheid geworden om software van derden effectief te integreren. Dit heeft het voor ontwikkelaars mogelijk gemaakt om zich bijvoorbeeld te concentreren op innovatie of functionaliteit, terwijl ze kant-en-klare componenten gebruiken voor schaalbaarheid of interfaces. Dit toegenomen gebruik van software van derden heeft een grote uitdaging gecreëerd voor de beveiliging van de softwaretoeleveringsketen. Naast het uitvoeren van een beoordeling van dergelijke code in overeenstemming met dezelfde normen die worden gebruikt om uw eigen code te beoordelen, stelt de gids voor om de binaire bestanden te scannen op eventuele kwetsbaarheden en de daaruit voortvloeiende risico's te evalueren. De resultaten van deze evaluatie moeten een rol spelen bij de beslissing om een specifieke softwarecomponent wel of niet te gebruiken. Bij de selectie van een softwarecomponent moet ook rekening worden gehouden met de bron ervan; Het opnemen van componenten van derden in uw broncode is het begin van een lange relatie en u moet ernaar streven om samen te werken met partners die u kunt vertrouwen. Code-eigendom, codeerpraktijken en versiebeheerbeleid zijn slechts enkele punten waarmee u rekening moet houden bij het selecteren van een vertrouwde bron. Denk maar aan alle toekomstige updates, releases en onderhoudswerkzaamheden voor elk onderdeel wanneer er nieuwe bedreigingen worden ontdekt. De uitdaging zal zijn om alle wijzigingen van derden te monitoren, te beoordelen op kwetsbaarheden en dienovereenkomstig te reageren, soms onder zware tijdsdruk.
Verhoog de beveiliging van uw software supply chain met een SBOM
Een belangrijke praktijk om de integriteit van uw softwaretoeleveringsketen op lange termijn te garanderen, is het up-to-date houden van uw softwaretoeleveringsketen Software stuklijst (SBOM). De SBOM is een gedetailleerde inventarisatie van de softwarecomponenten waaruit een bepaalde oplossing bestaat.
Dit bespaart u tijd en moeite, en, belangrijker nog, het vermindert uw blootstelling aan voortdurende bedreigingen. Elke softwarecomponent die in uw product wordt geïntegreerd, moet worden geleverd met een eigen SBOM, die moet worden gevalideerd en samengevoegd tot één 'master'-SBOM voor het product. Als u van plan bent componenten op te nemen die niet met een SBOM worden geleverd, moet u uw eigen analyse uitvoeren met behulp van tools voor softwarecompositieanalyse (SCA).
Hoe nauwkeuriger en beschrijvender de SBOM is, hoe gemakkelijker deze te onderhouden en te raadplegen is. Gezien de duizelingwekkende snelheid waarmee softwarecomponenten worden bijgewerkt, goed gestructureerde SBOM zal zijn vruchten afwerpen wanneer het tijd is om elke update, patch of release op te sporen en vast te leggen. Nog belangrijker: zodra een beveiligingsbedreiging wordt ontdekt, is elk moment van cruciaal belang. OnthoudenDe beveiliging van uw softwaretoeleveringsketen zal altijd zo sterk zijn als je zwakste schakel. Als er tientallen softwarecomponenten in gevaar zijn, zult u dankbaar zijn voor een SBOM die alle antwoorden heeft.
Voor een efficiënte workflow moet een bruikbare SBOM in ieder geval deze drie componenten bevatten:
- Data velden – Dit zijn de descriptors voor de componenten die u heeft geïmplementeerd. Het gemakkelijk kunnen identificeren welke componenten zijn gebruikt, zelfs lang nadat de ontwikkeling is voltooid, helpt om deze effectief te monitoren op kwetsbaarheden.
- Automatisering ondersteuning – Automatische monitoring van de SBOM vereist dat deze ook worden geïdentificeerd in een van de geaccepteerde machineleesbare formaten.
- Praktijken en beloften – Het beheren van een SBOM vereist een gemeenschappelijk begrip van onderhoudspraktijken, zoals de frequentie van versies, afhankelijkheden, bekende onbekenden, distributie en levering, toegangscontrole en hoe om te gaan met fouten.
Het delen van de SBOM onder de belanghebbenden van een specifiek product (de softwareontwikkelaar, de softwareleverancier en de klant) helpt de transparantie en afstemming te bevorderen, waardoor het vermogen van een softwaretoeleveringsketen om het product te verdedigen tegen beveiligingsbedreigingen wordt vergroot. Opgemerkt moet worden dat, gezien alle bewegende delen in een softwaretoeleveringsketen, het consequent onderhouden van een dergelijke SBOM – een SBOM waarnaar gemakkelijk kan worden verwezen, gemonitord en onderhouden – een complexe uitdaging is.
Slotwoorden: Hoe kunt u de beveiliging van uw software supply chain naar een hoger niveau tillen?
Nu de beveiliging van de softwaretoeleveringsketen steeds belangrijker wordt, worden organisaties herhaaldelijk uitgedaagd om transparant vertrouwen op te bouwen in de software die zij leveren of gebruiken. Omdat de acceptatie van de SBOM als best practice naar verwachting zal toenemen, is het hebben van een tool waarmee u deze uitdaging kunt overwinnen een belangrijke stap in de richting van het realiseren van beveiliging van de softwaretoeleveringsketen. Daarom hebben we onlangs de eerste evidence-based beveiligingshub voor softwareproducten gelanceerd, waardoor gebruikers vertrouwen in hun software kunnen opbouwen binnen teams en organisaties. Dit gebruiksvriendelijke platform zal ontwikkelingsteams helpen de risico's van de softwaretoeleveringsketen te beperken door de SBOM toegankelijk en gebruiksvriendelijk te maken, en vooral:maak de beveiliging van softwareproducten transparant voor klanten, kopers en beveiligingsteams.
Als u zich als softwareontwikkelaar zorgen maakt over de bedreigingen voor de veiligheid van uw softwaretoeleveringsketen, raden wij u aan dit te doen probeer het platform eens uit; het is gratis te gebruiken, zonder verplichtingen. Door onze workflow te implementeren, kunt u uw SBOM's binnen uw supply chain delen.
Deze inhoud wordt u aangeboden door Scribe Security, een toonaangevende aanbieder van end-to-end software supply chain-beveiligingsoplossingen die state-of-the-art beveiliging levert voor codeartefacten en codeontwikkelings- en leveringsprocessen in de software supply chain. Meer informatie.
Gerelateerde berichten
