CI/CD-arbetsflöden: Är din miljö i riskzonen för en ny attack?

CI/CD-pipelines (Continuous Integration/Continuous Deployment) automatiserar processen för att bygga, testa och släppa programvara, men de körs också med utökade behörigheter, lagrar produktionshemligheter och matar in otillförlitlig kod från externa källor. Säkerhetsforskare har visat att det för att få bidragsgivares åtkomst till ett större öppen källkodsprojekt inte krävdes mer än att korrigera ett stavfel, varefter ett skadligt pipeline-arbetsflöde kunde finnas kvar på bygginfrastrukturen och stjäla autentiseringstokens. Den rekommenderade åtgärden: granska pipeline-behörigheter, flytta hemligheter till dedikerad hemlighetshantering, tillämpa kodsignering på alla pipeline-utdata och behandla bygginfrastruktur som produktionsekvivalenta system med samma åtkomstkontroller.

Snabbt svar: Är CI/CD-miljöer i riskzonen för attacker?

Ja, och attackytan är bredare än de flesta organisationer inser. En CI/CD-pipeline är inte bara ett byggverktyg: den körs med utökade behörigheter på bygginfrastruktur, har åtkomst till kodsigneringsnycklar, produktionsdistributionsuppgifter och moln-API-tokens, och utlöses av händelser som pull requests som kan initieras av vem som helst med minimal åtkomst till arkivet. Attackerna är inte teoretiska: självhostade runner-kompromettering, beroendeförgiftning, exponering av hemligheter genom byggloggar och skadlig arbetsflödesinjektion har alla utnyttjats i dokumenterade incidenter som påverkar allmänt använda öppen källkodsprojekt och företagsmiljöer. Sonatypes rapport om tillståndet i programvarans leveranskedja för 2026 fann över 454 600 nya skadliga öppen källkodspaket år 2025, en ökning med 75 % jämfört med föregående år, de flesta inriktade på automatiserad beroendelösning i byggpipelines.

Vad är CI/CD?

CI/CD står för Continuous Integration and Continuous Deployment (eller Continuous Delivery). Det är ett automatiserat arbetsflöde som tar kod från en utvecklares commit genom bygg-, test- och distributionsfaser utan att manuella överlämningar mellan stegen krävs.

Kontinuerlig integration (CI) automatiserar processen att sammanfoga kodändringar och köra tester mot dem. Varje commit till ett delat repository utlöser en automatiserad bygg- och testkörning, vilket upptäcker integrationsfel tidigt snarare än att upptäcka dem vid lanseringstillfället. Kontinuerlig distribution (CD) utökar detta genom att automatiskt distribuera kod som klarar testning till produktions- eller stagingmiljöer, vilket gör det möjligt för organisationer att släppa flera gånger per dag istället för på fasta lanseringscykler.

Vanliga CI/CD-plattformar inkluderar GitHub Actions , Jenkins , GitLab CI, CircleCI och Buildkite. Alla delar samma grundläggande säkerhetsutmaning: för att göra sitt jobb behöver de privilegierad åtkomst till byggsystem, distributionsmiljöer, signeringsnycklar och produktionsuppgifter.

Varför CI/CD-pipelines är ett värdefullt attackmål

En lyckad attack mot en CI/CD-pipeline komprometterar inte bara en applikation. Den komprometterar den förtroendeinfrastruktur som alla nedströmskonsumenter är beroende av. Om en angripare kan injicera kod i en byggpipeline är varje artefakt som pipeline producerar potentiellt skadlig, och varje användare eller organisation som installerar dessa artefakter tar emot den skadliga koden via en legitim, betrodd kanal.

PyTorch-incidenten visade detta direkt. PyTorch är ett ramverk för maskininlärning med en marknadsandel på cirka 21 % inom maskininlärningsområdet. När forskare attackerade dess CI/CD-pipeline som en del av ett säkerhetsforskningsprojekt, visade de hur bred explosionsradien för en enskild pipeline-kompromittering kunde nå: varje projekt, företag och modell som är beroende av PyTorch skulle potentiellt ha påverkats om forskarna hade varit illvilliga snarare än ansvariga.

CI/CD-pipelines koncentrerar flera egenskaper som gör dem attraktiva mål. De kör automatiserade processer med utökade behörigheter som mänskliga operatörer inte kontinuerligt övervakar. De matar in kod och beroenden från externa källor som en del av sin normala funktion. De lagrar autentiseringsuppgifter som ger åtkomst till produktionssystem. Och de är ofta konfigurerade med tillåtande standardvärden utformade för utvecklarens bekvämlighet snarare än säkerhet.

