GitHub пријава рањивости: SECURITY.md не отвара приватни канал

Да бисте омогућили приватну пријаву рањивости у јавном GitHub репозиторијуму, отворите Settings → Advanced Security и укључите Private vulnerability reporting, како описује GitHub упутство за подешавање репозиторијума. Затим прилагодите образац потребама пројекта и подесите обавештења за особу која ће обрађивати извештаје.

Датотека SECURITY.md служи за упутства о пријављивању, али сама не укључује приватни формулар. Ако истраживаче усмерите на дугме Report a vulnerability, најпре проверите да ли је оно доступно у репозиторијуму и да ли је одговорна особа подесила пријем обавештења.

Укључите приватно пријављивање у репозиторијуму

Поставка је намењена јавном репозиторијуму. Могу да је промене власник репозиторијума, власник организације, менаџер безбедности или корисник са администраторском улогом. Ако не видите Settings или тражену опцију, проверите своја права и да ли сте отворили подешавања репозиторијума у ком желите да примате пријаве.

1. Отворите главну страницу репозиторијума и изаберите Settings.
2. У бочној навигацији, у одељку Security and quality, отворите Advanced Security.
3. Поред Private vulnerability reporting изаберите Enable.

Када је поставка укључена, на страници Advisories појављује се Report a vulnerability, преко ког истраживач шаље приватни извештај. Ако за више репозиторијума користите исту политику пријављивања, проверите поставку у сваком од њих: овај поступак укључује функцију на нивоу појединачног репозиторијума. Текст политике треба да упућује на канал који је заиста доступан посетиоцима тог репозиторијума.

Прилагодите образац за доказ концепта и утицај

Подразумевани формулар тражи сажетак, детаље, доказ концепта и опис утицаја. За питања специфична за пројекат додајте VULNERABILITY_REPORT.yml или VULNERABILITY_REPORT.yaml у директоријум .github репозиторијума. Формулар користи YAML синтаксу GitHub образаца за issues и може да садржи текстуална поља, падајуће листе и поља за потврду.

За прилагођени образац корисна су следећа поља, формулисана тако да одржавалац може да понови налаз и процени његове последице:

• Сажетак: шта је уочено и који део пројекта је погођен.
• Верзија и услови: у којој верзији, конфигурацији или окружењу се проблем јавља.
• Доказ концепта: кораци за понављање, очекивано понашање и стварни резултат.
• Утицај: шта би злоупотреба омогућила и ко или шта би могло бити погођено.

Ово је предлог за поља, не обавеза да истраживач већ зна сваки детаљ. На пример, ако тачна погођена верзија још није утврђена, оставите простор да наведе шта је успео да провери. За доказ концепта тражите довољно информација за понављање, без захтева да у извештај уноси стварне лозинке, токене или туђе личне податке.

Важна поља можете означити као обавезна, а за кратак унос или дужи текст задати и минималну дужину одговора. Ако прилагођени YAML не може да се прочита или провери, приказује се подразумевани формулар; зато после измене погледајте образац који ће истраживач видети. Ако је потребно да сваки нови извештај садржи и ознаку врсте слабости, у подешавањима приватног пријављивања постоји засебан захтев за доделу CWE.

Подесите обавештења за одговорну особу

Омогућен формулар не значи да ће одређена особа добити имејл. Обавештења о новој приватној пријави зависе од улоге примаоца, праћења репозиторијума и његових личних поставки. Зато одредите ко ће преузимати извештаје, па нека та особа провери сопствени налог.

1. На страници репозиторијума изаберите Watch, затим All Activity или Custom → Security alerts.
2. У личним подешавањима обавештења отворите Subscriptions → Watching.
3. У избору Notify me укључите Email и сачувајте промену.

Ова подешавања су лична: сваки администратор или менаџер безбедности који треба да прима имејл мора да их провери на свом налогу. У тиму договорите и ко преузима пријаву када главни прималац није доступан. Видљиво дугме Report a vulnerability потврђује да истраживач може да отвори формулар, док поставке примаоца одређују хоће ли њему стићи обавештење имејлом.

Реците истраживачима где да пошаљу налаз

Када је функција укључена, истраживач према GitHub упутству за приватну пријаву отвара Security and quality → Report a vulnerability, попуњава формулар и бира Submit report. Ако постоји SECURITY.md, политика се приказује изнад формулара. Особа са администраторским или безбедносним правима над репозиторијумом може уместо пријаве да направи нацрт безбедносног обавештења.

У SECURITY.md напишите где се шаљу детаљи рањивости и који контакт користити ако приватни формулар није укључен. Истраживачу јасно реците да опис пропуста и доказ концепта не објављује у јавном issue-у. Ако нема приватног формулара ни наведеног контакта, јавни issue може да послужи само за питање коме се треба обратити, без техничких детаља налаза.

После слања приватног извештаја пријавилац добија потврду у интерфејсу и постаје сарадник на предложеном безбедносном обавештењу. Тиме одржаваоци и истраживач добијају простор за даљи разговор о налазу пре јавне објаве. За одржаваоца је тада пресудно да постоји особа која прати пристигле пријаве и може да започне њихову процену.

Анализа 679 пројеката отвореног кода показала је да је имејл и даље главни начин пријављивања и да су неки сарадници јавно објављивали пропусте упркос подстицају да их пријаве приватно. То је налаз о пројектима обухваћеним истраживањем. Јасно упутство у политици, доступан приватни формулар и прималац који прати обавештења дају истраживачу конкретан пут за слање налаза без откривања детаља у јавном issue-у.

Прочитајте и:

• Пријава кодом уређаја заобилази MFA: како затворити пролаз у Entra ID-у
• Claude отвара директоријум додатака, али плаћени налог је улазница
• Талас пензионисања отвара простор за AI — али знање одлази са људима