GitHub схаваў частку абмеркавання ўразлівасцей — REST API яе не бачыць

2 кастрычніка 2026 года GitHub дадаў канфідэнцыйныя каментары да паведамленняў бяспекі рэпазіторыяў. Іх бачаць толькі людзі з правам запісу ў рэпазіторый. Аўтар прыватнай справаздачы і запрошаны супрацоўнік без гэтага права не бачаць закрытых запісаў і не атрымліваюць пра іх апавяшчэнняў. Прагляды такіх каментароў фіксуюцца ў журнале аўдыту, а REST API не вяртае іх.

У той жа дзень GitHub адкрыў публічны папярэдні доступ да REST API для каментароў, у тым ліку ў паведамленнях, створаных з прыватных справаздач пра ўразлівасці. Новыя эндпойнты дазваляюць чытаць, дадаваць і рэдагаваць звычайныя каментары. Калі каманда выгружае абмеркаванне для аўдыту або аўтаматычнага трыяжу, такая REST-выгрузка не ўтрымлівае закрытую частку размовы.

Каму бачная закрытая частка абмеркавання

Мяжа доступу да канфідэнцыйнага каментара праходзіць па бягучым праве запісу ў рэпазіторый. Запрашэнне да працы над паведамленнем пра ўразлівасць само па сабе гэтага права не дае. Звычайнае абмеркаванне застаецца даступным удзельнікам паведамлення ў межах іх правоў.

• Аўтар прыватнай справаздачы. Бачыць даступнае яму звычайнае абмеркаванне. Канфідэнцыйны каментар ён можа прачытаць толькі пры наяўнасці права запісу ў рэпазіторый; без яго не будзе і апавяшчэння пра такі запіс.
• Запрошаны супрацоўнік. Можа ўдзельнічаць у звычайным абмеркаванні паведамлення. Калі права запісу ў рэпазіторый няма, канфідэнцыйныя каментары для яго схаваныя, нягледзячы на запрашэнне.
• Удзельнік з правам запісу. Бачыць канфідэнцыйныя каментары ў гісторыі паведамлення разам са звычайнымі. Доступ залежыць ад бягучых правоў: пасля страты права запісу чалавек больш не можа прачытаць закрытыя запісы.

Гэтая розніца важная для прыватнай справаздачы: яе аўтар можа быць паўнавартасным удзельнікам размовы пра ўразлівасць, але не ўдзельнікам унутранага абмеркавання каманды рэпазіторыя. Тое ж датычыцца запрошанага супрацоўніка. Адрасат паведамлення і чалавек з правам запісу — розныя ролі, нават калі яны працуюць над адным выпраўленнем.

Як захоўваецца канфідэнцыйная размова

Пры напісанні каментара ўдзельнік выбірае пазнаку Confidential да адпраўкі. У гісторыі паведамлення такі запіс пазначаны асобна; пасля публікацыі пераключыць каментар са звычайнага ў канфідэнцыйны або назад нельга. Таму аўдыторыя нататкі вызначаецца ў момант яе адпраўкі, а не пасля таго, як у размове з’явяцца іншыя ўдзельнікі.

Прагляды канфідэнцыйных каментароў трапляюць у журнал аўдыту. Закрытая нататка пры гэтым застаецца ў гісторыі самога паведамлення пра ўразлівасць. Раней усе каментары ў такой гісторыі бачылі ўдзельнікі паведамлення, уключаючы аўтара справаздачы; для размовы пра падазрэнне ў злоўжыванні, дэталі расследавання або каардынацыю выпраўлення камандзе даводзілася карыстацца іншым каналам.

Новая пазнака дазваляе трымаць унутраныя нататкі побач са звычайным абмеркаваннем, але з асобнай мяжой бачнасці. Гэта мае значэнне пры аднаўленні ходу трыяжу: гісторыя паведамлення можа ўтрымліваць больш кантэксту, чым бачыць яго аўтар. Журнал аўдыту фіксуе прагляды закрытых каментароў, тады як даступнасць саміх запісаў па-ранейшаму вызначаецца правамі на рэпазіторый.

Што вяртаюць REST і GraphQL

Новыя REST-эндпойнты выдаюць спіс звычайных каментароў да паведамлення пра ўразлівасць, пры патрэбе — толькі абноўленых пасля зададзенага часу. Праз іх можна атрымаць асобны каментар, дадаць новы або адрэдагаваць існы. Выдаленне каментароў праз гэты API пакуль не падтрымліваецца.

У адказах на запыты пра рэпазіторныя паведамленні з’явілася поле comments з колькасцю каментароў. Для глабальнага паведамлення, звязанага з рэпазіторным, таксама вяртаецца колькасць каментароў да звязанага паведамлення. Гэтыя лічыльнікі ўлічваюць толькі неканфідэнцыйныя запісы. Таму нуль у полі не дае падставы сцвярджаць, што ўнутры паведамлення няма размовы каманды.

Для REST-запыту патрэбны доступ да самога паведамлення і адпаведны дазвол на чытанне або запіс паведамленняў бяспекі рэпазіторыя ці патрэбны дазвол токена. Чалавек, якому паведамленне недаступнае, не атрымае праз API яго каментары. Нават інтэграцыя з патрэбнымі правамі на чытанне паведамлення не знойдзе канфідэнцыйных каментароў у гэтых REST-адказах: яны выключаны з эндпойнтаў.

Канфідэнцыйныя каментары даступныя праз GraphQL API з улікам права на іх прагляд. Гэта адрознівае канал атрымання даных ад права доступу: GraphQL не адкрывае закрытую размову аўтару справаздачы або запрошанаму супрацоўніку без права запісу. Для ўдзельніка з такім правам ён дае магчымасць атрымаць частку гісторыі, якую REST не экспартуе.

Што змяняецца для аўдыту і трыяжу

Адначасовае з’яўленне дзвюх магчымасцей мае прамое наступства для аўтаматызацыі: REST можа пераносіць звычайнае абмеркаванне ў сістэму трыяжу, адбіраць абноўленыя каментары і дадаваць нататкі, але не збірае ўнутраныя запісы з пазнакай Confidential. Гэта абмежаванне дзейнічае і тады, калі інтэграцыя працуе ад імя чалавека з правам запісу ў рэпазіторый.

Для аўдыту важна адрозніваць гісторыю паведамлення ад яе REST-копіі. Першая можа ўтрымліваць закрытую размову і следы яе прагляду ў журнале аўдыту; другая ахоплівае звычайныя каментары. Калі REST-архіў выкарыстоўваецца як поўны запіс разгляду ўразлівасці, у ім могуць адсутнічаць менавіта нататкі пра ўнутранае расследаванне і каардынацыю выпраўлення.

Магчымасць атрымаць канфідэнцыйныя каментары праз GraphQL не робіць іх часткай REST-лічыльніка і не змяняе правы ўдзельнікаў паведамлення. Таму колькасць каментароў у REST-адказе апісвае толькі даступнае праз гэты інтэрфейс абмеркаванне. Поўная карціна ўнутранага трыяжу залежыць ад таго, ці мае атрымальнік права запісу і ці ўлічвае выгрузка закрытыя запісы асобна.

Чытайце таксама:

• GitHub Actions ці GitLab CI: кошт хвіліны не раскрывае кошт канвеера
• GitHub Copilot атрымаў чатыры мадэлі і лакальную пясочніцу
• Cursor ці GitHub Copilot: тып задачы важнейшы за агульны рэйтынг