Nu iedereen zich steeds bewuster wordt, het beschermen van uw softwaretoeleveringsketens zou een essentieel onderdeel moeten zijn van de cyberbeveiligingsstrategie van elke organisatie.
Een van de grootste problemen bij het creëren van een alomvattende strategie om bedreigingen voor de softwaretoeleveringsketen te beperken, is de complexiteit en diversiteit van toeleveringsketens. Elke toeleveringsketen is uniek en de betrokken elementen veranderen voortdurend, waardoor het moeilijk wordt om uw eigen toeleveringsketen te vertrouwen, laat staan de software die deze produceert.
In dit artikel beschrijven we een platform voor continue naleving waarmee softwareconsumenten en -producenten op transparante wijze vertrouwen en naleving kunnen aantonen om SDLC te beveiligen, best practices op het gebied van beveiliging te bevorderen, aan wettelijke vereisten te voldoen en risico's te beperken. cyberrisico's gebruik agetuigenissen.
Ons voorgestelde model bestaat uit setblokken die eenvoudig kunnen worden uitgebreid en geïntegreerd in uw stapel, ongeacht uw voorkeursplatform of gebruiksscenario’s. We eindigen met het demonstreren van een basisverificatiebeleid met behulp van Scribe's Valint-tool om te laten zien dat dit proces niet zo ingewikkeld is als je in eerste instantie zou vrezen.
Chaostheorie van de toeleveringsketen
Een van de grootste uitdagingen bij het beveiligen van toeleveringsketens is de enorme complexiteit van de betrokken systemen. Uw softwaretoeleveringsketen omvat elk stukje software dat betrokken is bij de creatie van uw eindproduct, hetzij als onderdeel van de omgeving, hetzij als een stukje software dat in uw codebasis is geïntegreerd. Je kunt aan deze beschrijving zien dat deze toeleveringsketens enorm zijn en alles omvatten, vanaf het moment dat een ontwikkelaar begint met het schrijven van code, via het compileren, testen, integreren en tot het punt waarop het eindproduct draait en elk stukje code bevat. software en bibliotheek die onderweg worden gebruikt.
Het definiëren van het beveiligingsmodel voor dergelijke systemen vereist inzicht in het enorme scala aan programmeringen talen, pakketbeheerders, producten, technologiestapels, CI-diensten, cloudproviders, import van afhankelijkheid, VM's, besturingssystemen en andere componenten die mogelijk in een bepaalde toeleveringsketen zijn opgenomen. Het is essentieel om rekening te houden met het brede scala aan activa die binnen een dergelijk systeem gevaar kunnen lopen, inclusief applicaties, tokens, sleutels en andere vormen van toegangsrechten.
Overzicht van het beleidsverificatiemodel
Ons voorgestelde model omvat verschillende bouwstenen die samenwerken om de veiligheid en naleving van een toeleveringsketen te garanderen. Deze bouwstenen zijn nodig voor het voortdurend verifiëren van softwarebeveiligingsaspecten en de naleving van de regelgeving voor de softwaretoeleveringsketen.
- bewijsmateriaal: onveranderlijke objecten die bedoeld zijn om automatisch door het beleid te worden gebruikt. Deze objecten bevatten metagegevens die nodig zijn om beleidshandhaving mogelijk te maken en om aan compliance-eisen te voldoen. Bewijsinhoud omvat metagegevens over artefacten, gebeurtenissen en instellingen, maar kan ook daadwerkelijke rapporten, configuraties of scans verzamelen.
bewijsmateriaal kan zowel in ondertekende als in niet-ondertekende vorm voorkomen. Wij raden u aan de i te volgenn-toto attest spec gebruikmakend van de ondertekende getuigenis en niet ondertekend verklaring formaten, respectievelijk.- Attesten (ook wel verifieerbaar ondertekend bewijsmateriaal genoemd): Verifieerbaar bewijs gekoppeld aan een specifiek gegeven ecologische context, het overbrengen van vertrouwen met behulp van een of andere vorm van PKI-handtekeningen.
- Omgevingscontext: De contextuele informatie verbindt het model met elkaar.
Het geeft antwoord op de vraag waar het bewijsmateriaal vandaan komt en welke informatie het bevat. Het is belangrijk dat de context aan het bewijsmateriaal is gekoppeld in plaats van er deel van uit te maken, omdat je meerdere bewijsstukken aan dezelfde context kunt koppelen en dit model het zoeken en ophalen van bewijsmateriaal eenvoudiger, efficiënter maakt.
In basistermen is een omgevingscontext een labelsysteem waarbij de meeste labels worden gelezen uit de omgeving, het platform of artefacten. Labels bieden genormaliseerde toegang tot veel processen van uw ontwikkelingsproces en CI/CD-pijplijn. Aspecten die verband houden met de oorsprong van het bewijsmateriaal, zoals Git-repository's, tags en commits, maar ook workflownamen, taaknamen, runID, enzovoort. De omgevingscontext kan ook aspecten van het onderwerp omvatten, zoals artefact-hashes, namen en tags.
Context kan gezien worden als een verlengstuk van het in-toto Attestspecificatie, geïntegreerd in de ondertekende payload. Met behulp van het labelingsysteem kunnen we de beleidsevaluatiefase een manier bieden om bewijsmateriaal op te vragen aan de hand van labels in een reeks aspecten. Bovendien kunnen de contextgegevens worden gebruikt als onderdeel van het beleidsevaluatieproces, waardoor ‘situationeel bewustzijn’ aan het bewijsmateriaal wordt toegevoegd.
- beleid: Een set door de gebruiker geconfigureerde beleidsmodules die het vereiste nalevingsrapport definiëren. Beleid kan de minimale beveiligingsnormen of de vereiste nalevingsniveaus specificeren voor verschillende soorten producten of systemen die deel uitmaken van uw build-pijplijn of uw ontwikkelingsproces. Het allerbelangrijkste is dat de daaruit voortvloeiende beleidsevaluaties nalevingsrapporten opleveren attesten ook. Hierdoor kunnen we niet alleen de nalevingsrapporten beheren – bijvoorbeeld door uw nalevingsstatus aan belanghebbenden bekend te maken – maar ook het nalevingsrapport gebruiken voor complexer beleid dat een grotere reikwijdte van de nalevingsregelgeving voor een organisatie kan omvatten. Beleid kan worden gegroepeerd in beleidsmodules. Dit zijn plug-ins die sets beleidsregels implementeren die bepaalde kenmerken gemeen hebben (vergelijkbaar met softwaremodules). Deze plug-ins worden geleverd door Policy Providers (daarover later meer).
Evaluatie van een beleidsmodule levert resultaten op, waaronder waarderingen, nalevingsdetails en uitspraken die verwijzen naar de betreffende beveiligingsregelgeving. Bovendien omvatten de resultaten het historische spoor van bewijsmateriaal dat nodig is om de op naleving beoordeelde bewijsmodule terug te vinden. - Winkels: Services die hosting, upload/download en mogelijkheden voor het opvragen van bewijs leveren (hierover later meer). Ze kunnen worden gebruikt via beeldregisters (OCI als opslag), speciale services (dwz Scribe Service) of eenvoudigweg het lokale bestandssysteem.
- Beleidsaanbieders: Dit zijn entiteiten (bedrijven, organisaties) die verantwoordelijk zijn voor het ondertekenen en aanbieden van beleidsmodules. Door beleid aan te bieden als een soort attest, brengen aanbieders vertrouwen en transparantie over in het beleid zelf. Een OPA Bundle Attestation kan toezichthouders bijvoorbeeld de bevoegdheid geven om officiële OPA-bundels te publiceren en te ondertekenen waarin beleidsmodules zijn geïmplementeerd.
Door deze bouwstenen te gebruiken, stelt ons model organisaties in staat om relatief eenvoudig de veiligheid en compliance van hun build-pipelines en ontwikkelingslevenscyclus te verifiëren.
Hoe werkt het?
Het startpunt van deze workflow is een ontwikkelaar of een systeem, dat bewijs genereert voor een softwareproduct of -component. De bewijsinhoud, evenals contextuele informatie, onderwerpen en handtekeningen, worden verzameld en geüpload naar een bewijsarchief.
Aan de andere kant worden nalevingsrapporten opgesteld door het evalueren van beleid dat is afgestemd op de behoeften en vereisten van de organisatie.
Met behulp van contextuele informatie kunnen beleidsevaluaties bewijsmateriaal dat door uw toeleveringsketen is geproduceerd, ondervragen en ervoor zorgen dat deze alle informatie bevatten die de regelgeving nodig heeft..
Als bijkomend voordeel zijn beleids- en nalevingsrapporten zelf toegankelijk als bewijsmateriaal, wat transparantie en vertrouwen biedt, evenals een geschiedenistraject terug naar al het betrokken bewijsmateriaal. Hierdoor kunnen organisaties nalevingsrapporten beheren, maar deze ook gebruiken als vertrouwde attesten om vertrouwen over te brengen aan softwareconsumenten.
Door gebruik te maken van deze stroom kunnen organisaties en belanghebbenden risico’s verminderen, transparantie bieden en compliance binnen hun toeleveringsketen garanderen, waardoor de impact van chaos wordt verminderd en de algehele veiligheid en het vertrouwen in hun producten wordt verbeterd.
Beleidsevaluatie
De evaluatie van een beleid wordt gedaan door een reeks beleidsmodules te verifiëren, die elk specifieke regelgeving en nalevingsbehoeften handhaven.
Bij een beleidsevaluatie worden aan elke module twee eenvoudige vragen gesteld:
- Welk bewijs is nodig om aan de module te voldoen?
- Wat zijn de criteria voor het bewijsmateriaal om de naleving aan te tonen?
Bijvoorbeeld in het kader van de SLSA-framework (Supply Chain Levels for Software Artefacts).kunnen beleidsmodules specificeren dat ondertekend SLSA-herkomstbewijs en een beveiligingsscan voor de build-pijplijn beide vereist zijn om aan de beveiligingsvereisten te voldoen. Het door deze modules geleverde bewijsmateriaal zou vervolgens worden geverifieerd om ervoor te zorgen dat het aan alle SLSA-vereisten voldoet.
- Welk bewijs is vereist om te voldoen aan de SLSA-vereisten?
- Een SLSA-herkomstattest (ondertekend bewijs) van het bouwartefact.
- Beveiligingsscan van de CI-pijplijn die het artefact produceert.
- Wat zijn de criteria voor het bewijsmateriaal om naleving van de SLSA-vereisten aan te tonen?
- Beide bewijsstukken moeten informatie bevatten die aan alle SLSA-vereisten voldoet.
Voor dit voorbeeld moet de SLSA-herkomstattestatie het bouwproces van uw image in zijn geheel beschrijven, terwijl de beveiligingspostuurattestatie moet verifiëren dat de SCM die de bron van de image heeft opgeslagen, vertakkingsbeschermingsregels gebruikt.
- Beide bewijsstukken moeten informatie bevatten die aan alle SLSA-vereisten voldoet.
Een ander voorbeeld van een beleidsmodule is de Controleer Artefact-module, waarin wordt aangegeven dat sommige artefacten moeten worden ondertekend door een vertrouwde bron. Gebruik maken van attesten (verifieerbaar ondertekend bewijsmateriaal) PKI-handtekening (Public Key Infrastructure), om te voldoen aan de eis van een specifieke persoon/entiteit die de artefacten moet ondertekenen en om de context te bevestigen van waar de artefacten vandaan komen.
De Controleer Artefact-module beantwoordt de volgende vragen:
1. Welk bewijsmateriaal is nodig om het voldoen aan de beveiligingseisen aan te tonen?
- Bewijs dat een artefact beschrijft dat een PKI-handtekening (attest) bevat.
2. Hoe kan dit bewijs worden geverifieerd om naleving te garanderen?
- Attest PKI-handtekening is geldig.
- De identiteit van het PKI-certificaat komt overeen met de gebruikersvereisten.
- Onderwerp van het bewijsmateriaal komt overeen met de gebruikerseisen.
- Formaat en herkomst sluiten aan bij de gebruikerseisen.
Van theorie tot praktijk
Laten we ons verdiepen in de implementatie van dit model dat momenteel wordt ondersteund door de Valint-tool.
Laten we eens kijken naar een eenvoudig voorbeeld van een beleid dat specificeert hoe de handtekeningen en oorsprong van een afbeelding moeten worden geverifieerd.
Concreet moeten we verifiëren dat het bewijsmateriaal aan de volgende criteria voldoet:
- Het bewijstype is CycloneDX SBOM-attest dat een afbeelding beschrijft.
- Het artefact is gesigneerd door mijnbedrijf.com.
- De afbeelding is afkomstig van een Circle-CI-workflow die wordt geactiveerd door de mijn_afbeelding_src rest.
Sjabloonbeleid
In het vorige voorbeeld was het beleid statisch en werd alleen gecontroleerd op een specifieke afbeelding met de naam mijnbedrijf/mijn_afbeelding. Het verdient echter vaak de voorkeur om beleid te hebben dat de mogelijkheden van sjablonen/variabelen ondersteunt. Hiermee kunt u vereisten definiëren die kunnen worden toegepast op meerdere vergelijkbare processen of artefacten in uw CI/CD-buildpijplijn.
Als sjabloon voor het beleid kunt u een variabele gebruiken in plaats van het beleid statisch aan een product te koppelen. In het bovenstaande voorbeeld kunt u de artefact_naam waarde aan '$MY_IMAGE` in plaats daarvan kunnen beoordelaars één beleid configureren voor een groot aantal afbeeldingen waarvoor dezelfde nalevingsregels gelden.
We zien je graag
At Schriftgeleerdeis ons uiteindelijke doel om de risico’s in de toeleveringsketen te beperken door middel van een verifieerbaar compliancemodel dat op bewijsmateriaal is gebaseerd. Een van de eerste plaatsen waar u dit model kunt uitproberen, is in uw CI/CD-buildpijplijn. Wij zijn van mening dat deze benadering van bewijsverificatie de sleutel is tot het waarborgen van transparantie en verantwoording in de toeleveringsketen, met voordelen voor alle betrokken belanghebbenden. Ons model omvat veel van de opkomende ideeën in de software supply chain-gemeenschap en definieert de relatie tussen veel ervan. Wij streven naar innovatie en verbetering van de transparantie van de softwaretoeleveringsketen. Als dit model uw interesse heeft gewekt, raad ik u aan om onze te bekijken Valint CLI-documentatie waar we de mogelijkheden en toepassingen van de tool uitbreiden. Probeer het gerust eens uit.
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
