Państwa aplikacja to niskie ryzyko. Pipeline buildu już nie.

To rozumowanie jest słuszne, do pewnego momentu

Słyszymy to często i zwykle ma to rozsądne podstawy. Aplikacja to wewnętrzny dashboard, pipeline danych lub mała usługa z garstką użytkowników. Nie ma w niej nic, czego chciałby napastnik. Budżet na bezpieczeństwo idzie najpierw na produkt dla klientów.

Ta logika sprawdza się w odniesieniu do aplikacji. Nie sprawdza się w odniesieniu do sposobu jej budowania. Każdy zespół, cokolwiek dostarcza, ma pipeline CI z poświadczeniami i drzewo zależności, którego nie napisał. Warto je atakować, ponieważ są współdzielone, a przejęcie w tym miejscu sięga wszystkiego, czego mogą dotknąć te poświadczenia: Państwa rejestrów, kont w chmurze i innych repozytoriów.

Ataki, którym nie robiło różnicy, co robi aplikacja

Żaden z tych incydentów nie był wymierzony w konkretny rodzaj aplikacji. Każdy dotarł do zespołów przez narzędzie lub pakiet, którego używały do budowania oprogramowania.

tj-actions/changed-files, 2025

Przejęto szeroko używaną akcję GitHub wykrywającą zmienione pliki. Według CISA złośliwe wersje były dostępne od 12 do 15 marca 2025, a przejęcie ujawniło sekrety, w tym klucze dostępu, osobiste tokeny dostępu GitHub, tokeny npm i prywatne klucze RSA. Wiz poinformował, że kod zrzucał pamięć runnera CI, więc w publicznych repozytoriach sekrety trafiały do logów workflow. Workflow odwołujące się do akcji przez tag wersji uruchamiały złośliwy kod, niezależnie od zawartości repozytorium.

Robak npm Shai-Hulud, 2025

We wrześniu 2025 CISA ostrzegła przed samoreplikującym się robakiem, który przejął ponad 500 pakietów npm. Zbierał osobiste tokeny dostępu GitHub i klucze API chmury do AWS, Google Cloud i Azure. Palo Alto Networks Unit 42 opisał, jak używał skradzionych tokenów npm do publikowania zainfekowanych wersji innych pakietów ofiary i jak późniejsza fala działała podczas pre-install, co rozszerzyło jego zasięg na pipeline'y CI/CD.

3:27

Codecov Bash Uploader, 2021

Napastnik wydobył poświadczenie dzięki błędowi w procesie budowania obrazu Docker firmy Codecov i zmodyfikował skrypt Bash Uploader, który wiele zespołów uruchamiało w CI. Od 31 stycznia do 1 kwietnia 2021 zmieniony skrypt mógł wysyłać do strony trzeciej zmienne środowiskowe, w tym poświadczenia, tokeny i klucze dostępne w środowisku CI. Wykryto to, gdy klient zauważył, że suma kontrolna skryptu się nie zgadza.

xz utils, 2024

Złośliwy kod umieszczono w wersjach 5.6.0 i 5.6.1 XZ Utils, biblioteki do kompresji danych, która może występować w dystrybucjach Linuksa. CISA zaleciła powrót do nieprzejętej wersji, takiej jak 5.4.6, i poszukiwanie śladów złośliwej aktywności. Biblioteka kompresji to chyba najmniej efektowna zależność, jaką można sobie wyobrazić, a mimo to stała się celem.

event-stream, 2018

Osoba podająca się za pomocnego opiekuna projektu przejęła popularny pakiet npm event-stream i w wersji 3.3.6 dodała złośliwą zależność flatmap-stream. Zespół npm poinformował, że ładunek celował w jedną konkretną aplikację, portfel bitcoinowy Copay. Wszyscy inni, którzy zainstalowali event-stream, również otrzymali złośliwy kod.

Co łączy te incydenty

