Képzeld el, hogy van egy ötleted egy alkalmazásra. Valami olyasmire, ami megkönnyítené a vállalkozásod működését, vagy akár másoknak is hasznos lehetne. Korábban valószínűleg programozót kellett volna keresned, elmagyarázni az elképzelésedet, árajánlatot kérni, majd várni, amíg elkészül a fejlesztés.
Most viszont leülsz a számítógéped elé, megnyitsz egy AI-eszközt, és leírod, mit szeretnél. Az AI kérdez néhányat, elkezd dolgozni, te pedig rövid idő múlva már kattintgathatsz is a saját alkalmazásodban.
Működik a regisztráció. Megjelennek az adatok. A gombok azt csinálják, amit vársz tőlük. Még a megjelenés is egész jól sikerült.
Hát nem fantasztikus?
De most jön az a kérdés, amit szerintem sokkal többször kellene feltennünk: attól, hogy valami működik, honnan tudjuk, hogy jól is van megírva?
És itt most nemcsak a biztonságra gondolok. Hanem arra is, hogy mennyire átgondolt a program felépítése, mennyire egyszerű később módosítani, megfelelő technológiával készült-e, és mi történik, ha a kezdetben néhány felhasználóra tervezett alkalmazást egyszer csak több százan szeretnék használni.
Az AI programozás óriási lehetőség. Olyan emberek előtt nyitotta meg a szoftverkészítés világát, akik korábban elképzelni sem tudták, hogy saját alkalmazást hozzanak létre. Ezzel semmi baj nincs. Én is szeretem, amikor a technológia új lehetőségeket ad.
A gond ott kezdődik, amikor a működő végeredményt összekeverjük a kész, biztonságos és hosszú távon is fenntartható termékkel.
Az AI megírta a kódot. De ki mondja meg, hogy jó-e?
Az AI-programozó eszközök egyik legnagyobb előnye, hogy akkor is használhatjuk őket, ha nem értünk a programozáshoz. Leírjuk, mit szeretnénk, és az eszköz megpróbálja megvalósítani. Csakhogy ebben rejlik az egyik legnagyobb nehézség is.
Ha nem értesz a programozáshoz, hogyan ellenőrzöd, amit az AI létrehozott?
Persze megkérdezheted tőle. Sőt, ez teljesen természetes reakció. Miután elkészült az alkalmazás, beírod, hogy „Nézd át a kódot, és mondd meg, biztonságos-e!” Az AI átvizsgálja, majd esetleg azt válaszolja, hogy a kód rendben van, megfelelő megoldásokat használ, és nem talált jelentős problémát.
Megnyugtató, igaz?
Csakhogy az AI véleménye a saját munkájáról még nem független szakértői ellenőrzés.
Ezt azért tartom fontosnak hangsúlyozni, mert egy AI-eszköz a rendelkezésére álló információk és a kapott utasítás alapján vizsgálódik. Ha bizonyos körülményeket nem ismer, egyes problémákat észre sem fog venni. Lehet, hogy a kód egy adott szempontból valóban megfelelő, miközben más szempontból komoly hiányosságai vannak.
Például lehet, hogy a program helyesen kezeli a jelszavakat, de hibásan szabályozza, melyik felhasználó milyen adatokhoz férhet hozzá. Vagy megfelelően működik a bejelentkezés, de a rendszer másik része nem kezeli jól a váratlan helyzeteket.
Az is előfordulhat, hogy az AI a számára látható kódot rendben találja, miközben a problémát a szerver beállítása, az adatbázis jogosultságai vagy egy külső szolgáltatás konfigurációja okozza.
És ez nem feltétlenül azért történik, mert az AI rossz választ akar adni. Egyszerűen korlátozott információkból dolgozik, és maga is tévedhet.
A GitHub Copilot hivatalos tájékoztatója is felhívja a figyelmet arra, hogy az AI által javasolt kód tartalmazhat hibákat és biztonsági problémákat, ezért ugyanúgy szükség van az ellenőrzésére és tesztelésére, mint más forrásból származó kód esetében.
Én ezért óvatos lennék azzal, amikor valaki kizárólag az AI megnyugtató válaszára alapozva jelenti ki, hogy az alkalmazása biztonságos.
Nem biztos, hogy rossz a kód. Lehet, hogy egyszerűen túlbonyolított
Van egy másik probléma is, amelyről szerintem kevesebb szó esik, pedig hosszabb távon nagyon kellemetlen következményei lehetnek. Az AI által írt kód működhet tökéletesen, miközben a megoldás indokolatlanul bonyolult.
Képzeld el, hogy megkérsz egy szakácsot, készítsen neked egy rántottát. Ő pedig elővesz öt különböző gépet, három serpenyőt, különleges konyhai eszközöket, és egy egész órás folyamat végén elkészíti. A rántotta finom lett. A feladatot teljesítette. Csak éppen egy serpenyővel és néhány perc alatt is meg lehetett volna oldani.
Valami hasonló előfordulhat a programozásban is.
Egy tapasztalt fejlesztő bizonyos feladatokat néhány jól megválasztott sorral meg tud oldani. Az AI ugyanarra a problémára esetenként jóval hosszabb, több részből álló megoldást készít. Olyan függvényeket, ellenőrzéseket vagy köztes lépéseket épít be, amelyekre az adott helyzetben nincs szükség.
Persze a rövidebb kód önmagában nem feltétlenül jobb. Néha éppen a részletesebb megoldás az átláthatóbb és biztonságosabb. A probléma az, amikor a bonyolultságnak nincs valódi oka.
Egy ilyen alkalmazás kezdetben még jól működhet. A nehézségek akkor jelentkeznek, amikor módosítani kell rajta valamit. Szeretnél egy új funkciót. Megváltozik egy üzleti folyamat. Másik szolgáltatással szeretnéd összekapcsolni. Kiderül, hogy az egyik korábbi megoldás miatt több másik részt is át kell alakítani. És ilyenkor kezd igazán számítani, milyen minőségű kódot kaptál.
A túlzottan bonyolult programot nehezebb lehet átlátni, tesztelni, javítani és továbbfejleszteni. Egy később bevont programozónak pedig először meg kell értenie, hogyan épül fel az egész rendszer. Ez időbe kerül. Az idő pedig pénz.
Szerintem ezért a kód minőségét nem érdemes pusztán azon mérni, hogy a program jelenleg elvégzi-e a feladatát.
A jó kód nemcsak ma működik. Hanem akkor is kezelhető marad, amikor holnap változtatni szeretnél rajta.
AI slop a programozásban – Amikor a mennyiség elfedi a minőséget
Biztosan találkoztál már az AI slop kifejezéssel. Általában azokra a tömegesen előállított, gyenge minőségű AI-tartalmakra használják, amelyek első pillantásra elfogadhatónak tűnnek, de valójában kevés értéket képviselnek.
Szerintem a programozásban is megfigyelhető egy ehhez hasonló jelenség.
Az AI pillanatok alatt képes rengeteg kódot létrehozni. A képernyőn sorra jelennek meg a fájlok, a funkciók, az újabb és újabb megoldások. A felhasználó pedig azt látja, hogy halad a munka.
De vajon tényleg halad? Vagy csak egyre több kód keletkezik?
Egy alkalmazás attól még nem lesz jobb, hogy több ezer sorból áll. Sőt, ha ugyanazt a feladatot egyszerűbben is meg lehetne oldani, a felesleges bonyolultság később problémát jelenthet. Különösen érdekes ez akkor, amikor az AI saját korábbi hibáit próbálja javítani. Valami nem működik. Megkéred, hogy javítsa ki. Hozzáír néhány sort, módosít egy másik fájlt, esetleg létrehoz egy újabb megoldást. Ettől megjavul az eredeti hiba, de közben egy másik rész kezd furcsán viselkedni. Újabb kérés, újabb javítás.
Egy idő után már nehéz követni, pontosan miért is kerültek bizonyos részek a programba.
Természetesen egy jó AI-eszköz képes lehet a kód egyszerűsítésére és átszervezésére is. Egy tapasztalt fejlesztő pedig kifejezetten hatékonyan használhatja erre. De ha a felhasználó nem tudja megítélni a megoldások minőségét, könnyen elfogadhat minden újabb módosítást pusztán azért, mert a program ismét működik.
Itt jön be az emberi szakértelem szerepe.
Egy programozó nemcsak azt nézheti meg, hogy van-e hiba a kódban, hanem azt is, hogy az egész felépítésnek van-e értelme. Hogy bizonyos részekre valóban szükség van-e, és hogy egy egyszerűbb megoldással könnyebb lenne-e a későbbi fejlesztés.
Mert a programozás nem pusztán kódírás. Legalább annyira szól a megfelelő megoldás kiválasztásáról is.
Az sem mindegy, milyen technológiával készül az alkalmazásod
Tegyük fel, hogy szeretnél egy egyszerű online időpontfoglalót. Vagy egy kisebb ügyfélkezelő rendszert. Esetleg egy olyan alkalmazást, amely segít a vállalkozóknak rendszerezni a feladataikat. Megkéred az AI-t, hogy készítse el.
De milyen programozási nyelven? Milyen keretrendszerrel? Milyen adatbázissal? Hol fog futni az alkalmazás? Mennyibe kerül majd a működtetése? Hogyan lehet később bővíteni?
Ha nem vagy programozó, ezekre a kérdésekre valószínűleg nem tudsz magabiztos választ adni. Az AI viszont választani fog valamilyen megoldást, hiszen szeretné teljesíteni a kérésedet. És itt van a probléma. Attól, hogy egy technológia alkalmas egy feladat megvalósítására, még nem biztos, hogy a te helyzetedben az a legjobb választás.
Lehet, hogy az AI egy összetett rendszert épít fel valamire, amit egy meglévő, megbízható eszközzel egyszerűbben is megoldhattál volna. Vagy olyan technológiát választ, amelyhez később nehezebb megfelelő szakembert találni. Esetleg a kezdetben olcsónak tűnő megoldás fenntartása és bővítése válik költségessé.
Ezeket a szempontokat egy tapasztalt fejlesztő már a tervezéskor mérlegelheti.
És van egy kérdés, amit szerintem különösen érdemes feltenni: biztosan saját alkalmazást kell fejlesztened ahhoz, amit szeretnél?
Lehet, hogy igen. De az is lehet, hogy már létezik rá egy jól működő rendszer, amelyet csak megfelelően be kell állítani, vagy össze kell kapcsolni más eszközökkel.
Egy jó szakember sokszor éppen azzal tud pénzt megtakarítani neked, hogy megmutatja, mit nem érdemes lefejleszteni. Ezért az AI programozás előtt is hasznos lehet legalább egy konzultáció. Nem feltétlenül azért, hogy valaki helyetted készítse el az egészet, hanem azért, hogy segítsen kiválasztani a megfelelő irányt.
A legnagyobb különbség: saját kísérlet vagy másoknak eladott alkalmazás?
Szerintem itt érdemes meghúzni egy nagyon fontos határt.
Ha otthon, saját használatra készítesz egy egyszerű programot, amellyel rendszerezed a feladataidat vagy kipróbálsz egy ötletet, egészen más kockázatot vállalsz, mint amikor egy alkalmazást mások számára is elérhetővé teszel. Egy saját kísérleti projektben bátrabban tanulhatsz, hibázhatsz, újrakezdhetsz. Ha valami nem működik, legfeljebb bosszankodsz egy kicsit, és megpróbálod kijavítani.
De mi történik akkor, ha az alkalmazásodat már ügyfelek használják?
Tegyük fel, hogy AI segítségével készítesz egy online ügyfélkezelő rendszert. A felhasználók regisztrálnak, megadják az adataikat, dokumentumokat töltenek fel, és előfizetnek a szolgáltatásodra. A program működik. Te kipróbáltad. Az ismerőseid is kipróbálták. Mindenki elégedett.
De vajon ellenőrizte valaki, hogy az egyik felhasználó valóban csak a saját adataihoz férhet hozzá?
Mi történik, ha valaki megpróbálja megnyitni egy másik felhasználó dokumentumát?
Mi van, ha egy hibás kérés miatt a rendszer olyan információt ad vissza, amelyhez az illetőnek nem lenne jogosultsága?
Ezek olyan problémák, amelyekre a szokásos kattintgatós tesztelés során könnyen nem derül fény.
Az OWASP webalkalmazás-biztonsági kockázatokat bemutató útmutatója külön is foglalkozik a hibás hozzáférés-szabályozással, a nem megfelelő biztonsági beállításokkal és a tervezési hiányosságokkal. Ezek a problémák egy kívülről tökéletesen működő alkalmazásban is jelen lehetnek.
És ami különösen fontos: a biztonságot nem lehet kizárólag a kód egy-egy részletének ellenőrzésére szűkíteni. A teljes rendszer felépítése, beállításai és működési környezete is számít. Éppen ezért én egészen másként kezelném azt a projektet, amellyel csak saját magamnak kísérletezem, és azt, amelyet már pénzért kínálok másoknak.
Ha mások adatait vagy pénzét bízod egy alkalmazásra, akkor már nemcsak a saját kockázatodról döntesz.
Miért kevés, ha megkéred az AI-t, hogy ellenőrizze saját magát?
Szeretnék még visszatérni erre a kérdésre, mert szerintem ez az egyik legfontosabb tanulság.
Sokan úgy gondolkodhatnak, hogy ha az AI képes megírni a programot, akkor nyilván arra is képes, hogy megvizsgálja a biztonságát. És ebben van igazság. Az AI valóban segíthet a hibák keresésében, a kód átnézésében, a lehetséges sérülékenységek felismerésében. Akár egy másik AI-eszközt is megkérhetünk arra, hogy ellenőrizze az elkészült munkát. Ez hasznos lehet. De továbbra sem jelent teljes körű garanciát.
Egy alkalmazás biztonságának megítéléséhez ugyanis tudni kell, milyen környezetben működik, milyen adatokat kezel, kik férhetnek hozzá, hogyan történik a telepítés, és milyen kockázatok merülhetnek fel a használata során. Ráadásul nem biztos, hogy laikusként minden fontos kérdés eszedbe jut.
Honnan is jutna?
Ha nem értesz az alkalmazásbiztonsághoz, valószínűleg nem tudod felsorolni az összes olyan helyzetet, amelyet ellenőrizni kellene. Megkérdezheted az AI-t, hogy „biztonságos-e a program?”, de ez rendkívül tág kérdés.
Lehet, hogy az AI talál néhány problémát, kijavítja őket, majd azt mondja, hogy az alkalmazás megfelelő. Csakhogy attól, hogy a megtalált hibákat kijavította, még maradhatnak olyanok, amelyeket nem ismert fel.
Az OWASP alkalmazásbiztonsági ellenőrzési szabványa jól érzékelteti, mennyire sokrétű feladat egy webalkalmazás biztonságának vizsgálata. Nem egyetlen kérdésre adott igen vagy nem válaszról beszélünk, hanem különböző követelmények és működési helyzetek ellenőrzéséről.
Én ezért úgy tekintek az AI biztonsági javaslataira, mint hasznos segítségre, amelyet érdemes komolyan venni, de amely önmagában nem helyettesíti a megfelelő szakmai ellenőrzést.
Ez nemcsak az AI-ra igaz. Egy hagyományosan fejlesztett alkalmazásnál sem attól lesz megbízható a rendszer, hogy a saját készítője azt mondja róla, minden rendben van.
Ha már megspóroltad a fejlesztés költségét, az ellenőrzésre miért sajnálnád a pénzt?
Na, ez az a kérdés, amit szerintem érdemes lenne sokkal gyakrabban feltenni.
Tegyük fel, hogy van egy alkalmazásötleted. Ha hagyományos módon készíttetnéd el, jelentős fejlesztési költséggel kellene számolnod. Ehelyett AI segítségével elkészíted az első működő változatot. Rengeteg időt és pénzt takaríthattál meg.
Miért ne fordítanál ennek egy részéből arra, hogy egy hozzáértő szakember átnézze az elkészült munkát?
Nem feltétlenül kell rögtön egy teljes fejlesztőcsapatot megbíznod. A projekt méretétől és összetettségétől függően lehetőség lehet egy célzott kódellenőrzés, technikai felülvizsgálat vagy biztonsági vizsgálat is. Persze ezek nem ugyanazt jelentik. Egy programozó megvizsgálhatja a kód felépítését és minőségét, míg egy alkalmazásbiztonsággal foglalkozó szakember kifejezetten a sérülékenységeket és a lehetséges támadási pontokat keresheti. Összetettebb projektnél akár mindkettőre szükség lehet.
És azt sem szeretném állítani, hogy egy ilyen ellenőrzés minden esetben olcsó. Egy nagyobb, bonyolultabb rendszer alapos vizsgálata komoly munka, és előfordulhat, hogy jelentős hibákat kell kijavítani. De egy kisebb projekt célzott felülvizsgálatának költsége nem feltétlenül éri el egy teljes alkalmazás nulláról történő fejlesztésének árát. Éppen ezért érdemes előre árajánlatot kérni, és tisztázni, hogy pontosan mire terjed ki az ellenőrzés. Szerintem az lenne az ideális, ha a vállalkozó már az elején úgy tervezne, hogy az AI segítségével elkészített alkalmazás szakmai átnézése is része a költségvetésnek.
Így továbbra is kihasználhatja az AI nyújtotta lehetőségeket, miközben nagyobb eséllyel veszi észre azokat a problémákat, amelyek később sokkal többe kerülhetnének.
Ha egy alkalmazással pénzt szeretnél keresni, akkor az ellenőrzésre fordított összegre érdemes a termékfejlesztés részeként tekinteni, nem felesleges kiadásként.
Ha szükséged van biztonsági áttekintésre vagy tanácsadásra, jó szívvel ajánlom kollégámat Asztalos Dávidot. Rendszeresen dolgozom vele projekt alapon, megbízható, nagy tudású programozó, aki ért a biztonságos működéshez.
Milyen szakembert érdemes keresni az AI-val készített alkalmazásodhoz?
Itt szeretnék egy fontos dolgot tisztázni: attól, hogy valaki programozó, még nem feltétlenül alkalmazásbiztonsági szakértő is. Ahogyan a weboldalkészítésen belül is vannak különböző szakterületek, úgy a szoftverfejlesztésben is.
Van, aki elsősorban felhasználói felületeket készít. Más adatbázisokkal, szerveroldali fejlesztéssel vagy összetett rendszerek tervezésével foglalkozik. És vannak olyan szakemberek, akik kifejezetten az alkalmazások biztonsági vizsgálatára szakosodtak.
Ha az a célod, hogy valaki megmondja, mennyire jó minőségű és továbbfejleszthető a kódod, akkor érdemes tapasztalt szoftverfejlesztőt keresned, aki ismeri az alkalmazásodhoz használt technológiákat.
Ha viszont a rendszer ügyféladatokat kezel, bejelentkezést biztosít, fizetési folyamatokhoz kapcsolódik, vagy más érzékeny műveleteket végez, akkor alkalmazásbiztonsági tapasztalattal rendelkező szakember bevonása is indokolt lehet.
És itt egy újabb fontos szempont: ne csak azt kérdezd meg, hogy „biztonságos-e az alkalmazásom?” Inkább azt szeretnéd megtudni, milyen problémákat találtak, azok milyen kockázatot jelentenek, melyeket szükséges kijavítani az éles indulás előtt, és milyen további ellenőrzésekre lehet szükség.
Egy jó szakmai felülvizsgálatnak szerintem nem pusztán egy megnyugtató mondatot kell eredményeznie. Olyan visszajelzést érdemes kérni, amelyből megérted, hol tart az alkalmazásod, és milyen feladatok vannak még hátra. Azt is fontos tisztázni, hogy a szakember milyen hozzáférést kap, milyen környezetben végezheti a vizsgálatot, és hogyan kezeli a munkája során megismert adatokat. Éles, valódi ügyféladatokat tartalmazó rendszer esetében ez különösen lényeges.
És még valami: egyetlen felülvizsgálat sem jelent örök garanciát. Ha később jelentősen módosítod az alkalmazást, új funkciókat építesz bele vagy megváltoztatod a működési környezetét, új problémák is megjelenhetnek.
A szakmai ellenőrzés tehát fontos állomás, de a későbbi karbantartást és odafigyelést is érdemes megtervezni.
Az AI programozás nem teszi feleslegessé a szakértelmet. Inkább más szerepet ad neki.
Én egyáltalán nem szeretném, ha ebből a cikkből az a következtetés születne, hogy programozói tudás nélkül senki ne készítsen alkalmazásokat AI segítségével. Sőt, szerintem kifejezetten izgalmas, hogy ma már olyan emberek is megvalósíthatják az ötleteiket, akik korábban erre nem láttak lehetőséget. Kísérletezhetnek, tanulhatnak, kipróbálhatnak új megoldásokat. Egy vállalkozó elkészítheti egy régóta tervezett szolgáltatás első változatát, és megnézheti, van-e rá egyáltalán igény.
Ez hatalmas előrelépés.
De közben fontos lenne felismernünk, hogy a programozás több annál, mint hogy működő kódot állítunk elő. Egy tapasztalt fejlesztő nemcsak kódot ír. Mérlegeli a lehetőségeket, megtervezi a rendszer felépítését, figyelembe veszi a későbbi bővítést, a karbantarthatóságot, a teljesítményt és a biztonságot. És néha éppen az a legnagyobb érték, amit hozzáad, hogy megmutatja: az eredeti elképzelést sokkal egyszerűbben is meg lehet valósítani.
Szerintem a jövőben egyre több olyan együttműködést fogunk látni, ahol a vállalkozó AI segítségével készíti el az alkalmazás első változatát, majd szakembert von be a felépítés, a kódminőség és a biztonság ellenőrzésébe.
Ebben nincs semmi ellentmondás.
Az AI segíthet abban, hogy gyorsabban és kisebb költséggel jussunk el egy működő prototípusig. A szakember pedig abban, hogy ebből valóban megbízható, hosszabb távon is használható termék születhessen. Talán ez lenne a legfontosabb szemléletváltás.
Attól, hogy az AI meg tud írni egy programot, még nem kell minden szakmai döntést is rábíznunk.
Ha saját használatra kísérletezel, tanulj és alkoss bátran. Ha viszont az alkalmazásodat másoknak is szeretnéd eladni, különösen akkor, ha személyes adatokat kezel, gondolj arra is, ki fogja ellenőrizni az elkészült munkát.
Mert egy működő alkalmazás remek kezdet.
De attól még nem biztos, hogy kész termék.
Gyakran ismételt kérdések
Biztonságos az AI által írt programkód?
Lehet biztonságos, de az AI által készített kód ugyanúgy tartalmazhat hibákat és sérülékenységeket, mint az ember által írt program. A biztonság megítéléséhez a kód mellett az alkalmazás felépítését, beállításait és működési környezetét is figyelembe kell venni.
Meg tudja mondani az AI, hogy biztonságos-e az alkalmazásom?
Az AI segíthet a lehetséges hibák felismerésében és javításában, de a válasza nem jelent teljes körű biztonsági ellenőrzést. Különösen olyan alkalmazásoknál érdemes szakértőt bevonni, amelyek személyes adatokat kezelnek, vagy üzleti szempontból fontos feladatokat látnak el.
Miért írhat az AI feleslegesen bonyolult kódot?
Az AI többféle lehetséges megoldás közül állíthat elő egyet, és nem mindig a legegyszerűbbet választja. Előfordulhat, hogy szükségtelen részeket épít be, vagy a korábbi módosítások miatt válik bonyolulttá a program. Egy tapasztalt fejlesztő segíthet a kód egyszerűsítésében és átláthatóbbá tételében.
Eladhatok AI segítségével készített alkalmazást?
Igen, de az értékesítés előtt érdemes ellenőrizni a működését, a biztonságát, a felhasznált technológiák és szolgáltatások feltételeit, valamint a vonatkozó jogi és adatvédelmi követelményeket. Az AI használata önmagában nem mentesít a szolgáltatóként fennálló felelősség alól.
Mennyibe kerül egy AI-val készített alkalmazás szakmai ellenőrzése?
A költség a program méretétől, összetettségétől és az ellenőrzés mélységétől függ. Egy célzott kódellenőrzés vagy technikai konzultáció kisebb feladat lehet, mint egy teljes fejlesztés, míg egy összetett alkalmazás alapos biztonsági vizsgálata jelentősebb ráfordítást igényelhet. Érdemes több szakembertől árajánlatot kérni.
Milyen szakemberrel érdemes átnézetni az AI által írt kódot?
A kód minőségének, felépítésének és karbantarthatóságának vizsgálatához tapasztalt szoftverfejlesztőt érdemes keresni. A biztonsági kockázatok felméréséhez pedig alkalmazásbiztonsággal foglalkozó szakemberre lehet szükség. Összetettebb projekteknél a kétféle szakértelem kiegészítheti egymást.
