Beveilig uw software-toeleveringsketen van build tot implementatie

Voorkom dat niet-gescande, niet-ondertekende of kwetsbare containerimages de productie bereiken. Deze handleiding laat zien hoe registercontroles, kwetsbaarheidsscans, artefactondertekening en Kubernetes-toegangsbeleid een afdwingbare workflow creëren in de software-toeleveringsketen. 
Aan de slagManaged Private Registry
Illustratie domeinnamen

Verifieer elk onderdeel in uw pipeline

Beveiliging van de software-toeleveringsketen betekent het continu verifiëren van elke afhankelijkheid, elk pakket en elk artefact in een CI/CD-pipeline. Vertrouwen moet betrekking hebben op bronnen, openbare pakketten, externe technologie, componenten van derden, build-elementen, registers en de uiteindelijke release. Een dreiging kan binnendringen via gewijzigde afhankelijkheden of gecompromitteerde processen. Begin met het identificeren van elke klantgericht component aan de hand van een erkend raamwerk, zoals NIST-richtlijnen of SSCS-principes. Teams kunnen vervolgens leren waar bewijs ontbreekt, veilige codeerpraktijken toepassen en outputs ondertekenen met Cosign. Deze op een raamwerk gebaseerde aanpak stelt u in staat om zekerheid af te dwingen in de hele keten in plaats van te vertrouwen op één controlepunt. Elke partij kan traceren wat de build is binnengekomen, hoe dit is verwerkt en welk bewijs de implementatie ondersteunt.
[object Object]

Bouw release-garantie op verifieerbare controles

Private Harbor-projecten, Trivy-beleid, Cosign-ondertekening en Europese jurisdictie
Community@2x.png
Beperk registertoegang
Cyber Security@2x.png
Blokkeer bekende kwetsbaarheden
Magnifying Glass Check@2x.png
Verifieer herkomst en resilience

Bescherm elke fase die aanvallers als doelwit kunnen zien

Wat is beveiliging van een toeleveringsketen in een moderne containeromgeving?

Wat is beveiliging van een toeleveringsketen in een moderne containeromgeving? Het beschermt de route van broncode en afhankelijkheden van derden via build-systemen, image-opslag en implementatie eindpunten. Beveiliging van de software-toeleveringsketen behandelt deze processen als verbonden, omdat een aanval aan het ene uiteinde elke latere controle kan verzwakken.

Bescherming van bronopslag

Een bronopslag is een duidelijk doelwit. Een aanvaller kan inloggegevens stelen, code wijzigen, een beoordelingsregel uitschakelen of een afhankelijkheid introduceren die legitiem lijkt. Gecontroleerde downloadbronnen, verplichte peer-review en beveiligde branches vormen de eerste verdedigingslinie. Teams moeten ook afhankelijkheidsversies vergrendelen en checksums, licenties en herkomst verifiëren in plaats van wijzigende inputs voor elke build te accepteren. Deze controles verminderen het risico op het importeren van kwaadaardige of ongeautoriseerde software van een andere partij.

Aanvalstrajecten voor build-infrastructuur

Build-infrastructuur biedt verschillende aanvalstrajecten. Gecompromitteerde runners, blootgestelde geheimen of veranderbare basisimages kunnen een artefact wijzigen nadat ontwikkelaars de bron ervan hebben goedgekeurd. Scherm build-processen af, gebruik kortstondige inloggegevens en leg exacte inputs vast. Deze aanpak ondersteunt de beveiliging van containerimages door onverwachte codewijzigingen gemakkelijker traceerbaar te maken.

Register-naar-cluster-controles

De route van register naar cluster heeft onafhankelijke controles nodig. Een aanvaller zou een goedgekeurde image kunnen vervangen, een oude tag kunnen hergebruiken of buitensporige implementatierechten kunnen misbruiken. Toegang met de minste privileges beperkt wat elke identiteit kan publiceren of ophalen. Onveranderlijke referenties verbinden manifesten met precieze images, terwijl Kyverno releases kan afwijzen die geen vertrouwd bewijs bevatten of beveiligingsvereisten schenden.