• Doszło do nich w czasie buildu lub instalacji. Złośliwy kod działał na maszynach programistów i runnerach CI, a nie w aplikacji produkcyjnej.
• Celowały w poświadczenia. Nagrodą były tokeny i klucze w pipeline, ponieważ otwierają drzwi poza budowany projekt.
• Przyszły pod zaufanymi nazwami. Znana akcja, znany pakiet, znany skrypt. Nikt nie zdecydował się zainstalować złośliwego oprogramowania.
• Pierwsze pytanie potem było takie samo. Czy któryś z naszych buildów pobrał złą wersję i do czego miała dostęp? Zespoły bez zapisu tego, czego używał każdy build, musiały to odtwarzać.

Jak wygląda minimalny wysiłek

Do opanowania podstaw nie potrzeba zespołu bezpieczeństwa. Większość zaleceń GitHub i CISA mieści się na krótkiej liście:

1. Przypinać zewnętrzne akcje GitHub do pełnego SHA commita zamiast do tagu, aby przesunięty tag nie mógł zmienić tego, co jest uruchamiane.
2. Commitować lockfile i przypinać wersje zależności do znanych, dobrych wydań.
3. Dawać tokenom CI najwęższe działające uprawnienia i rotować je, gdy incydent dotyczy czegoś, czego Państwo używają.
4. Wymagać uwierzytelniania wieloskładnikowego odpornego na phishing na kontach programistów i kontach publikacyjnych.
5. Prowadzić zapis tego, co zainstalował każdy build, aby na pytanie „czy to nas dotyczyło?” odpowiadać na podstawie danych, a nie pamięci.

Pierwsze cztery to konfiguracja. Piąty punkt większość małych zespołów pomija, ponieważ wymaga narzędzi.

Jak CRACI pomaga małym nakładem pracy

CRACI zajmuje się prowadzeniem zapisów i dodaje granicę sieciową, bez konieczności zmiany aplikacji czy workflow.

• Jedna linia na zadanie. Wystarczy zmienić runs-on na craci. Workflow GitHub Actions pozostają bez zmian, a uruchomienia nadal widać w GitHub.
• SBOM z każdego buildu. CRACI rejestruje pakiety faktycznie pobierane przez każde zadanie, łącznie z pakietami przywróconymi z cache, i eksportuje wynik w formacie CycloneDX lub SPDX.
• Ślad sieciowy dla każdego zadania. Gdy zostanie ogłoszony incydent, mogą Państwo sprawdzić, które buildy pobrały dany pakiet i z czym łączyło się każde zadanie.
• Polityka ruchu wychodzącego, którą można przełączyć na domyślne blokowanie. Wystarczy zezwolić na źródła pakietów potrzebne zadaniu, a przejęty krok będzie miał mniej miejsc, do których może wysłać to, co znajdzie. Polityki w razie awarii blokują ruch (fail closed), a naruszenia wywołują alert.
• Ciągła ponowna ocena. Monitorowane SBOM-y są sprawdzane ponownie w miarę publikowania nowych podatności, więc stary build nie pozostaje „czysty” tylko dlatego, że nikt nie sprawdził.

Aby jasno określić granice: polityka ruchu wychodzącego nie powstrzymałaby przejętego tj-actions przed wypisaniem sekretów do publicznego logu i żadne narzędzie nie cofnie wycieku tokenu. Przypinanie i rotacja nadal mają znaczenie. CRACI zmienia to, jak szybko mogą Państwo ustalić, czy byli narażeni, i jak daleko może sięgnąć przejęty krok.

Uruchomienie pierwszego workflow wymaga zainstalowania GitHub App i zmiany jednej linii na runs-on: craci.

Ile to kosztuje

CRACI pobiera opłaty tylko za minuty buildu: $0.002 za minutę vCPU ($0.004 za domyślny runner 2 vCPU), naliczane co sekundę, bez opłaty miesięcznej i bez opłat za SBOM. Pełne warunki znajdą Państwo w cenniku. Kwalifikujące się startupy mogą zgłosić się do programu dla startupów, aby otrzymać co najmniej 100 tys. darmowych minut buildu i praktyczne wsparcie we wdrożeniu.

Jeśli sprzedają Państwo oprogramowanie w UE, warto też sprawdzić, czy dotyczy Państwa Cyber Resilience Act. Nasz przewodnik po CRA wyjaśnia zakres i terminy.