← Natrag
Tech

GitLab je ostavio otvorena vrata i sad se čudi što susjedi ulaze

Damir Radulić· 25. rujna 2026.· 5 min čitanja· 8 pregleda
GitLab je ostavio otvorena vrata i sad se čudi što susjedi ulaze
🎧 Poslušaj članak

Ako tvoj sigurnosni model ovisi o tome da nitko neće pogledati u README, ne imaš sigurnosni model. Imaš nadu. A nada, kao što znamo iz svake propale firme i svakog propalog braka, nije strategija.

GitLab, platforma na kojoj živi polovica ozbiljnog open-source svijeta i dobar dio onog neozbiljnog, ima značajku koju su njegovi inženjeri zamislili kao zgodan shortcut: privatna e-mail adresa vezana uz projekt služi kao svojevrsni ključ. Pošalješ mail na tu adresu, GitLab prepozna projekt, i tvoj issue ili zadatak — ili, ovisno o konfiguraciji, tvoj kod — završi tamo gdje treba. Genijalno. Elegantno. I potpuno oslonjeno na pretpostavku da tu adresu nitko neće vidjeti.

E pa, tu adresu vide svi. Jer stoji u README-u. Stoji u CONTRIBUTING.md. Stoji na stranicama za prijavu bugova, u support dokumentaciji, u onom dijelu repozitorija koji je, po definiciji, javan. Piše ti lijepo: "Pošaljite prijavu na projekt-xyz@gitlab.com". I onda netko pošalje. Samo ne ono što si mislio.

Sad, prije nego što netko kaže da je to GitLabov bug — jest, ali nije. To je bug ljudske prirode koji je GitLab samo omogućio. Platforma ti daje mehanizam, ti ga ostaviš na vidjelu, i onda se čudiš. To je kao da ostaviš ključ pod otiračem pa kriviš proizvođača brave. Brava radi točno ono što piše u specifikaciji. Ti si taj koji je ključ ostavio na javnom mjestu.

Mehanika napada je gotovo uvredljivo jednostavna. Vidiš adresu u README-u. Pošalješ mail. GitLab, dobra duša, provjeri dolazi li mail s adrese koja ima pravo pisati u projekt. Ako dolazi — a dolazi, jer si ti tu adresu objavio da bi ljudi mogli prijavljivati bugove — posao je obavljen. Nema captche. Nema dvofaktorske. Nema "jesi li siguran da baš ti želiš pushati u main branch produkcijske aplikacije u petak u 16:47".

To je ono što struka zove "email spoofing", a ja zovem "pisanje lažnih čekova u ime firme koja je objavila svoj matični broj na webu". Tehnički, možeš se zaštititi — SPF, DKIM, DMARC, cijela abeceda protokola koju svaka ozbiljna firma danas ima konfiguriranu. Ali GitLabov inbound mail handler, čini se, nije baš mario za ta slova. Primio je mail, vidio adresu, rekao "dobar dan, izvolite". Kao recepcionar u hotelu koji ne provjerava osobnu jer, eto, gost izgleda pristojno.

I sad dolazimo do pravog pitanja, onog koje boli. Zašto, zaboga, GitLab uopće ima značajku koja mailom omogućuje pisanje u repozitorij? Zato što je to zgodno. Zato što developeri vole automatizaciju. Zato što je 2015. netko u product meeting-u rekao "znate što bi bilo super, da možete otvoriti issue mailom" i svi su kimnuli jer je zvučalo moderno. A nitko nije rekao ono što je trebalo reći: "A što ako netko lažira pošiljatelja?"

To je klasična bolest cijele tech industrije. Gradimo značajke jer mogu, ne jer bi trebale. Dodamo integraciju jer konkurencija ima integraciju. Otvorimo API jer svi otvaraju API. I onda, deset godina kasnije, netko u sigurnosnom timu otkrije da si izgradio stražnja vrata i ostavio ih otključana, a ključ zalijepio na ulazna vrata. Upute za upotrebu, u boji, plastificirane.

GitLab nije jedini. GitLab je samo najnoviji u nizu. Isti obrazac vidjeli smo kod Jenkinsa, kod raznih CI/CD pipelineova, kod svakog alata koji je nekad bio "developer-friendly" pa je postao "attacker-friendly" jer nitko nije htio biti taj koji će reći ne. Jer reći ne znači biti "neprijatelj produktivnosti". A biti neprijatelj produktivnosti u startup kulturi znači dobiti otkaz.

