Anthropic-ը անվճար կսկանավորի բաց կոդը, բայց արդյունքը մարդ չի ստուգի

2026 թվականի հոկտեմբերի 8-ի Anthropic-ի հայտարարությամբ մեկնարկեց Cyber Mission-ը, որի բաց կոդին ուղղված մասը՝ OSS Scanner-ը, ընդունված նախագծերին առաջարկում է անվճար պարբերական սկանավորում։ Պահպանողները կստանան հնարավոր խոցելիության բացատրություն, դրա շահագործման վերարտադրելի օրինակ և, երբ հնարավոր է, առաջարկվող շտկում։ Մոդելի կազմած հաշվետվությունը նրանց կուղարկվի առանց նախնական մարդկային ստուգման, ուստի այն պետք է դիտել որպես ստուգման ենթակա գտածո։

Նույն օրը Axios-ի լուսաբանումը նկարագրեց նախաձեռնության մյուս ուղղությունը՝ կարևոր ենթակառուցվածքների պաշտպանության ծրագիրը, որի գործընկերների թվում են Accenture-ը, CrowdStrike-ը, Dragos-ը և Rockwell Automation-ը։ OSS Scanner-ը նախատեսված է բաց կոդով նախագծերի պահպանողների համար. նրանց բաժին է հասնում հնարավոր սխալի մասին արագ տեղեկությունը, ինչպես նաև դրա ճշտության ու առաջարկվող շտկման գնահատման աշխատանքը։

Որ նախագծերը կարող են միանալ OSS Scanner-ին

OSS Scanner-ի մասնակցության կանոններով նախագծի հիմնական պահպանողը գրանցման հայտ է ներկայացնում Anthropic-ի GitHub պահոցում pull request-ի միջոցով։ Կազմաձևում նշվում են սկանավորվող կոդի պահոցը, հիմնական կոնտակտի էլեկտրոնային հասցեն և նախագծի կառուցման համար անհրաժեշտ Dockerfile-ի տեղը կամ տրամադրվում է հենց Dockerfile-ը։ Մինչ նախագծի ընդունումը ստուգվում է, որ հայտ ներկայացնողն իսկապես հիմնական պահպանող է։

Գրանցումը կամավոր է, իսկ ընդունումը՝ անհատական։ Ծրագիրը նախատեսված է կայացած նախագծերի համար, որոնք կարևոր են ենթակառուցվածքների կամ օգտատերերի անվտանգության տեսանկյունից։ Գնահատման մեջ դեր ունեն, օրինակ, անվստահելի մուտքային տվյալների մշակումը և այն, թե քանի այլ ծրագիր է կախված տվյալ նախագծից։ Հետևաբար անվճար ծառայությունը ինքնաշխատ չի միացվում ցանկացած հրապարակային պահոցի։

Պահպանողը կարող է կցել նաև սպառնալիքների մոդել՝ նշելով, թե որ մուտքերն են դիտվում որպես չարամիտ, կոդի որ մասերն են ստուգման շրջանակում և ինչպես է նախագիծը գնահատում խոցելիության ծանրությունը։ Դա օգնում է սկանավորման գործակալին հաշվի առնել այն պայմանները, որոնք միայն կոդից ակնհայտ չեն։ Կառուցման միջավայրը սահմանվում է Dockerfile-ով. կախվածությունները տեղադրվում են նախապես, իսկ դրանից հետո ստուգող գործակալն աշխատում է առանց ինտերնետ հասանելիության։

Ինչ կստանա պահպանողը սկանավորումից հետո

Առաջին սկանավորումից հետո հիմնական կոնտակտին էլեկտրոնային փոստով կուղարկվի հայտնաբերված խնդիրների փաթեթը։ Սկանավորման շղթայում գործակալները կրկին քննում են հնարավոր սխալները, վերլուծում դրանց պատճառը և առաջարկում փոփոխություններ։ Հետագա պարբերական ստուգումները կարող են գտնել ինչպես նոր ավելացած խոցելիություններ, այնպես էլ նախորդ անգամ բաց թողնվածները։ Դրանց հստակ հաճախականություն սահմանված չէ. այն կախված է նաև ծրագրում ընդգրկված նախագծերի ծավալից։

Վերարտադրելի օրինակը ցույց է տալիս, թե ինչ վարքագիծ է մեքենան համարել վտանգավոր, իսկ առաջարկվող patch-ը՝ ինչ փոփոխությամբ է փորձել փակել այդ ուղին։ Դրանք օգտակար ելակետ են, քանի որ պահպանողը կարող է աշխատել կոնկրետ մուտքի և կոդի հատվածի հետ։ Միևնույն ժամանակ պատրաստի փոփոխության առկայությունը չի ապացուցում, որ խնդիրը վերարտադրվում է աջակցվող տարբերակում կամ որ շտկումը կարելի է անմիջապես միավորել հիմնական ճյուղին։

Հաշվետվությունները հասցեագրված են նախագծին, ոչ թե հրապարակվում են որպես բոլորի համար բաց խնդիրների ցանկ։ Եթե թիմն արդեն դժվարությամբ է հասցնում մշակել հաստատված լուրջ խոցելիությունները, լրացուցիչ ավտոմատ գտածոները կարող են մեծացնել հերթը։ Գրանցված նախագիծը կարող է դադարեցնել հաշվետվությունների ստացումը իր կազմաձևում կամ դուրս գալ ծրագրից. սա պահպանողին հնարավորություն է տալիս կառավարել ստացվող աշխատանքի ծավալը։

Ինչու մեքենայի կրկնակի ստուգումը բավարար չէ

