Consolidare practică a securității pentru acțiunile GitHub

Acasă » Piton » Consolidare practică a securității pentru acțiunile GitHub

GitHub Actions a devenit motorul CI/CD de facto pentru depozitele găzduite pe GitHub, alimentând totul, de la testele unitare la implementările de producție și modificările de infrastructură. Această comoditate vine cu un compromis serios: fluxurile de lucru rulează adesea cu privilegii largi, gestionează token-uri și secrete puternice și pot ajunge direct la sistemele de producție. Dacă nu le consolidați în mod deliberat, oferiți practic fiecărei configurații greșite, erori de dependență sau cont compromis o cale rapidă către canalele și conturile cloud.

Acest ghid prezintă o listă de verificare amplă și argumentată pentru securizarea GitHub Actions de la un capăt la altul.: cum să gestionați corect secretele, să evitați injectarea de scripturi, să blocați token-urile și declanșatoarele, să evaluați acțiunile terților, să gestionați rulanții și să profitați de funcțiile de securitate încorporate, cum ar fi scanarea codului, OIDC, Dependabot și jurnalele de audit. Scopul este de a reuni cele mai bune practici dispersate, lecțiile învățate din incidentele recente și propriile îndrumări GitHub pentru consolidarea securității într-o singură referință practică, pe care o puteți aplica în proiecte reale.

Profilul real de risc al acțiunilor GitHub

La nivel general, un flux de lucru GitHub Actions este doar un fișier YAML sub .github/workflows care definește unul sau mai multe joburi, fiecare compus din pași. Pașii pot fie să execute comenzi shell, fie să invoce acțiuni reutilizabile publicate de GitHub sau de comunitate. Fluxurile de lucru sunt declanșate de evenimente precum push-uri, pull request-uri, activitate privind problemele, programări sau dispecerizări manuale.

Din perspectiva securității, aceste fluxuri de lucru se află chiar în vârful lanțului de aprovizionare cu software.Aceștia construiesc și semnează artefacte de lansare, distribuie imagini Docker, implementează în medii cloud, furnizează infrastructură, execută migrări și multe altele. Dacă un atacator poate controla codul, configurația sau mediul în care rulează un flux de lucru privilegiat, acesta poate adesea:

• Artefacte compilate de Backdoor (binare, containere, pachete) pe care le expediați ulterior clienților.
• Extrage jetoane și secrete puternice și de lungă durată din memorie, jurnale, memorii cache sau artefacte.
• Abuzează rolurile privilegiate în cloud acordată CI pentru a implementa servicii suplimentare, a modifica rețeaua sau a accesa date.
• Proiecte în aval de otrăvire prin compromiterea canalelor de lansare open-source și distribuirea de versiuni protejate de troieni.

Incidente recente din lumea reală au subliniat cât de atractivă este GitHub Actions ca suprafață de atac.Atacatorii au abuzat de fluxuri de lucru vulnerabile pentru a injecta criptomineri în pachetele publicate, iar popularul tj-actions/changed-files acțiunea a fost compromisă într-un atac în mai multe etape care a încercat să ajungă la Coinbase. Codul malițios a extras secrete din fluxurile de lucru și le-a scris în jurnalele de compilare, creând o potențială cascadă de compromiteri ulterioare ale lanțului de aprovizionare.

Ideea cheie de reținut este că majoritatea atacurilor GitHub Actions se referă la „probabilitate × impact”.Doriți să reduceți probabilitatea de a adopta componente rău intenționate sau cu erori (acțiuni ale unor terțe părți, rulatoare nesigure, declanșatoare riscante) și, în același timp, să limitați drastic raza exploziei dacă o componentă este compromisă.

Blocarea secretelor în acțiunile GitHub

Secretele sunt de obicei cea mai atractivă țintă în orice sistem CI/CDÎn acțiunile GitHub, acestea apar ca secrete de repozitoriu, organizație sau mediu și ca valori ad-hoc pe care le-ați putea transfera accidental în configurații, jurnale, cache-uri sau artefacte.