CI/CD-hotmodell: Attackvektorer och kontroller

Attackvektor	Hur det fungerar	Exempel i verkligheten	Primär kontroll
Kompromis för löpare med egen värd	Angripare får bidragsåtkomst, skickar pull request med skadligt arbetsflöde; löpare kör den innan sammanslagningen godkänns på grund av standardinställningar	Forskare demonstrerade detta mot PyTorchs GitHub Actions-pipeline med hjälp av självhostade runners.	Inaktivera åtkomst till egenhostade runner-funktioner för fork pull-förfrågningar; kräv manuellt godkännande innan arbetsflöden från externa bidragsgivare körs
Beroendeförgiftning	Skadligt paket publicerat i det offentliga registret (typosquatting, kontokompromettering eller beroendeförvirring); CI-pipeline laddar ner och kör det	Sonatype identifierade fler än 454 600 skadliga paket med öppen källkod under 2025 (75 % ökning jämfört med föregående år)	Beroendefästning med hashverifiering; privata paketspeglar; Programvarukompositionsanalys (SCA) i pipeline
Hemlighetsexponering i byggloggar	Pipeline loggar API-nycklar, tokens eller autentiseringsuppgifter i klartext under byggstegen; loggar är tillgängliga för alla samarbetspartners i arkivet	GitHub-forskare identifierade 13 miljoner API-hemligheter exponerade genom offentliga databaser i mars 2024	Använd hantering av plattformshemligheter; skicka aldrig hemligheter till stdout; skanna byggloggar efter autentiseringsuppgifter
Skadlig arbetsflödesinjektion	Angripare modifierar arbetsflödes-YAML-filer i en gren eller fork för att lägga till steg som exfiltrerar hemligheter eller modifierar byggutdata	Liknande mönster som den självhostade runner-attacken; arbetsflödesfiler i forks körs före granskning	Skydda arbetsflödesfiler med grenskyddsregler; kräv godkännande av kodägare för arbetsflödesändringar
Komprometterade åtgärder från tredje part	CI/CD-arbetsflödet refererar till en extern åtgärd som senare ändras av ett komprometterat underhållarkonto	Dokumenterat mönster i leveranskedjeforskning; pinning med commit SHA snarare än tagg är begränsningsåtgärden	Fäst alla tredjepartsåtgärder till specifika commit-SHA:er; granska alla externa åtgärder före användning
Bygg infrastrukturens uthållighet	Skadlig kod som körs av löparen kvarstår på värddatorn och påverkar framtida versioner utan att den initiala attacken behöver utlösas igen.	Demonstrerat i GitHub Actions-forskningen: runners kvarstår på värden och fortsätter att påverka builds	Tillfälliga löpare som förstörs och återskapas för varje build; löparisolering med hjälp av containrar eller virtuella maskiner

Hur den självhostade löparattacken fungerar: Steg för steg

Säkerhetsforskare demonstrerade en specifik attackkedja mot GitHub Actions självhostade runners som illustrerar den strukturella sårbarheten i standard pipelinekonfigurationer. Attacken fortskrider enligt följande:

1. Uppnå bidragsstatus: Forskarna fick bidragsgivares tillgång till ett större projekt med öppen källkod genom att korrigera ett typografiskt fel i dokumentationen. En felkorrigering räcker för att få bidragsgivares status i många stora projekt.
2. Skicka en pull request med ett skadligt arbetsflöde: Med bidragsstatus skapar angriparen en fork och lägger till en skadlig GitHub Actions-arbetsflödesfil. Som standard utlöser en bidragsgivares pull request projektets CI/CD-arbetsflöde, inklusive åtkomst till den självhostade runnern, innan pull requesten granskas eller godkänns.
3. Kör skadlig kod på löparen: Det skadliga arbetsflödet körs på den självhostade löparen, som körs på värddatorn med utökade behörigheter. Löparen kan inte skilja mellan ett legitimt arbetsflöde och ett skadligt eftersom båda uttrycks i samma YAML-format och skickas via samma pull request-mekanism.
4. Loggautentiseringstoken: Det skadliga arbetsflödet fångar de autentiseringstokens som finns tillgängliga i runner-miljön. Dessa tokens ger fullständig åtkomst till databasen, inklusive möjligheten att pusha kod, ändra utgåvor, komma åt hemligheter och utlösa ytterligare arbetsflöden.
5. Fortsätt på byggmaskinen: Eftersom runners finns kvar på värddatorn mellan byggen kan skadlig kod förbli aktiv och påverka framtida byggen utan att angriparen behöver utlösa attacken igen. Detta möjliggör tyst, kontinuerlig kompromiss av alla efterföljande pipeline-utdata.
6. Manipulera pipeline-artefakter tyst: Med ihållande åtkomst kan angriparen infoga bakdörrar i byggartefakter, modifiera beroendeupplösning eller stjäla signeringsnycklar, vilket påverkar alla nedströms konsumenter av projektets utgåvor.

