Wykorzystywanie rozwiązań open-source jest już czymś tak powszechnym, że nie wyobrażamy sobie bez tego pracy. Właściwie każdy projekt, nad którym pracowałem, w mniejszym lub w większym stopniu korzystał z dobrodziejstw rozwijanych przez społeczność open-source. Ten trend nie dotyczy tylko firm produktowych czy startupów. Duże instytucje finansowe i inne krytyczne sektory również czerpią korzyści z wykorzystywania oprogramowania o otwartym kodzie. Potwierdza to między innymi raport State of Open Source przygotowany przez OpenLogic & Open Source Initiative.
Tak częste wykorzystanie narzędzi open-source może jednak prowadzić do pewnych problemów. Wie to każdy, kto pracował z aplikacjami opartymi o repozytorium pakietów npm czy maven. Programiści, w tym również ja sam, często ulegają pokusie polegania na gotowych bibliotekach i narzędziach. To sprawia, że lista zależności w projekcie rośnie i rośnie. Zarządzanie i monitorowanie tych zależności nie jest sprawą trywialną. Pojawia się też problem zaufania do wykorzystywanych zależności. W pewnym momencie nasze projekt/produkt dojdzie do momentu, w którym będzie trzeba zrobić rachunek sumienia i wykonać audyt użytych bibliotek.
Jako inżynierowie oprogramowania powinniśmy dbać o jakość i bezpieczeństwo naszych rozwiązań. Z tego powodu winniśmy przyjrzeć się temu tematowi jak najwcześniej. Im szybciej zaadresujemy ten temat w cyklu tworzenia oprogramowania (SDLC), tym więcej czasu zaoszczędzimy w przyszłości.
Ostatnio miałem okazję robić rozeznanie wśród komercyjnych narzędzi do skanowania i raportowania podatności – Sonatype, JFrog, Snyk. Postanowiłem zebrać wszystkie swoje przemyślenia i wyniki PoC. Porównanie będzie subiektywne, gdyż odnosi się do aspektów kluczowych w kontekście mojego projektu.
Stack technologiczny mojego projektu – kluczowy aspekt, pod kątem którego robiłem porównanie:
- mikroserwisy napisane w Java/Kotlin
- obrazy Docker jako finalne artefakty
- GitHub jako repozytoria kodu & CI/CD
- Kubernetes
- IaaC – Terraform
Sonatype vs JFrog vs Snyk
Oto tabela, w której dokonałem porównania narzędzi Sonatype JFrog, oraz Snyk. W lepszej jakość możesz otworzyć ją pod tym linkiem do Miro.
Podsumowanie
Na podstawie kolorów komórek łatwo dojść do wniosku, że Snyk zyskał u mnie największą sympatię. Myślę, że najlepiej pasuje on do projektów opartych o nowoczesny stack technologiczny – mikroserwisy, Docker, CI/CD ala GitHub Workflows. Produkt Sonatype okazał się najmniej odpowiedni do mojego projektu. Myślę, że ma on swoje zalety, które dostrzegą projekty, w których wciąż wykorzystuje się Jenkinsa bądź prywatne repozytoria pakietów.
Pomimo sporego czasu, jaki poświęciłem na przetestowanie wszystkich powyższych narzędzi, wraz z zespołem nie zdecydowaliśmy na wybranie żadnego z nich. Zamiast tego postanowiliśmy zbudować własny pipeline do skanowania podatności w oparciu o rozwiązania open-source takie jak Trivy czy Syft.
Jak wspomniałem wcześniej, powyższe porównanie jest moją osobistą oceną. Moje wnioski są bardzo subiektywne, ponieważ szukałem narzędzie pod kątem projektu. W przypadku innego stosu technologicznego być może wnioski mogłyby być inne. Porównanie wykonałem w sierpniu 2022 roku, więc jeśli czytasz to po długim czasie, wiedz, że niektóre rzeczy mogą być już nieaktualne.
