Bezpieczne zarządzanie zależnościami

Nowoczesne aplikacje importują setki pakietów innych firm. Każda zależność — a także jej zależności przechodnie — zwiększa powierzchnię ataku. Luka w popularnej bibliotece (taka jak Log4Shell w Log4j) może jednocześnie narazić na atak tysiące aplikacji.

Pliki blokad (package-lock.json, yarn.lock, Pipfile.lock) przypinają każdą zależność do dokładnej wersji, w tym zależności przechodnie. Pliki blokad należy zatwierdzać w systemie kontroli wersji. Zapewnia to powtarzalne kompilacje i zapobiega przypadkowym aktualizacjom wersji, które mogą wprowadzić luki.

Narzędzia SCA skanują drzewa zależności i porównują je z bazami danych CVE w celu identyfikowania podatnych pakietów. OWASP Dependency-Check, Snyk i GitHub Dependabot automatycznie wykrywają znane luki oraz sugerują poprawione wersje wraz ze wskazówkami dotyczącymi usunięcia problemu.

Dependabot i Renovate Bot automatycznie otwierają PR-y, gdy dostępne są nowe wersje bez zmian powodujących niezgodność. Nadają priorytet aktualizacjom bezpieczeństwa. Należy skonfigurować automatyczne scalanie aktualizacji poprawek po pomyślnym przejściu CI, aby utrzymywać aktualność zależności przy minimalnym nakładzie pracy ręcznej.

Przed dodaniem zależności należy sprawdzić liczbę pobrań, aktywność ostatnich commitów, liczbę otwartych zgłoszeń, zgodność licencji oraz historię znanych CVE. Należy wybierać dobrze utrzymywane pakiety z aktywnymi procesami reagowania na incydenty bezpieczeństwa zamiast nieutrzymywanych alternatyw.

Zależności bezpośrednie wciągają własne zależności. W incydencie związanym z event-stream napastnicy przejęli kontrolę nad zależnością przechodnią używaną przez miliony pakietów. Należy audytować całe drzewo zależności, a nie tylko zależności bezpośrednie.

Ataki typu dependency confusion polegają na publikowaniu w publicznych rejestrach złośliwych pakietów o tej samej nazwie co pakiety wewnętrzne. Należy ograniczać to ryzyko za pomocą nazw pakietów z zakresem, uwierzytelniania w prywatnym rejestrze oraz umieszczania zatwierdzonych rejestrów na liście dozwolonych w plikach .npmrc lub pip.conf.

Zestawienie komponentów oprogramowania (SBOM) to możliwy do odczytu maszynowego spis wszystkich komponentów użytych w oprogramowaniu. Zestawienia SBOM można generować za pomocą Syft lub CycloneDX. Po opublikowaniu nowych CVE zestawienia SBOM umożliwiają szybką ocenę wpływu podatności — pozwalają zidentyfikować zagrożone wersje w ciągu kilku minut.

Licencje OSS nakładają określone obowiązki. GPL może wymagać ujawnienia kodu źródłowego. Licencje MIT i Apache 2.0 są liberalne. FOSSA i TLDR-Legal pomagają oceniać zgodność licencji. Należy uwzględnić skanowanie licencji w CI, aby zapobiec przypadkowemu włączeniu kodu objętego GPL do produktów komercyjnych.

Subresource Integrity (SRI) dla skryptów hostowanych w CDN wykorzystuje skrót kryptograficzny w atrybucie integrity. Plik npm package.json zawiera pole integrity. Podczas pobierania pakietów w CI należy weryfikować sumy kontrolne, aby wykrywać manipulacje w łańcuchu dostaw.

W przypadku krytycznych podatności należy wdrażać poprawki bezpieczeństwa w ciągu 24–48 godzin od opublikowania CVE. Do ustalania priorytetów należy używać ocen CVSS oraz danych dotyczących możliwości wykorzystania podatności. Zależność z poprawką bezpieczeństwa, nawet jeśli poprawka wprowadza niekompatybilną zmianę, jest lepsza niż możliwa do wykorzystania podatność w środowisku produkcyjnym.

Na czym polega atak typu dependency confusion?

Bezpieczne zarządzanie zależnościami wymaga przypinania wersji w plikach blokad, uruchamiania skanowania SCA w CI/CD, automatyzacji aktualizacji poprawek, generowania zestawień SBOM na potrzeby oceny wpływu oraz oceny poziomu bezpieczeństwa nowych zależności przed ich przyjęciem.