Primul lucru de internalizat este modelul de acces: oricine are acces de scriere la un depozit poate citi efectiv toate secretele la nivel de depozit.Aceștia pot pur și simplu să modifice un flux de lucru existent pe o ramură neprotejată, să injecteze cod de înregistrare în jurnal sau de exfiltrare și să ruleze acel flux de lucru pentru a afișa sau a divulga secrete. Mascarea în jurnale de către GitHub este o apărare bazată pe efort maxim, nu o garanție infailibilă.

Pentru a menține secretele supraviețuibile sub acel model, urmați aceste reguli de bază:

• Aplicați principiul privilegiului minimOrice acreditări utilizate într-un flux de lucru trebuie să aibă doar permisiunile minime absolut necesare. Evitați partajarea token-urilor de administrator cu scop general ca secrete ale fluxului de lucru.
• Preferați secretele de mediu în locul secretelor de depozit sau organizație pentru valori sensibileSecretele de mediu sunt disponibile numai pentru joburile care declară mediul respectiv și le puteți include în protecții suplimentare, cum ar fi recenzori obligatorii și restricții de ramificare.
• Nu stocați niciodată secrete în text simplu în fișierele YAML ale fluxului de lucru sau în codul înregistrat în depozit. Tot ce este sensibil ar trebui să treacă prin mecanismul GitHub Secrets sau printr-un manager de secrete extern.
• Evitați utilizarea fișierelor BLOB structurate (JSON, YAML, XML) ca o singură valoare secretăMascarea se bazează în mare măsură pe potrivirea exactă a șirurilor de caractere; datele cu câmpuri multiple sunt mult mai greu de redactat în mod fiabil. În schimb, împărțiți datele sensibile în mai multe intrări secrete dedicate.
• Înregistrați explicit toate secretele derivateDacă transformați un secret (Base64, codificare URL, semnare JWT etc.) și rezultatul respectiv ar putea apărea în jurnalele de lucru, înregistrați valoarea transformată ca secret propriu, astfel încât GitHub să poată încerca să o mascheze.

Rotația și igiena contează la fel de mult ca configurația inițialăVerificați periodic ce secrete există, cine și ce are nevoie de ele și eliminați sau rotiți-le pe cele care sunt învechite. După orice suspiciune de expunere (de exemplu, un secret afișat needitat în jurnale sau utilizat într-o acțiune compromisă), ștergeți imediat jurnalele afectate, revocați acreditările și creați altele noi.

Evitarea injectării de scripturi și a interpolării nesigure

Una dintre cele mai comune, dar subtile, clase de erori GitHub Actions este injectarea de scripturi prin expresii.GitHub oferă „contexte” bogate, cum ar fi github, env, secrets și sarcini utile de evenimente, la care faceți referire în fluxurile de lucru folosind ${{ ... }} sintaxă. Aceste expresii sunt evaluate de GitHub înainte pasul tău de coajă rulează.

Când încorporezi un context nesigur direct într-o comandă shell, inviți injecția de comenzi.De exemplu, dacă faceți:

run: echo "new issue ${{ github.event.issue.title }} created"

și un atacator poate controla titlul problemei, pot trimite un titlu precum $(id)După evaluarea expresiei, pasul devine:

echo "new issue $(id) created"

care execută id pe alergătorNicio modificare a citatelor sau adăugarea unei validări simple în shell nu te va salva în mod sigur de acest model.

Modelul sigur recomandat de GitHub este utilizarea unei variabile de mediu intermediare:

env:
TITLE: ${{ github.event.issue.title }}
run: |
echo "new issue \"$TITLE\" created"

