Osvědčené postupy pro bezpečnost softwarového dodavatelského řetězce

Zdrojový kód

• Vyžadujte silné ověřování. U každého účtu na hostingu kódu používejte vícefaktorové ověřování.
• Chraňte hlavní větev. Před merge vyžadujte review a nikomu nedovolte pushovat přímo do release větve.
• Nedávejte tajné klíče do kódu. Hledejte je při každém push a vše, co uniklo, vyměňte.
• Soubory workflow berte jako kód. Změna pipeline může dosáhnout na vaše tajné klíče, proto u nich vyžadujte review vlastníků.

Závislosti

• Commitujte lockfile a instalujte z něj. Používejte npm ci a jeho ekvivalenty, aby buildy omylem nepřebíraly nové verze. Lockfile má své limity, ale je to místo, kde začít.
• Zaveďte čekací dobu pro nové verze. Škodlivá vydání bývají často odhalena brzy poté, co se objeví, takže když verzi nepřevezmete v den jejího zveřejnění, dáte tomu šanci.
• Omezte instalační skripty. Kde to jde, vypněte je. Skripty spouštěné při instalaci jsou cestou, kudy se šíří npm červi.
• Prověřujte nové závislosti. Zkontrolujte, zda název není typosquatting, a podívejte se na údržbu a popularitu. Část z toho automatizuje OpenSSF Scorecard.
• Chraňte interní názvy balíčků. Používejte scopes a konfiguraci registru, aby veřejný balíček nemohl prostřednictvím dependency confusion zaujmout místo interního.
• Odstraňte, co nepotřebujete. Každá závislost je další věc, kterou je třeba monitorovat.

Build a CI/CD

• Připínejte GitHub Actions na úplný hash commitu. Tagy lze přesunout, jak ukázala kompromitace tj-actions.
• Omezte, co může každý job dělat. Dejte tokenu workflow jen nejnižší oprávnění, které potřebuje, a místo dlouhodobých tajných klíčů používejte krátkodobé přihlašovací údaje.
• Omezte odchozí provoz. Build potřebuje balíčky ze známých zdrojů a publikuje na známá místa. Vše ostatní zablokujte a ukradené tajné klíče nebudou mít kam odejít. Viz egress policy pro GitHub Actions.
• Spouštějte každý job v čistém, izolovaném prostředí. Z jednoho jobu do dalšího by se nemělo nic přenášet, a už vůbec ne z pull requestu od externího přispěvatele.
• Berte cache jako vstup. Otrávená cache přežívá mezi buildy a to, co obnoví, se snadno přehlédne. Viz cache GitHub Actions.

Úplný seznam najdete v checklistu bezpečnosti CI/CD pipeline a ve srovnání bezpečnosti runnerů.

Vydání

• Ke každému vydání generujte SBOM, a to z buildu. Uchovávejte ji spolu s artefaktem. Viz osvědčené postupy pro SBOM.
• Podepisujte artefakty a publikujte původ (provenance). Uživatelé si pak mohou ověřit, odkud vydání pochází. Úrovně stanovuje SLSA.
• Sestavujte vydání jen v CI. Za vydáním z notebooku nestojí žádný spolehlivý záznam.
• Od testu po produkci používejte jeden artefakt. Povyšujte to, co jste otestovali, místo nového sestavení, aby záznam zůstal pravdivý.

Po vydání

• Monitorujte, co jste dodali. SBOM podporovaných vydání průběžně kontrolujte proti novým zranitelnostem.
• Při prioritizaci nevycházejte jen z CVSS. Používejte CISA KEV, EPSS a kontext. Viz jak prioritizovat zranitelnosti.
• Vězte, jak dlouho jste byli zranitelní. Historie buildů ukáže, která vydání balíček obsahovala, a od kdy.
• Mějte plán dřív, než ho budete potřebovat. Rozhodněte, kdo provádí triáž, kdo opravuje a kdo komunikuje se zákazníky. Viz životní cyklus správy zranitelností.
• Trénujte na reálném scénáři. Zeptejte se, jak dlouho by trvalo najít každé vydání s daným balíčkem. Pokud je odpověď ve dnech, začněte tam.

Co udělat jako první

Kdy	Co udělat
Tento týden	Vícefaktorové ověřování, lockfily v CI, připnuté GitHub Actions, tokeny workflow s nejnižším oprávněním
Tento měsíc	SBOM z buildu každého vydání, upozornění na závislosti s vlastníkem, skenování tajných klíčů
Toto čtvrtletí	Pravidla odchozího provozu pro buildy, monitorování dodaných vydání, otestovaný plán reakce
Potom	Podepsaný původ (provenance), formální posouzení pokrytí SLSA nebo NIST SSDF, SBOM od dodavatelů

Co z toho zvládne CRACI

CRACI pokrývá build a vše, co následuje. Jako váš runner pro GitHub Actions spouští každý job ve vlastním izolovaném virtuálním stroji, zaznamenává do SBOM každý balíček, který job stáhne, označuje balíčky obnovené z cache CI a vynucuje egress policy, která blokuje spojení, jež váš build nepotřebuje. Pak průběžně kontroluje, co bylo dodáno, ukazuje, které buildy obsahovaly zranitelný balíček, a může buildy blokovat pomocí policy gates.

Zbytek zůstává na vašich dalších nástrojích: CRACI neskenuje zdrojový kód ani tajné klíče, neodhaluje nové škodlivé balíčky podle chování a nepodepisuje SBOM ani původ (provenance). Čím vyplnit jednotlivé mezery, ukazuje srovnání nástrojů pro bezpečnost softwarového dodavatelského řetězce.

Osvědčené postupy pro bezpečnost dodavatelského řetězce: časté dotazy

Jak zabezpečit softwarový dodavatelský řetězec?

Vězte, co dodáváte, díky SBOM z buildu každého vydání, kontrolujte, co se dostane dovnitř, pomocí lockfilů a prověřování, chraňte build omezením tajných klíčů a odchozího provozu a průběžně monitorujte, co jste vydali.

Čím by měl malý tým začít?

Zapněte vícefaktorové ověřování, v CI instalujte z lockfilů, připněte GitHub Actions na hashe commitů a dejte tokenům workflow jen nejnižší potřebné oprávnění. Tyto kroky zaberou dny a uzavřou běžné cesty útoku.

Jak zabránit škodlivým balíčkům?

Žádný jednotlivý krok to nezvládne. Odkládejte převzetí nových verzí, omezte instalační skripty a prověřujte nové závislosti. Omezení odchozího provozu z buildů zmírní škody, pokud škodlivý balíček projde.

Proč připínat GitHub Actions na hash commitu?

Protože tag verze lze přesunout na jiný kód. Úplný hash commitu vždy odkazuje na stejný kód, takže unesený tag se do vaší pipeline nedostane.

Jak často byste měli dodavatelský řetězec revidovat?

Monitorování by mělo být nepřetržité. Politiku závislostí, oprávnění workflow a plán reakce revidujte alespoň jednou ročně a po každém incidentu ve vašem stacku.