Wyjaśnić zależności od dostawców, którzy również mają niejasne zależności

Czas: 1:45 (łącznie 13:20) - Definicja dla wszystkich: SCA czyta manifesty, lockfile'y albo zawartość obrazu, rozpoznaje komponenty i wersje, a potem porównuje je z bazą podatności. - Narzędzia open source: OSV-Scanner, Trivy, Grype, Dependency-Track. Komercyjnych jest sporo, zasada działania ta sama. - Kluczowe: „rozpoznanych” i „znanych”. Czego narzędzie nie rozpozna (vendoring, skopiowany kod, shading w Javie, binaria), tego nie sprawdzi. Czego nie ma w bazie, tego nie zgłosi. - Złośliwe paczki: baza OSV ma wpisy MAL- (projekt OpenSSF malicious-packages), więc część narzędzi oznaczy znane złośliwe wersje – ale dopiero, gdy ktoś je zgłosi. - Osiągalność: większość zgłoszeń dotyczy kodu, którego aplikacja nigdy nie wywołuje. Dlatego wynik to lista do oceny, a nie automatyczny wyrok. Przejście: „SCA odpowiada na pytanie dziś. A co, jeśli pytanie pojawi się za pół roku?”

Czas: 1:45 (łącznie 15:05) - Formaty: SPDX (norma ISO/IEC 5962) i CycloneDX (ECMA-424). Generatory open source: Syft, Trivy, cdxgen. Do przechowywania i odpytywania: Dependency-Track, GUAC. - SBOM to deklaracja, nie dowód. Jest tak dobry jak narzędzie, które go wygenerowało, i opisuje konkretny artefakt w konkretnej chwili. - Wiązanie z digestem: SBOM musi wskazywać dokładnie ten obraz, który działa na produkcji (sha256), a najlepiej być podpisanym poświadczeniem tego obrazu. - Wartość pojawia się dopiero, gdy ktoś go używa: codzienne dopasowanie do nowych podatności, odpowiedź na „gdzie mamy X?”. - Oprogramowanie kupowane: proś dostawców o SBOM. CRA każe producentom go mieć, ale nie każe go publikować – warto to zapisać w umowie. Przejście: „Wróćmy do piątku, 10 grudnia – tym razem z SBOM-ami.”

Czas: 1:45 (łącznie 16:50) - Lewa strona: jeśli SBOM-y powstają przy każdym buildzie i leżą w jednym miejscu, odpowiedź na pytanie z piątku to jedna komenda. Trudne nie jest zapytanie, tylko to, żeby SBOM-y istniały i były aktualne. W praktyce zamiast grepa: Dependency-Track albo GUAC. - Prawa strona: VEX (Vulnerability Exploitability eXchange) – producent mówi, czy podatność dotyczy jego produktu. Tu fragment w formacie OpenVEX: Log4j jest w obrazie, ale klasa JndiLookup została usunięta, więc podatnego kodu nie ma. Inne formaty: CSAF VEX, CycloneDX VEX. - VEX odsiewa szum ze skanów, ale to deklaracja. Od dostawców bierz VEX, ale miej możliwość sprawdzenia; własne VEX-y wystawiaj tylko z uzasadnieniem, które obronisz. Przejście: „Wiemy już, co mamy. Kolejne pytanie: skąd to przyszło?”

Czas: 1:45 (łącznie 18:35) - Definicja: podpis wiąże artefakt (dokładnie te bajty) z tożsamością. Sigstore (projekt OpenSSF) zdejmuje problem zarządzania kluczami: CI podpisuje swoją tożsamością OIDC, Fulcio wydaje krótko żyjący certyfikat, a wpis trafia do publicznego logu Rekor. - Podpis odpowiada na pytanie „kto”, a nie „czy dobrze”. Podpisany złośliwy kod jest nadal złośliwy – za chwilę xz-utils. - Najczęstszy błąd: weryfikacja „czy podpis jest poprawny” bez sprawdzenia, czyj. Atakujący też umie podpisać. Polityka musi mówić, kto powinien był podpisać: które repozytorium, który workflow, która gałąź. - Upstream: pokrycie podpisami w ekosystemach wciąż jest dziurawe (kontenery i npm najlepiej). Własne buildy: tu możesz wymagać podpisu na 100%. Przejście: „Podpis mówi kto. A jak i z czego to zbudowano?”

Czas: 1:45 (łącznie 20:20) - SLSA (Supply-chain Levels for Software Artifacts, projekt OpenSSF). Ścieżka Build: L1 – provenance istnieje, L2 – podpisane przez hostowaną platformę, L3 – platforma utwardzona, build nie ma dostępu do klucza podpisującego. - Provenance zamyka lukę „artefakt ≠ źródło”: wiesz, z którego commita powstały te bajty. - Granica: SLSA nic nie mówi o jakości samego kodu ani o zależnościach. Przykład z PyPI, Ultralytics (2024): pierwsze złośliwe wersje opublikował przejęty, ale prawdziwy workflow projektu, więc miały poprawne provenance. Kolejne wrzucono kradzionym tokenem i provenance już nie miały. Poprawne provenance ≠ bezpieczny kod, a brak provenance tam, gdzie zwykle było, to sygnał. - Uwaga dla audytorów: „mamy SLSA” bez podania ścieżki i poziomu nic nie znaczy. Przejście: „Jak to wygląda w terminalu?”

