A GitLab szerint gépi sebességű védelem kell a szoftverfejlesztésben

Gyorsabban nő a felfedezések száma, mint a javítási kapacitás

A GitLab szeptember 18-án közzétett bejegyzése szerint az AI-modellek és az ügynöki rendszerek gyorsabbá és olcsóbbá teszik a meglévő biztonsági hiányosságok felderítését, összekapcsolását és kihasználását. A vállalat biztonsági vezetője úgy látja, hogy ez sok esetben nyugtalanítóbb egy új, ismeretlen sérülékenységnél, mivel a kockázat már eleve jelen lehet a szervezet környezetében.

A GitLab adatai szerint 2026-ban eddig 317 CVE-t publikáltak, szemben a 2025-ös teljes év 181, illetve a 2024-es év 170 CVE-jével. A hibajutalmazási program az elmúlt 90 napban valamivel több mint 3600 bejelentést kapott, miközben 2024 egészében 1440 jelentés érkezett.

A cég szerint az iparági adatok is hasonló nyomást jeleznek. A Verizon Data Breach Investigations Report alapján a sérülékenységek kihasználása először előzte meg a hitelesítő adatokkal való visszaélést a kezdeti hozzáférési módszerek között. A megoldás mediánideje közben 32 napról 43 napra nőtt. A GitLab szerint a súlyosság alapján rendezett hibajegyzékek egyre kevésbé mutatják meg a kockázatok teljes összefüggését, mert az ügynökök több, önmagában alacsonyabb súlyosságú hibát is össze tudnak kapcsolni.

A GitLab háromrétegű védekezési modellt javasol

A vállalat szerint a legfontosabb mérőszámnak nem a vizsgálatok, hibajegyek vagy felülvizsgálatok száma kell lennie, hanem a felismeréstől az ellenőrzött javításig eltelt idő. A biztonsági kontrollokat a végrehajtási folyamatba kell helyezni, minden jelentős hibához pedig lezárt javítási ciklust kell kapcsolni.

Az első réteg a teljes támadási felület felderítése. A GitLab azt javasolja, hogy a szervezetek saját kódjukon, infrastruktúrájukon és telepítési útvonalaikon is használják a fejlett modelleket. A vállalat ezt az Anthropiccal közösen futó Project Glasswing keretében teszi meg, ahol a modelleket kritikus rendszereken és termékeken alkalmazzák. A GitLab Duo Agent Platform ezt követően folyamatosan osztályozza és javítja a feltárt problémákat.

A második réteg az alapok megerősítése. Ennek része a teljes támadási felület folyamatos vizsgálata, a statikus alkalmazásbiztonsági tesztelés, a függőségek, konténerek, titkok, API-k és a dinamikus alkalmazásbiztonság egységes kezelése. A GitLab szerint a hitelesítő adatoknak meghatározott identitással, hatókörrel, élettartammal és visszavonási folyamattal kell rendelkezniük. Az ügynököket különálló, kiemelt jogosultságú szereplőként kell kezelni, saját azonosítóval, korlátozott eszközökkel és naplózott műveletekkel.

A védelemnek az élesítés után is folytatódnia kell

A harmadik réteg a már élesített szoftver védelme. Egy korábban kiadott összetevő egy későbbi sérülékenységi bejelentés miatt is kockázatossá válhat, és a kihasználás akár a javítás elérhetővé válása előtt is megkezdődhet. Emiatt a GitLab szerint az ellenőrzéseket az egyesítés után is folytatni kell, a gyártási környezetet pedig újra kell értékelni, amikor erősebb modellek jelennek meg.

A vállalat elképzelése szerint a javításnak ugyanabban a fejlesztői munkafolyamatban kell megtörténnie, amelyben a módosítás készült. A szabályokat azokon a pontokon kell érvényesíteni, ahol a munka végrehajtása történik, az ügynöki műveletekhez pedig egyértelmű jóváhagyási határok szükségesek. A GitLab szerint így a fejlesztési folyamat nem csak gyorsabb lehet, hanem a kód létrehozásától az élesítésig folyamatosan ellenőrizhetővé és irányíthatóvá válik.