Bezpečnost CI/CD

Proč jsou pipeline cílem

• Mají klíče. Přes CI procházejí cloudové přístupové údaje, tokeny registrů i podpisové klíče.
• Spouštějí cizí kód. Každá závislost, instalační skript a action třetí strany se spouští na runneru.
• Dosáhnou do produkce. Čemukoli, co z pipeline vyjde, se důvěřuje, je to podepsáno a dodáno. Útočník v buildu zasáhne všechny zákazníky najednou.
• Málokdo je hlídá. Soubory workflow se mění zřídka a procházejí menší revizí než kód aplikace.

Kompromitace tj-actions i npm červ Shai-Hulud mířily na tajné klíče v CI. Jak takové útoky probíhají, popisuje stránka co je útok na dodavatelský řetězec.

Hlavní bezpečnostní rizika CI/CD

Standardní referencí je OWASP Top 10 CI/CD Security Risks. Seskupeno podle toho, co se pokazí:

Oblast	Rizika OWASP	Jak to vypadá
Kdo může co měnit	Nedostatečné řízení toku, nedostatečná správa identit a přístupů	Kód se dostane do produkce bez revize nebo staré účty si ponechají přístup
Co v pipeline běží	Zneužití řetězce závislostí, otrávené spuštění pipeline (poisoned pipeline execution)	Škodlivý balíček nebo upravené workflow běží s přístupy jobu
Kam job dosáhne	Nedostatečné řízení přístupu v pipeline, nedostatečná hygiena přístupových údajů	Jeden job může číst všechny tajné klíče a tokeny žijí roky
Jak je to nastaveno	Nezabezpečená konfigurace systému, neřízené používání služeb třetích stran	Neaktualizované runnery a integrace s většími přístupy, než potřebují
Co dokážete doložit	Nedostatečné ověřování integrity artefaktů, nedostatečné logování a přehled	Nikdo neví, co bylo součástí vydání nebo kam se job připojoval

Každé riziko přiřazené ke kontrolám runneru najdete ve srovnání bezpečnosti runnerů.

Osvědčené postupy bezpečnosti CI/CD

1. Definice pipeline berte jako produkční kód. Vyžadujte revizi souborů workflow a nedůvěryhodné pull requesty držte dál od tajných klíčů.
2. Omezte, co může každý job dělat. Dávejte tokenům co nejmenší potřebná oprávnění a místo uložených tajných klíčů upřednostňujte krátkodobé přístupové údaje.
3. Připínejte actions třetích stran na hash commitu. Tagy lze přesunout na jiný kód.
4. Izolujte joby. Spouštějte každý job v čistém prostředí, aby se nic nepřeneslo do dalšího.
5. Kontrolujte odchozí provoz. Build potřebuje známé zdroje a známé cíle. Zablokování všeho ostatního zabrání odcizeným tajným klíčům v úniku. Viz egress policy pro GitHub Actions.
6. Zaznamenávejte, co se stalo. Uchovávejte SBOM každého buildu a log jeho síťové aktivity, abyste mohli později odpovídat na otázky.

Verzi krok za krokem najdete v kontrolním seznamu bezpečnosti pipeline CI/CD.

Typy nástrojů pro bezpečnost CI/CD

Typ	Co dělá	Příklady
Bezpečnost runnerů	Izoluje joby a kontroluje, kam mohou za běhu dosáhnout	CRACI, StepSecurity
Správa bezpečnostního stavu	Vyhledává riziková nastavení pipeline a repozitářů	Legit Security, Cycode, Apiiro, OX Security
Skenování kódu a závislostí	Kontroluje kód, závislosti a tajné klíče při každé změně	GitHub Advanced Security, Snyk, Semgrep
SBOM a důkazy	Zaznamenává, co bylo součástí každého vydání	CRACI, Syft, Anchore

Tyto nástroje pracují v různých fázích, takže je většina týmů kombinuje. Skener prohlíží soubory před buildem, nástroje pro správu bezpečnostního stavu kontrolují nastavení a bezpečnost runnerů působí během běhu jobu, tedy ve chvíli, kdy škodlivý balíček jedná. Viz srovnání nástrojů pro bezpečnost softwarového dodavatelského řetězce a srovnání nástrojů DevSecOps.

Kam zapadá CRACI

CRACI zabezpečuje build během jeho běhu. Nahrazuje vaše runnery hostované na GitHubu rychlejšími a levnějšími: každý job běží ve vlastním izolovaném virtuálním stroji, egress policy blokuje spojení, která build nepotřebuje, a každý balíček, který si job stáhne, se zapíše do SBOM. Protože politika povoluje jen to, co build potřebuje, chrání vás i před útokem, který dosud nikdo neviděl.

CRACI nekontroluje konfiguraci vašich workflow, neskenuje zdrojový kód ani tajné klíče a nepodepisuje původ, takže si na to ponechte nebo přidejte jiné nástroje. Dnes je podporovaným CI systémem GitHub Actions a další CI systémy jsou v plánu vývoje.

Bezpečnost CI/CD: časté dotazy

Co je bezpečnost CI/CD?

Je to praxe ochrany pipeline, které sestavují, testují a dodávají software, včetně jejich přístupových údajů, kódu, který spouštějí, a artefaktů, které vytvářejí.

Jaká jsou největší bezpečnostní rizika CI/CD?

Škodlivé závislosti a actions třetích stran, otrávené pipeline, tokeny s příliš velkými oprávněními a dlouhodobé tajné klíče a chybějící přehled o tom, co build dělal. Standardním seznamem je OWASP Top 10 CI/CD Security Risks.

Co je poisoned pipeline execution?

Útočník změní, co pipeline spouští, například úpravou souboru workflow nebo skriptu, který workflow volá, prostřednictvím pull requestu, takže jeho kód běží s přístupy pipeline.

Jak zabezpečit pipeline CI/CD?

Revidujte změny pipeline, dejte každému jobu co nejmenší potřebný přístup, připínejte actions třetích stran na hash commitu, izolujte joby, omezte odchozí provoz a uchovávejte záznam o tom, co každý build dělal.

Jaký je rozdíl mezi bezpečností CI/CD a DevSecOps?

DevSecOps je širší praxe, která začleňuje bezpečnost do způsobu vývoje softwaru. Bezpečnost CI/CD se zaměřuje na samotnou pipeline, na které závisejí i nástroje DevSecOps.

Potřebuje GitHub Actions dodatečné zabezpečení?

GitHub nabízí kontroly, jako jsou oprávnění tokenů a skenování tajných klíčů, ale musíte je nakonfigurovat a hostované runnery ve výchozím nastavení odchozí provoz neomezují. Většina týmů přidává připínání, pravidla revizí a kontroly runnerů.