Aici, valoarea potențial ostilă rămâne în memorie ca variabilă de mediu., iar cochilia vede doar $TITLE, nu o linie de comandă construită dinamic. Încă aveți nevoie de igiena normală a shell-ului (intercalarea variabilelor cu citate, evitarea evaluărilor inutile etc.), dar pasul periculos de interpolare este eliminat.

Ori de câte ori ești tentat să încorporezi ${{ github.* }} sau alte date controlate de utilizator direct în run: blocuri, oprește-te și împinge-l prin env: in schimbAcest obicei elimină o întreagă clasă de probleme legate de injectarea de scripturi în fluxurile de lucru.

Configurarea permisiunilor și a token-urilor în siguranță

GITHUB_TOKEN ceea ce GitHub injectează în fiecare rulare a fluxului de lucru este incredibil de puternic dacă este lăsat cu setările implicitePoate citi și scrie conținut, poate deschide și actualiza solicitări de extragere și poate interacționa cu depozitul în multe moduri. Din punct de vedere istoric, multe organizații aveau setarea implicită pentru citire/scriere fără să-și dea seama.

Primul pas de consolidare ar trebui să fie setarea permisiunilor implicite pentru token-ul fluxului de lucru la doar citire. la nivel de organizație și/sau depozit. Există o setare dedicată pentru aceasta în configurația Acțiuni. De acolo, puteți acorda selectiv permisiuni suplimentare pentru fiecare flux de lucru sau pentru fiecare job, de exemplu:

permissions:
contents: read
pull-requests: write

Acest model de tip „refuzare implicită, permitere unde este necesar” reduce dramatic potențialul unui atacator în cazul unui flux de lucru compromis.De asemenea, îi obligă pe autori să se gândească la ce capabilități necesită de fapt munca lor, în loc să moștenească un token general.

Dacă organizația dumneavoastră a fost creată înainte de începutul anului 2023, ar trebui să auditați în mod explicit aceste valori implicite.Multe organizații mai vechi încă au token-uri de flux de lucru activate pentru scriere, deoarece sunt anterioare setării implicite mai sigure și nu au optat niciodată pentru modificare.

Pe lângă domeniile de aplicare ale tokenurilor, fiți foarte atenți la setările care permit GitHub Actions să aprobe sau să creeze solicitări de extragere.Permiterea aprobării PR-urilor de către fluxuri de lucru deschide calea abuzurilor în care lucrările compromise îmbină cod rău intenționat fără revizuire umană. Dacă nu aveți un caz de utilizare solid și bariere de siguranță stricte, mențineți această funcție dezactivată.

Alegerea și fixarea acțiunilor terților

Fiecare acțiune externă pe care o utilizați este o bucată de cod la distanță care rulează cu aceleași privilegii ca restul jobului dvs.Dacă acțiunea respectivă devine rău intenționată, este compromisă sau este abandonată cu dependențe vulnerabile, devine un punct de sprijin predefinit în cadrul canalului dumneavoastră de procesare.

Există mai multe niveluri de apărare pe care le puteți aplica atunci când consumați acțiuni ale unor terțe părți.:

• Începeți de la o listă de permisiuni mică și de încredereAcțiuni întreținute de GitHub (cum ar fi actions/checkout, actions/setup-node) și acțiunile de pe piață de la creatorii verificați reprezintă de obicei o bază mai sigură decât depozitele aleatorii. Multe organizații impun acest lucru prin intermediul opțiunii „Permite acțiuni specificate și fluxuri de lucru reutilizabile” la nivel de organizație.
• Favorizează acțiuni populare, menținute activCercetările arată că multe acțiuni de pe piață au scoruri OpenSSF Scorecard scăzute, administratori unici și conturi de proprietar de scurtă durată sau foarte tinere. Acțiunile utilizate pe scară largă tind să acumuleze mai multă atenție și remedieri mai rapide.
• Fiți atenți la un număr mare de PR-uri Dependabot deschise în depozitul acțiunii.Acesta este adesea un semn că administratorul nu aplică actualizări de securitate, lăsând vulnerabilitățile tranzitorii necorectate.
• Preferați acțiuni cu mai mult de un întreținător și o bază de cod activă, nearhivatăSute de acțiuni de pe piață sunt arhivate, ceea ce înseamnă că nu există noi corecții sau actualizări de compatibilitate și riscuri în creștere în timp.

