Un repo privat pe GitHub suna bine. Nu este public, nu il vede oricine, accesul pare controlat si ai impresia ca ai inchis usa.
Doar ca in multe proiecte moderne GitHub nu mai este doar locul unde sta codul. De acolo pornesc build-uri, teste, scanari, release-uri, deploy-uri, publicari de artefacte, imagini, pachete si tot felul de automatizari. Practic, GitHub ajunge sa fie o bucata activa din lantul de productie.
Si atunci intrebarea nu mai este doar “cine vede codul?”, ci “ce poate face tot ce ruleaza in jurul codului?”.
Un atacator nu trebuie neaparat sa sparga direct productia. Uneori este suficient sa prinda un token, sa compromita un cont, sa modifice un workflow, sa abuzeze o GitHub Action sau sa intre printr-un pachet folosit in build. Daca acel pipeline are acces la secrets, registry, cloud sau release-uri, deja discutia devine serioasa.
Mai exista si categoria de atacatori care nu forteaza usa. Doar asteapta.
Lurkeri, bots, scanere, oameni care urmaresc repo-uri publice, organizatii, commit-uri, pachete si evenimente. Daca cineva publica din greseala cod, un .env, un token, o configuratie interna sau un repo care trebuia sa ramana privat, exista sanse ca altcineva sa vada asta inainte ca echipa sa isi dea seama. Uneori greseala traieste public doar cateva minute, dar cateva minute pot fi suficiente.
Asta face partea de GitHub public presence destul de interesanta. Chiar daca repo-urile importante sunt private, organizatia poate fi vizibila. Userii pot fi vizibili. Repo-uri vechi sau uitate pot da indicii despre naming intern, dependinte, tool-uri, workflow-uri sau stilul de lucru. Nu trebuie sa gasesti cheia de la usa ca sa intelegi cum arata cladirea.
Si nu vorbim doar teoretic.
Au fost cazuri recente in care tool-uri si ecosisteme folosite serios au venit cu surprize. Trivy, un produs de securitate foarte folosit, a avut probleme de supply chain in zona de release-uri, imagini si GitHub Actions. Checkmarx a documentat un incident in jurul unor artefacte si integrari, inclusiv un plugin Jenkins modificat. tj-actions/changed-files, o actiune populara din GitHub Actions, a fost compromisa prin tag-uri modificate. In zona npm, pachete populare au fost folosite in atacuri pentru furt de token-uri si credentiale.
Partea incomoda este simpla: daca si tool-urile de security pot fi prinse in astfel de situatii, atunci niciun tool nu ar trebui tratat ca fiind “safe by default” doar pentru ca are un nume cunoscut.
Ce as verifica, macar orientativ:
cine mai are acces la organizatie si repo-uri
conturi externe sau vechi uitate prin proiecte
token-uri si PAT-uri care nu mai au motiv sa existe
GitHub Actions cu permisiuni prea mari
actiuni folosite dupa tag, nu pin-uite pe commit SHA
workflow-uri care pot fi modificate fara review
secrets care pot ajunge in logs
dependinte, pluginuri si pachete folosite in build
cine poate face release si publica artefacte
branch protection si review pentru schimbari in pipeline
Ce nu as presupune:
Privat nu inseamna sigur.
Popular nu inseamna curat.
Security tool nu inseamna imposibil de compromis.
Token cu drepturi mari nu este normal doar pentru ca “asa merge build-ul”.
CI/CD nu este doar automatizare, este infrastructura critica.
Pentru mine, GitHub trebuie privit ca parte din productie. Poate nu serveste requesturi direct, dar poate decide ce cod ajunge acolo, ce imagine se publica, ce artefact se livreaza si ce secret este folosit pe drum.
O intrebare buna de pus intern ar fi asta:
Daca maine cineva compromite un token, un workflow sau o actiune folosita in build, cat de departe poate ajunge pana sa observam?
Surse pentru verificare
GitHub Security Advisory – Trivy ecosystem supply chain temporarily compromised
Aqua Security / Trivy security incident discussion
Checkmarx – Supply Chain Security Incident Update
Checkmarx – Incident Update May 9, Jenkins AST Plugin
GitHub Advisory – tj-actions/changed-files compromise
CISA – Supply chain compromise of tj-actions/changed-files
Palo Alto Unit 42 – npm / Shai-Hulud supply chain attack