Սկանավորման ներսում գործակալների կրկնակի ստուգումը մարդկային անկախ գնահատում չէ։ Մոդելը կարող է ճիշտ նկարագրել կոդի վարքագիծը, բայց սխալ հասկանալ, թե արդյոք վտանգավոր մուտքը հասանելի է իրական տեղակայման պայմաններում։ Այն կարող է նաև չափազանց բարձր գնահատել ծանրությունը կամ առաջարկել փոփոխություն, որը փակում է նկարագրված ուղին, սակայն խախտում է օրինական օգտագործման դեպքը։

Սրանք առանձին հարցեր են՝ սխալը կա՞, այն շահագործելի՞ է նախագծի աջակցվող կազմաձևերում, և առաջարկվող շտկումն անվտանգ ու համատեղելի՞ է։ Հնարավոր է, որ վերարտադրիչը աշխատի միայն հին կախվածությամբ կամ չաջակցվող կարգավորումով։ Հնարավոր է նաև, որ խնդիրը իրական լինի, բայց patch-ը փոխի հրապարակային API-ի վարքագիծը կամ կոտրի առկա թեստերը։ Այդ պատճառով հաշվետվության ծանրության պիտակը և պատրաստի կոդը չեն փոխարինում պահպանողի որոշմանը։

Փոքր թիմի համար արագ առաքման օգուտը կախված է ստուգելու կարողությունից։ Եթե մի քանի գտածո հասնի միաժամանակ, յուրաքանչյուրի համար պետք է վերականգնել համապատասխան միջավայրը, հասկանալ ազդեցությունը և առանձին փորձարկել շտկումը։ Ծրագրի կամավոր ձևաչափը թույլ է տալիս այդ ծանրաբեռնվածությունը հաշվի առնել դեռ միանալուց առաջ։

Ինչպես ստուգել գտածոն մինչև patch-ի միավորումը

Չստուգված հաշվետվությունն ընդունելու գործնական հերթականությունը սկսվում է նկարագրված վարքագծից, ոչ թե պատրաստի patch-ից։ Ստորև բերվածը պահպանողի համար խմբագրական ընթացակարգ է. այն անհրաժեշտ է հենց այն պատճառով, որ ուղարկվող արդյունքը նախապես մարդը չի վավերացնում։ Յուրաքանչյուր փուլ առանձին հարցի է պատասխանում, որպեսզի ճիշտ հայտնաբերված սխալը չշփոթվի միավորման պատրաստ փոփոխության հետ։

1. Վերարտադրել գտածոն։ Առանձին փորձարկման միջավայրում վերցնել հաշվետվության նշած կոդի տարբերակը, կախվածությունները, մուտքային տվյալներն ու գործարկման պայմանները։ Ստուգել՝ նույն գործողությունը հանգեցնո՞ւմ է նկարագրված անվտանգության խախտմանը։ Եթե արդյունքը փոխվում է կազմաձևից կամ տարբերակից կախված, այդ պայմանները գրանցել նախքան ազդեցության մասին եզրակացնելը։
2. Գնահատել իրական ազդեցությունը։ Պարզել՝ խոցելի ուղին հասանելի՞ է նախագծի աջակցվող տեղակայումներում, ո՞վ կարող է կառավարել անհրաժեշտ մուտքը և ի՞նչ տվյալ կամ իրավունք կարող է ստանալ։ Եթե հաղորդված վարքագիծը վերարտադրվում է միայն փորձնական կարգավորումով, դա փոխում է առաջնահերթությունը։ Ծանրությունը որոշել այդ պայմաններով, ոչ թե միայն ավտոմատ հաշվետվության պիտակով։
3. Առանձին փորձարկել առաջարկվող patch-ը։ Վերարտադրիչը վերածել հետընթացը հայտնաբերող թեստի և փոփոխությունը կիրառել առանձին ճյուղում։ Այնուհետև հաստատել, որ վտանգավոր վարքագիծը վերացել է, իսկ սովորական գործառույթները, համատեղելիությունը և սահմանային դեպքերը շարունակում են աշխատել։ Եթե patch-ը թեստն անցնում է միայն խնդրի նկարագրված սցենարում, անհրաժեշտ է քննել դրա ազդեցությունը կոդի մնացած ուղիների վրա։
4. Միավորել վերանայումից հետո։ Կոդի վերանայման ընթացքում հստակ արձանագրել՝ գտածոն վերարտադրվե՞լ է, ի՞նչ ազդեցություն ունի և առաջարկվող շտկումն անցե՞լ է անհրաժեշտ թեստերը։ Եթե այդ հարցերից որևէ մեկը բաց է, հաշվետվությունը պահել որպես հետաքննության նյութ։ Հիմնական տարբերակին միավորվում է միայն այն փոփոխությունը, որի ազդեցությունն ու համատեղելիությունը պահպանողը հաստատել է։

Այս հերթականությունը թույլ է տալիս օգտվել արագ ստացված գտածոյից՝ առանց մեքենայի առաջարկը շփոթելու հաստատված շտկման հետ։ Վերջնական որոշման հիմքը նախագծի սեփական միջավայրում վերարտադրված խնդիրը և առանձին փորձարկված փոփոխությունն են։

Կարդացեք նաև:

• Kit թե Mailchimp․ անվճար 10 հազար բաժանորդը գալիս է առանց ավտոմատացումների
• «Գիտեմ ԱԲ» գրառումը քիչ է․ պորտֆոլիոն պետք է ցույց տա որոշումն ու արդյունքը
• Docker-ի 2375 պորտը բաց է․ ինչպես փակել առանց հեռավար կառավարումը կորցնելու