Attacken riktade sig mot ett offentligt arkiv, men liknande sårbarheter finns i privata arkiv där vilken anställd eller entreprenör som helst med minimal åtkomst till arkivet kan utlösa samma kedja.

Åtkomstkontroller: Låsning av pipelinebehörigheter

• Inaktivera åtkomst till fork pull-förfrågningar för självhostade löpare: I GitHub Actions tillåter standardinställningen att fork pull requests använder självhostade runners. Detta bör inaktiveras för alla repositories som använder självhostade runners. Använd GitHub-hostade efemära runners för pull request-arbetsflöden från externa bidragsgivare, och reservera självhostade runners för arbetsflöden som bara körs efter sammanslagning.
• Kräv manuellt godkännande för arbetsflöden för externa bidragsgivare: Konfigurera arkivet så att det kräver att en auktoriserad underhållare godkänner arbetsflödeskörningar från nya eller externa bidragsgivare innan de körs. Detta lägger till en mänsklig grind mellan otillförlitlig kodinlämning och pipeline-körning.
• Tillämpa behörigheter med lägsta behörighet på pipeline-tokens: Arbetsflödestokens för GitHub Actions beviljas behörigheter som definieras i arbetsflödesfilen. Ange explicit räckvidden för varje arbetsflödes tokenbehörigheter till endast vad det arbetsflödet kräver (till exempel skrivskyddad åtkomst till arkivets innehåll för ett testarbetsflöde; endast skrivåtkomst för ett distributionsarbetsflöde). Undvik att använda standardtoken för alla behörigheter.
• Skydda YAML-filer i arbetsflödet med grenskydd och kodägare: kräver godkännande från kodägaren för alla ändringar av arbetsflödesfiler. Detta förhindrar att en angripare som får commit-åtkomst till en funktionsgren ändrar CI/CD-konfigurationen utan att en underhållare granskar ändringen.
• Använd kortlivade löpare: konfigurera runners så att de förstörs och återskapas som en ren miljö för varje build. Detta eliminerar persistensvektorn: skadlig kod som körs i en build kan inte påverka framtida builds eftersom runnermiljön ersätts.

Hemlighetshantering i CI/CD-pipelines

Hemligheter (API-nycklar, distributionsuppgifter, signeringsnycklar, databaslösenord, molnåtkomsttokens) som lagras i CI/CD-miljöer är det primära exfiltreringsmålet i pipeline-attacker. Effektiv hantering av hemligheter kräver att varje hemlighet behandlas som ett potentiellt intrångsmål och att både antalet hemligheter i miljön och deras exponeringsyta minimeras:

• Hårdkoda aldrig hemligheter i källkod eller konfigurationsfiler: Hårdkodade autentiseringsuppgifter exponeras permanent för alla som har åtkomst till databasen, inklusive externa bidragsgivare, förgrenade databaser och alla som någonsin klonar projektet. Använd plattformshemlighetslager (GitHub Actions-hemligheter, GitLab CI-variabler, Jenkins-autentiseringsuppgifter) eller dedikerade lösningar som HashiCorp Vault för att injicera hemligheter endast vid körning.
• Omfånga hemligheter till det lägsta nödvändiga pipeline-steget: En hemlighet som endast behövs av distributionssteget ska inte vara tillgänglig under bygg- eller teststegen. Stegspecifika hemligheter minskar fönstret under vilket ett komprometterat steg kan komma åt en given autentiseringsuppgift.
• Rotera hemligheter enligt ett definierat schema och omedelbart vid misstänkt kompromettering: Långlivade hemligheter som aldrig roteras komprometteras permanent om de exfiltreras. Definiera ett rotationsschema för alla pipeline-hemligheter och automatisera rotationen där det är möjligt.
• Skanna byggloggar efter autentiseringsmönster: Pipeline-steg som av misstag upprepar miljövariabler eller skriver ut felsökningsutdata kan exponera hemligheter i byggloggar. Använd loggskanningsverktyg för att upptäcka och varna för autentiseringsuppgifter i pipeline-utdata.
• Lagra kodsigneringsnycklar i en HSM, inte i pipeline-miljön: Signeringsnycklar som lagras som filer eller miljövariabler i byggmiljön är exfiltrerbara. HSM som en tjänst lagrar signeringsnycklar i FIPS 140-3-validerad hårdvara och utför signeringsåtgärder inuti HSM så att den privata nyckeln aldrig kommer in i pipeline-miljön.

