Najważniejsze informacje o raporcie Rozpowszechnienie zagrożeń związanych z łańcuchem dostaw oprogramowania

W sierpniu 2022 r. Enterprise Strategy Group (ESG) wydała „Walking the Line: GitOps i Shift Left Security”, raport z badań nad bezpieczeństwem programistów dla wielu klientów, analizujący aktualny stan bezpieczeństwa aplikacji. Kluczowym odkryciem raportu jest występowanie zagrożeń związanych z łańcuchem dostaw oprogramowania w aplikacjach natywnych dla chmury. Jason Schmitt, dyrektor generalny Synopsys Software Integrity Group, powtórzył to, stwierdzając: „Ponieważ organizacje są świadkami poziomu potencjalnego wpływu, jaki luka w zabezpieczeniach lub naruszenie bezpieczeństwa łańcucha dostaw oprogramowania może mieć na ich działalność poprzez głośne nagłówki, priorytetyzacja proaktywna strategia bezpieczeństwa jest obecnie podstawowym imperatywem biznesowym”.

Raport pokazuje, że organizacje zdają sobie sprawę, że łańcuch dostaw to coś więcej niż tylko zależności. To narzędzia programistyczne/potoki, repozytoria, interfejsy API, infrastruktura jako kod (IaC), kontenery, konfiguracje chmury i nie tylko.

Chociaż oprogramowanie typu open source może być pierwotnym problemem w łańcuchu dostaw, przejście w kierunku tworzenia aplikacji natywnych dla chmury powoduje, że organizacje obawiają się zagrożeń związanych z dodatkowymi węzłami ich łańcucha dostaw. W rzeczywistości 73% organizacji zgłosiło, że „znacząco zwiększyły” swoje wysiłki w zakresie bezpieczeństwa łańcucha dostaw oprogramowania w odpowiedzi na ostatnie ataki łańcucha dostaw.

Respondenci biorący udział w ankiecie raportu wskazywali na przyjęcie jakiejś formy silnej technologii uwierzytelniania wieloskładnikowego (33%), inwestycję w kontrolę testowania bezpieczeństwa aplikacji (32%) oraz ulepszone wykrywanie zasobów w celu zaktualizowania inwentarza powierzchni ataków ich organizacji (30%) jako kluczowego zabezpieczenia inicjatywy realizowane w odpowiedzi na ataki w łańcuchu dostaw.

Czterdzieści pięć procent respondentów wskazało API jako obszar najbardziej podatny na ataki w ich organizacji. Repozytoria przechowywania danych zostały uznane za najbardziej zagrożone przez 42%, a obrazy kontenerów aplikacji zostały zidentyfikowane jako najbardziej podatne przez 34%.

Raport pokazuje, że brak zarządzania open source zagraża kompilacji SBOM.

Badanie wykazało, że 99% organizacji używa lub planuje korzystać z oprogramowania open source w ciągu najbliższych 12 miesięcy. Podczas gdy respondenci mają wiele obaw dotyczących utrzymania, bezpieczeństwa i wiarygodności tych projektów open source, ich najczęściej cytowane obawy dotyczą skali, w jakiej open source jest wykorzystywane w tworzeniu aplikacji. Dziewięćdziesiąt jeden procent organizacji korzystających z oprogramowania open source uważa, że ​​kod ich organizacji składa się – lub będzie – w 75% z oprogramowania open source. Pięćdziesiąt cztery procent respondentów podało, że „posiadanie wysokiego odsetka kodu aplikacji, który jest open source” jako problem lub wyzwanie związane z oprogramowaniem open source.

Badania Synopsys również wykazały korelację między skalą użytkowania oprogramowania open source (OSS) a występowaniem związanego z nim ryzyka. Wraz ze wzrostem skali wykorzystania OSS, jego obecność w aplikacjach również będzie się naturalnie zwiększać. Presja na poprawę zarządzania ryzykiem w łańcuchu dostaw oprogramowania zwróciła uwagę na rachunek za oprogramowanie kompilacji materiałów (SBOM). Jednak wraz z gwałtownym wzrostem użycia OSS i słabym zarządzaniem OSS, kompilacja SBOM staje się złożonym zadaniem — a 39% respondentów ankiety w badaniu ESG oznaczono jako wyzwanie związane z używaniem OSS.

Zarządzanie ryzykiem OSS jest priorytetem, ale organizacjom brakuje jasnego rozgraniczenia odpowiedzialności.

Ankieta wskazuje na fakt, że podczas gdy skupienie się na łataniu open source po ostatnich wydarzeniach (takich jak luki Log4Shell i Spring4Shell) zaowocowało znacznym wzrostem działań ograniczających ryzyko OSS (73%, o których wspomnieliśmy powyżej), strona odpowiedzialna za te działania łagodzące pozostają niejasne.

Wyraźna większość Zespoły DevOps postrzegać zarządzanie OSS jako część roli programisty, podczas gdy większość zespołów IT postrzega je jako odpowiedzialność zespołu ds. bezpieczeństwa. To może dobrze wyjaśniać, dlaczego organizacje od dawna zmagają się z prawidłowym załataniem OSS. Badanie wykazało, że zespoły IT są bardziej zaniepokojone niż zespoły ds. bezpieczeństwa (48% vs. 34%) źródłem kodu OSS, co jest odzwierciedleniem roli IT w prawidłowym utrzymywaniu łatek podatności OSS. Jeszcze bardziej zaciemniając sprawę, respondenci IT i DevOps (w liczbie 49% i 40%) uważają, że zidentyfikowanie luk w zabezpieczeniach przed wdrożeniem jest obowiązkiem zespołu ds. bezpieczeństwa.

Aktywność programistów rośnie, ale brak wiedzy na temat bezpieczeństwa jest problematyczny.

„Przesunięcie w lewo” było kluczowym czynnikiem przesuwania obowiązków związanych z bezpieczeństwem na dewelopera. Ta zmiana nie obyła się bez wyzwań; chociaż 68% respondentów określiło umożliwienie programistów jako wysoki priorytet w swojej organizacji, tylko 34% respondentów w zakresie bezpieczeństwa rzeczywiście czuło się pewnie, że zespoły programistyczne przejmują odpowiedzialność za testowanie bezpieczeństwa.

Obawy, takie jak przeciążanie zespołów programistów dodatkowymi narzędziami i obowiązkami, zakłócanie innowacji i szybkości oraz uzyskiwanie nadzoru nad działaniami w zakresie bezpieczeństwa, wydają się być największymi przeszkodami w działaniach AppSec prowadzonych przez programistów. Większość respondentów ds. bezpieczeństwa i AppDev/DevOps (przy 65% ​​i 60%) stosuje zasady umożliwiające programistom testowanie i naprawianie ich kodu bez interakcji z zespołami ds. bezpieczeństwa, a 63% respondentów z działu IT stwierdziło, że ich organizacja ma zasady wymagające zaangażowania programistów zespoły bezpieczeństwa.

O autorze

Mike McGuire jest starszym menedżerem ds. rozwiązań w firmie Synopsys, gdzie koncentruje się na zarządzaniu ryzykiem otwartego oprogramowania i łańcucha dostaw oprogramowania. Po rozpoczęciu kariery jako inżynier oprogramowania Mike przeszedł na role związane ze strategią produktową i rynkową, ponieważ lubi kontaktować się z kupującymi i użytkownikami produktów, nad którymi pracuje. Wykorzystując kilkuletnie doświadczenie w branży oprogramowania, głównym celem Mike'a jest połączenie złożonych problemów związanych z AppSec na rynku z rozwiązaniami firmy Synopsys do tworzenia bezpiecznego oprogramowania.