Czas: 1:15 (łącznie 21:35) - cosign: tożsamość to konkretny workflow w konkretnym repozytorium i gałęzi, a wystawca to GitHub Actions. Inny workflow, fork albo czyjeś konto – weryfikacja nie przejdzie. - gh attestation verify: sprawdza poświadczenie provenance, czyli że obraz zbudowało CI z repozytorium org/app. - npm audit signatures: szybki test dla projektów w JS – sprawdza podpisy rejestru i provenance paczek z lockfile'a. - Odpowiedniki w innych ekosystemach: PyPI ma poświadczenia z Trusted Publishing, Maven Central ma podpisy PGP – z różną jakością weryfikacji po stronie klienta. Przejście: „Teraz najważniejszy przykład: xz-utils.”

Czas: 1:45 (łącznie 23:20) - Jedno zdanie o incydencie (CVE-2024-3094): atakujący przez dwa lata zdobywał zaufanie i prawa maintainera, a potem wypuścił wydania z backdoorem. Bez szczegółów ataku – patrzymy, co by zadziałało. - Podpis: tarballe były podpisane przez osobę z prawem wydawania. Podpis zadziałał dokładnie tak, jak powinien – i nie miało to znaczenia. - Build ze źródła: skrypt aktywujący backdoor (build-to-host.m4) był tylko w tarballu, nie w repozytorium. Budowanie z git i provenance odsłoniłyby różnicę. Ale tylko częściowo – sam ładunek był w plikach testowych w git, czyli w źródle, którego SLSA nie ocenia. - Weryfikacja „tarball = git” to praca dla wszystkich naraz: dystrybucje i reproducible builds. Nie każda firma musi przebudowywać świat u siebie. - Stabilny kanał działa jak długa karencja: dotknęło to głównie wersji rozwojowych i rolling. - Wykrył to Andres Freund, inżynier, któremu logowanie SSH trwało ok. pół sekundy dłużej i chciał wiedzieć dlaczego. Najlepszy „mechanizm” to ludzie, którzy patrzą. Przejście: „Część rzeczy da się zatrzymać wcześniej – zanim w ogóle wpuścimy je do siebie.”

Czas: 0:45 (łącznie 29:20) - Pipeline ma dostęp do sekretów, rejestrów i produkcji, więc jest celem samym w sobie. - Ultralytics (2024) zaczął się właśnie tu: wstrzyknięcie przez pull_request_target i zatruty cache w CI projektu. tj-actions (2025) – przez akcję używaną w pipeline'ach. - Narzędzia open source: zizmor (statyczna analiza workflowów GitHub Actions) i OpenSSF Scorecard (sprawdza m.in. uprawnienia tokenów i przypięcie akcji). - Reproducible builds: jeśli niezależne buildy dają identyczne bajty, nie musisz ślepo ufać jednej platformie. To robota wspólna – dystrybucje (Debian, Arch, NixOS) i projekty robią ją dla wszystkich. Przejście: „Mamy mechanizmy. Jak je złożyć w całość?”

Czas: 1:45 (łącznie 38:15) - Dopuszczenie: lekki proces, nie komisja. Większość zależności przechodzi automatycznie, człowiek patrzy tylko na nowe i nietypowe. - Monitorowanie: tu pracują SBOM, SCA i automatyczne aktualizacje z poprzedniej części. Pin + automatyczne PR-y + kilka dni karencji, a poprawki bezpieczeństwa idą od razu. - Wycofanie: najczęściej pomijany etap. Wyzwalacze: koniec wsparcia (EOL), porzucony projekt, krytyczna podatność bez poprawki, kompromitacja, zmiana licencji. Opcje: zamiana na inny komponent, fork i własne utrzymanie, płatne wsparcie rozszerzone, izolacja ze środkami kompensującymi albo świadoma akceptacja ryzyka – zawsze z datą ważności, bo wyjątek bez daty staje się stanem docelowym. - S2C2F (Secure Supply Chain Consumption Framework, OpenSSF): 8 praktyk – od pobierania przez proxy i inwentaryzacji, przez aktualizacje i skanowanie, po przebudowę ze źródeł i poprawki w upstreamie – ułożonych w 4 poziomy. - Najwyższy poziom, czyli przebudowa wszystkiego ze źródeł u siebie, dla większości organizacji to przesada. Lepiej robić to wspólnie – dystrybucje, reproducible builds, fundacje – niż żeby każdy powtarzał tę samą pracę. Przejście: „Skąd wiadomo, że taki program jest dobry? Tu wchodzi OpenChain.”