Daniel Stenberg, autori i mjetit për dërgimin dhe marrjen e të dhënave në rrjet, curl, shprehu kritika ndaj përdorimit të mjeteve AI për krijimin e raporteve mbi vulnerabilitetet. Këto raporte përfshijnë detaje të hollësishme, janë shkruar në një gjuhë normale dhe duken cilësore, por nëse nuk analizohen me kujdes, ato thjesht mund të çorientojnë, duke zëvendësuar problemet reale me përmbajtje që duket cilësore por është në të vërtetë e padobishme.
Projektin Curl ofron shpërblime për zbule të vulnerabiliteteve të reja dhe deri tani ka marrë 415 raporte për probleme të mundshme, prej të cilave vetëm 64 janë konfirmuar si vulnerabilitete dhe 77 si gabime jo të lidhura me sigurinë. Kështu, 66% e të gjitha raporteve nuk përmbanin ndonjë informacion të dobishëm dhe vetëm ia kanë marrë kohën zhvilluesve, që mund të ishte shpenzuar për diçka më të dobishme.
Zhvilluesit janë të detyruar të shpenzojnë shumë kohë kot duke analizuar raporte të pavlera dhe duke verifikuar informacionin aty disa herë, pasi cilësia e jashtme e paraqitjes krijon një besim të mëtejshëm në informacion dhe krijon ndjesinë se zhvilluesi ka kuptuar diçka keq. Në anën tjetër, krijimi i një raporti të tillë kërkon përpjekje minimale nga aplikuesi, i cili nuk merr mundimin për të verifikuar nëse ka një problem real, por thjesht kopjon pa mendim të dhënat e marra nga ndihmësit AI, duke shpresuar për fat në garën për të marrë shpërblimin.
Dy shembuj të tillë të raporteve të pavlera jepen. Një ditë përpara shpalljes së planifikuar të informacionit mbi një vulnerabilitet të rrezikshëm të tetorit (CVE-2023-38545), përmes Hackerone u dërgua një raport që thoshte se patch-i me korrigjimin kishte dalë në publik. Në të vërtetë, raporti përmbante një përzierje të përgatitur nga ndihmësi AI Google Bard, e mbushur me fakte rreth problemeve të ngjashme dhe fragmente informacioni të detajuar rreth vulnerabiliteteve të kaluara. Si rezultat, informacioni dukej i ri dhe i aktualizuar, por në të vërtetë nuk kishte lidhje me realitetin.
Shembulli i dytë trajton raportin e marrë më 28 dhjetor rreth mbushjes së tamponit në trajtuesin WebSocket, dërguar nga një përdorues që kishte informuar tashmë projekte të ndryshme për dobësitë përmes Hackerone. Si metodë për të riprodhuar problemin, raporti përfshinte fjalë të përgjithshme për transmetimin e një kërkese të modifikuar me një vlerë që tejkalon madhësinë e tamponit të përdorur gjatë kopjimit me strcpy. Raporti gjithashtu përmbante një shembull korrigjimi (shembulli i zëvendësimit të strcpy me strncpy) dhe përmendte një lidhje në rreshtin e kodit "strcpy(keyval, randstr)", ku sipas mendimit të ankuesit kishte një gabim.
Zhvilluesi e kontrolloi gjithçka tri herë dhe nuk gjeti ndonjë problem, por sepse raporti ishte shkruar me siguri dhe madje përfshinte një korrigjim, kishte ndjesinë se diçka po humbiste diku. Përpjekja për të sqaruar se si hulumtuesi mundi të kalonte kontrollimin e madhësisë para thirrjes së strcpy dhe si madhësia e tamponit keyval u bë më e vogël se madhësia e të dhënave të lexuara, çoi në marrjen e shpjegimeve të detajuara, por pa informacion shtesë, të cilat vetëm shpjegonin arsyet e zakonshme të ndodhjes së mbushjes së tamponit, të pa lidhura me kodin specifik të Curl. Përgjigjet i ngjanin komunikimit me një ndihmës AI dhe pas kalimit të gjysmë dite në përpjekje të panevojshme për të mësuar si shfaqej problemi, zhvilluesi u bind përfundimisht se nuk kishte asnjë dobësi në të vërtetë.
Burimi: opennet.ru
