GitHub Actions: justificați permisiunile înainte să permiteți execuția

Când o automatizare nu mai pornește, prima grijă este adesea restabilirea verificării reușite. Într-un flux GitHub Actions cu permisiuni asupra depozitului, remedierea cere însă și o decizie despre încredere: ce poate controla un contribuitor și ce autoritate primește codul influențat de el.

Prin anunțul din 2 noiembrie, GitHub mută pe 2 decembrie blocarea implicită planificată pentru pull_request_target. La data documentării, 8 noiembrie, sunt anunțate și două intervale temporare de aplicare: 9 și 16 noiembrie, între 16:00 și 18:00 UTC. Acestea sunt programări, fără un rezultat confirmat aici. Pregătirea utilă începe cu justificarea permisiunilor fiecărui flux pentru care doriți o excepție.

Politica de pornire și siguranța codului

Conform domeniului descris de GitHub, schimbarea vizează depozitele publice de pe GitHub Free, Team și Enterprise Cloud. Depozitele private sau interne și GitHub Enterprise Server nu intră în acest anunț. O politică aplicabilă poate permite explicit evenimentul, inclusiv pentru un anumit fișier de flux. Modul de evaluare arată ce execuții ar fi blocate.

Aceste informații descriu politica furnizorului. Nu stabilesc starea unui depozit anume. O regulă care permite pornirea rezolvă accesul la execuție; analiza codului trebuie să justifice separat de ce acea execuție este acceptabilă.

Pentru fiecare excepție, notați ce sarcină îndeplinește automatizarea, ce cod de încredere o realizează și ce permisiune îi trebuie. Urmăriți apoi locul în care intră datele controlate de contribuitor. Dacă explicația devine greu de urmărit, poate că același flux combină sarcini care cer niveluri diferite de încredere.

Etichetele nu cer construirea aplicației

Luați un exemplu ilustrativ: un program adaugă etichete unei propuneri de modificare în funcție de fișierele schimbate. Îi trebuie dreptul de a modifica etichete. Sarcina nu cere, prin ea însăși, construirea aplicației propuse sau instalarea dependențelor din ramura contribuitorului.

Ghidul de securitate GitHub explică faptul că pull_request_target folosește definiția fluxului din ramura implicită a depozitului de bază și poate avea acces la secrete și la permisiuni extinse prin token. Riscul apare când în acest context este executat cod care nu este de încredere. Preluarea unor fișiere și executarea lor sunt operații distincte; un pas ulterior de testare le poate lega.

În cazul programului care aplică etichete, urmăriți cum devin datele acțiuni. Titlul unei propuneri rămâne o intrare controlată din exterior chiar dacă îl citește un script de încredere. Păstrați-l ca dată, fără să construiți din el comenzi pentru interpretor. Limitați și etichetele pe care programul le poate modifica, dacă atât cere sarcina.

Un flux care nu construiește codul contribuit poate avea totuși nevoie de reguli pentru intrări și de permisiuni restrânse. În același timp, existența evenimentului nu dovedește singură o vulnerabilitate. Automatizările legitime trebuie evaluate prin ceea ce fac și prin cine răspunde de ele.

Testele execută material influențat de contribuitor

Al doilea exemplu ilustrativ este un flux care instalează dependențe și construiește aplicația dintr-un fork, adică din copia depozitului controlată de contribuitor. Acesta execută material influențat de persoana care propune modificarea. Faptul că o comandă de testare este cunoscută nu face sigur codul pe care îl pornește.

Pentru verificările obișnuite ale contribuțiilor externe, este de preferat un context conceput pentru cod fără încredere acordată în prealabil. Ghidul GitHub compară contextul pull_request pentru fork cu pull_request_target. Permisiunile și accesul la secrete trebuie potrivite sarcinii. Înlocuirea numelui evenimentului nu scutește echipa de verificarea restului configurației.

Dacă este necesară o operație autentificată, stabiliți ce intrare minimă îi trebuie și separați-o de construirea contribuției. Verificați și legătura dintre etape. Un fișier produs de o execuție fără încredere nu devine sigur doar pentru că este preluat ulterior de un flux de încredere.

Separarea are un cost real de întreținere. Dependențele private pot complica testele, iar mai multe etape cer coordonare. Acesta este argumentul cel mai serios pentru o proiectare atentă a excepției. Dificultatea nu justifică automat oferirea secretelor depozitului oricărui cod contribuit.

Protecția la preluarea codului este un strat separat

Anunțul GitHub din 18 iunie descrie protecții pentru anumite moduri de preluare a codului din fork în fluxuri privilegiate. Nota editorială din 15 iulie mută pe 20 iulie data modificării versiunilor încă acceptate. În corpul inițial a rămas o dată anterioară; nota trebuie citită împreună cu acesta.

Protecția respectivă și politica anunțată în noiembrie intervin în locuri diferite. Prima privește preluarea codului, iar a doua pornirea fluxului. Anunțul din iunie menționează limite, inclusiv alte comenzi de preluare și alte depozite fără încredere acordată. Niciunul dintre aceste mecanisme nu justifică executarea oricărui cod extern cu secretele proiectului.

Urmăriți și scripturile auxiliare, nu doar acțiunea de preluare. Verificați instalarea dependențelor și versiunea exactă folosită de flux. O protecție anunțată pentru o versiune acceptată nu dovedește că o revizie veche, fixată în configurație, a primit aceeași modificare.

O excepție trebuie să rămână explicabilă

Blocarea tuturor utilizărilor poate opri activități legitime de administrare sau verificări autentificate proiectate atent. Păstrarea lor după analiză poate fi o alegere rezonabilă. Excepția ar trebui să identifice fișierul vizat, motivul permisiunilor și intrările pe care fluxul nu le execută.

Examinați separat drepturile tokenului și expunerea secretelor. Notați cine întreține automatizarea și ce modificări ale scripturilor ori dependențelor cer o nouă analiză. O permisiune acordată întregii organizații pentru a reporni un singur program este mai greu de justificat ulterior.

Înaintea termenului anunțat, identificați execuțiile afectate în informațiile de evaluare și desemnați un responsabil pentru fiecare. Verificați din nou calendarul. Dacă un interval temporar produce o execuție blocată, păstrați mesajul de eroare ca dovadă a efectului politicii. Mesajul singur nu demonstrează o vulnerabilitate.

Aceasta este o sarcină concretă de mentenanță software: legarea permisiunilor de scopul actual al automatizării. Restabiliți execuția când explicația este solidă și păstrați drepturile suficient de restrânse pentru ca ea să rămână valabilă.