GitHub Push Protection може да прескокне push над 50 MB

30 септември 2026 г., во 05:00|Автор: Уредувачки тим на QUASA|5 мин. читање| 1

Според опсегот на откривање тајни на GitHub, Push Protection ја прескокнува проверката на push поголем од 50 MB во јавен репозиториум. Затоа успешен push не докажува дека commit-ите се без клучеви. Проверката може да истече и кај големи операции, а постари или неподдржани формати на токени може да не бидат препознаени.

За репозиториум со код што мора да остане без тајни, проверете која заштита е активна и дополнете ја со локално скенирање, задолжителна CI проверка и преглед на код. Описот на Push Protection разликува корисничка заштита, стандардно вклучена за јавни репозиториуми на GitHub.com, од заштита на репозиториум, која бара GitHub Secret Protection и посебно вклучување. Во приватен репозиториум затоа прво треба да се утврди дали репозиториската заштита навистина е поставена.

Кои промени ги опфаќа заштитата

Push Protection може да блокира поддржана тајна при push од командна линија, commit во веб-интерфејсот, прикачување датотеки или барање преку REST API. Опфатени се и интеракции со GitHub MCP server во јавни репозиториуми. Менувањето на начинот на испраќање, само по себе, не е сигурен начин да се избегне проверката; за одлуката се важни поставките на репозиториумот, видот на тајната и обемот на промената.

Блокирањето се применува на дел од обрасците што може сигурно да се препознаат, а постара верзија на токен може да остане надвор од тој опсег. За некои парови акредитиви, како идентификатор и таен дел, двата дела мора да бидат во иста датотека и да стигнат заедно во репозиториумот за да се создаде предупредување. Ако се поделени меѓу датотеки, отсуството на предупредување не кажува ништо за тоа дали комбинацијата е употреблива.

Матрица: каде се јавува празнината

Јавен репозиториум, помал push, поддржан токен: корисничката заштита на GitHub.com може да го блокира препознаениот клуч. Проверете и дали е вклучена заштитата на репозиториум ако тимот сака предупредувања за заобиколувања и контрола над нив. Успешното испраќање не е потврда дека нема друга, непрепознаена тајна.
Јавен репозиториум, push над документираниот праг: операцијата се прескокнува од Push Protection. Скенирањето треба да се изврши локално пред испраќање, бидејќи CI почнува дури откако промената ќе стигне до репозиториумот. Задолжителната CI проверка сепак може да спречи спојување на таква гранка.
Приватен репозиториум: утврдете дали GitHub Secret Protection и репозиториската Push Protection се вклучени. Документираниот праг за целосно прескокнување се однесува на јавен репозиториум; голем push во приватен репозиториум може да ја истроши временската граница на проверката. Одржувајте независно скенирање и тука.
Стар или сопствен формат на токен: проверете дали конкретниот формат е меѓу поддржаните обрасци за блокирање. Постарите верзии не мора да ја активираат заштитата, а за внатрешен формат тимот треба да постави сопствено правило и во својот скенер. Прегледувачот треба да бара сомнителни вредности и кога автоматски нема наод.
Дозволено заобиколување: кај репозиториската заштита корисник со право на запишување стандардно може да наведе причина и да продолжи. Настанот се евидентира и се создава предупредување; тим што бара претходна контрола треба да постави делегирано одобрување и јасно да ги ограничи лицата со право на заобиколување.

Проверки што треба да останат во CI и при преглед

Поставете скенер за тајни во CI да ги проверува промените во барањето за спојување и направете го неговиот резултат задолжителен услов за спојување. Во правилата вклучете ги форматите на токени за услугите што ги користи тимот и сопствените акредитиви, наместо да се потпрете на општиот список на алатката. Одржувајте безбедни, невалидни тест-примери за да проверите дека правилото навистина дава наод кога конфигурацијата се менува.

Прегледувачот треба да ги отвори промените во конфигурациски датотеки, тестови и примероци што содржат вредности слични на лозинки, приватни клучеви или токени. Посебно разгледајте парови акредитиви поделени меѓу датотеки: автоматското препознавање на пар во GitHub зависи од нивното заедничко присуство во една датотека. Ако пуштањето на скенерот трае предолго или дел од датотеките се исклучени, поправете ја конфигурацијата пред неговиот зелен резултат да го користите како услов за спојување.

Кај јавен репозиториум локалната проверка пред push е критична за обемни промени: последователен CI наод доаѓа откако кодот веќе е објавен на гранката. За приватен репозиториум CI и прегледот остануваат независна проверка на поставките и форматите што Push Protection можеби не ги покрива. Тимот може да ги користи истите правила локално и во CI, но треба да провери дека двете извршувања го опфаќаат истиот материјал.

Кога клуч веќе поминал

Третирајте вистински клуч во репозиториум како изложен, без оглед на тоа дали имало предупредување или одобрено заобиколување. Насоките на GitHub за блокиран push бараат отповикување на изложените вистински тајни за да се спречи неовластен пристап; кога услугата мора да продолжи да работи, заменскиот клуч може да се создаде пред стариот да се отповика. Самото бришење на вредноста од последната верзија на датотеката не ја поништува изложеноста во претходните commit-и.

Утврдете на која услуга припаѓа клучот и какви дозволи имал. Создајте замена ако е потребна за непрекината работа, ажурирајте ги зависните системи и отповикајте го стариот клуч кај давателот.
Побарајте ја истата вредност во другите гранки и во историјата, а потоа отстранете ја од кодот и од местата што ја копирале. Прегледајте ги достапните записи за употреба на клучот и предупредувањата за да утврдите дали бил користен надвор од очекуваниот тек.
Проверете кој услов ја пропуштил тајната: големина на push, неподдржан формат, истек на време или одобрено заобиколување. Додајте правило, сменете ја постапката за одобрување или поправете го CI опфатот според утврдената причина.

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

Сподели: