GitHub spalio 7 d. paskelbė apie specialiai slaptų duomenų aptikimui sukurtą AI modelį. Jo tikslas – padėti rasti ne tik atpažįstamo formato tokenus, bet ir slaptažodžius ar kitus galimus prisijungimo duomenis, kurių struktūra nėra tipiška. Modelis analizuoja aplinkinį kodą ir bando įvertinti, ar eilutė iš tiesų panaši į slaptą informaciją.
Tai aktualu visiems, kurie kuria svetaines, automatizacijas ar AI įrankius. Slaptas raktas, patekęs į Git istoriją, nebėra vien vietinė kūrėjo klaida. Jis gali likti senose versijose, pasiekti žurnalus, būti nukopijuotas į kitus klonus arba panaudotas iki tol, kol raktas atšaukiamas.
Kas naujo?
GitHub teigia, kad naujas modelis bus naudojamas slaptų duomenų aptikimo įspėjimuose, push protection ir Copilot saugumo peržiūrose. Jis skaito aplinkinį kodą, kad geriau atskirtų tikėtiną kredencialą nuo atsitiktinės teksto eilutės, tačiau pats negeneruoja kodo ar teksto.
Esami AI aptikti slapto kodo įspėjimai GitHub Secret Protection ir GitHub Advanced Security klientams automatiškai perkeliami į naują modelį be papildomo mokesčio. Tuo tarpu AI tikrinimas push metu ir Copilot `/security-review` funkcijos turi skirtingas prieinamumo ir AI kreditų sąlygas.
Svarbu: dalis funkcijų dar nėra visuotinai prieinamos
GitHub nurodo, kad AI aptikimas push protection sistemoje yra privačioje peržiūroje. Jis skirtas GitHub Enterprise Cloud arba GitHub Teams naudotojams, turintiems GHSP arba GHAS apsaugą, o administratoriui reikia šią funkciją įjungti pagal organizacijos taisykles.
Copilot saugumo peržiūros komanda su nauju klasifikatoriumi taip pat ruošiama privačiai peržiūrai. Be to, push protection ir saugumo peržiūra gali naudoti AI kreditus, todėl prieš įjungiant verta patikrinti organizacijos planą, leidimus ir išlaidų kontrolę.
Tai reiškia, kad pranešimas nėra pažadas, jog kiekviena nemokama GitHub saugykla šiandien automatiškai gauna visas naujas galimybes. Kūrėjui svarbu atskirti jau veikiančius secret scanning įspėjimus nuo eksperimentinių ar mokamų tikrinimų.
Ar AI aptikimas pakeičia įprastą saugumo tvarką?
Ne. Net geras klasifikatorius gali suklysti: nepastebėti neįprasto rakto, pažymėti testinę reikšmę arba nerasti slapto duomenų failo, kuris nepatenka į tikrinamą sritį. Todėl bazinės taisyklės nesikeičia.
API raktai ir slaptažodžiai neturi būti laikomi kodo faile, pavyzdžiuose ar viešame issue. Vietoje jų naudokite aplinkos kintamuosius ir paslapčių saugyklą. Push protection verta įjungti prieš pirmą komandos išleidimą, o ne po to, kai raktas jau pateko į istoriją. Jei raktas nutekėjo, vien failo ištrynimo neužtenka – jį reikia nedelsiant atšaukti arba pakeisti.
Taip pat verta patikrinti CI/CD žurnalus, build artefaktus, ekrano kopijas ir dokumentaciją. Slaptas raktas gali pasirodyti ne tik `.env` faile, bet ir klaidos pranešime ar testiniame JSON pavyzdyje.
Ką gali padaryti mažas projektas?
Pirmiausia inventorizuokite, kokios paslaptys naudojamos: API raktai, duomenų bazės prisijungimai, deploy raktai, webhook adresai. Tada nustatykite, kas gali juos matyti, kiek laiko jie galioja ir kaip greitai būtų pakeisti. Galiausiai pridėkite patikrą į pull request arba push procesą ir dokumentuokite, ką daryti aptikus įspėjimą.
AI aptikimas gali sumažinti tikimybę nepastebėti neįprasto kredencialo, bet jis nėra leidimas laikyti raktus kode. Saugiausias procesas vis dar prasideda nuo principo, kad paslapties į repozitoriją patekti neturi.
Šaltiniai
- GitHub Changelog – Purpose-built model for leaked secret detectionOficialus modelio, prieinamumo, planų ir AI kreditų aprašymas.
- GitHub Docs – Enabling push protection for your repositoryOficialūs push protection įjungimo principai.
