Anthropic hap OSS Scanner falas—raportet dalin pa verifikim njerëzor

Më 8 tetor 2026, Axios raportoi se Anthropic hapi OSS Scanner, një shërbim falas që u ofron projekteve të pranuara me kod të hapur skanime periodike për dobësi sigurie. Raportet shkojnë te mirëmbajtësit pa shqyrtim njerëzor paraprak dhe përfshijnë shpjegime e korrigjime të propozuara. Shpejtësia e dërgimit sjell edhe një përgjegjësi të qartë: marrësi duhet të përcaktojë nëse gjetja është reale përpara se të ndryshojë kodin.

Në njoftimin teknik të Anthropic të 8 tetorit 2026, Todd Ouska i wolfSSL tha “We found the signal from these reports high”: nga 74 raportet që mori projekti, 72 u vlerësuan të vlefshme dhe pesë gjetje u bënë CVE. Kjo është përvoja e një projekti në provën e hershme, jo një normë saktësie e garantuar për çdo skanim. Anthropic pranon se raportet e krijuara nga modeli mund të përmbajnë gjetje të pasakta ose vlerësime të fryra të ashpërsisë.

Kush mund të marrë skanime falas

OSS Scanner është shërbim me regjistrim për mirëmbajtësit kryesorë të projekteve të përshtatshme, jo një skaner që kushdo e nis mbi një depo të zgjedhur. Përzgjedhja merr parasysh rëndësinë e projektit për infrastrukturën dhe sigurinë e përdoruesve. Ekspozimi ndaj hyrjeve të pasigurta dhe numri i projekteve që varen prej tij janë faktorë të rëndësishëm; vendimi për pranimin merret veçmas për secilin aplikim. Mirëmbajtësi duhet të jetë i gatshëm të hetojë edhe raporte që nuk janë konfirmuar ende.

Sipas udhëzimeve të regjistrimit në GitHub, aplikimi bëhet me një kërkesë për ndryshim që shton konfigurimin e projektit, adresën e kontaktit dhe mënyrën e ndërtimit të kodit. Një përshkrim opsional i modelit të kërcënimit mund të tregojë cilat hyrje duhen trajtuar si të pasigurta, cilët përbërës janë në fushën e kontrollit dhe si vlerësohet ashpërsia. Kjo i jep skanerit kontekstin që mund t’i mungojë kur analizon vetëm kodin.

Adresa e kontaktit bëhet pika ku mbërrijnë gjetjet dhe problemet e ndërtimit; për këtë arsye, ajo duhet të ndiqet nga njerëz që mund të reagojnë. Konfigurimi i publikuar në depo e bën adresën të dukshme, ndaj një alias sigurie mund të jetë më i përshtatshëm se adresa personale. Projekti mund të caktojë edhe marrës të tjerë të raporteve, ndërsa për raportet e enkriptuara parashikohet një çelës publik OpenPGP dhe një marrës kryesor.

Çfarë ndodh nga skanimi te raporti

Pas pranimit, shërbimi ndërton projektin në një mjedis të izoluar dhe e analizon pa qasje në internet. Ndërtimi duhet t’i ketë përgatitur më parë varësitë që analiza ka nevojë të përdorë. Skanimi fillestar mund të sjellë një grup raportesh me email; skanimet pasuese kërkojnë dobësi të reja ose probleme që kontrolli i mëparshëm mund t’i ketë humbur. Ritmi i tyre varet edhe nga ngarkesa e shërbimit dhe përdorimi i projektit.

Raporti synon t’i japë mirëmbajtësit më shumë se një vendndodhje të dyshimtë në kod. Ai përfshin një mënyrë riprodhimi dhe shpjegimin e dobësisë; kur është e mundur, identifikon ndryshimin që e futi defektin dhe shton një patch kandidat. Brenda shërbimit, agjentë të modelit bëjnë kontrolle të gjetjeve dhe analizë të shkakut, por kjo nuk zëvendëson shqyrtimin nga një njeri përpara dërgimit. Dallimi ka rëndësi kur raporti duket i plotë dhe bindës: hollësitë e tij janë material për hetim, jo vendim përfundimtar.

Çfarë tregojnë rezultatet e hershme

Rasti i wolfSSL tregon se një rrjedhë raportesh automatike mund të prodhojë gjetje të dobishme për një projekt konkret. Ai tregon gjithashtu pse vlerësimi bëhet nga mirëmbajtësit: ata e njohin konfigurimin, rrugët e përdorimit dhe kriteret e sigurisë së kodit të tyre. Një provë riprodhimi mund të funksionojë vetëm me kushte të veçanta hyrjeje, ndërsa një dobësi reale mund të jetë më pak e rëndë sesa sugjeron etiketa në raport.

Një tjetër dallim është ai mes një defekti të ri dhe një raporti që përsërit një problem të njohur. Të dy mund të përshkruajnë sjellje reale të kodit, por vetëm i pari kërkon domosdoshmërisht një hetim të ri. Edhe një patch që ndal provën e paraqitur mund të lërë të hapur një rrugë tjetër drejt të njëjtit defekt ose të prishë sjellje të pritshme. Prandaj numri i raporteve të marra, i shkëputur nga rezultatet e verifikimit, nuk mat sa është përmirësuar siguria e projektit.

Verifikimi para bashkimit të patch-it

Për ekipin që merr raportin, pika vendimtare është kalimi nga pretendimi automatik te një provë që mund të shqyrtohet nga njerëzit. Kontrolli duhet të ruajë kushtet në të cilat defekti shfaqet dhe të ndajë shkakun e tij nga korrigjimi i propozuar. Kjo është veçanërisht e rëndësishme kur një projekt përdoret në shumë mjedise: një konfigurim prove mund të mos përfaqësojë mënyrën si përdoret kodi në praktikë.

1. Riprodhoni sjelljen e raportuar në një mjedis të kontrolluar. Shënoni versionin e kodit, konfigurimin, hyrjen dhe të drejtat e nevojshme; nëse prova dështon, kontrolloni nëse mungon një parakusht përpara se ta hidhni poshtë gjetjen.
2. Shqyrtoni patch-in kandidat kundrejt shkakut të defektit. Kontrolloni nëse mbyll rrugën e shfrytëzimit, nëse prek funksione të tjera dhe nëse mund të shoqërohet me një test që kap rikthimin e problemit.
3. Ekzekutoni testet përkatëse dhe kalojeni ndryshimin në procesin e zakonshëm të rishikimit të kodit. Bashkimi i patch-it duhet të mbështetet te prova e riprodhuar dhe te vlerësimi i mirëmbajtësve.

Renditja e raporteve kërkon të njëjtin kujdes. Një përshkrim me ndikim të mundshëm të lartë meriton vëmendje të shpejtë, por përparësia reale varet nga arritshmëria e defektit, kushtet e shfrytëzimit dhe mbrojtjet që projekti ka tashmë. Nëse riprodhimi konfirmohet dhe korrigjimi kalon shqyrtimin, raporti ka shërbyer si pikënisje për një ndryshim të arsyetuar; pa këto hapa, ai mbetet një sinjal automatik në kutinë postare të mirëmbajtësit.

Lexoni gjithashtu:

• Cloudflare hap kërkimin web për agjentët, por furnizuesi mbetet vendimtar
• Diella nuk trashëgon pushtet kushtetues: përgjegjësia mbetet njerëzore
• AI nuk po i heq njerëzit nga puna: po riorganizon detyrat rreth tyre