Fixarea versiunilor este un alt subiect criticDacă specificați o acțiune doar prin etichetă, cum ar fi some-org/some-action@v2, aveți încredere că eticheta nu se mută niciodată în cod malițios. Etichetele pot fi redirecționate dacă contul sau depozitul de întreținere este compromis.

Cea mai defensivă abordare astăzi este fixarea la un SHA complet commit.:

uses: some-org/some-action@247835779184621ab13782ac328988703583285a

Fixarea la un SHA face codul practic imuabil din perspectiva ta. (cu excepția unui atac de coliziune SHA-1 asupra obiectelor Git). Dezavantajul este operațional: trebuie să actualizați SHA-ul atunci când doriți funcții sau remedieri noi, iar diferite fluxuri de lucru pot trece la SHA-uri diferite dacă nu sunteți atenți.

Pentru a atenua această dificultate, unele echipe centralizează utilizarea acțiunilor terților în fluxuri de lucru partajate sau compozite.Depozitele individuale fac referire la acele fluxuri de lucru partajate prin etichetă, în timp ce fluxurile de lucru partajate fixează acțiunile subiacente la SHA-uri verificate și sunt actualizate într-o cadență controlată, uneori cu instrumente care deschid PR-uri pentru SHA-uri noi.

Indiferent de strategia pe care o alegeți, amintiți-vă că fixarea fixă ​​nu este un firewall magic.O acțiune poate totuși prelua dinamic codul în timpul execuției (de exemplu, prin curl | bash modele) și ocoliți codul PIN. Tot trebuie să parcurgeți sursa pentru modele evident nesigure înainte de a acorda încredere unei acțiuni cu secrete sau token-uri cu capacitate de scriere.

Proiectarea unor fluxuri de lucru și a unor locuri de muncă mai sigure

Modul în care structurați fluxurile de lucru și joburile influențează puternic raza de acțiune a unui compromis.Un anti-pattern comun este un singur job gigantic care verifică codul, compilează, testează, împachetează și implementează, toate acestea având permisiuni extinse și acces la secretele de producție.

Împărțirea muncii în joburi separate și chiar în fluxuri de lucru separate oferă atât izolare, cât și claritateDe exemplu, ați putea avea:

• A construiește și testează jobul care rulează cu permisiuni minime și fără secrete de implementare.
• A job de pachet care produce artefacte semnate, dar tot nu comunică cu producția.
• A implementare job care depinde de celelalte și este singura care are permisiunea de a accesa secretele de mediu și de a-și asuma roluri în cloud.

Pe runner-urile găzduite pe GitHub, fiecare job dintr-un flux de lucru rulează într-o mașină virtuală nouă, ceea ce vă oferă un grad de izolare între joburi. Nu este echivalent cu un sandbox consolidat și există vectori cross-job cunoscuți (cum ar fi cache-urile de ramificații partajate), dar divizarea joburilor îi obligă în continuare pe atacatori să muncească mai mult și reduce scurgerea accidentală de secrete în etape fără legătură.

Folosește medii pentru a lega pașii sensibili de protecțiiUn job de implementare ar putea declara:

environment: production

si production mediul poate fi apoi configurat să accepte doar implementări dintr-o ramură protejată, eventual cu aprobări manuale obligatorii. Combinarea acestui aspect cu reguli stricte de protecție a ramurilor (revizuiri obligatorii, fără lansări rapide, respingerea aprobărilor învechite) vă apropie de principiul celor patru ochi pentru schimbările de producție.

