GitHub сега препознава пет нови тајни — Lovable-клучот може веднаш да се повлече

GitHub во објавата од 5 октомври 2026 година потврди дека secret scanning веќе препознава пет нови типови тајни од Lovable Labs, Pydantic Services Inc. и Supabase. Ако API-клуч на Lovable се најде во јавен репозиториум, GitHub автоматски го пријавува кај Lovable Labs. Издавачот тогаш може веднаш да го повлече или замени клучот, но пријавата сама по себе не значи дека пристапот е поништен.

За развоен тим, разликата е во тоа кој го добива наодот и кој ја проверува состојбата на клучот. Корисничко предупредување во GitHub бара реакција од сопственикот на репозиториумот; партнерската пријава за јавен Lovable-клуч оди до неговиот издавач. За приватните репозиториуми, CloudNinjas посочува дека одговорноста за санација останува кај сопственикот, без автоматска партнерска пријава.

Кои клучеви и токени влегоа во новото откривање

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

• Lovable Labs — lovable_api_key. Детекторот го препознава API-клучот во покриен репозиториум. За јавен репозиториум е предвидена и автоматска партнерска пријава до Lovable Labs, по која издавачот може да го повлече или ротира клучот. Тимот сепак треба да утврди дали клучот сè уште се користи и дали замената е завршена.
• Pydantic Services Inc. — logfire_token и pydantic_ai_gateway_api_key. Обрасците се однесуваат на токен за Logfire и API-клуч за Pydantic AI Gateway. Во покриен јавен или приватен репозиториум откривањето создава корисничко предупредување што го обработува тимот. За овие два типа во објавената промена нема наведена нова партнерска пријава до Pydantic.
• Supabase — supabase_oauth_access_token и supabase_scoped_personal_access_token. Станува збор за OAuth-пристапен токен и личен пристапен токен со ограничен опсег. Нивното откривање во покриен репозиториум води до корисничко предупредување. Оваа новост не ги опфаќа автоматски сите други клучеви поврзани со проект на Supabase.

Ваквата поделба е важна кога ист проект содржи повеќе услуги. Наод означен како Supabase OAuth-токен не се решава со промена на Lovable-клуч, а предупредување за Logfire не кажува ништо за состојбата на Pydantic AI Gateway-клуч. Точниот тип во наодот го одредува местото каде што се проверува и заменува пристапот.

Пријавата до Lovable не е исто што и предупредување

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

Можноста Lovable Labs брзо да повлече изложен клуч е реална последица од автоматското известување, но објавата не задава рок за реакција. Ако апликација или автоматизација го користи истиот клуч, неговото повлекување може да го прекине тој пристап сè додека не се постави замена. Затоа тимот треба да ја провери состојбата кај услугата што го издала клучот, наместо да ја проценува според тоа дали во GitHub се гледа предупредување.

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

Каде тимот може да очекува наод

Референтната листа на GitHub наведува дека скенирањето работи автоматски и бесплатно за јавни репозиториуми. За приватни и внатрешни репозиториуми во сопственост на организација, потребен е вклучен GitHub Secret Protection на GitHub Team или GitHub Enterprise Cloud. Истата документација ги разликува корисничките предупредувања, предупредувањата по заобиколена заштита при испраќање код и партнерските пријави, кои не се прикажуваат како партнерски предупредувања во безбедносниот дел на репозиториумот.

Тим со јавен код и приватна инфраструктура затоа може да има различна покриеност меѓу репозиториумите. Додавањето детектор во GitHub не значи дека секој приватен репозиториум на организацијата ја има потребната функција за кориснички предупредувања. За Lovable, проверката само на списокот со предупредувања дополнително не ја покажува состојбата на партнерската пријава ниту потврдува дека издавачот го повлекол клучот.

Редослед за веќе изложен клуч

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

Бришењето на тајната од тековната верзија на кодот ја отстранува видливата вредност таму, но не ја поништува кај издавачот. Стариот клуч може да остане во претходни записи или во други копии на проектот, па главната проверка е дали тој повеќе овозможува пристап. Дури по потврдената замена има смисла да се затвори создаденото предупредување и да се провери дали зависните процеси работат со новиот клуч.

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

• AWS budget alert може сам да сопре ресурс, но IAM-улогата ја носи опасноста
• GitHub Push Protection може да прескокне push над 50 MB
• GitHub Actions без долгорочен клуч: OIDC бара прецизна политика на доверба