Bezpieczne zależności

  • 5 min

Duży procent kodu obecny w nowoczesnych aplikacjach składa się z bibliotek i zależności wybranych przez Ciebie, dewelopera. Jest to powszechna praktyka oszczędzająca czas i pieniądze. Jednak wadą jest to, że odpowiadasz za ten kod — mimo że inni go napisali — ponieważ używaliśmy go w projekcie. Jeśli badacz (lub co gorsza, haker) wykryje lukę w zabezpieczeniach w jednej z tych bibliotek innych firm, ta sama usterka prawdopodobnie również będzie obecna w aplikacji.

Używanie składników mających znane luki w zabezpieczeniach to duży problem w naszej branży. Jest to tak problematyczne, że stał się OWASP top 10 listy najgorszych luk w zabezpieczeniach aplikacji internetowych, utrzymując się na #9 przez kilka lat.

Śledzenie znanych luk w zabezpieczeniach

Naszym problemem jest uzyskanie wiedzy, kiedy problem został ujawniony. Utrzymywanie aktualności naszych bibliotek i zależności (nr 4 na naszej liście!) oczywiście pomoże, ale dobrym pomysłem jest śledzenie zidentyfikowanych luk w zabezpieczeniach, które mogą mieć wpływ na Twoją aplikację.

Ważne

Gdy system ma znaną lukę w zabezpieczeniach, jest znacznie bardziej prawdopodobne, że istnieją dostępne luki w zabezpieczeniach, kod, którego ludzie mogą używać do ataku na te systemy. Jeśli program wykorzystujący luki zostanie upubliczniony, ważne jest, aby wszystkie systemy, których dotyczy problem, były natychmiast aktualizowane.

Mitre jest organizacją niedochodową prowadzącą listę najpopularniejszych luk w zabezpieczeniach i zagrożeń (CVE). Ta lista to umożliwiający publiczne wyszukiwanie zestaw znanych luk w cyberbezpieczeństwie w aplikacjach, bibliotekach i strukturach. Jeśli znajdziesz bibliotekę lub składnik w bazie danych CVE, ma on znane luki w zabezpieczeniach.

Społeczność zabezpieczeń przesyła problemy, gdy w produkcie lub składniku znaleziono usterkę zabezpieczeń. Każdy opublikowany problem ma przypisany identyfikator i zawiera datę wykrycia, opis luki w zabezpieczeniach oraz odwołuje się do opublikowanych obejść lub oświadczeń dostawcy dotyczących problemu.

Jak sprawdzić, czy występują znane luki w zabezpieczeniach składników innych firm używanych w Twoim oprogramowaniu

Możesz ustawić w swoim telefonie codzienne zadanie i sprawdzać tę listę, ale na szczęście istnieje wiele narzędzi umożliwiających sprawdzenie, czy mamy zależności podatne na ataki. Te narzędzia możesz uruchomić dla swojej bazy kodu lub, jeszcze lepiej, dodać je do potoku ciągłej integracji/ciągłego wdrażania, aby automatycznie sprawdzać występowanie problemów jako części procesu projektowania.

  • OWASP Dependency Check, który ma wtyczkę Jenkins
  • Snyk, narzędzie bezpłatne w przypadku repozytoriów open-source w usłudze GitHub
  • Black Duck, które jest używane przez wiele przedsiębiorstw
  • Retire.js narzędzie do sprawdzania, czy biblioteki JavaScript są aktualne, które może służyć jako wtyczka do różnych narzędzi, łącznie z Burp Suite

Możesz również użyć niektórych narzędzi przeznaczonych specjalnie do analizy kodu statycznego.

Więcej informacji na temat zagrożeń związanych z używaniem składników podatnych na ataki znajdziesz na stronie organizacji OWASP dedykowanej tej tematyce.

Podsumowanie

Jeśli używasz bibliotek lub innych składników innych firm w ramach aplikacji, podejmujesz również wszelkie ryzyko, jakie mogą one mieć. Najlepszym sposobem ograniczenia tego ryzyka jest zapewnienie, że używasz tylko składników, które nie mają skojarzonych z nimi znanych luk w zabezpieczeniach.