Che e’ esattamente quello che sto sostenendo dall’inizio, ci sono tante variabili da analizzare e non puoi dare per scontato che un mondo sia piu sicuro dell’altro.
Quello che sto contestando qui e’ la storiella di porkchop “il dipendente truffaldino ha inserito una backdoor senza che nessuno si accorgesse”.
State facendo un minestrone, le brutte pratiche di Meta e la sicurezza sono ben altra cosa, lo ripeto di nuovo: il discorso verte attorno alla figura di dipendente faang che inserisce backdoor malevola senza che nessuno se ne accorge per i PROPRI (o esterni) interessi, non per quelli di Meta.
Se sono gli interessi di Meta e’ ovvio che non si tratta di una backdoor inserita di nascosto dal dipendente ma voluta dall’azienda.
Su questo ti posso assicurare che tutti i dipendenti di queste grandi societa’ vengono “schedati” (se per schedare intendi un background check approfondito non una raccolta di dati delle persone eh), indipendentemente da che tipo di progetto lavorano. Ti posso assicurare che pure chi fa un internship passa da questo processo.
Non avrebbe senso farlo “a selezione”, tu si perche lavori su un progetto importante, tu no perche lavori su un progetto che frega poco.
Esatto sto solo parlando di dipendenti, e’ quello il discorso che e’ stato fatto e portato avanti da porkchop, e’ tutto in risposta a quello.
State allargando a cose e casistiche che io non ho citato e non e’ il punto che sto cercando di far passare
Solo che, indovina un po’, nell’open source è più facile controllare, anche casi estremi come questo. Cioè questa backdoor è stata trovata proprio perché dopo aver notato la lentezza era possibile vedere i test e i suoi binari, non so se è chiaro. La stessa cosa sull’ennesimo aggiornamento di un prodotto closed? MH, non so eh
Ripeto, ammetto la mia ingenuità nel credere che questo tipo di attacchi fossero evitabili a monte per natura dell’open source ma è un processo trasparente, aperto, che questo precedente rafforzerà ancora di più
Ah, l’unica ragione per la quale questa cosa non avviene nelle grandi (e pure piccole) corporazioni è perché c’è il tuo nome e cognome, ma se io oggi volessi pushare su una nostra repository un binario malevolo in qualche unit test che poi viene preso dalla build per mettere qualche backdoor ci metterei boh, 2 giorni?
Tanto per cominciare servirebbe un meccanismo che impedisca che progetti di singola persona in burnout diventino in scioltezza parte integrante di infrastrutture terze.
Ma anche se comincia a starti sul cazzo il project manager che ti spacca il cazzo per deliverare e contemporaneamente ti arriva un bustone con dei bei soldini e una villa a cuba o dove preferisci.
Fortunatamente questa cosa è sotto gli occhi di tutti da ben prima di xz, ricordiamo anche che per le grandi corporazioni opensource equivale a sfruttamento gratis. Chissà macOS cosa sarebbe stato senza FreeBSD
Qui da me, multinazionale, non potrebbe succedere per un qualsiasi progetto che ha anche solo una rilevanza pubblica, ci sono talmente tanti step di mezzo che la probabilita’ che controlli umani o automatici non se ne accorgano e’ estremamente bassa (ma come tutte le cose a questo mondo non e’ 0 impossibile)
Quel che dici puo’ succedere (per mia esperienza) in tutte le company di piccola medio grandezza, o grandi company dove tech e’ un contorno. In qualsiasi grande azienda tech di rispetto fatico a vedere come questo possa succedere.
Da me per progetti di molta poca importanza se si parla di esposizione al pubblico vedo:
almeno 2-3 persone review
scan automatici di almeno 2 tipi, tutti i file e dipendenze che includi nel progetto per eventuali vulnerabilita’ conosciute
QA che spesso controllano anche il codice per dare un occhiata e capire meglio
SRE che devono dare l’okay a deployare il tuo codice
Non oso immaginare come la trafila possa essere solo piu’ lunga e complessa per progetti che hanno invece molta rilevanza, gia’ quello detto qui sopra per me rende quasi impossibile per un dipendente mtt qualunque di buttarci dentro un binario che per ogni chiamata manda i dati chissa dove
Assolutamente d’accordo
In tanti casi meglio ancora ci sono fondazioni, Open Linux foundation, Open JS foundation, Cloud Native Computing Foundation CNCF, ho colleghi e conoscenti che stimo e lavorano in queste realta’
Guarda, non è vero. Scrivimi qua e spergiura che il vostro WhiteSource (o qualsiasi altra cosa avete) fa il controllo di vulnerabilità anche su tutto quello che è presente in devDependencies di packages.json. Sei sicuro al 100% che quello appena successo su xz non è replicabile in tutto il vostro processo? Non sto parlando di puro codice
Quello che sto scrivendo è che si da per scontato tante cose, non sottovalutare questo, anche in multinazionali
Non ho uno screenshot da mostrarti perche’ e’ passato troppo tempo ma sono abbastanza certo lo faccia
Fino a circa 1 anno fa il mio monorepo da 7 app usava ancora per alcune Webpack (versione vecchia) che si portava dentro un merdaio di dipendenze a sua volta e il sistema mi flaggava sempre svariate vulnerabilita’ quasi tutte relative a DDOS che pero’ di fatto potevamo ignorare perche’ Webpack e tutto il suo merdaio non esiste in produzione ma il server serve solo in locale e poi si crea un bundle di file statici.
Fortunatamente 1 anno fa mi son rimboccato le maniche e migrato tutto quel che rimeva a Vite e ora si dorme meglio
Son d’accordo non si possono ritenere perfette, ma il livello di scrutinio (nella mia esperienza) e’ decisamente elevato.
Di nuovo tutto questo e’ nato dalle affermazioni di porkchop che “basta un dipendente truffaldino che ti piazza una bella backdoor che tanto nessuno controlla anche in faang e il codice e’ closed source”
Tutto qui, sono d’accordo con te su tutta la linea
E tu sei sicuro che il bundle creato dalle devDependencies da pacchetti che arrivano esterni all’azienda fossero sicuri al 100%? però dai, ci siamo capiti
Eh ma vedi che alla fine arriviamo lì, questa cosa che è successa con xz è a livello di Bond villain e può succedere benissimo anche nelle FAANG se un DevOp malevolo smanetta con binari e cose non visibili a occhio nudo, ad esempio
no aspetta un attimo la dipendenza della dipendenza della dipendenza che scappa al controllo e ti ritrovi nel tuo bundle JS un codice malevolo che boh manda dei dati della pagina che stai visualizzando e’ una casistica totalmente diversa da DevOp malevolo smanetta con binari e cose non visibili a occhio nudo
questa casistica e’ estremamente improbabile se passa da tutti i controlli che ho descritto sopra (e sono quelli per robe di poco conto che faccio io )
devi virtualmente corrompere 10+ persone che lavorano su diverse aree, software engineer, qa, devops, security… a me sembra estremamente improbabile per non dire virtualmente impossibile.
Per me sei in modalità sweet summer child o io troppo paranoico quello che è successo con xz è un risultato di 2 anni di lavoro. DUE ANNI. Se la metti su questo piano il limite è solo la tua fantasia
Un bel progettino open source sviluppato nel tuo tempo libero che casualmente serve proprio al progetto usato nella tua azienda e lo piazzi nella pipeline. Nessuna vulnerabilità conosciuta, codice pulito, tutto ok, stessa backdoor di xz però
Capisco ma dammi una possibile spiegazione di come possa avvenire e sono pronto a prenderla in considerazione e rivalutare la situazione.
Un conto e’ pagare qualcuno per farsi leakare un segreto, ma riuscire a corrompere 10+ persone in aziende del genere dove sei cmq strapagato e rischi di finire nel penale (perche’ e’ ovvio che vieni scoperto dopo 3 secondi e c’e’ una trail di log che porta fino al tuo buco del culo ) a me sembra estremamente improbabile.
2 anni su xz ma e’ un progetto di nuovo con UN maintainer in burnout.
Prendi anche il caso (fantascientifico secondo me) che un entita grossa tipo un governo decide di attuare un attacco del genere, ora che convincono 10+ persone passano anni, e dopo 2 anni la persona che avevi convinto 2 anni prima e’ passata a fare altro e non svolge piu quella funzione, o il software che volevi attaccare e’ cambiato…
Attenzione pero’ qui tu stai descrivendo un altro scenario: qui non c’e’ l’intenzione e la premeditazione di inserire una backdoor secondo un piano ben preciso ma la subisci parte del tuo chain supply scegliendo quel package inconsciamente.
In questo tutti sono vulnerabili fin tanto che non viene scoperta la falla, dal faang di 100 mila ingegneri alla startup di 1 intern.
