Jak sprawdzić zależności projektu pod kątem luk? Poradnik deptrust

Każdy, kto tworzy oprogramowanie — czy to prostą stronę internetową, czy zaawansowany system w dużej firmie — korzysta z gotowych „klocków”, czyli bibliotek i pakietów. To ogromne ułatwienie, ale i ryzyko. Co jeśli taki klocek ma ukrytą wadę, czyli lukę w bezpieczeństwie? Atakujący może ją wykorzystać, by przejąć kontrolę nad aplikacją. Problem ten staje się jeszcze poważniejszy, gdy do gry wchodzą agenci AI, którzy często bezrefleksyjnie pobierają stare, dziurawe wersje zależności ¹.

Na szczęście istnieje proste narzędzie, które pomoże nam zapanować nad tym chaosem. Nazywa się deptrust i jest naszym strażnikiem w świecie zależności ². W tym poradniku przeprowadzimy przez instalację i użycie deptrust, aby można było samodzielnie weryfikować bezpieczeństwo komponentów, z których buduje się projekty. Nie potrzeba specjalistycznej wiedzy — wystarczy terminal i chęć zadbania o cyfrowe fundamenty pracy.

Co potrzebujesz (5 min)

Zanim zaczniemy, upewnij się, że masz przygotowane środowisko. deptrust to narzędzie działające w wierszu poleceń (terminalu), więc będziemy go potrzebować. Do instalacji wybierz jedną z poniższych ścieżek:

• Dla większości użytkowników (zalecane): Zainstalowany Node.js wraz z menedżerem pakietów npx lub pnpx.
• Dla użytkowników macOS: Zainstalowany menedżer pakietów Homebrew.
• Dla programistów Go: Zainstalowane środowisko Go.

Nie martw się, jeśli te nazwy brzmią obco. W pierwszym kroku pokażemy dokładnie, co wpisać.

Krok 1: Instalacja deptrust

Zaczynamy od zainstalowania narzędzia. deptrust to program uruchamiany z wiersza poleceń (CLI — Command Line Interface), który działa w pełni lokalnie na Twoim komputerze ³. Nie wysyła żadnych danych do centralnej usługi, a jedynie bezpośrednio odpytuje publiczne bazy danych o lukach, takie jak OSV czy GitHub Advisory Database ^{4 5}.

1. Otwórz swój terminal (na Windows może to być PowerShell, na macOS lub Linuksie — Terminal).

2. Wybierz jedną z poniższych metod instalacji, w zależności od tego, co masz na komputerze ⁶. Rekomendujemy pierwszą opcję z pnpx lub npx.

   • Opcja A (zalecana, przez npx/pnpx): Wpisz w terminalu poniższą komendę i naciśnij Enter. Ta komenda pobierze i zainstaluje deptrust.

     pnpx @clidey/deptrust@latest install

     Jeśli nie używasz pnpm, możesz skorzystać z npx:

     npx @clidey/deptrust@latest install

   • Opcja B (dla użytkowników Homebrew na macOS):

     brew install clidey/tap/deptrust

   • Opcja C (dla programistów Go):

     go install github.com/clidey/deptrust/cmd/deptrust@latest

3. Po zakończeniu instalacji, wpisz komendę deptrust --version, aby upewnić się, że wszystko działa. Powinieneś zobaczyć numer wersji narzędzia.

Jeśli coś poszło nie tak… Najczęstszy problem to brak wymaganego narzędzia (npx, brew lub go). Jeśli widzisz błąd „command not found”, upewnij się, że masz zainstalowany Node.js (dla npx), Homebrew (dla brew) lub Go (dla go) i że są one dostępne w ścieżce systemowej (PATH).

Krok 2: Pierwsze skanowanie — sprawdzanie konkretnej wersji pakietu

Teraz, gdy mamy już deptrust, sprawdźmy jego działanie na konkretnym przykładzie. Użyjemy popularnej biblioteki lodash w wersji, o której wiemy, że zawiera luki.