În cele din urmă, fiți atenți la artefacte, cache-uri și jurnale.Sunt modalități convenabile de a partaja date între joburi și fluxuri de lucru, dar:

• Nu grupați secretele în cache-uri, în special locații mai puțin cunoscute, cum ar fi ~/.docker/config.json care pot conține acreditări Docker simple.
• Evitați înregistrarea secretelor sau descărcarea unor contexte întregi în jurnale, deoarece acest lucru poate anula mascarea sau poate dezvălui valori derivate pe care GitHub nu știe să le redacteze.
• Rețineți că oricine are acces de citire la depozit poate de obicei descărca artefacte și răsfoi jurnalele., inclusiv colaboratori externi dacă le acordați acces.

OIDC și acreditări cloud de scurtă durată

Una dintre cele mai importante schimbări pe care le puteți face este să nu mai stocați complet acreditările furnizorilor de cloud pe termen lung ca secrete GitHub.În schimb, utilizați OpenID Connect (OIDC) pentru a obține token-uri de scurtă durată, cu scop bine definit, legate la o identitate specifică a fluxului de lucru.

Fluxul la nivel înalt este simplu:

• Furnizorul tău de cloud (AWS, Azure, GCP etc.) este configurat să aibă încredere în furnizorul OIDC al GitHub.
• Definești o politică de identitate care spune „se acceptă doar token-uri din această organizație/depozit/ramură sau mediu”.
• În timpul unui job, GitHub poate solicita un token OIDC, iar fluxul de lucru utilizează o acțiune specifică cloud-ului (de exemplu aws-actions/configure-aws-credentials) pentru a schimba acel token cu un rol de scurtă durată sau un token de cont de serviciu.

Condiția de încredere este cea în care poți deveni foarte detaliatPentru AWS, o politică tipică ar putea include:

"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:Org/Repo:ref:refs/heads/main"
}

Asta asigură că doar fluxurile de lucru dintr-un anumit depozit și ramură pot prelua rolulDacă doriți o definire și mai precisă a domeniului de aplicare, puteți lega rolul de un anumit mediu în loc de o ramură și apoi puteți solicita acel mediu doar pentru jobul de implementare. O acțiune compromisă a unei terțe părți într-un job care nu este de implementare va constata că apelurile OIDC pur și simplu eșuează.

Utilizarea OIDC nu elimină necesitatea politicilor de rol cu ​​privilegii minime în cloud, dar elimină cheile de acces statice care se află în GitHub Secrets, unde ar putea fi furate și reutilizate pe termen nelimitat din afara GitHub-ului.

Protecția ramurilor, seturile de reguli și mediile care funcționează împreună

Multe dintre căile de atac înfricoșătoare din GitHub Actions se reduc la „atacatorul injectează modificări rău intenționate într-o ramură protejată”.Protecția ramurilor și seturile de reguli sunt principala ta linie de apărare acolo.

Pe ramuri precum main or production, de obicei vrei cel puțin:

• Necesită o solicitare de extragere înainte de îmbinare – interziceți împingerile directe.
• Necesită cel puțin o (adesea mai multe) revizuiri de aprobare de la cineva altcineva decât ultimul împingător.
• Închideți aprobările învechite când se adaugă noi commit-uri – astfel încât atacatorii să nu poată strecura codul după revizuire.
• Solicitați aprobarea celei mai recente cereri revizuibile – împiedică un atacator să deturneze PR-ul altcuiva, să promoveze cod greșit și să se autoaprobe.

Apoi puteți conecta aceste protecții la medii. De exemplu, a production mediul ar putea accepta doar implementări de la main ramură și, eventual, necesită și aprobarea manuală din partea unui grup restrâns de recenzori (cu opțiunea „prevenirea autoevaluării” activată). În acest fel, un singur cont de contribuitor compromis nu poate trimite cod arbitrar în producție fără implicarea explicită a altcuiva.

