Sprawdź, co trafia do wydania

Sprawdź, czy zależność jest potrzebna

Agent może zaproponować pakiet, który pozornie rozwiązuje problem. Sugestia jest propozycją, a nie dowodem, że pakiet istnieje lub jest odpowiedni. Przed instalacją sprawdź dokładny rejestr, wydawcę, nazwę pakietu i wersję.

W fikcyjnym eksporcie CSV środowisko wykonawcze może już zapewniać potrzebne zachowanie. Nowy pakiet nadal może być uzasadniony, ale dodaje obowiązki utrzymania i ścieżki wykonania. Porównaj nakład implementacji ze stałą odpowiedzialnością za zależność.

Przejrzyj licencję i wspierane środowisko wykonawcze. Sprawdź aktywność utrzymania i odpowiednie komunikaty bezpieczeństwa. Znana nazwa może oznaczać inny pakiet w innym rejestrze. Udana instalacja dowodzi tylko, że instalacja się zakończyła.

Sprawdź zachowanie instalacji i buildu

Zależności mogą wykonywać kod podczas instalacji lub budowania. Ogranicz dane uwierzytelniające i dostęp do sieci w tych środowiskach. Nie udostępniaj produkcyjnych sekretów zadaniu przetwarzającemu niezaufany pull request.

Jeśli ekosystem to obsługuje, dodaj lockfile do repozytorium. Wymagaj jego przestrzegania podczas buildu. Przeglądaj zmiany lockfile razem ze zmianą kodu, w tym niespodziewane pakiety przechodnie. Przypięcie wersji poprawia odtwarzalność, ale nie czyni podatnej wersji bezpieczną.

NIST SSDF obejmuje ochronę oprogramowania i praktyki wytwarzania w całym cyklu życia. Uwzględnij tę szerszą perspektywę przy projektowaniu środowiska budowania. Przeczytaj framework.

Odróżniaj spis składników od pochodzenia

Software Bill of Materials, czyli SBOM, zapisuje składniki oprogramowania. Pomaga wskazać dotknięte wydania, gdy któryś składnik wymaga uwagi. Sam nie potwierdza bezpieczeństwa składników.

Provenance opisuje, jak powstał artefakt. SLSA definiuje format informacji o buildzie i jego danych wejściowych. Weryfikacja musi powiązać je z zaufanym wytwórcą i artefaktem, którego chcesz użyć. Sam plik nazwany „provenance” nie wystarcza. SLSA provenance.

Dla usługi eksportu zapisz łańcuch, który można sprawdzić:

1. Przejrzany commit identyfikuje zaakceptowany kod źródłowy.
2. Build identyfikuje dane wejściowe i środowisko wykonania.
3. Artefakt ma stały digest.
4. Kontrole identyfikują badany artefakt lub kod.
5. Wdrożenie zapisuje artefakt umieszczony w środowisku docelowym.

Nie buduj po zatwierdzeniu innego wariantu bez określonego procesu weryfikacji. Zmienny tag taki jak latest może później wskazywać inny obraz.

Ustal znaczenie wykrytego problemu

Wykryta podatność wymaga kontekstu: dotkniętej wersji, osiągalnego zachowania, narażenia, dostępnej poprawki i konsekwencji. Zapisz dowody uzasadniające każdy tymczasowy wyjątek. Wyznacz właściciela, termin wygaśnięcia i zdarzenie wymagające przeglądu.

Nie wyłączaj całego skanera dlatego, że jedno ustalenie nie ma zastosowania. Nie ogłaszaj czystego wyniku, gdy skan się nie zakończył. Przekroczenie limitu czasu, niewspierany pakiet lub niedostępne źródło komunikatów oznaczają brak dowodów.

Zaplanuj też aktualizacje po wydaniu. Nowe komunikaty mogą dotyczyć artefaktu zaakceptowanego wczoraj. Właściciel usługi potrzebuje spisu składników, procesu reagowania i możliwości przygotowania poprawionego wydania.

Przejdź do ciągłego zarządzania podatnościami, aby powiązać regularne skany ze zweryfikowanymi poprawkami produkcyjnymi.