Daniel Stenberg, autor i një programi për marrjen dhe dërgimin e të dhënave në rrjet, kritikoi përdorimin e mjeteve të AI gjatë krijimit të raporteve të cenueshmërisë. Raporte të tilla përfshijnë informacione të detajuara, janë të shkruara në gjuhë normale dhe duken me cilësi të lartë, por pa analiza të menduara në realitet ato mund të jenë vetëm mashtruese, duke zëvendësuar problemet reale me përmbajtjen e mbeturinave me pamje cilësore.
Projekti Curl paguan shpërblime për identifikimin e dobësive të reja dhe ka marrë tashmë 415 raporte për probleme të mundshme, nga të cilat vetëm 64 u konfirmuan si dobësi dhe 77 si defekte jo të sigurisë. Kështu, 66% e të gjitha raporteve nuk përmbanin ndonjë informacion të dobishëm dhe u merrte vetëm kohë zhvilluesve që mund të ishin shpenzuar për diçka të dobishme.
Zhvilluesit janë të detyruar të humbin shumë kohë duke analizuar raportet e padobishme dhe duke kontrolluar disa herë informacionin e përmbajtur atje, pasi cilësia e jashtme e dizajnit krijon besim shtesë në informacion dhe ekziston një ndjenjë se zhvilluesi ka keqkuptuar diçka. Nga ana tjetër, krijimi i një raporti të tillë kërkon përpjekje minimale nga aplikanti, i cili nuk shqetësohet të kontrollojë për një problem real, por thjesht kopjon verbërisht të dhënat e marra nga asistentët e AI, duke shpresuar për fat në luftën për të marrë një shpërblim.
Janë dhënë dy shembuj të raporteve të tilla të mbeturinave. Një ditë përpara zbulimit të planifikuar të informacionit në lidhje me cenueshmërinë e rrezikshme të tetorit (CVE-2023-38545), një raport u dërgua përmes Hackerone se patch-i me rregullimin ishte bërë i disponueshëm publikisht. Në fakt, raporti përmbante një përzierje faktesh për probleme të ngjashme dhe copa informacioni të detajuar në lidhje me dobësitë e kaluara të përpiluara nga asistenti i AI i Google, Bard. Si rezultat, informacioni dukej i ri dhe i rëndësishëm dhe nuk kishte asnjë lidhje me realitetin.
Shembulli i dytë ka të bëjë me një mesazh të marrë më 28 dhjetor në lidhje me një tejmbushje buferi në mbajtësin e WebSocket, dërguar nga një përdorues që kishte informuar tashmë projekte të ndryshme për dobësitë përmes Hackerone. Si një metodë për riprodhimin e problemit, raporti përfshinte fjalë të përgjithshme për kalimin e një kërkese të modifikuar me një vlerë më të madhe se madhësia e bufferit të përdorur gjatë kopjimit me strcpy. Raporti jepte gjithashtu një shembull të një korrigjimi (një shembull i zëvendësimit të strcpy me strncpy) dhe tregoi një lidhje me rreshtin e kodit "strcpy(keyval, randstr)", i cili, sipas aplikantit, përmbante një gabim.
Zhvilluesi kontrolloi dy herë gjithçka tre herë dhe nuk gjeti ndonjë problem, por meqenëse raporti ishte shkruar me besim dhe madje përmbante një korrigjim, kishte një ndjenjë se diçka mungonte diku. Një përpjekje për të sqaruar se si studiuesi arriti të anashkalojë kontrollin e qartë të madhësisë të pranishme përpara thirrjes strcpy dhe se si madhësia e tamponit të çelësit doli të ishte më e vogël se madhësia e të dhënave të lexuara çoi në shpjegime të detajuara, por jo me informacion shtesë. që përtypet vetëm në shkaqet e zakonshme të dukshme të tejmbushjes së tamponit që nuk lidhen me kodin specifik Curl. Përgjigjet të kujtonin komunikimin me një asistent të AI dhe pasi kaloi gjysmë dite në përpjekje të pakuptimta për të zbuluar saktësisht se si shfaqet problemi, zhvilluesi më në fund u bind se në fakt nuk kishte asnjë cenueshmëri.
Burimi: opennet.ru