Badacze bezpieczeństwa ujawnili klasę podatności w pipeline'ach CI/CD nazwaną Cordyceps, dotykającą ponad 300 repozytoriów GitHub należących do organizacji takich jak Microsoft, Google i Apache Software Foundation. Luka wynika z niebezpiecznych wzorców konfiguracji GitHub Actions – szczególnie kombinacji triggerów, uprawnień tokenów GITHUB_TOKEN i sposobu checkout kodu z pull requestów. Dla polskich firm B2B korzystających z open source i własnych pipeline'ów CI/CD, incydent ten wymaga natychmiastowego audytu workflow.
Mechanizm Cordyceps
Cordyceps wykorzystuje scenariusze, w których workflow uruchamiany przez zdarzenia związane z pull requestami otrzymuje zbyt szerokie uprawnienia (write access do repozytorium, dostęp do sekretów) i wykonuje kod z gałęzi PR bez odpowiedniej izolacji. Atakujący otwiera PR ze złośliwym kodem w pliku konfiguracyjnym workflow lub w skrypcie testowym; po uruchomieniu workflow złośliwy kod wykonuje się z uprawnieniami repozytorium docelowego – umożliwiając wstrzyknięcie backdoora do gałęzi głównej, kradzież sekretów CI/CD lub publikację skompromitowanych artefaktów do rejestrów pakietów.
To wariant ataku pwn request i poisoned pipeline, który dotyczy nie tylko małych projektów – gigantów technologicznych również. Skala (300+ repo) pokazuje, że niebezpieczne wzorce są powszechne mimo lat edukacji społeczności DevSecOps.
Checklist audytu GitHub Actions
- Minimalne uprawnienia GITHUB_TOKEN – permissions: contents: read domyślnie.
- Unikaj pull_request_target z checkout PR – lub izoluj w hardened runner.
- Sekrety – nigdy w workflow triggerowanych przez fork PR bez approval.
- Pin actions – używaj commit SHA zamiast @main/@v1.
- Branch protection – wymagaj review i status checks przed merge.
Ryzyko supply chain dla konsumentów open source
Polskie firmy B2B często konsumują pakiety npm, PyPI, Composer i Maven bez weryfikacji integralności łańcucha dostaw. Skompromitowane repozytorium upstream może opublikować złośliwną wersję biblioteki, która trafi do setek projektów produkcyjnych przez automatyczne dependency updates (Dependabot, Renovate). Po incydencie Cordyceps warto włączyć SBOM, podpisywanie artefaktów (Sigstore, SLSA) i politykę blokowania instalacji pakietów bez weryfikacji provenance.
Zespoły rozwijające dedykowane oprogramowanie powinny traktować pipeline CI/CD jako część powierzchni ataku równą produkcyjnemu API. Hardening runnerów (self-hosted z izolacją, GitHub-hosted z ograniczonymi permissions) to standard, nie opcja.
Reagowanie na potencjalną kompromitację
Jeśli audyt wykryje wzorzec Cordyceps w repozytorium organizacji: natychmiast wyłącz podejrzane workflow, przejrzyj historię merge PR z ostatnich miesięcy, rotuj wszystkie sekrety CI/CD i sekrety wdrożeniowe (AWS, Azure, npm tokens), przebuduj i podpisz ponownie artefakty z ostatniego release. Powiadom klientów korzystających z waszych bibliotek open source o potencjalnym ryzyku.
Integracja skanerów pipeline security (StepSecurity Harden-Runner, OpenSSF Scorecard, GitHub Advanced Security) w ramach infrastruktury IT automatyzuje wykrywanie niebezpiecznych wzorców przed merge.
SLSA i poziomy dojrzałości supply chain
Framework SLSA (Supply-chain Levels for Software Artifacts) definiuje poziomy dojrzałości od SLSA 1 (podstawowe provenance) do SLSA 4 (hermetyczne, odporne buildy). Po Cordyceps organizacje powinny ocenić, na którym poziomie są ich pipeline'y i ustawić cel na minimum SLSA 3 w ciągu 12 miesięcy. GitHub Actions wspiera artifact attestation – funkcja, którą warto włączyć natychmiast dla release builds.
Klienci korporacyjni coraz częściej wymagają SBOM i signed artifacts w RFP – dostawcy oprogramowania bez tych elementów tracą przewagę konkurencyjną na rynku enterprise.
Odpowiedzialność maintainerów open source
Cordyceps dotknął repozytoria organizacji, które są maintainerami krytycznych bibliotek open source – kompromitacja ich pipeline'u ma mnożnik ryzyka w całym ekosystemie. Firmy B2B korzystające z pakietów od Microsoft, Google czy Apache powinny monitorować security advisories tych organizacji i mieć procedurę szybkiej aktualizacji dependency po incydencie supply chain. Pinning wersji dependency w produkcji daje czas na ocenę, czy nowa wersja po incydencie jest bezpieczna.
Wkład w OpenSSF Best Practices Badge i udział w koalicjach SLSA to sygnały dla klientów enterprise, że wasz software supply chain jest dojrzały – przewaga w przetargach publicznych i B2B.
Organizacje publikujące pakiety open source powinny włączyć Dependabot security updates i required reviews na wszystkich PR modyfikujących pliki workflow – Cordyceps pokazał, że sam workflow file jest wektorem ataku. Branch protection z required status checks od StepSecurity lub podobnego skanera blokuje merge niebezpiecznych konfiguracji przed trafieniem do main.
Audyt zewnętrzny pipeline CI/CD raz do roku przez niezależnego partnera security dostarcza obiektywnej oceny dojrzałości – materiał cenny dla klientów enterprise w due diligence.
Każde repozytorium produkcyjne powinno mieć przypisanego business ownera odpowiedzialnego za bezpieczeństwo workflow – accountability zapobiega sierocym repo z niebezpiecznymi konfiguracjami GitHub Actions.
Podsumowanie
Cordyceps to alarm dla każdej organizacji używającej GitHub Actions. Audyt workflow, minimalizacja uprawnień i pinowanie actions to pilne działania. Zapraszamy do audytu DevSecOps w ramach usług IT dla firm.
Źródło: The Hacker News – Cordyceps CI/CD Flaws Expose 300+ GitHub Repositories to Supply-Chain Attacks