Kodsignering som en CI/CD-säkerhetskontroll

Kodsignering i en CI/CD-pipeline har två säkerhetsfunktioner. För det första tillhandahåller den verifiering av artefaktintegritet: varje binärfil, containeravbildning eller paket som produceras av pipelinen är kryptografiskt signerad, och nedströmskonsumenter kan verifiera signaturen för att bekräfta att artefakten är autentisk och omodifierad sedan pipelinen producerade den. Om en angripare komprometterar byggmiljön och modifierar en artefakt efter signering, misslyckas signaturverifieringen vid installationstillfället.

För det andra tillhandahåller den verifiering av byggproveniens: signeringshändelsen registrerar metadata om bygget, inklusive pipeline-stadiet, commit SHA, byggets tidsstämpel och signeringsidentitet. Detta skapar en granskningsbar post över var varje releaseartefakt kommer ifrån, vilket är avgörande för säkerhetsutredningar i leveranskedjan och efterlevnadsrevisioner.

Encryption Consultings CodeSign Secure integreras direkt med GitHub Actions , Jenkins och Azure DevOps pipelines. Den utför alla signeringsåtgärder inuti en HSM så att privata nycklar aldrig kommer in i pipeline-miljön, tillämpar rollbaserad åtkomstkontroll över vilka pipeline-steg och användare som kan utlösa en signeringshändelse och loggar varje signeringsåtgärd för den revisionslogg som både säkerhetsteam och efterlevnadsramverk kräver. För GitLab CI och andra plattformar tillhandahåller CodeSign Secure även integrationsvägar som upprätthåller samma HSM-baserade nyckelskyddsmodell oavsett vilken CI/CD-plattform som används.

Beroendesäkerhet och kontroller av programvaruleveranskedjan

• Fäst beroenden till specifika versioner och hashvärden: Att ange ett exakt versionsnummer är otillräckligt eftersom en skadlig aktör kan publicera ett nytt paket under samma version. Fäst beroenden till kryptografiska hashvärden (SHA-256-digester) så att bygget misslyckas om det nedladdade paketet inte matchar den förväntade hashen, oavsett versionsnummer.
• Använd Software Composition Analysis (SCA) i processen: SCA-verktyg skannar beroendeträd efter kända sårbarheter och skadliga paket och jämför dem med databaser med kända dåliga paket innan de installeras. Integrera SCA som ett obligatoriskt pipeline-steg som blockerar byggen när allvarliga sårbarheter upptäcks.
• Använd privata paketspeglar för kritiska beroenden: En privat spegel cachar godkända versioner av paket som har granskats och validerats. Pipelinen löser beroenden från den privata spegeln snarare än direkt från publika register, vilket förhindrar typosquatting och beroendeförvirringsattacker.
• Granska CI/CD-åtgärder och plugin-program från tredje part: CI/CD-arbetsflöden som refererar till tredjepartsåtgärder exekverar kod från externa underhållare med samma behörigheter som arbetsflödet. Fäst alla externa åtgärder till specifika commit-SHA:er snarare än muterbara taggar eller grenar, och granska koden för varje åtgärd före användning.
• Upprätthåll en programvaruförteckning (SBOM): generera och publicera en SBOM för varje releaseartefakt som dokumenterar alla beroenden efter namn, version och hash. En SBOM gör det möjligt för nedströmskonsumenter att bedöma sin exponering när en sårbarhet eller ett skadligt paket identifieras, och krävs i allt högre grad av statliga upphandlingskrav och ramverk som NIST SSDF.

Efterlevnadsmappning: CI/CD-säkerhetskrav

