Sztuczna inteligencja zmienia bezpieczeństwo oprogramowania open source. Odpowiedzialność za cykl życia oprogramowania również musi ulec zmianie.

Gdy Drupal ujawnił CVE-2026-9082 w maju, próby wykorzystania luki w zabezpieczeniach zostały zgłoszone w ciągu 48 godzin. To kurczące się okno między ujawnieniem a wykorzystaniem ilustruje nową rzeczywistość, z którą muszą się mierzyć organizacje, które polegają na oprogramowaniu open source. Mają mniej czasu niż kiedykolwiek wcześniej, aby ocenić ryzyko i zareagować, zanim luki w zabezpieczeniach zostaną aktywnie wykorzystane.

Sztuczna inteligencja przyspiesza tę zmianę, dramatycznie zwiększając szybkość i skalę odkrywania luk w zabezpieczeniach. Wraz ze zwiększaniem się odkrywania luk w zabezpieczeniach, wyzwaniem dla przedsiębiorstw nie jest już tylko identyfikacja luk w zabezpieczeniach, ale również zapewnienie, że oprogramowanie, na którym polegają, pozostaje bezpieczne, obsługiwane i odporne na awarie w całym cyklu życia.

Sztuczna inteligencja przyspiesza zagrożenia szybciej niż przedsiębiorstwa mogą zareagować

Narzędzia wspomagane sztuczną inteligencją przyspieszają odkrywanie luk w zabezpieczeniach i obniżają barierę dla tworzenia exploitów, redukując czas, jaki organizacje mają na ocenę ryzyka i reakcję. Zaktualizowane prognozy branżowe z FIRST szacują, że około 66 000 luk w zabezpieczeniach zostanie ujawnionych w 2026 roku, co stanowi 11% wzrost w stosunku do prognozy z lutego, po tym, jak ujawnienia przekroczyły o 46% tempo przewidziany do kwietnia.

FIRST słusznie zauważa, że ryzyko wykorzystania luk w zabezpieczeniach nie wzrosło w tym samym tempie, co surowa liczba luk, i że KEV i EPSS mogą pochłonąć ten wzrost. Ale triage i łatanie zakładają, że istnieje łata. Dla oprogramowania zbudowanego na frameworkach, które są już nieobsługiwane, takiej łaty nie ma, a cały model priorytetowy załamuje się w momencie, w którym jest to najważniejsze.

Tymczasem zespoły ds. bezpieczeństwa nie działają z prędkością maszyn. Nadal muszą określić, które systemy są dotknięte, ocenić ryzyko biznesowe, przetestować poprawki i wdrożyć aktualizacje bez zakłócania działalności. Dla organizacji, które polegają na oprogramowaniu open source, to wyzwanie staje się jeszcze większe, gdy kluczowe dla biznesu komponenty osiągnęły koniec swojego życia i nie otrzymują już poprawek bezpieczeństwa od swoich pierwotnych twórców.

Wynikiem jest rozszerzająca się luka między identyfikacją luk w zabezpieczeniach a ich rzeczywistym usunięciem. Organizacje potrzebują więcej niż tylko widoczność luk w zabezpieczeniach. Potrzebują pewności, że oprogramowanie, na którym polegają, pozostanie bezpieczne i obsługiwane w całym cyklu życia.

Oprogramowanie nieobsługiwane staje się coraz większym ryzykiem dla przedsiębiorstw

Wiele organizacji nadal używa wersji oprogramowania open source, które są już nieobsługiwane, takich jak Drupal, Spring i AngularJS, ponieważ zastąpienie kluczowych dla biznesu aplikacji jest kosztowne, wymaga dużych zmian i często trwa kilka lat.

Ta rzeczywistość coraz częściej koliduje z nowymi oczekiwaniami regulacyjnymi. Ramy prawne, takie jak Unijna ustawa o cyberodporności, DORA, NIS2 i PCI DSS 4.0, kładą większy nacisk na utrzymanie oprogramowania, widoczność łańcucha dostaw i ciągłe wsparcie oprogramowania, czyniąc oprogramowanie nieobsługiwane coraz większym ryzykiem i problemem operacyjnym.

Ponieważ modernizacja często trwa kilka lat, organizacje potrzebują strategii, aby utrzymać bezpieczne i obsługiwane oprogramowanie w trakcie przejścia.

Organizacje potrzebują widoczności cyklu życia, a nie tylko widoczności luk w zabezpieczeniach

Większość organizacji zainwestowała dużo w narzędzia, które mają na celu identyfikację luk w zabezpieczeniach we wszystkich środowiskach. Te narzędzia odpowiadają na pytanie, gdzie znajdują się luki w zabezpieczeniach. Nie odpowiadają na inne pytanie, które staje się równie ważne: Czy to oprogramowanie jest nadal obsługiwane?

Odpowiedź na to pytanie wymaga, aby organizacje spojrzały poza zarządzanie lukami w zabezpieczeniach. Muszą mieć widoczność, czy kluczowe komponenty oprogramowania open source są aktywnie utrzymywane, zbliżają się do końca swojego życia lub nie otrzymują już wsparcia społeczności, oraz muszą mieć strategię, aby utrzymać te systemy bezpieczne do czasu zakończenia modernizacji.

Liderzy przedsiębiorstw powinni skupić się na trzech priorytetach:

• Wiedz, co posiadasz. Zidentyfikuj oprogramowanie nieobsługiwane przed lukami w zabezpieczeniach, audytami lub incydentami, które zmuszą do zajęcia się tym problemem, i zrozum, które aplikacje kluczowe dla biznesu zależą od niego.
• Zaplanuj bezpieczną modernizację. Wbuduj planowanie cyklu życia w strategie zakupu, rozwoju i modernizacji, z wyraźnymi planami utrzymania oprogramowania bezpiecznie w trakcie przejścia.
• Traktuj wsparcie oprogramowania jako priorytet biznesowy. Wraz ze zwiększaniem się złożoności ekosystemów oprogramowania, długoterminowe wsparcie oprogramowania powinno być traktowane jako strategiczna zdolność biznesowa, a nie tylko kwestia inżynieryjna.

Sztuczna inteligencja zmienia sposób, w jaki tworzone jest oprogramowanie, w jaki odkrywane są luki w zabezpieczeniach, oraz jak szybko organizacje są oczekiwane do zareagowania. To, co nie uległo zmianie, to odpowiedzialność przedsiębiorstw za utrzymanie oprogramowania, na którym już polegają, w sposób bezpieczny. Wraz ze zmianą bezpieczeństwa oprogramowania open source przez sztuczną inteligencję, sukces będzie zależał od traktowania odpowiedzialności za cykl życia oprogramowania jako podstawowej zdolności bezpieczeństwa, a nie tylko kwestii technicznej.

Organizacje, które odniosą sukces, niekoniecznie będą tymi, które łatają najszybciej. Będą tymi, które mogą z pewnością zarządzać ryzykiem oprogramowania w całym cyklu życia, utrzymując aplikacje kluczowe dla biznesu bezpieczne i operacyjne, jednocześnie modernizując się na własnych warunkach.