Effectief beheer van de software-toeleveringsketen begint met een inventaris. Registreer bibliotheken van eerste en derde partijen, basis-images, licenties en build-tools die door elke applicatie worden gebruikt. Verbind elke software bill of materials (SBOM) met het project, de commit en de pipeline-run die het artefact heeft geproduceerd. Deze relatie helpt cyberbeveiligingsteams om diensten te identificeren die worden getroffen wanneer een gevoelige component wordt gecompromitteerd. Kies een tool die machineleesbaar bewijs exporteert en releases vergelijkt via automatisering. De inventaris moet zich samen met de software ontwikkelen, in plaats van afhankelijk te zijn van periodiek handmatig werk. Wijs een contactpersoon toe voor afhankelijkheidsonderwerpen, uitzonderingen en herstel, zodat het eigenaarschap duidelijk blijft.
Voer beveiligingstesten vroeg genoeg uit om ontwikkelaars bruikbare resultaten te geven. Pipeline-automatisering kan bronafhankelijkheden, containerlagen en configuratie onderzoeken vóór promotie. Definieer drempelwaarden voor CVE-scans op basis van blootstelling van de workload en zakelijke impact, en stuur mislukte resultaten vervolgens door naar het verantwoordelijke team. Een mislukte controle moet de voortgang stoppen in plaats van een ongelezen waarschuwing te genereren. Registreer het probleem, het getroffen pakket, de ernst en de goedgekeurde reactie. Dit bewijs helpt de kwaliteit van releases te beschermen en houdt beslissingen over de beveiliging van de software-toeleveringsketen consistent in alle applicaties.
Ondertekening van images bewijst welk gecontroleerd proces een artefact heeft goedgekeurd. Onderteken elk image met een onveranderlijke digest nadat de vereiste testen zijn geslaagd, en bewaar vervolgens de herkomst die de bronrevisie, bouwer en workflow identificeert. Vermijd het alleen ondertekenen van veranderbare tags, aangezien een tag later naar andere inhoud kan verwijzen. Scheid ondertekeningsrechten van algemene ontwikkelaars- en pipeline-toegang. Verificatie moet gebruikmaken van vertrouwde identiteiten of openbare sleutels die door uw organisatie zijn gedefinieerd. Een gecompromitteerd buildproces kan dan geen acceptabel bewijs creëren, tenzij het ook voldoet aan het ondertekeningsbeleid.
Een Kubernetes-toegangscontroller biedt het definitieve beslispunt voordat workloads een cluster binnenkomen. Configureer deze om niet-ondertekende images, niet-goedgekeurde registers, mislukte kwetsbaarheidscriteria of ontbrekende herkomst te weigeren. Kyverno en OPA Gatekeeper kunnen deze voorwaarden uitdrukken als versiebeheerde beleidsregels. Test elke regel met representatieve workloads vóór uitvoering in productie. Begin in auditmodus om legitieme uitzonderingen te vinden en zet volwaardige controles vervolgens in blokkeermodus. Onderhoud een geautoriseerd uitzonderingspad met een eigenaar, reden en vervaldatum. Het cluster kan vervolgens releasebewijs consistent evalueren, zelfs wanneer een eerdere controle omzeild of verkeerd geconfigureerd wordt.
Effectief beheer van de software-toeleveringsketen begint met een inventaris. Registreer bibliotheken van eerste en derde partijen, basis-images, licenties en build-tools die door elke applicatie worden gebruikt. Verbind elke software bill of materials (SBOM) met het project, de commit en de pipeline-run die het artefact heeft geproduceerd. Deze relatie helpt cyberbeveiligingsteams om diensten te identificeren die worden getroffen wanneer een gevoelige component wordt gecompromitteerd. Kies een tool die machineleesbaar bewijs exporteert en releases vergelijkt via automatisering. De inventaris moet zich samen met de software ontwikkelen, in plaats van afhankelijk te zijn van periodiek handmatig werk. Wijs een contactpersoon toe voor afhankelijkheidsonderwerpen, uitzonderingen en herstel, zodat het eigenaarschap duidelijk blijft.

Wijs eigenaarschap toe aan vier governanceprioriteiten

Betrouwbare code en leveranciersbeheer

Een aangewezen leider moet criteria voor betrouwbare bronnen en leveranciers definiëren, ondersteund door inkoop-, engineering- en beveiligingsmiddelen. Gebruik SLSA als leidraad voor sterkere build-integriteit en herkomst zonder uit te gaan van een specifiek bereikbaarheidsniveau. Schaal beoordelingen naar de omvang van de organisatie en het risico van de software-toeleveringsketen.

Beleidshandhaving en conforme infrastructuur

Beveiligings- en platformeigenaren moeten nalevingsverplichtingen vertalen naar meetbare beleidshandhaving voor code, cloud en infrastructuur. Definieer wie uitzonderingen mag goedkeuren, welk bewijsmateriaal zij moeten verstrekken en hoe controles voldoen aan interne vereisten.

Documentatie, audits en bewijsmateriaal

Wijs een verantwoordelijke resource toe om documentatie voor beslissingen, afhankelijkheden en controlewijzigingen bij te houden. Regelmatige audits moeten testen of rapporten overeenkomen met de operationele praktijk. Geef beoordelaars voldoende ondersteuning om een probleem te herleiden naar de eigenaar, de getroffen release en de oplossing.