Ramverk	Relevanta krav	CI/CD-implikation
NIST SP 800-218 (SSDF)	Säkra programvaruutvecklingsmetoder inklusive säkra byggmiljöer, artefaktintegritet och beroendehantering	Kräver att organisationer skyddar byggverktyg och miljöer, verifierar integriteten hos byggartefakter och hanterar programvarukomponenter från tredje part.
SLSA (Leveranskedjans nivåer för programvaruartefakter)	Fyra nivåer av garantier för byggproveniens, från grundläggande dokumentation av byggprocessen (L1) till HSM-stödd signering och hermetiska byggen (L3+)	Ger en färdplan för gradvis hårdare pipelinesäkerhet; Nivå 2 kräver signerad proveniens; Nivå 3 kräver isolerade, härdade byggmiljöer
PCI DSS v4.0 (krav 6)	Skydda webbapplikationer och programvaruutvecklingsprocesser; Krav 6.3 kräver att säkerhetsbrister identifieras och åtgärdas	CI/CD-pipelines som producerar programvara som behandlar kortinnehavardata måste implementera säkra utvecklingsmetoder och sårbarhetshantering.
SOC 2 typ II	Kriterier för säkerhet för betrodda tjänster: logiska åtkomstkontroller, ändringshantering och övervakning	CI/CD-åtkomstkontroller, godkännandeflöden för kodändringar och pipeline-granskningsloggar utvärderas som en del av SOC 2-ändringshanteringskontrollerna.
HIPAA säkerhetsregel	Tekniska skyddsåtgärder för programvara som åtkommer ePHI; revisionskontroller och åtkomsthantering	CI/CD-pipelines som producerar programvara som har åtkomst till ePHI måste ha åtkomstkontroller, revisionsloggning och kontroller av artefaktintegritet.

Begränsningar: Vad säkerhetskontroller för rörledningar inte kan göra

• Kodsignering verifierar integritet, inte korrekthet: En signerad artefakt bevisar att den kom från pipelinen utan modifiering efter signering. Den bevisar inte att koden som pipelinen byggde är fri från sårbarheter eller skadlig logik. Kodsignering och testning av applikationssäkerhet kompletterar varandra, inte ersätter varandra.
• Hemlighetshantering förhindrar inte insiderhot från auktoriserade användare: En auktoriserad utvecklare med legitim åtkomst till pipeline-hemligheter kan fortfarande missbruka dem. Hemlighetshantering i kombination med åtkomstloggning, lägsta behörighetsnivå och rotation av hemligheter minskar men eliminerar inte insiderrisken.
• SCA-verktyg är beroende av kända dåliga databaser: Programvarukompositionsanalys upptäcker paket med kända sårbarheter eller känt skadligt beteende. Ett nytt skadligt paket som publiceras samma dag som det matas in av en pipeline kommer ännu inte att finnas i SCA-databasen. Djupgående försvar, inklusive beroendefästning och hashverifiering, krävs utöver SCA.
• Tillfälliga löpare minskar risken för persistens men ökar infrastrukturens komplexitet: Att skapa en ny runner-miljö för varje build eliminerar persistensattackvektorn men kräver automatisering av infrastruktur och ökar byggtiderna. Avvägningen är lämplig för pipelines med hög känslighet men kanske inte är praktisk för alla miljöer.

Hur krypteringskonsulting kan hjälpa

• CodeSign Säkert: CodeSign Secure integrerar kodsignering direkt i CI/CD-pipelines med HSM-baserad nyckellagring, rollbaserad åtkomstkontroll för signering, obligatorisk tidsstämpling och fullständig granskningsloggning. Den stöder GitHub Actions, Jenkins, Azure DevOps, GitLab CI och andra plattformar, och bibehåller samma nyckelskyddsmodell för alla pipeline-integrationer.
• CertSecure-chef: CertSecure-hanterare hanterar certifikatlivscykeln för certifikat som används i pipeline-autentisering, mTLS mellan pipeline-tjänster och kodsignering, inklusive automatisk förnyelse för att förhindra att certifikatutgången stör pipeline-driften.
• HSM som en tjänst: HSM som en tjänst tillhandahåller FIPS 140-3-validerad hårdvarunyckellagring för kodsigneringsnycklar och pipeline-autentiseringsuppgifter, vilket säkerställer att även en fullständig kompromettering av byggservern inte kan extrahera de privata nycklarna som signerar pipeline-utdata.
• Krypteringsrådgivningstjänster: vår Krypteringsrådgivningstjänster utvärdera säkerhetsarkitekturen i pipelines, identifiera luckor i åtkomstkontroll och svagheter i hanteringen av hemligheter och bygga en åtgärdsplan som omfattar autentisering, artefaktintegritet, beroendesäkerhet och efterlevnadsanpassning.