1. W terminalu wpisz następującą komendę ⁷:

   deptrust check npm lodash 4.17.20

   • check to polecenie sprawdzenia.
   • npm to ekosystem pakietów (dla JavaScript/Node.js) ⁸.
   • lodash to nazwa pakietu.
   • 4.17.20 to konkretna wersja, którą analizujemy.

2. Naciśnij Enter. deptrust połączy się z publicznymi bazami i po chwili wyświetli wynik. Powinieneś zobaczyć coś podobnego do tego ⁹:

   [SCREENSHOT: Wynik skanowania deptrust check npm lodash 4.17.20 pokazujący rekomendację block i listę znalezionych luk.]

   npm lodash@4.17.20: 2 known vulnerabilities found
   recommendation: block
   risk_score: 80
   vulnerabilities:
     - id: GHSA-35jh-r3h4-6jhm
       aliases: [CVE-2021-23337]
       summary: Command Injection in lodash
       severity: high
       source: OSV
       advisory_url: https://github.com/advisories/GHSA-35jh-r3h4-6jhm
       affected_ranges: [SEMVER: introduced 0, fixed 4.17.21]
       fixed_versions: [4.17.21]
     - id: GHSA-p6mc-m468-83gw
       aliases: [CVE-2020-8203]
       summary: Prototype Pollution in lodash
       severity: medium
       source: OSV
       advisory_url: https://github.com/advisories/GHSA-p6mc-m468-83gw
       affected_ranges: [SEMVER: introduced 0, fixed 4.17.20]
       fixed_versions: [4.17.20]

   Co tu widzimy? deptrust znalazł dwie znane luki. Jedna z nich, oznaczona jako GHSA-35jh-r3h4-6jhm (znana też jako CVE-2021-23337), ma status high (wysoki) ¹⁰. CVE (Common Vulnerabilities and Exposures) to unikalny identyfikator dla publicznie znanej luki w bezpieczeństwie. Z tego powodu deptrust wydał rekomendację: block.

Krok 3: Interpretacja wyników — co oznaczają rekomendacje?

deptrust używa prostego systemu rekomendacji, aby pomóc w podjęciu decyzji ¹¹. Zrozumienie go jest kluczowe.

• block (blokuj): Znaleziono co najmniej jedną lukę o statusie krytycznym (critical) lub wysokim (high). Używanie tej wersji pakietu jest wysoce ryzykowne. Należy ją natychmiast zaktualizować.
• review (przejrzyj): Znaleziono lukę o średniej (medium) lub nieznanej (unknown) szkodliwości. Może to też oznaczać, że pakiet jest bardzo nowy (opublikowany w ciągu ostatnich 72 godzin) i wymaga ręcznego sprawdzenia, zanim zostanie użyty w produkcji ¹².
• allow (zezwól): Nie znaleziono żadnych znanych publicznie luk lub znaleziono tylko takie o niskim (low) priorytecie. To ważna rekomendacja, ale uwaga: nie jest to gwarancja 100% bezpieczeństwa ¹³. Oznacza jedynie, że w publicznych bazach danych nie ma informacji o poważnych zagrożeniach dla tej wersji. Zawsze należy zachować ostrożność.

Krok 4: Szukanie bezpiecznej wersji pakietu

Skoro wiemy, że lodash w wersji 4.17.20 jest niebezpieczny, jak znaleźć bezpieczną alternatywę? deptrust ma na to komendę.

1. Wpisz w terminalu:

   deptrust suggest npm lodash

2. To polecenie (suggest) przeszuka dostępne wersje lodash i zaproponuje najnowszą, dla której nie znajduje żadnych znanych podatności ¹⁴.

   W naszym przypadku deptrust poinformuje nas, że wersja 4.17.21 naprawia znalezioną wcześniej krytyczną lukę ¹⁵. To jest wersja, której należy użyć.

Krok 5: Porównywanie dwóch wersji

Chcesz zobaczyć, co dokładnie różni dwie wersje pod kątem bezpieczeństwa? deptrust potrafi je porównać.

1. Użyjmy komendy compare, aby zobaczyć różnicę między starą a nową wersją lodash ¹⁶:

   deptrust compare npm lodash 4.17.20 4.17.21

2. Wynik pokaże, że wersja 4.17.21 nie ma już luki o statusie high, co potwierdza, że aktualizacja jest właściwym krokiem.