E, tu je srž problema. Ne u GitLabu. U kulturi. U industriji koja je od "move fast and break things" napravila religiju, a onda se čudi kad stvari koje se slome uključuju i tuđe podatke, tuđi kod, tuđu infrastrukturu. Brzina je postala vrlina sama po sebi, a sigurnost je postala "ono što radimo na kraju sprinta, ako ostane vremena". A vremena nikad ne ostane. Jer je sljedeći sprint već počeo, i u njemu je nova značajka koja će opet biti zgodna, i opet će negdje ostaviti otvorena vrata.

I onda imamo situaciju u kojoj privatna e-mail adresa — PRIVATNA, naglašavam, to je riječ koju je GitLab sam upotrijebio — stoji na javnoj stranici koju indeksira Google, arhivira Wayback Machine, kopiraju botovi koji skeniraju repozitorije za upravo ovakve stvari. Jer botovi postoje. Ljudi koji skeniraju GitHub i GitLab za izložene API ključeve, za .env fajlove slučajno commitane, za lozinke u konfiguracijama — to nije teorija zavjere, to je industrija. Postoje firme koje žive od toga. Postoje ljudi koji su od toga kupili stanove. I ti ljudi ne spavaju. Ti ljudi skeniraju.

A ti si im, dragi maintaineru, u README-u lijepo napisao gdje da pokucaju.

Sad, možda misliš da je ovo problem samo za velike projekte s puno suradnika. Ne. Ovo je problem za svaki projekt koji ima javni repozitorij i tu adresu negdje u dokumentaciji. A to je, grubo, svaki ozbiljniji open-source projekt na planeti. Što znači da smo dobili situaciju u kojoj tisuće repozitorija ima otvoren ulaz za kojeg većina maintainera nije ni znala da postoji, a kamoli da je otvoren.

GitLab je, naravno, izdao preporuku. Uklonite adrese iz javne dokumentacije. Koristite service desk umjesto maila. Konfigurirajte SPF i DMARC. Sve točno. Sve korisno. Sve — i ovdje dolazi moj omiljeni dio — DESET GODINA PREKASNO. Jer značajka postoji od kad postoji, a upozorenje dolazi tek kad je netko drugi otkrio rupu. To je kao da ti proizvođač auta kaže "znate, možda ne biste trebali ostavljati ključeve u bravi preko noći" tek nakon što su ti auto ukrali. Hvala, genijalci. Baš ste mi pomogli.

Pravo pitanje nije "kako zaštititi svoj projekt od ovoga". Pravo pitanje je zašto je ikad bilo moguće da mailom pišeš u tuđi repozitorij bez ikakve provjere identiteta. To nije "značajka s rizikom". To je značajka KOJA JE RIZIK. Cijela poanta je rizik. I svi su to znali, ili su trebali znati, i nitko nije ništa rekao jer je bilo zgodno.

Ovo nije priča o GitLabu. Ovo je priča o tome kako gradimo alate koje sami ne bismo koristili da razumijemo kako rade. O tome kako "developer experience" postaje izlika za nepostojanje sigurnosti. O tome kako se svaka nova integracija, svaki novi webhook, svaki novi API endpoint dodaje s pretpostavkom dobre namjere, a svijet — pa, svijet nije pun dobrih namjera. Svijet je pun ljudi koji traže otvorena vrata. I ti si im ih upravo nacrtao u README-u, crnom bojom, na bijeloj pozadini, s uputama.

Rješenje je jednostavno i nitko ga neće voljeti: prestanite koristiti mail kao mehanizam autorizacije. Točka. Mail je protokol iz 1982. Dizajniran u doba kad je internet bio deset fakulteta i jedna vojna baza, i kad je pretpostavka bila da su svi na mreži prijatelji. Ta pretpostavka je umrla negdje oko 1994. i od tada je svaki mail-based auth mehanizam tempirana bomba. Ali mi ga i dalje koristimo. Jer je zgodno. Jer je jednostavno. Jer alternativa zahtijeva malo više truda, malo više koda, malo više UX-a.

A znamo svi što se dogodi kad treba birati između "malo više truda" i "zgodno". Zgodno pobijedi. Uvijek. Pa i onda kad cijena zgodnog bude tuđi repozitorij u tuđim rukama.

Ako tvoj sigurnosni model stane u README, nije sigurnosni model. To je pozivnica.

Izvor: bleepingcomputer.com

GitLab sigurnostemail spoofingpush kodopen source ranjivostREADME adresecyber sigurnostdeveloper alati

Zanima vas ovakva AI tehnologija?

RiNET gradi sovereign AI rjesenja za javni sektor i poduzeca - od civic intelligence do automatizacije nabave.

Kontaktirajte nas →
0 komentara

Komentari