Fiți atenți la regulile de mediu care depind de implementările în sine (de exemplu, „solicită ca implementările să aibă succes înainte de a permite actualizările etichetelor”). Dacă este structurat necorespunzător, puteți crea dependențe circulare sau pseudo-controale pe care un colaborator le poate ocoli prin editarea fluxurilor de lucru. Cel mai sigur model este în continuare: protecție puternică a ramurilor → medii cu scop precis → utilizarea explicită a acelor medii doar în joburile minime care au cu adevărat nevoie de ele.

Gestionarea rulorilor: găzduit pe GitHub vs. auto-găzduit

Runnerii sunt mașinile care execută efectiv fluxurile tale de lucruRunner-ele găzduite pe GitHub sunt mașini virtuale efemere gestionate de GitHub; runner-ele auto-găzduite sunt mașini sau containere pe care le furnizați și le controlați.

Runner-ele găzduite pe GitHub sunt, în general, mult mai sigure în mod implicit:

• Sunt efemere și se resetează pentru fiecare job, deci nu există compromisuri persistente de-a lungul rulărilor.
• GitHub publică SBOM-uri pentru imagini standard (Ubuntu, Windows, macOS), permițându-vă să analizați software-ul preinstalat pentru vulnerabilități.
• Anumite gazde rău intenționate sunt blocate din fabrică (de exemplu, pool-uri de criptominare cunoscute) prin intermediul /etc/hosts configurare.

Alergătorii auto-găzduiți sunt puternici, dar periculoși dacă nu le tratați ca pe servere de producție:

• De obicei nu sunt efemere decât dacă le construiești singur., deci orice flux de lucru rău intenționat poate încerca persistența, mișcarea laterală sau furtul de date.
• Adesea au acces mai larg la rețea și secrete locale. (chei SSH, interfețe CLI în cloud, servicii de metadate), ceea ce sporește miza oricărui compromis.
• Depozitele publice nu ar trebui aproape niciodată să utilizeze rulouri auto-găzduite, deoarece oricine poate deschide o cerere de extragere (pull request) care ajunge să execute cod în infrastructura ta.

Dacă trebuie să utilizați alergători auto-găzduiți, împărțiți-i în limite de încredere.Folosiți grupuri de alergători și restricții astfel încât:

• Proiectele publice și private nu împart niciodată același grup de candidați.
• Depozitele cu sensibilitate ridicată (de exemplu, infrastructura de producție) au propriii lor funcționali de gestionare strict controlați.
• Doar anumite repozitorii sau organizații pot trimite joburi către un anumit grup.

Puteți reduce și mai mult riscul cu ajutorul unor rulouri just-in-time (JIT) furnizate prin intermediul API-ului RESTAcești alergători se înregistrează dinamic, execută cel mult o singură operațiune, apoi sunt eliminați automat. Trebuie totuși să vă asigurați că gazda subiacentă este curățată sau distrusă, dar acest lucru restrânge fereastra în care o operațiune compromisă le poate afecta pe cele ulterioare.

Tratați rulotorii auto-găzduiți ca pe orice alt sistem de producție: monitorizați activitatea proceselor, blocați căile de rețea de ieșire, mențineți sistemul de operare și instrumentele actualizate și presupuneți că orice utilizator cu permisiunea de a declanșa fluxuri de lucru are efectiv execuție de cod pe acea mașină.

Funcții de securitate încorporate: scanare de cod, Scorecard-uri și Dependabot

GitHub oferă o serie de funcții de primă clasă, menite special să evidențieze riscul fluxului de lucru și al dependenței.și merită costul mic de instalare.

Scanarea codului (de exemplu cu CodeQL) poate acum analiza fluxurile de lucru GitHub Actions în sine., nu doar sursa aplicației tale. Reguli precum „Expunerea excesivă a secretelor” pot detecta tipare în care GitHub nu poate determina ce secrete sunt necesare (de exemplu, secrete dinamice secrets[myKey] utilizarea în construcțiile de matrice), ceea ce duce la încărcarea mai multor secrete decât este necesar în memoria jobului.