Incidentgereedheid en verantwoordelijkheid voor herstel

Een security leader moet responstaken coördineren voordat een aanvaller ze test. Onderhoud een plan om potentiële problemen aan te pakken, inclusief triage, beheersing, communicatie met belanghebbenden en herstel. Elke actie heeft een verantwoordelijke eigenaar, ondersteunende resources en tijdlijnen nodig die passen bij de risicoblootstelling van de organisatie.

Beheer Harbor via vier beveiligingspijlers

Beheer toegang nauwkeurig

Harbor ondersteunt RBAC op project- en teamniveau voor het scheiden van enterprise-workloads en verantwoordelijkheden. Geef robotaccounts met beperkte scope uit voor CI/CD push- en pull-taken in plaats van brede menselijke inloggegevens te delen. Koppel elke identiteit aan één doel, roteer het geheim en verwijder ongebruikte toegang. Deze werkwijze beperkt de impact van blootstelling van inloggegevens terwijl de dagelijkse publicatie wordt beveiligd.

Detecteer onveilige componenten continu

Combineer continue Trivy-controles met software composition analysis (SCA) en afhankelijkheidsbeheer. Deze tools detecteren bekende kwetsbaarheden, verouderde pakketten en indicatoren van kwaadaardige code binnen elke component. Produceer een duidelijk rapport voor elke release, inclusief ernst, locatie en herstelstatus. Teams kunnen vervolgens blokkerende bevindingen onderscheiden van geaccepteerde uitzonderingen en opmerken wanneer nieuwe informatie invloed heeft op opgeslagen artefacten.

Verbind ontwikkelingsworkflows

Integreer het platform met GitLab CI, Tekton en andere goedgekeurde ontwikkelingsworkflows. Houd beleidsbeslissingen dicht bij de pipeline, zodat een mislukte controle nuttige feedback biedt vóór promotie. Referenties voor broncodebeheer (SCM) moeten elk artefact koppelen aan de commit, build-run en eigenaar. DevSecOps-teams hebben dan een consistent overzicht in plaats van afzonderlijk bewijsmateriaal dat verspreid is over systemen.

Bereid operationele respons voor

Onderhoud een incidentresponsplan voor gecompromitteerde inloggegevens, onveilige images en mislukte controles. Bepaal wie de distributie pauzeert, een getroffen versie verwijdert, toegang onderzoekt en herstel goedkeurt. Waarschuwingen hebben een eigenaar en een verwacht responstraject nodig; ze alleen genereren vermindert het risico niet. Voer oefeningen uit om te bevestigen dat beveiligings- en platformteams het relevante rapport kunnen vinden, inhoud kunnen afschermen en beslissingen kunnen communiceren. Deze operationele pijler zet detectie om in tijdige actie binnen het leveringsplatform.

Bewaar betrouwbaar bewijsmateriaal voor elke release

Zichtbaarheid van releases hangt af van bewijsmateriaal dat laat zien wie een artefact heeft geproduceerd, waar het vandaan kwam en hoe het is getest. Genereer en bewaar Trivy-resultaten, gegevens van de software-bill-of-materials en handtekeningen voor elke image en set aan Helm-charts. Dit stelt de organisatie in staat om elk inhoudstype te identificeren en een potentieel beveiligingsprobleem te onderzoeken. Integreer controles met GitLab CI om feedback voor ontwikkelaars te automatiseren voordat software de gecontroleerde omgeving binnenkomt. Consistente testen ondersteunen ook het beveiligingsbewustzijn door te laten zien waarom een release is mislukt. Bescherm Cosign-ondertekeningssleutels via OVHcloud Key Management Service, met gebruik van FIPS 140-2 HSM-ondersteunde opslag. Gecentraliseerd sleutelbeheer helpt ervoor te zorgen dat elke gegenereerde handtekening gekoppeld is aan gecontroleerd sleutelmateriaal in plaats van aan een blootgesteld pipeline-geheim.
[object Object]
Handhaaf uw container-releasebeleid met OVHcloud
Bouw een gecontroleerde route van CI/CD-output naar Kubernetes-implementatie met Managed Private Registry en Managed Kubernetes Service. Evalueer hoe registervalidatie, releasebewijs en clusterhandhaving niet-gescande, niet-ondertekende of kwetsbare images kunnen stoppen vóór productie. Ontdek Managed Private Registry en beoordeel vervolgens de Kubernetes-integratie voor uw workloads, beleidsmodel en operationele verantwoordelijkheden.
Verken registerpad