k0nsult.cloud / ai-truth / ipIII / playbook-supply-chain
Playbook F · Supply chain / CI-CD / dostawcy
Procedura reagowania na kompromitację łańcucha dostaw oprogramowania. Wektor supply chain jest wyjątkowo groźny, bo jedno naruszone ogniwo (biblioteka, aktualizacja, dostawca, pipeline) może skompromitować wiele systemów naraz — efekt kaskadowy: jedno źródło, wiele ofiar. Playbook prowadzi od wykrycia zatrutego artefaktu do bezpiecznego odtworzenia z zachowanym łańcuchem nadzoru.
Ufasz nie tylko swojemu kodowi — ufasz każdemu ogniwu, które go zbudowało i dostarczyło.
Poziom 1 (cyber klasyczny) z potencjałem kaskady. Priorytet P1, podbijany do P0 gdy zatruty artefakt trafił na produkcję lub gdy naruszony jest dostawca infrastruktury krytycznej. Wyzwalane flagi: NIS2_RELEVANT, CRITICAL_INFRA, warunkowo GDPR_BREACH.
Problem — powierzchnia ataku łańcucha dostaw
Kompromitacja może wejść przez dowolne ogniwo między kodem źródłowym a działającą usługą. Krytyczne obszary ryzyka:
Zależności kodu
Biblioteki open-source — typosquatting, przejęte pakiety, złośliwe wersje, kompromitacja konta maintainera. Zależności tranzytywne rozszerzają powierzchnię wykładniczo.
Konektory / integracje
Wtyczki, rozszerzenia, konektory do systemów zewnętrznych z szerokimi uprawnieniami — furtka omijająca kontrole rdzenia.
Modele AI
Pobrane modele/wagi z niezaufanego źródła, zatrute dane treningowe, złośliwe artefakty modelu — nowy wektor supply chain.
SaaS / dostawcy
Kompromitacja dostawcy usługi (MSP, SaaS) daje atakującemu dostęp do wielu klientów naraz.
CI/CD
Pipeline budujący i wdrażający — przejęcie runnera, złośliwy krok build, wstrzyknięcie do artefaktu w locie.
Kontenery / obrazy bazowe
Zatrute obrazy bazowe, złośliwe warstwy, publiczne rejestry bez weryfikacji pochodzenia.
Klucze API / sekrety
Wyciek lub nadużycie kluczy dostępowych do rejestrów, chmury, dostawców — wejście bez łamania kodu.
Aktualizacje
Zatruta aktualizacja podpisana kluczem dostawcy — klasyczny scenariusz kaskadowy o szerokim zasięgu.
WYKRYCIE→ZABLOKUJ DEPLOY→SBOM→PORÓWNAJ HASHE→OCEŃ DOSTĘP DO SECRETS→ROTUJ KLUCZE→BEZPIECZNA WERSJA→CHAIN OF CUSTODY
1→N
Efekt kaskadowy
jedno źródło, wiele ofiar
SBOM
Podstawa widoczności
wiesz, co masz w buildzie
P0/P1
Priorytet
P0 gdy artefakt na produkcji
8
Kroków playbooka
wykryj → chain of custody
Rozwiązania — kontrola integralności i pochodzenia (provenance)
- SBOM (Software Bill of Materials) — pełna lista składników każdego buildu (biblioteki, wersje, licencje, hashe). Bez SBOM nie odpowiesz na pytanie „czy mamy zatrutą wersję X i gdzie".
- Dependency scanning — ciągły skan zależności pod kątem znanych CVE i złośliwych pakietów (typosquatting, malware w rejestrze).
- Pinning wersji — przypięcie zależności do konkretnej wersji + hash (lockfile). Brak automatycznego podciągnięcia złośliwej „najnowszej".
- Podpisywanie buildów — kryptograficzne podpisy artefaktów i weryfikacja provenance (kto zbudował, z jakiego commita). Deploy tylko artefaktów o zweryfikowanym podpisie.
- Separacja sekretów — sekrety w dedykowanym magazynie (vault), nigdy w kodzie/repo/logach; wstrzykiwane w runtime z minimalnym zakresem i czasem życia.
- Rotacja kluczy — regularna i awaryjna rotacja kluczy API, tokenów, poświadczeń rejestrów; zdolność do natychmiastowego unieważnienia.
- Least-privilege CI/CD — runnery i pipeline z minimalnymi uprawnieniami; brak współdzielonych, wszechmocnych tokenów; izolacja środowisk build.
- Code owners + wymuszony review — zmiany w krytycznych ścieżkach wymagają zatwierdzenia przez właścicieli; brak merge bez przeglądu.
- Staging przed prod — obowiązkowa bramka: artefakt przechodzi przez środowisko testowe z weryfikacją, zanim trafi na produkcję.
- Vendor risk assessment — ocena ryzyka dostawców (postawa bezpieczeństwa, certyfikaty, klauzule powiadamiania o incydencie, prawo do audytu).
Zasada zaufania: żaden artefakt nie wchodzi na produkcję bez zweryfikowanego pochodzenia (podpis + hash + SBOM). „Zbudowane u nas / przez zaufanego dostawcę" bez dowodu integralności to GAP.
Playbook operacyjny — 8 kroków
1. Wykryj — sygnał kompromitacji: advisory o zatrutym pakiecie/dostawcy, alert dependency scanera, anomalia w buildzie, powiadomienie od dostawcy. Ustal, które ogniwo łańcucha jest podejrzane i od kiedy.
2. Zablokuj deploy — natychmiastowe wstrzymanie pipeline i wdrożeń (freeze). Cel: zatrzymać propagację zatrutego artefaktu na kolejne środowiska, zanim ustalisz zasięg. Zablokuj automatyczne aktualizacje z podejrzanego źródła.
3. SBOM — ustal ekspozycję — przez SBOM sprawdź, które buildy/usługi zawierają podejrzany komponent i w jakiej wersji. To odpowiedź na „gdzie to jest u nas". Brak SBOM → traktuj wszystkie buildy z danego okna jako potencjalnie dotknięte.
4. Porównaj hashe — zweryfikuj integralność artefaktów: hash i podpis względem znanej-dobrej wartości (znany-dobry baseline). Rozbieżność = artefakt zmodyfikowany. Ustal, które wdrożenia zawierają wersję niezgodną z provenance.
5. Oceń dostęp do sekretów — czy skompromitowane ogniwo miało dostęp do sekretów, kluczy API, magazynu poświadczeń, uprawnień CI/CD? Załóż, że każdy sekret w zasięgu zatrutego artefaktu/pipeline jest ujawniony.
6. Rotuj klucze — unieważnij i zrotuj wszystkie poświadczenia w zasięgu kompromitacji (klucze API, tokeny CI/CD, poświadczenia rejestrów, sekrety aplikacji). Priorytet: klucze o najszerszym zakresie i dostępie do produkcji.
7. Wdróż bezpieczną wersję — odtwórz artefakt z zaufanego źródła (znany-dobry commit, czysta zależność, zweryfikowany obraz bazowy). Przejście przez staging z pełną weryfikacją podpisu/hash/SBOM przed produkcją. Potwierdź brak zatrutego komponentu.
8. Chain of custody, walidacja i raport — skompletuj łańcuch nadzoru dowodowego: zatruty artefakt, hashe przed/po, log rotacji, chronologia. Ocena flag: NIS2_RELEVANT (jeśli usługa kluczowa), GDPR_BREACH (jeśli był dostęp do danych). Lessons learned: dodaj kontrolę provenance, zawęź uprawnienia CI/CD, zaktualizuj vendor assessment. Poziom odporności +1.
Powiązania systemowe
← Classification Engine
Zasięg + ekspozycja produkcji wyznaczają P0/P1 i flagi. Silnik klasyfikacji.
← Evidence Layer
SBOM, hashe przed/po, log rotacji kluczy — chain of custody. Evidence Board.
→ Legal / Compliance
NIS2 gdy usługa kluczowa; RODO gdy dostęp do danych. Compliance.
Uwaga metodyczna: opis wektorów supply chain i praktyk (SBOM, pinning, podpisy, provenance) to ramka metodyczna / dobra praktyka branżowa (norma), nie opis konkretnego naruszenia u odbiorcy. Odwołania do NIS2 opierają się na publicznie znanej treści dyrektywy. Wszelkie wartości liczbowe użyte przykładowo to SYMULACJA (dane demonstracyjne), nie operacyjne.
Doktryna: po kompromitacji łańcucha dostaw incydent uznaje się za zamknięty dopiero po zweryfikowanym odtworzeniu z zaufanego źródła, rotacji sekretów w zasięgu i kompletnym łańcuchu nadzoru — zgodnie z zasadą claim ≤ proof.