Fișele de scor OpenSSF și acțiunea Fișe de scor adaugă un alt nivel prin clasificarea stării de securitate a dependențelor tale.Pentru acțiunile de pe piață, fișele de bord pot semnala practici nesigure în lanțul de aprovizionare, cum ar fi:

• Nu se fixează dependențele.
• Lipsa protecțiilor ramurilor sau a cerințelor de revizuire a codului.
• Lipsa unei politici de securitate sau a unor procese de răspuns la vulnerabilități.

Dependabot joacă două roluri aici:

• Alerte Dependabot vă avertizează când o dependență a acțiunilor sau fluxurilor dvs. de lucru are o vulnerabilitate cunoscută, pe baza bazei de date GitHub Advisory.
• Versiunea Dependabot și actualizările de securitate poate deschide automat PR-uri pentru versiuni cu acțiune de modificare rapidă și poate aplica patch-uri la versiuni vulnerabile.

Graficul de dependențe pentru fluxurile de lucru este o altă caracteristică subestimatăGitHub tratează fișierele fluxului de lucru ca manifeste și vă poate arăta:

• De ce acțiuni și fluxuri de lucru reutilizabile depindeți.
• Ce conturi sau organizații le dețin.
• La ce versiuni sau SHA-uri ați fixat.

Acest lucru facilitează răspunsul la întrebări precum „Unde folosim această acțiune compromisă?” când apar noi avertismente și pentru a planifica remedieri în masă.

Monitorizare, audit și guvernanță

Securitatea nu se oprește la configurare; aveți nevoie și de vizibilitate asupra a ceea ce se întâmplă în timp.GitHub oferă jurnale de audit și jurnale de securitate atât la nivel de utilizator, cât și la nivel de organizație.

Din punctul de vedere al acțiunilor, există mai multe lucruri care merită urmărite:

• Evenimente legate de secrete, Cum ar fi org.update_actions_secret sau modificări ale secretelor depozitului. Acestea indică crearea, actualizarea sau ștergerea acreditărilor sensibile.
• Flux de lucru și modificări ale setului de regulicine a modificat regulile de protecție, cine a editat fluxurile de lucru de implementare, cine a modificat protecțiile mediului.
• Acțiuni noi sau modificate în marketplace și aplicații GitHub instalate în organizație, în special cele cărora li s-au acordat domenii de aplicare largi pentru repozitoriu sau organizație.

Puteți suplimenta controalele proprii ale GitHub cu aplicații de aplicare a politicilor, cum ar fi Allstar de la OpenSSF., care verifică continuu dacă depozitele respectă standardele de securitate de bază ale organizației dvs. (protecții ale ramurilor, scanare de cod activată, revizuiri necesare etc.).

În ceea ce privește „fluxurile de lucru în desfășurare”, fiți atenți la tiparele care ar putea sugera abuzuri.: creșteri neobișnuite ale timpilor de execuție ai joburilor, trafic de ieșire neașteptat de la runners sau joburi care eșuează frecvent în jurul pașilor care gestionează secrete sau token-uri OIDC. Acestea nu sunt întotdeauna rău intenționate, dar sunt locuri bune pentru a începe investigațiile.

A pune toate acestea laolaltă înseamnă a considera Acțiunile GitHub ca parte a suprafeței de producție principale., nu doar „scripturi de lipire”. Cu secrete și token-uri atent definite, protecții stricte ale ramurilor și mediului, utilizarea conservatoare a acțiunilor terților, runneri întăriți și monitorizare continuă cu instrumente precum CodeQL, Scorecards și Dependabot, oferiți organizației dvs. o șansă de luptă împotriva clasei tot mai mari de atacuri CI/CD și ale lanțului de aprovizionare care vizează în mod explicit fluxurile de lucru GitHub.