Slutsats

CI/CD-pipelines är inte en perifer del av programvaruleveranskedjan. De är det mest privilegierade automatiserade systemet i de flesta organisationer: de bygger, signerar och distribuerar den programvara som användare och kunder litar på. En komprometterad pipeline producerar komprometterad programvara via en betrodd kanal, och den nedströms explosionsradie, som PyTorch-forskningen visade, kan omfatta ett helt branschekosystem.

Kontrollerna som minskar pipeline-risken är väl förstådda: inaktivera standardåtkomst för löpare för externa bidragsgivande arbetsflöden, tillämpa behörigheter med lägst behörighet på pipeline-tokens, flytta hemligheter till dedikerade hanteringssystem, signera alla pipeline-artefakter med HSM-baserade nycklar, fäst beroenden till hash-verifierade versioner och granska alla pipeline-komponenter från tredje part. Detta är inte teoretiska bästa praxis: det är de specifika luckor som dokumenterade attacker har utnyttjat.

Om er organisation använder CI/CD och behöver en säkerhetsbedömning av er pipelinearkitektur, åtkomstkontroller och artefaktintegritetskontroller, kontakta Encryption Consulting . Vårt team kan utvärdera er nuvarande konfiguration, identifiera de högsta prioritetsluckorna och integrera kodsignering och kryptografiska kontroller som skyddar er pipeline utan att bromsa er releasehastighet.

Vanliga frågor om partihandel med mat och dryck

Vad är en CI/CD-pipeline och varför är det en säkerhetsrisk?

En CI/CD-pipeline är ett automatiserat arbetsflöde för byggande, testning och distribution som körs med utökade behörigheter, lagrar produktionshemligheter och matar in extern kod genom beroenden. Det är en säkerhetsrisk eftersom en kompromiss producerar skadliga versioner som levereras till nedströmsanvändare via en betrodd kanal, med en explosionsradie som kan utsträckas till alla konsumenter i det komprometterade projektet.

Vad är en självhostad runner-attack på GitHub Actions?

Som standardinställningar utlöser en bidragsgivares pull-förfrågan den självhostade löparen innan PR:n granskas. En angripare som uppnår bidragsgivarestatus (vilket visat sig endast kräva en skrivfelkorrigering) kan skicka in en pull-förfrågan med ett skadligt arbetsflöde som körs på löparen, fångar autentiseringstokens och kvarstår på byggmaskinen för att påverka alla efterföljande byggen.

Vad är beroendeförgiftning i ett CI/CD-sammanhang?

Beroendeförgiftning inträffar när ett skadligt paket publiceras till ett offentligt register under ett namn som byggpipelinen kommer att ladda ner, genom typosquatting, kompromettering av underhållskonto eller beroendeförvirring. Pipelinen kör det skadliga paketet som en del av sin normala byggprocess. Sonatype identifierade fler än 454 600 skadliga paket enbart under 2025.

Hur skyddar kodsignering en CI/CD-pipeline?

Kodsignering ger verifiering av artefaktintegritet (nedströmskonsumenter kan bekräfta att artefakten kom från pipelinen oförändrad) och proveniensbekräftelse (en granskbar registrering av vilket pipeline-steg som producerade artefakten, vid vilken commit). Nycklar måste lagras i en HSM snarare än i byggmiljön för att förhindra nyckelutvinning vid en pipeline-kompromiss.

Vad är skillnaden mellan hantering av hemligheter och hårdkodade autentiseringsuppgifter?

Hårdkodade autentiseringsuppgifter är inbäddade i källkod eller konfigurationsfiler och exponeras permanent för alla med åtkomst till arkivet. Hemlighetshantering lagrar autentiseringsuppgifter i ett krypterat hemlighetslager och injicerar dem vid körning endast till det auktoriserade pipeline-steg som kräver dem, så att de aldrig visas i källkod, byggloggar eller pipeline-artefakter.

Vilka regelverk för efterlevnad hanterar säkerhet för CI/CD-pipelines?

NIST SP 800-218 (SSDF) kräver säkra byggmiljöer och artefaktintegritet. SLSA definierar fyra nivåer av byggproveniensgarantier. PCI DSS v4.0 Krav 6 kräver säkra programvaruutvecklingsprocesser. SOC 2 Typ II utvärderar CI/CD-åtkomstkontroller och ändringshantering. HIPAA kräver åtkomstkontroller och granskningsloggning för pipelines som producerar programvara som har åtkomst till ePHI.