Krok 6: Sprawdzanie najnowszej wersji i innych ekosystemów

Nie zawsze znamy numer wersji, który chcemy sprawdzić. Czasem chcemy po prostu wiedzieć, czy najnowsza dostępna wersja pakietu jest bezpieczna.

1. Użyj słowa kluczowego latest ¹⁷. Sprawdźmy na przykład popularną bibliotekę requests z ekosystemu PyPI (dla języka Python):

   deptrust check pypi requests latest

2. deptrust automatycznie znajdzie najnowszą wersję requests i przeskanuje ją w poszukiwaniu luk. Narzędzie obsługuje wiele popularnych ekosystemów, w tym Maven (Java), NuGet (.NET), RubyGems (Ruby) czy Composer (PHP) ⁸.

Krok 7: Weryfikacja akcji w GitHub Actions

deptrust potrafi również analizować zależności w naszych procesach CI/CD, a konkretnie akcje używane w GitHub Actions. To bardzo ważne, ponieważ złośliwy kod w jednej z akcji może prowadzić do kradzieży sekretów lub sabotażu procesu budowania aplikacji.

1. Aby sprawdzić akcję, użyj składni właściciel/repozytorium i podaj wersję. deptrust inaczej traktuje różne sposoby wersjonowania:

   • Pełny hash commita (najbezpieczniej): Jeśli używasz pełnego identyfikatora SHA, deptrust traktuje to jako wersję „przypiętą” i bezpieczną pod kątem niezmienności ¹⁸.

     deptrust check github-actions actions/checkout 44c2b7a8a4ea60a981eaca3cf939b5f4305c123b

   • Tag semantyczny (dobra praktyka): Pełne tagi, np. v4.1.1, są również akceptowane jako stabilne odniesienie ¹⁸.

     deptrust check github-actions actions/checkout v4.1.1

   • Tag ogólny lub gałąź (ryzykowne): Używanie tagów typu v4 albo gałęzi main jest dozwolone, ale deptrust oznaczy taką zależność rekomendacją review ¹⁹. Dzieje się tak, ponieważ kod pod takim odniesieniem może się zmienić w każdej chwili bez wiedzy użytkownika, potencjalnie wprowadzając lukę.

     deptrust check github-actions actions/checkout v4

Co dalej i na co uważać

Gratulacje! Można już używać deptrust do podstawowej weryfikacji zależności. Pamiętaj jednak o kilku pułapkach i dobrych praktykach:

• Rekomendacja allow to nie wszystko. Jak wspomnieliśmy, brak znanych luk nie dowodzi, że pakiet jest w 100% bezpieczny ¹³. Może zawierać nieodkryte jeszcze podatności (tzw. zero-day) lub być złośliwy z innego powodu (np. typosquatting). Zawsze weryfikuj autora i popularność pakietu.
• Uważaj na nowe pakiety. deptrust słusznie flaguje do przeglądu (review) pakiety opublikowane w ciągu ostatnich 72 godzin ¹². To mechanizm obronny przed atakami, w których napastnicy publikują złośliwy kod i liczą na szybkie, automatyczne wdrożenie przez ofiary.
• Brak wsparcia to też informacja. Jeśli deptrust nie ma dostępu do bazy podatności dla danego ekosystemu, zwraca status unknown ²⁰. Nie należy traktować tego jako zielonego światła — to sygnał, że trzeba zweryfikować bezpieczeństwo tego komponentu w inny sposób.

deptrust to potężny sojusznik w walce o bezpieczny łańcuch dostaw oprogramowania. Warto włączyć go do swojej codziennej pracy, a nawet zautomatyzować jako krok w procesie CI/CD (ciągłej integracji i dostarczania), aby żadna podatna zależność nie przedostała się do produkcyjnej wersji Twojej aplikacji.

Źródła

Zobacz też

• Secluso: Zbuduj własną, prywatną kamerę monitoringu za mniej niż 100 zł
• Luka RCE w rozszerzeniu VS Code dla Angulara (CVE-2026-50178)
• Jak oglądać YouTube bez algorytmów? Poradnik NoSuggest krok po kroku

