Egyedi szoftvered van? Ki keresi benne a hibákat?

Rövid válasz: ha erre most nem tudsz nevet mondani, akkor valószínűleg senki. Ezen a héten kiderült, hogy az AI-eszközök húszéves hibákat is megtalálnak a világ egyik legelterjedtebb programozási nyelvében. Ez jó hír. A rossz hír az, hogy ugyanezek az eszközök a támadóknak is elérhetők, és a javítás után a támadás már nem hetek, hanem napok vagy órák kérdése. Egy cég egyedi szoftverének biztonsága ma nem az átadáskor dől el. Hanem azon, ki figyeli utána.

Mi történt?

A PHP2Shell-hibákról tegnap írtunk a céges weboldalak szemszögéből. A hír másik fele most fontosabb. A TechCrunch szerint a két kritikus hibát a 2004-es PHP 5 óta minden verzió tartalmazta, és két biztonsági csapat AI-eszközökkel találta meg őket: a Calif az OpenAI „Patch the Planet” programjában, a Google-hoz tartozó Wiz pedig saját AI-ügynökével és több nagy nyelvi modellel. A PHP október 21-én kiadta a javított verziókat (8.5.12, 8.4.27, 8.3.36 és 8.2.35).

A Wiz egy mondatban foglalta össze, mi változott: a hibák kihasználásának nehézsége eddig akadályt jelentett, de „az AI-val ez már nem akadály”. A Bitport arra is felhívja a figyelmet, hogy egy nyilvános javításból AI-val gyorsan visszafejthető, mi volt a hiba. A The Register szerint a VulnCheck egyetlen éjszaka alatt működő támadókódot épített, amely a szerver memóriavédelmét is megkerüli, és a cég arra figyelmeztet, hogy a támadók is AI-t használnak újabb támadási utak keresésére.

Ugyanezen a héten a GitLab, a sok cég által saját szerveren futtatott kódtároló és fejlesztési platform, maximális, 10-es súlyosságú hibát javított. A The Register szerint a hiba a 2014-es 7.0-s verzió óta, vagyis tizenkét évnyi kiadásban volt jelen, és hitelesítés nélküli kódfuttatást tesz lehetővé a saját telepítésű példányokon. Ezt nem AI, hanem egy bugbounty-programban dolgozó kutató találta meg. A tanulság mégis ugyanaz: a régi, „bevált” kód nem biztonságos kód.

A védők oldalán is gyorsul a tempó. Az AWS október 22-én általánosan elérhetővé tette az AWS Continuum nevű szolgáltatását, amely a cég szerint AI-val keresi meg, elkülönített környezetben ellenőrzi és rangsorolja a kódhibákat, majd javítási javaslatot küld a fejlesztőknek.

Mit jelent ez egy kkv-nak?

Sok kkv-nak van valamilyen egyedi szoftvere: ügyfélportál, belső nyilvántartó rendszer, webshop-kiegészítés, egy integráció két rendszer között. Ezeket jellemzően egy külső fejlesztő vagy ügynökség építette, és az átadás után a szoftver „csak működik”.

Az ilyen alkalmazás nagy része nem a fejlesztőd által írt kód. Keretrendszerekre, nyílt forrású könyvtárakra és futtatókörnyezetekre épül, például PHP-ra. Ha ezek egyikében hiba van, a te szoftvered is sérülékeny, akkor is, ha a fejlesztőd egyetlen sort sem rontott el.

Eddig sok cég abból élt, hogy a régi hibákat senki nem találta meg. Ez a védelem most megszűnik. Amit egy AI-eszköz húsz év után megtalál egy széles körben használt nyelvben, azt egy kevésbé ismert könyvtárban is megtalálhatja. És nem csak a védők gépe keres.

Tipikus helyzet, hogy a fejlesztési szerződés részletesen leírja, mit kell leszállítani, de arról hallgat, mi történik utána. Ki figyeli, ha egy felhasznált könyvtárban kritikus hibát jelentenek? Ki telepíti a javítást, és mennyi időn belül? Ki fizeti? Ha ezt senki nem írta le, akkor egy ilyen héten mindenki a másikra vár.

Az AI-alapú hibakeresők ebben segíthetnek, de nem helyettesítik a felelőst. Egy eszköz javasolhat javítást. Azt valakinek át kell néznie, tesztelnie és élesítenie kell.

Mit tegyél most?

1. Kérj komponenslistát a fejlesztőtől. Mire épül a szoftver (nyelv, keretrendszer, fontosabb könyvtárak), melyik verziókon, és hol fut. Ha erre nem kapsz egy oldalon választ, az már maga is válasz.
2. Tisztázd írásban a karbantartást. Ki figyeli a biztonsági közleményeket, mennyi időn belül kerül fel egy kritikus javítás, és ez benne van-e a havidíjban. A határidőt napokban mérd, ne hónapokban.
3. Kérdezd meg, hogyan keresik a hibákat. Használ-e a fejlesztő automatikus, akár AI-alapú kódellenőrzést, milyen gyakran, és ki dönt a talált hibákról. A válasz ne az legyen, hogy „majd ha baj van”.
4. Nézd meg, hol van a forráskód. Ha saját telepítésű GitLabon vagy más kódtárolón, ki frissíti azt? Ott vannak a jelszavak és hozzáférési kulcsok is? A kódtároló ugyanolyan célpont, mint maga az alkalmazás.
5. Ha a szoftvert már senki nem tartja karban, dönts róla. Frissítés, kiváltás vagy leállítás. Az egyedi szoftver vagy dobozos termék cikkünkben leírtuk, mi alapján érdemes ezt mérlegelni, a szoftverfejlesztés megrendeléséről szóló cikkben pedig azt, mit írj bele a következő szerződésbe.

Ha szeretnéd, hogy valaki átnézze, mire épül és hogyan van karbantartva a céged egyedi szoftvere, nézd meg a szoftverfejlesztés szolgáltatásunkat.

Források

• TechCrunch – PHP Armageddon: OpenAI, Google's Wiz find ancient holes, panicking the internet
• PHP.net – News archive 2026 (critical security advisory, 21 Oct)
• The Register – PHP2Shell exploit bypasses protections designed to stop remote code execution
• The Register – Max-severity GitLab bug allows remote code execution over 12 years of releases
• AWS – AWS Continuum for code vulnerabilities is now generally available
• Bitport – Pánikmód: évtizedes PHP-résre bukkantak az MI segítségével