Przypisy

1. Narzędzie deptrust powstało z frustracji spowodowanej ciągłym używaniem starych wersji przez agentów AI. — github.com › deptrust ↩

2. deptrust to narzędzie CLI (Command Line Interface), które sprawdza wersje pakietów pod kątem znanych luk w zabezpieczeniach. — github.com › deptrust ↩

3. Narzędzie deptrust działa lokalnie jako CLI i jako serwer MCP. — github.com › deptrust ↩

4. deptrust bezpośrednio wywołuje publiczne rejestry pakietów i API OSV; nie ma hostowanej usługi deptrust. — github.com › deptrust ↩

5. Dostawcy poradników bezpieczeństwa, tacy jak OSV i GitHub Advisory Database, są równolegle odpytywani przez deptrust. — github.com › deptrust ↩

6. Instalacja deptrust jest możliwa za pomocą ‘pnpx @clidey/deptrust@latest install’, Homebrew lub bezpośrednio z Go. — github.com › deptrust ↩

7. deptrust może sprawdzać konkretne wersje pakietów, np. ‘deptrust check npm lodash 4.17.20’. — github.com › deptrust ↩

8. deptrust obsługuje ekosystemy takie jak npm, PyPI, Cargo/crates.io, Go modules, RubyGems, NuGet, Maven, Packagist/Composer, pub.dev, CocoaPods, Hex.pm, Hackage i GitHub Actions. — github.com › deptrust ↩ ↩²

9. W przypadku pakietu ‘lodash’ w wersji ‘4.17.20’ znaleziono 2 znane luki w zabezpieczeniach, w tym jedną o wysokiej ważności, co skutkuje rekomendacją ‘block’. — github.com › deptrust ↩

10. Luka ‘GHSA-35jh-r3h4-6jhm’ (CVE-2021-23337) dotyczy wstrzykiwania poleceń w pakiecie ‘lodash’ i ma ważność ‘high’. — github.com › deptrust ↩

11. deptrust zgłasza znane luki w zabezpieczeniach i wydaje proste rekomendacje: ‘block’ dla luk krytycznych i wysokich, ‘review’ dla średnich/nieznanych, ‘allow’ dla niskich i braku luk. — github.com › deptrust ↩

12. deptrust emituje również sygnały ryzyka, które nie są CVE, np. wersja opublikowana w ciągu ostatnich 72 godzin jest oznaczana do przeglądu. — github.com › deptrust ↩ ↩²

13. Rekomendacja ‘allow’ oznacza, że nie znaleziono żadnej znanej luki w publicznych źródłach danych, ale nie dowodzi to bezpieczeństwa pakietu. — github.com › deptrust ↩ ↩²

14. deptrust może sugerować bezpieczne wersje pakietów, np. ‘deptrust suggest npm lodash’. — github.com › deptrust ↩

15. Wersja ‘4.17.21’ pakietu ‘lodash’ naprawia lukę ‘GHSA-35jh-r3h4-6jhm’. — github.com › deptrust ↩

16. deptrust może porównywać dwie wersje pakietów, np. ‘deptrust compare npm lodash 4.17.20 4.17.21’. — github.com › deptrust ↩

17. deptrust może sprawdzać najnowsze wersje pakietów, np. ‘deptrust check pypi requests latest’. — github.com › deptrust ↩

18. Dla GitHub Actions, pełne SHAs commitów są traktowane jako przypięte, a tagi semver (np. v4.2.2) są akceptowane bez dodatkowego sygnału przypięcia. — github.com › deptrust ↩ ↩²

19. Tagi tylko z główną wersją (np. v4) i odniesienia do gałęzi (np. main) są ważnymi referencjami dla GitHub Actions, ale deptrust dodaje sygnał przeglądu, ponieważ mogą się one zmieniać. — github.com › deptrust ↩

20. Pokrycie dostawców poradników różni się w zależności od ekosystemu; jeśli deptrust nie znajdzie wsparcia dla danego ekosystemu, zwraca ‘unknown’ zamiast traktować pakiet jako bezpieczny. — github.com › deptrust ↩