Siamo noi che nonostante il deploy fallito, la CIA rossa, il business incazzato, ci troviamo al Gitbar e davanti a una guerra tutto ci sembra un po' meno grave.Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua nel nostro bar degli sviluppatori.Tutte le volte che si registra una nuova puntata di Gitbar la porta si apre per far entrare un amico nel nostro bar appunto per bere con lui qualcosa di fresco, prevalentemente una birra.E anche oggi non diciamo rompiamo questa tradizione ma prima di presentarvi l'ospite di oggi due cosine veramente veloci.Cosine al volo prima di iniziare vi volevo ricordare che questo episodio è stato fatto in collaborazione con Fisco Zen ma adesso partiamo poi ci prendiamo un minuto e ne parliamo.Seconda cosa vi devo ricordare i nostri contatti info@gitbar.it @brainrepo su Twitter e il nostro gruppo Telegram che è un po' la nostra casa e un po' quei tavolini lì in fondo dove si sente mormorare e chiacchierare talvolta anche con voce un più alta e succedono cose, ci passa gente per cui andatelo a visitare e iscrivervi se non l'avete ancora fatto.Ultima cosa ma non meno importante è il nostro nuovo canale youtube siamo piccolini siamo bebè della piattaforma stiamo provando a vedere se la cosa funziona quindi anche là mi mi raccomando iscrivetevi e cliccate sul campanaccio che è il modo insomma per ricevere le nostre notifiche.C'era una volta un ragazzo che giocava sulle chat irc e provava a installare Linux.Quella volta però era un po' di anni fa e oggi è un CTO di un'azienda italiana abbastanza conosciuta che è Sparkfabric.Abbiamo con noi qua su Gitbar un amico innanzitutto, CTO di Sparkfabric come vi ho detto, Advisory Member della Linux Foundation Europe, Paolo Mainardi.Ciao Paolo! Eccoci, ciao Mauro, ciao, grazie per l'invito dopo quasi due anni e mezzo che non ci vediamo qui su Gitbar, ma ci siamo visti poi negli anni in altri posti anche qualche settimana fa e un saluto a tutti gli ascoltatori di Gitbar.Sì, tu sei stato uno dei primi guest di Gitbar ed è un onore per me riaverti qua dopo un po' di tempo e sapere che tante cose in realtà sono cambiate, ma quello che non cambia è la passione, la tua attività frenetica nel mondo dell'open source, della tecnologia in genere che io non lo so è quasi veramente spaventoso quante cose fai.Allora la prima domanda che ti voglio fare è siccome c'è questo nuovo titolo che ha catturato la mia attenzione "Advice to remember della Linux Foundation Europe" che vorrì? Beh un'ottima domanda.Allora Linux Foundation Europe nasce più o meno durante il Covid poi è rimasta chiaramente spenta per tutto quello che sappiamo.Si è riattivata in Europa con un gruppo guidato tra l'altro da un italiano che è l'ex executive director Gabriele Columbro.Sono partiti credo gennaio dell'anno scorso e ovviamente hanno pensato bene di dotarsi di un gruppo di persone che facessero da advisory per guidare un po' l'iniziativa all'interno del territorio europeo.Era una parte delle candidature, l'ho mandata, ho raccontato un po' la mia storia, i progetti con cui ho collaborato, il fatto che rappresento anche una tipologia di azienda media italiana, di informatica, che lavora tanto all'open source, poi ecco l'Italia è un'industria, un'industria software, a differenza della Germania dove puoi trovare SAP, dove puoi trovare mega industrie non esiste, è il corrispettivo in Italia, quindi diciamo fatto anche un po' leva su questo, diciamo in rappresentanza di aziende come Sparfabric.Quello che fa Advisory Board è quella di al momento cercare di definire quali saranno le azioni di adesso e come renderle più forti, la maggior parte dell'impegno oggi è sul il Cyber Resiliency Act, è tutto quello che c'è al contorno, abbiamo visto quello delle chat, sul controllo, abbiamo visto quello sulla AI, sono tanti elementi su cui l'Europa sta correndo, cercando di definire delle leggi che partono da buoni propositi, ma poi le implementazioni al momento lasciano un po' a desiderare, soprattutto il Cyber Resiliency Act, che è il topic grosso su cui oggi la New York Foundation Europe sta lavorando su più ambiti, lavorando con fondazioni, istituzioni a Bruxelles principalmente, come Open Forum Europe, che hanno l'esperienza anche di parlare con i policy makers, che non hanno la competenza nel comprendere che differenza c'è tra il software, tra virgolette, gira in una telecamera cinese che magari è super bucata, le vulnerabilità che noi vogliamo proteggere, proteggere il mercato da questa roba.Però cercare di spiegargli cos'è il software open source, come funziona e da qui si aprono poi tanti branch per parlare con gli sviluppatori, parlare con chi farà le leggi, andare in Parlamento, partecipare alle conferenze, quindi organizzare un po' tutte queste attività.E in più ovviamente Linux Foundation Europe è il posto dove si fa hosting e anche fostering dell'open source, degli open standard.Noi diciamo cifreggiamo in Europa di essere, di avere probabilmente un approccio culturale più avanzato da questo punto di vista.Siamo indietro come industria e l'obiettivo Linux Foundation Europe è quello di prendere open source, progetti europei, hosting trasformarli in quello che poi nella Linux Foundation negli Stati Uniti principalmente diventano progetti, si spera, come Kubernetes, come Prometheus e tutto quello che conosciamo.L'obiettivo è ambizioso, allora tu lo sai che io poi appena si inizia a parlare c'è la mia vena stronza, devo fare proprio una domanda cattiva.Siccome per un periodo della mia vita mi sono occupato di politiche e di istituzioni.Secondo te che tipo di registro bisogna adottare per dialogare con un impianto di istituzioni europeo che è abituato a certi registri "lobistic style" no? Cioè proviamo a dirlo così, quindi abbiamo una fondazione che ha anche una quantità di risorse limitata, immagino, rispetto a una OpenAI che arriva nel Parlamento Europeo e vuole parlare e spiegare che la intelligenza artificiale è pericolosa ma il Large Language Model no, insomma cose di questo tipo.Quali pensi sia veramente la forza di una fondazione nel riuscire a costruire un dialogo fattivo? Quali sono i giolli da giocare? Sicuramente le cose da non fare, partiamo da quelle, quindi escludere un approccio completamente tecnico con cui si vanno a spiegare questi elementi, perché prima risposta, altrimenti diventa quella del cyber resiliency act, cioè io scrivo le leggi e sarai tu ad adeguarti visto che sei il massimo esperto tecnico a sviluppare qualcosa che vada sul mercato e sia il più sicuro possibile, che non comprometta la sicurezza nazionale come tutti i casi che ci sono stati negli ultimi due o tre anni, il caso SolarWinds che è quello che poi ha scatenato anche tensioni mondiali molto importanti.Di cui parleremo tra pochini.Esatto, sicuramente l'approccio deve essere quello multidirezionale, bisogna lavorare su più ambiti e bisogna anche far capire il valore delle fondazioni alle aziende europee, quindi partecipare alla fondazione anche diventando partner, quindi poter accedere, innanzitutto finanziare la fondazione che si occuperà comunque di creare un mercato sostenibile per tutti, visto che tutti lavoriamo ormai all'open source.Quindi questo è uno dei primi aspetti su cui bisogna andare sul mercato.Per comprendere cosa fa la fondazione, che non è solo raccogliere soldi, chi mette più soldi e quello che guiderà il mercato.C'è spazio per tutti, le fondazioni open source sono un bene comune soprattutto per le imprese, perché grazie ad esse prendiamo gli ultimi casi anche delle licenze, quindi la protezione delle licenze, la protezione delle marchi, la protezione delle proprietà intellettuali, sono quelle cose che oggi permettono di creare opportunità per tutti.Vedo una tendenza in Europa a non cogliere completamente il fatto di poggiare il proprio business su un territorio fatto di opportunità per tutti, sostenute da organizzazioni super partes, che non sono organismi nazionali che fanno leggi, né aziende che si autoregolano, quindi creare questo ecosistema fatto come Kubernetes, che è diventato uno standard de facto e quello ha creato una sua economia, ma grazie al fatto proprio che è stato protetto dalla CNCF che ha preso il marchio, ha preso le licenze, ha protetto le proprietà intellettuali e ha creato un ecosistema basato su questo.L'open source in realtà in Europa.È un valore, è un valore che è scritto in tanti posti, gli Open Data, gli Open Standard.Il punto è che c'è la sicurezza nazionale, ci sono delle risposte da dare e ci sono stati probabilmente anche gli interlocutori sbagliati, dato che non c'erano fino a Linux Foundation Europe organizzazioni, fondazioni molto tecniche capaci di spiegare, di portare queste ragioni qui.In Europa non ne abbiamo, Open Forum Europe hanno dato grandissimo supporto per quanto riguarda la parte più legale di quello che è scritto all'interno, ma non c'era la controparte in Europa come la Linux Foundation o altre capaci di argomentare, di essere chiamate in causa e di rispondere.Quindi sicuramente dobbiamo sostenere noi come professionisti e come aziende fondazioni di questo tipo.Oggi c'è Linux Foundation Europe, domani potrebbero essercene altre, quindi si spera che si vada in quella direzione lì, soprattutto in un mercato in cui i progetti open source possono cambiare licenza da un momento all'altro.Prendiamo Terraform grazie a Linux è stato creato Open Tofu, quindi significa che da quel momento in avanti quell'ecosistema sarà protetto e si farà di tutto per poterlo sostenere economicamente lato marketing, lato promozione, lato sviluppo e tutto il resto Questa settimana ci sono state un po' di discussioni sulla partita IVA nel gruppo Telegram Aprire e gestire una partita IVA non è una cosa facile e banale banale.Per farlo bisogna quasi sempre affidarsi a un professionista che vuol dire cercare informazioni online oppure andare in uno studio trovando parcheggio, il traffico del centro città, insomma un macello.Esiste quindi un modo smart per farlo ed è affidarsi a Fiscozen che tra l'altro sponsorizza questo episodio.Fiscozen è un servizio per aprire e gestire la partita IVA tutto online che ci mette a disposizione però un commercialista dedicato che ci segue dall'inizio del nostro contratto per tutto appunto il tempo che noi stiamo su fisco zen e che possiamo contattare via email chat e persino telefono tutto questo proprio basandosi su una piattaforma evoluta che tra le varie cose ci permette di emettere delle fatture elettroniche e avere una un forecast una previsione in tempo reale delle tasse che andremo a pagare per quanto riguarda la dichiarazione di redditi tra l'altro ci pensa il commercialista dedicato senza costi aggiuntivi, commercialista che ci manda pure il modello F24.Se ciò che vi ho detto vi può interessare in descrizione trovate un link per avere una prima consulenza gratuita e senza un impegno appunto a parlare con un esperto fiscale.Eventualmente ci sono anche 50 euro di sconto sulla sottoscrizione del primo anno qualora decidiate appunto di di procedere.Quindi ringraziamo Fisco Zen che ha sponsorizzato questo episodio.Ti faccio una domanda, un'altra provocazione.Sì.Quello che sta succedendo su tante, proprio riguardo tante aziende che lanciano un prodotto, lo fanno open source e poi si trovano nella condizione di dover cambiare licenza.Adesso non voglio entrare nel merito se è giusto o sbagliato cambiare licenza.Il prodotto, l'effort, ce l'hanno investito, se la risolveranno con da una parte il venture capital che è sempre un po' l'uno frattore in media, tutto quello che tocca diventa quasi sempre merda.Momentum of opinion.E dall'altra parte c'hai il problema della community che ha fatto in modo che quel progetto si realizzasse perché non è solo effort interno che dovrai comunque bilanciare.Però quello che mi chiedo è il meccanismo dell'azienda che fa qualcosa di open source e poi lo monetizza direttamente con consulenze, con supporto, con quello che ti pare, con l'hosting che adesso sta andando molto di moda.Certo.Pensi abbia fallito? Ma in realtà no, ci sono dei casi sporadici rispetto a una quantità enorme di aziende che fanno open source, di progetti più o meno grandi che comunque hanno la capacità di sostenersi.Ovviamente poi si arriva ad una massa critica come quella di AsciCorp con Terraform, che è grandissima, un'azienda bravissima a sviluppare la tecnologia, ma non sono stati probabilmente altrettanto bravi o non hanno avuto un advisor negli investor, come dicevi tu, tanto bravi a poter guardare il futuro e di poter portare sul mercato un business.Però ecco, negli ultimi anni abbiamo visto rispetto a tutto quello che utilizziamo pochi casi.C'è stato il caso di Elastic, c'è stato il caso di Terraform.Ovviamente questi hanno un impatto grosso perché sono standard de facto, fondamentalmente, quando si fa infrastructure as code, quando si usa Elastic per fare ricerche, logging e tutto il resto.Però secondo me non è un sistema che è fallito.Sicuramente una variabile che non c'era quando sono state progettate le licenze open source e free software, oggi si menziona poco, era il discorso dei big cloud vendor capaci di poter prendere il tuo lavoro e metterlo con una capacità economica che tu non ti potrai mai permettere, di poterlo monetizzare più velocemente e meglio di te.Quindi probabilmente c'è da potenziare questo discorso qui.Però ritorno sempre al discorso che le fondazioni servono anche a questo.Quindi portare nella fondazione la tua parte open e quindi farla sostenere non più da te come azienda, trasformarla in uno standard per tutti e quello diventa l'industria su cui devi lavorare.Quello che doveva fare probabilmente anche Ashicorp, donare il progetto la fondazione, trasformarlo in un business, in un'industria su cui tutti potremmo lavorare, guardiamo Kubernetes, e su quello creare poi un indotto su più fronti.Però il problema di HashiCorp è che ha il suo progetto e ha i suoi investor che hanno messo un sacco di soldi e si aspettano un rientro rapido.uno frattore mida più vedo più vedo questo mondo e più mi rendo conto che in realtà il venture capital è qualcosa che fa partire a mille ma poi tira il cappio e quando tira il cappio si è arrivata a pagina 2 il vero problema in realtà e qua ne sparo un'altra grossa è che non abbiamo ancora fatto il salto nel vedere che Il software open source è conoscenza che appartiene alla collettività e in quanto tale deve essere sostenuto dalla collettività.Se facessi un paragone con l'arte mi direste "Mauro è un'utopia questa" perché io ho sempre detto in un mondo ideale mi immagino l'industria della cultura che non etichetterei come industria sostenuta dalla collettività.Quindi l'accesso alla cultura libero per tutti è la tassa sulla cultura che pagano tutti.Quindi non compro un libro e lo pago di più.Il libro ce l'hai accesso gratuito perché anche quel libro che dice cose che potresti condividere o meno fa parte della collettività.Per fare questo, per arrivare a questo passaggio, va fatta tutta un'evoluzione di tipo culturale.non l'abbiamo ancora raggiunta completamente con la cultura in senso ampio e ci siamo fermati al concetto di scuole che però è un primo importante passo in quella direzione.La scuola è libera e disponibile per tutti quindi è già un passo da gigante.Le biblioteche sono un'altra operazione che un po' stiamo perdendo e col software non l'abbiamo fatta.Le aziende se mi devo proiettare in un contesto italiano ma europeo ma anche mondiale la media azienda utilizza costantemente software open source ci fa revenue allucinanti e alla fine sono veramente mosche bianche chi si fa carico di quel costo e investe.Le aziende che hanno sviluppatori dedicati l'open source o le aziende che fanno donation importanti a progetti open source indipendenti non sono numericamente comparabili con le aziende che utilizzano l'open source.Infatti quello che dici è assolutamente corretto e mi ricollego sempre al Cyber Resiliency Act perché uno dei punti più errati di quella legge è proprio della proposta di legge che già in una fase pure troppo avanzata è quella di spostare a responsabilità non nelle aziende che creano il prodotto consumando software open source quindi essere loro responsabili se quello che hanno impacchettato ha delle vulnerabilità e quindi andare a correggerle visto che fanno il prodotto no loro dicono deve essere chi ha creato la libreria perché quelli che l'hanno creata, quindi upstream, sono quelli che ne conoscono di più, quindi sono loro i responsabili.Questo è totalmente contrario anche dal punto di vista del condividere la responsabilità.Sei tu downstream che crei il prodotto e in pacchetti pezzi come azienda che vai sul mercato a vendere, perché parla di questo, saper si rinsegna, se fai soldi, allora devi essere tu i responsabili.E' questo uno dei punti chiave che Linux Foundation Europe e le altre stanno cercando di far cambiare, di shiftare completamente questo modello, perché solo così a quel punto si riuscirà anche ad aumentare il livello di sostenibilità del mercato open source.Quindi se io impacchetto un software che ha una vulnerabilità nota e tu hai scritto libreria e quella libreria non la posso utilizzare perché il sabere la legge vuole, il Sierra vuole che non abbia vulnerabilità, allora io prenderò il mio tempo, ti manderò una patch, tu integrerai quella patch, io ho contribuito e tu hai ottenuto in cambio, tutti hanno ottenuto in cambio un vantaggio.Paolo mi sono ripromesso di quando c'è qualcosa di nuovo fare step back e provare ad osservare da più vicino, quindi ti chiedo, quando parliamo di Cyber Resiliency Act, in particolare di cosa stiamo parlando? Perché un elemento l'hai già evidenziato, l'elemento responsabilità, ma dovendo inquadrare proprio la regolamentazione nella sua interezza, come si manifesta e secondo te quali sono gli impatti a parte quello che ci hai appena descritto? L'idea è praticamente quella del bollino, noi vediamo nei prodotti elettronici il marchio ma trasposto nel mercato software, quindi qualsiasi prodotto capace di far girare software, e tutto il software, sarà oggetto e soggetto alle regolamentazioni del CRI che imporranno tutta una serie di requisiti.All'interno della legge chiaramente non tutto il software è visto uguale, c'è il software critico, quindi si parla di Kernel, c'è il software meno critico, ci sono le librerie, ci sono i prodotti, ci sono anche gli attori coinvolti nel mondo dello sviluppo, ci sono le aziende, ci sono anche contemplati gli sviluppatori open source con una postilla che è completamente errata, cioè se sei esente dalle imposizioni del il CRA se non hai un profitto economico, dove profitto economico potrebbe essere qualsiasi cosa, potresti avere una pagina di donazioni su github ad esempio, quello è profitto o non è profitto, se qualcuno mi paga, mi dona qualcosa perché ho sviluppato quella libreria lì.Però tornando dal punto di vista tecnico, imporrà una serie di requisiti, quindi fare audit, produrre software bill of materials, rimuovere tutte le versioni non vulnerabili dal mercato, questa è un'altra cosa che è totalmente contraria anche al modello di sviluppo open source, perché avere versioni vulnerabili ancora scaricabili, fruibili dagli utenti è un valore perché io posso fare ricerca di sicurezza, posso guardare cosa era sbagliato quindi verificare che nelle versioni nuove quella stessa problematica si possa ripresentare e tutto il resto.Quindi impone tutta questa serie di attività tecniche e in più determina anche delle sanzioni molto importanti per chi poi non rispetterà, non sarà in regola con questa attività, tant'è con queste imposizioni tecniche, tant'è che alcune fondazione hanno già detto, come è scritto in CRE adesso, noi non rilasceremo più software in Europa, sia come fondazione, sia come sviluppatori indipendenti, ma probabilmente anche come azienda, perché comunque il burden che viene richiesto è molto alto, quindi non è più come adesso dove tu crei la tua libreria, vai su github, la pubblichi e te la dimentichi, oppure la aggiorni ogni tanto, fai delle cosette, accetti le contribuzioni.No, da quel momento in avanti sai che stai mettendo qualcosa sul mercato, quindi devi guardare GitHub non più come il tuo repository, fino a quando è pubblico, appena fino a quando è privato.Quando è pubblico diventa il mercato, dove c'è qualcuno che può usare quella libreria per fare qualcosa, quella libreria lì se ha delle vulnerabilità tu verrai notificato e sarai tu soggetto a dare una risposta e soprattutto se la rendi disponibile devi anche sottostare al creare delle cose che oggi si possono fare la maggior parte in automatico, ma ci sono.Se il tuo software rientra nei software critici dovrai chiedere un audit a pagamento di un'azienda terza che farà audit del tuo codice e questo è un obbligo.Quindi è tutto molto molto complicato, è uno shift culturale di mercato enorme per come lo vediamo, per come vediamo l'open source.No, crea il repo, butti la libreria fino a quando vuoi usarla, la usi, qualcuno può usarla, amen, quando ti stanchi la togli, ma non rischi, non rischi perché nella licenza c'è scritto tu te lo prendi senza garanzie, come è scritto in tutte le licenze open source, invece no.Però la licenza è un contratto tra te e un'altra persona, un'altra entità, è una regolamentazione sopra il contratto, è il potente del contratto, vediamo con i social per cui le regolamentazioni alla fine spingono e limitano in qualche modo i social.Abbiamo due elementi, il primo elemento è "too big to fail" anche per un meccanismo di questo tipo.Credo che alla fine ci si renderà conto che è un errore di fondo fare questo tipo di azione e ci si renderà conto anche perché in realtà crollerebbe un'industria molto semplicemente.Altra cosa, la cosa in realtà che secondo me sta mancando è un ragionamento di tipo filosofico.Se noi non facciamo un ragionamento di tipo filosofico non saremo mai in grado di sbrogliare questa mattassa.Il problema è che fare un ragionamento filosofico è un bordello.Proviamo a farlo, la filosofia della 020 di birra di Gitbar, ok? Proviamo a fare un ragionamento.Il codice open source è un artefatto o conoscenza? Perché in realtà definendo il codice open source in uno di questi due elementi ok e proiettandolo in un contesto più più ampio ci rendiamo conto che cambia completamente il modo in cui lo osserviamo e la catena di responsabilità.Se il codice è un artefatto e noi decidiamo che il mercato è l'unica unità di misura della nostra collettività a quel punto il codice è venduto anche quando io ricevo donazioni e il cyber resiliency act non fa una grinza ok? Certo.C'è un unico problema in realtà che è un problema legato alla correlazione di responsabilità e impatto.Quando tu stai scrivendo una libreria o un pezzo del codice open source tu sei responsabile del codice ma non sei per niente consapevole mai lo potrai essere dell'impatto che questo potrà avere nella collettività perché è fuori dal tuo controllo quindi mi spieghi come cazzo puoi essere responsabile di questo impatto allora vuol dire che vedere e inquadrare il codice come un artefatto in un contesto di mercato è filosoficamente errato allora il codice è conoscenza noi sappiamo come si fa la bomba atomica ma chi ha scritto, chi descrive nei libri di fisica come si fa la bomba atomica o le tecnologie legate a abcd non può essere responsabile dell'impatto diretto perché non è a consapevolezza a meno che non ci sia un dolo esplicito e il dolo è facilmente riconoscibile perché nel codice, nell'azione, nell'elemento sono chiare le intenzioni ma nel codice open source non sono chiare le intenzioni dolose e quindi è completamente sbagliato dal mio punto di vista.Scusate mi sono riscaldato troppo, devo prendere una valiriana dopo, però è completamente sbagliato a livello filosofico proprio l'inquadramento.Infatti, ma il problema secondo me è anche una scarsa conoscenza di un'industria come quella software è la sua supply chain che è completamente diversa da tutte le industrie che ci sono oggi sul mercato.Il punto è anche quello, chi ha scritto questa roba si sarà domandato "va beh ma come si farà un software?" Ci sarà un'azienda che prende 4-5 pezzi come avviene per una telecamera, compri la scheda, compri l'ottica, compri la parte elettrica, la componi, sono tre aziende, devono accordarsi tra di loro su come devono fare queste cose e poi la mettono sul mercato.Probabilmente è partito dal dir punto, ma la software supply chain, in particolare quella open source oggi, è un qualcosa che ha dimostrato di essere pericolosissima, conosciuta poco non solo agli sviluppatori di leggi nel Parlamento europeo, ma agli sviluppatori tessi del software open source.Facciamo un passo indietro e proviamo a inquadrare la software supply chain perché io quando sento supply chain la prima cosa che mi viene in mente sono le pubblicità di radio 24 sono una cosa abbastanza infelice no? Per cui quando noi parliamo di software supply chain a cosa ci riferiamo specificatamente? Ci riferiamo al tutto quello che noi facciamo come individui, come aziende e con altre aziende per comporre un artefatto, un prodotto e poi andiamo a portare sul mercato.E fin qui la supply chain che ho appena descritto è valida in ogni scenario, da Radio 24 fino all'Innus Dorvals.Il vero problema è che oggi lo sviluppo di un software di qualsiasi tipo commerciale sicuramente utilizza pezzi di codice open source.Secondo le stime che vengono fatte da GitHub, con l'Octaverse, un progetto medio oggi, dal più piccolo, contiene almeno circa oltre 600 dipendenze diverse.Quindi significa che se sto sviluppando qualcosa io dipenderò da 600 componenti che hanno sviluppato persone che io non conosco.Qualcosa può essere anche un Hello World, la cosa spaventosa è quella.Esattamente, tant'è che nel mio blog, l'ultimo post parla proprio di questo, delle dipendenze dei software open source che sono fuori controllo e ho provato ad esempio a fare il bootstrap di un'applicazione Next con un Hello World e si parte da 450 pacchetti o 350, un numero di questo, solo per un Hello World, quindi già tu parti con una base così super complicata.Il punto è che non è solo quello, non sono solo le dipendenze, perché poi si pensa sempre se i problemi del software open source sono le dipendenze, no, c'è tutta una catena di cose che sono diagrammate bene da un diagramma che si chiama Salsa SLSA.dev che è stato sviluppato dall'OpenSSF Foundation che fa vedere esattamente dal produttore al consumatore come è fatta una supply chain software, che parte chiaramente dal nostro computer, che può essere locale o in cloud, e già oggi per come sviluppiamo già quello è soggetto a problemi di supply chain, perché se sviluppo in VI, EMAX, VS Code, JetBrains, probabilmente avrò già aggiunto, posso aggiungere, ho la possibilità di farlo, di aggiungere estensioni, fatte da terzi, quindi sto già mettendo all'interno di questa roba delle dipendenze terze, attori sconosciuti nella fase di produzione del software.Prendo il mio software, lo porto in una CI, questa CI la posso gestire io, può essere compromessa, può stare in cloud, può essere compromessa perché io nel cloud a quel punto posso aggiungere, posso scrivere dei job di ma posso usare servizi terzi come Codecov, è stato uno dei casi di supply chain più gravi degli ultimi anni dove vado ad integrare all'interno della mia pipeline, che crea il software, altro software fatto da altri e quel software dipenderà ancora da altro.Ok? E poi a quel punto prenderò il mio software che ho creato, probabilmente posso averlo anche credo compromesso lo posso e lo vado a portare in un registry che a sua volta è altro software, dove oggi non esistono strumenti, esistono standard ma sono usati pochissimo dalla community di sviluppatori per ragioni tecniche molto valide, non so quante volte avete usato OpenSSL per firmare, scambiarvi le chiavi, c'è tutto un meccanismo complicato anche per validare e quel software che sto scaricando arriva effettivamente da quella persona, da quell'azienda che dice di essere, nonostante gli strumenti ci siano.Quindi sono tutta una serie di cose e una catena appunto di vulnerabilità che si presentano, ma sono state poi esacerbate anche dall'avvento dei container che hanno sicuramente semplificato tantissimo il modello con cui io impacchetto il mio software e lo porto in prod.Ho impacchetto il mio software e lo do al mio collega.Però io in quel momento la superficie del mio software è diventata molto più grande perché sto impacchettando il mio software all'interno di un sistema operativo, un sistema operativo che ha delle vulnerabilità con dei pacchetti che possono essere aggiornati o meno ed è difficile renderlo riproducibile.In più sviluppo magari micro servizi quindi non ho più un solo ecosistema di programmazione, ho dieci container magari fatti con distribuzioni diverse, che sono difficili da introspettare, non so se si dice in italiano, fatta di 5-6 run time di linguaggi di programmazione con euro pacchetti e quindi a un certo punto io ho impacchettato questo mostro, di cui conosco probabilmente la parte che ho scritto io.Secondo le stime, quella parte che ho scritto io oggi in media è meno del 10%, il resto, il 90% di tutta questa produzione sono cose che ha fatto qualcun altro, quel qualcun altro che io non conosco e non so se oggi è un buon attore o un attore cattivo.Prendiamo ad esempio i casi delle librerie di No JS, Colors e Faker.Fino al giorno X lo sviluppatore di quella libreria era un buon attore sul mercato, un giorno si è incazzato, ha detto io voglio protestare contro questa cosa, voglio protestare contro i big vendor che non mi danno indietro nulla, quindi rilascio una libreria e dentro ci metto un denial of service che a catena spacca qualsiasi cosa.Prendiamo il caso di Log4j, una libreria che è standard per loggare, che a catena ha impattato e ancora impatta tantissimo, sono...c'è sonatype che ha un dashboard in real time che fa vedere quante persone ancora scarichano la libreria vulnerabile dopo tre anni, ne sono tantissime ancora, quindi è un meccanismo dove anche la conoscenza dei sedicenti esperti è molto bassa, perché la complessità che abbiamo generato negli ultimi anni, spingendo tantissimo dal punto vista tecnologico ed era giusto così, ha creato qualcosa che oggi è piena di vulnerabilità in più fasi, in più punti della catena che vengono sfruttate continuamente.Queste vulnerabilità sono sempre più impattanti.Rischiano di compromettere non un sistema, addirittura rischiano di compromettere la sicurezza dei paesi e l'industria.Perché oggi il software è ovunque, il software è infrastructure e scode, sono policy e scode, il codice è ovunque.Codice significa dipendenze, codice significa malicious code, codice malevolo.Codice significa qualcuno che oggi è un buon attore e domani no, che può iniettare qualcosa magari solo anche per spiare, quindi è difficile da valutare.Dopo questa riga Paolo io credimi sto per diventare un amish del codice, un neoludista, solo codice a chilometro zero, una roba del genere.Questo codice a chilometro zero ci faremo una maglietta.No, però è inquietante la cosa in realtà.E quello che è veramente inquietante è che è un bordello averne il controllo.È un bordello averne il controllo perché in questi anni in realtà il nostro codice ha, dal mio punto di vista, aggiunto livelli di astrazione su livelli di astrazione su livelli di astrazione tale per cui le standard lib praticamente nessuno le conosce adesso mi sto muovendo in un punto che mi serve per dare un'altra bold opinion però fondamentalmente mi chiedo se e questa è giusto ludica una uscita ludica ma voglio chiedervelo mi chiedo se in realtà è un po' anche colpa dei linguaggi e delle standard library il fatto che milioni di pacchetti per fare la qualunque per fare il pad left o per fare le cose più più più stupide appaiono.Sì ma anche io la mia opinione su questo ma è chiaro c'è inutile nascondersi javascript ah ah na sappiamo tutti com'è nato non ripercorriamo la storia.Sappiamo che la Node.js philosophy è quella di scrivere cose piccole che fanno una cosa e impacchettarle come modulo.Un po' per la Unix philosophy e un po' per, ma anche probabilmente superare storicamente i problemi della standard library di un linguaggio non nato per fare server side o non nato per fare quello che fa oggi.Quindi sicuramente l'ecosistema più impattato dal numero di pacchetti è quello, ma in realtà se andiamo a vedere poi ci sono ecosistemi impattati tantissimo come Python, Go in parte, ma non impattati solo delle dipendenze, ma impattati da altri tipi di attacchi, ad esempio Python soffre tantissimo le limitazioni di security che è il suo registry, che non era nato per avere l'esplosione che ha avuto Python negli ultimi tre anni.Ci sono degli attacchi, ad esempio la dependency confusion, che è quell'attacco in cui se io vengo a sapere un nome di una tua libreria che è privata, che magari tu hai committato per errore o l'hai committata nelle tue Dev Dependency su GitHub, di un progetto open source.Io pubblico un pacchetto che ha lo stesso nome all'interno del registry, probabilmente oggi l'hanno sanato, ma fino a qualche release fa quello che accadeva è che il PyPy scaricava la versione prima del registry pubblico e poi quella privata.ovviamente senza che tu te ne fossi mai accorto magari io vado ad implementare quello che tu ti aspetti che faccia e in più nel frattempo mi vado anche a recuperare tutte le tue credenziali, cloud posso fare quello che voglio e questa è una tipologia di attacchi, poi ci sono gli attacchi di type of squatting sono gli attacchi più stupidi come quello del type of squatting uno di quelli che viene usato di più però ovviamente usando tantissime dipendenze la probabilità che tu installi qualcosa magari con un nome simile con un type all'interno non te ne accorgi e ti scarichi quella roba.Mauro stanotte che ha scaricato una libreria che si chiamava "suffisso-postfisso" la scritta senza il dash tra suffisso e postfisso e si è scaricato un'altra roba che faceva dell'altra roba.Esatto, esatto.Come le estensioni di VS Code anche lì è piena magari tu vuoi scaricarti estensioni di ESLint e magari ti vengono fuori ESLint, ES-Lint, ES-Lint-NG, però quale scegli fai difficoltà magari di base sul numero di funzionalità, sul numero di stars eccetera, è un altro caso, però sono questi i tipi di attacchi che ci sono, sono più banali ma sono quelli che funzionano ancora di più.Oppure magari anche lavorare come maintainer, mantenere di un progetto, quindi ti fai i tuoi tre, quattro mesi a collaborare con un progetto, acquisisci fiducia, acquisisci autorità all'interno del progetto e a quel punto inizi ad avere magari write access su quel repo e quindi piano piano lì dentro infili robe.Questi sono dei tipi di realtà che le fanno, le fanno sempre di più.C'è gente pagata per diventare fake, di progetti, acquisire autorità e poi inserire all'interno di una MR fatta di 20.000 righe in diff qualcosa che magari fa exfiltration di dati o altro.E tu immaginati questa cosa quando tu installi un ex JS ai 450 dipendenze e tu non hai assolutamente scelto, l'ha scelto qualcuno per te, e quel qualcuno per te non le ha scelte propriamente perché conoscono tutte quelle persone lì.In realtà sono davvero pochissime le aziende che fanno l'assessment sulle dipendenze.Andrebbe fatto ma anche per una questione di licenze ad esempio, infatti un altro punto.cosa li can't eat? io sto accumulando tipo questa lista di cose a cui voglio rispondere che sto lasciando parlare ciao Carmi, ciao scusa no no no no no in realtà no, rispetto al tipo squatting è ancora più brutto quando tu scarichi qualche cosa che ha la stessa funzionalità che ti aspetti, per chi volesse controllare, oggi 2 novembre che stiamo registrando, se fate Gem install Rails invece che Gem install Rails, vi ritrovate comunque Ruby on Rails più qualche altra cosa che c'è.Esatto, un crypto miner.Sì, sì, esatto.E questa cosa qui ve la dico proprio per esperienza personale.Io ho anche utilizzato per settimane, prima che me ne accorgessi, non Rials ma Kylint all'epoca, scritto male, che effettivamente lintava una bomba, però chissà che cos'altro ha fatto.Tante volte infatti uno si immagina "chissà che attacchi incredibili questi hacker nordcoreani che si sono inventati".No, ma in realtà si passa da lì, si passa dai grandi numeri, con tantissimi software che scaricano dipendenze e i typos sono a portata di mano continuamente, quindi da lì si entra.Sì, ma anche il container, cioè prendi il primo container che ti capita sotto mano che fa una roba fai il container però secondo me è più semplice fare l'inspecto nel senso io posso guardare il docker file dal registry e di solito sono poche righe - e guardi tutte le volte? - molte volte sì perché so che poi succede il casino dopo perché sei un bravo ragazzo però però però però sì diciamo alla fine io sono anche una persona pigra quindi di solito ho integrato snick nelle siamo nella pipeline oppure ma anche anche banalmente se siete sotto già schiette fate npm odit odit assolutamente comunque insomma lo scenario che ho raccontato drammatico ha avuto poi due conseguenze la prima quella di promulgare le leggi, quindi sono partiti prima gli americani con l'ordine esecutivo, lo scorso marzo con la National Cyber Security Strategy che va proprio a entrare nel dettaglio di che cos'è la cyber security, di quali devono essere i rapporti tra pubblico e privato, di come si sviluppa il software e soprattutto si parla anche di tecnologie legate al software supply chain, quindi si richiede in modo obbligatorio quando la pubblica di amministrazione compra un software di avere la Bill of Materials, che è banalmente la lista degli ingredienti che hanno composto quell'artefatto.Si fa sempre, e lo devo fare, mi sento obbligato a farlo, il paragone con gli alimenti.Quanti di noi oggi andrebbero a un supermercato a comprare qualcosa che non ha una lista degli ingredienti? Semplicemente anche se non la leggi, ma sai che c'è, però se sei allergico a qualcosa e tu potresti essere allergico a una licenza che quel software si porta dentro, quella lì diventa obbligatoria.Ma avere la Bill of Materials in sé è semplicemente una lista degli ingredienti, però ottenuta quella poi è possibile fare cose come vulnerability scanning, license policy, etc.Il secondo effetto che ho trovato sul mercato, vabbè abbiamo parlato già di CRI, ma l'altro è stato che poi sono nate, c'è stata una risposta della community enorme, importante.La Linux Foundation ha creato la OpenSSF, grazie al supporto chiaramente dei grandi vendor e la Open Source Security Foundation, quindi dedicata alla security dell'industria open source.e da lì sono nati i progetti chiave uno tra tutti è sicuramente SIGSTOR che è un ecosistema di software che permette di fare firma degli artefatti in un modo super semplice loro vogliono essere quello che è stato Let's Encrypt per i certificati TLS l'obiettivo è quello quindi rendere democratico e semplice semplice e a prova di sviluppatore, firmare un artefatto che è la prima cosa che noi dovremmo chiedere quando collaboriamo con persone conosciute e sconosciute.La stessa cosa diceva Ken Thompson nell'84 in un paper, è questo spoiler o quello che avrei detto a fine della puntata, è "Reflections on Trust in Trust" in cui si chiedeva appunto ma come possiamo, era l'84, quindi non credo usasse tante dipendenze, però si domandava una cosa chiave, come possiamo fidarci che il software che usiamo, che non abbiamo scritto noi faccia effettivamente quello che noi ci aspettiamo, quello che dichiara di essere o di fare? Tant'è che lui lo dimostra nel paper scrivendo un pezzo di codice C che cambia il compilatore e quando vengono compilati dei software, in quel caso veniva compilato il login per loggarsi nelle macchine Unix, aggiungendo all'interno una backdoor, ma guardando il codice non l'avresti mai detto.A quel punto la sua conclusione è stata, che è ancora validissima, anzi oggi è più valida anche mai, non possiamo fidarci del fatto che Mauro o Paolo o Carmine abbiano scritto quel codice e sicuramente fa quello che dice perché potrebbe essere stato manomesso nella catena che lo ha portato a me, ad esempio.Quindi la cosa fondamentale è fidarsi delle persone, per fidarsi delle persone abbiamo bisogno di creare l'integrità del software e Sigtor e OpenSSF stanno lavorando sull'integrità del software, quindi creando software che firma in modo semplice, creando software che prende un artefatto e ti estrae tutta la lista degli ingredienti, prendi questa lista degli ingredienti e la dai a qualcosa come GRIPE che ti indica immediatamente tutte le vulnerabilità note che ci sono all'interno.La risposta dell'industria, della community è stata importantissima, questo è un fattore chiave perché altrimenti sembra che un'industria completamente allo sbando che ha bisogno delle leggi per autoregolarsi, invece no, questa è una risposta che andrebbe data, come mi chiedevi all'inizio, alle istituzioni.Questa industria è matura, è complessa, è diversa dalle altre, ma oggi è matura per dare le giuste risposte.In realtà sì, sta tutto proprio sul concetto di fiducia, nel senso che la fiducia può essere guidata dall'ingenuità o guidata dalla consapevolezza e sono due fiducia diverse.Possiamo dire che a oggi la fiducia in ambito IT e della nostra industria è stata guidata prevalentemente dall'ingenuità e dall'ignoranza, dove ignoranza intendo proprio nel senso di ignorare e quello che noi dobbiamo fare è effettuare questa trasformazione.Allora, siccome Gitbar è un podcast pragmatico, noi siamo i braccianti del codice come direbbe carmine quindi siamo persone proprio la mondina del codice.Mi viene da dire se tu oggi dovessi essere un'azienda che vuole in qualche modo essere il più compliant possibile col concetto di fiducia che abbiamo raccontato.Che tipo di processo creeresti? Proprio tool e step.Ne hai citato alcuni, no? La firma, però a livello proprio pratico dovendo fare un processo da dall'albero alla zebra, cosa ci metteresti? Assolutamente, prima ho menzionato il framework Salsa, che non è un framework codice, ma è una checklist fatta a livelli, tant'è che SLSA significa proprio questo, sono livelli di sicurezza pensati per gli artefatti software.Vanno dal livello 1 al livello 4.Il livello 1 è abbastanza semplice perché per essere compliant devi avere quantomeno il tuo codice su git e poi devi creare una cosa che si si chiama la software attestation, cioè devi attestare come hai creato quel software, utilizzando del software che potenzialmente lo genere in automatico.Salsa, insieme a questa checklist, ha creato anche il software che crea queste attestation.La provenance, io voglio sapere tu come hai impacchettato, dove, cosa ci hai aggiunto dentro, lo voglio firmato da te, lo voglio poter visionare insieme all'artefatto.Quindi oggi quello che consiglierei è prendere salsa che è fatto da 1 a 4 e cercare di essere compliant ai livelli sempre al livello più alto.Uno è meglio che niente come in tutti i discorsi security però il percorso è già ben definito.Domanda pratica.Scusa se la butto proprio sul pratico pratico ma secondo me è importante proprio partire dalle azioni pratiche perché secondo me è quello che attiva la rivoluzione.questo assolutamente quindi azioni creo la mia cartella mkdir devo fare il mio progetto node ok esatto fai il tuo faccio npm init ci metto dentro 70 librerie che mi servono per fare le load che vuoi npm install a quel punto che faccio a quel punto devi decidere come vuoi impacchettare questo software oggi sicuramente esistono diverse modalità puoi fare un un tar uno zip di questa directory oppure puoi usare strumenti più avanzati, puoi usare qualcosa come gli OCI Artifact che non sono per forza oggetti progettati per i container, tu puoi usare gli OCI Artifact per impacchettare la tua applicazione lì dentro, prendere questo tuo OCI Artifact e utilizzare gli strumenti cloud native più avanzati per chiedere al tuo software capace di fare introspection di questo container, dammi tutta la lista di dipendenze, c'è un software ad esempio che si chiama GRIPE o TRIVI, ce ne sono diversi, o anche DOCKER, DOCKER SBOM, e a quel punto tu hai immediatamente la lista di tutte le due dipendenze.Cosa ci fai con questa lista delle dipendenze? Innanzitutto è un modo per informare gli utenti di cosa stanno usando, quindi questa qui è una buona pratica.Quello ci puoi fare è fare lo scan delle vulnerabilità, quindi tu passi questo bill of material, questo SBOM a un altro software e dai a lista delle vulnerabilità che questa applicazione già ha all'interno.Purtroppo il discorso vulnerabilità è molto più complesso di così, perché non è detto che tutte le vulnerabilità anche di NPM audit o di software che oggi utilizza i database pubblici pubblici dei CV dia un'indicazione reale del fatto che quella vulnerabilità è presente ma sia sfruttabile nella tua applicazione.E infatti, apro parentesi, esiste uno standard che si chiama OpenVEX, che è proprio la possibilità per chi impacchetta software di aggiungere quell'informazione in più, di dire "ok, io lo so che questa libreria se verrà scansionata quella versione ha quella vulnerabilità ma io non apro quella porta abbiamo fatto un audit e questo è il vex è un documento standard ti garantisco mi assumo responsabilità che quella parte lì non sarà mai compromissibile perché abbiamo fatto questa azione.Quindi come dicevi tu la prima cosa da fare questo è NPM init, creo il progetto, lo porto su GitHub, all'interno di GitHub posso iniziare a sviluppare la mia pipeline DCI dove genero il bill of material, dove genero la software attestation in modo molto banale utilizzando il workflow già sviluppato dalla salsa framework, quindi mi genera automaticamente tutta l'attestation che indicherà a chiunque userà quella libreria cosa, in che modalità è stata creata.In più posso aggiungere, ed è praticamente un job sempre di una chitta Abaction, un job che mi firma il software utilizzando Cosign, anche questo è gratis ovviamente, introduco il job, faccio una keyless signing e a quel punto insieme agli artefatti del mio software c'è anche la firma, io ti indico che quel giorno lì io ho fatto girare la pipeline con queste cose che è arrivato dalla provenance e in più l'ho firmata, ho autorizzato, ho firmato il fatto che questa roba arriverà da me e contiene queste cose.Questo qui non aumenta il livello di security, questo è importante, tutto questo che ho raccontato aumenta la integrity, la security, perché io ti posso pure firmare qualcosa che all'interno contiene, non bisogna confondere i piani.Oggi il problema è anche quello dell'integrità.Devo fidarmi di te, devo sapere che quello che arriva è quello che tu hai firmato, quello che hai scritto, quello che hai delineato nella bilo material, eccetera.Perché la fiducia sta tra persone e organizzazione, non tra cose.Esatto.Poi vuoi fare static analysis? È un altro scenario, lì entriamo proprio nella la security vera e propria del software con pattern matching, analisi, magari anche con l'AI.Un abbraccio a Paolo, il nostro amico di Codice Insicuro, un abbraccio grandissimo.Esci un po' fuori dal discorso della integrity che è il discorso chiave oggi per questa roba.Dobbiamo avere meccanismi automatici per quanto è grande la complessità per poter magari a un certo punto, una volta che ho tutte queste informazioni qui e voglio deployare la mia applicazione su un cluster Kubernetes, a quel punto visto che posso usare le policies e scode, io nel mio cluster Kubernetes posso mettere un qualcosa che dice "ok, scarica quel container".Quel container deve avere però, per farlo girare da me, deve avere una bill of material firmata da quella persona, se no non entra.Bene, non mi basta, voglio che ci siano vulnerabilità critica è zero e che ci sia un VEX attaccato se c'è una vulnerabilità critica che spiega perché quella roba lì è stata eliminata delle cose quindi posso supportare anche un documento VEX e a quel punto io sempre escode con le mie polisi automaticamente posso dire un software con la licenza BSD non entra, un software con Medium o non firmato da Paolo e Carmine non entrerà, nonostante sia stato firmato dalla pipeline, perché è un software critico, quindi voglio che vengano fatte tutte queste serie di cose.Prima, prima di Sixthore, prima degli S-Bomb, prima di tutta questa roba, fino a Soli tre anni fa, questa roba qui era impossibile.Era complicatissima, perché dovevo chiedere "dammi la tua chiave, dobbiamo fare il mezzo tutto e incontrarci, scambiarci le chiavi di persona".Questa era la prima cosa, che altrimenti se tu mi passi la chiave potrebbe comunque essere manomessa e già ho nascosto dietro un muretto passato da me guardandosi a strano i parti, mi ricordo all'università ho partecipato, i parti in cui le persone si scambiavano fisicamente la loro pubblici in modo tale da essere sicuri che quella chiave era arrivata a quella persona lì, ecco però bisogna arrivare lì, i sistemi ci sono Beh sta parlando una persona che dovuta andare a Londra per prendersi il portatile per evitare Esatto, per evitare di avere un attacco di supply chain.Il tuo portatile parte da Londra arriva a casa tua in Francia, in Sardegna, che ne sai che nel frattempo ne è successo qualcosa.È la stessa cosa che è successa ai tedeschi con Enigma.Loro sono stati soggetti ad un attacco di supply chain, no? Perché la macchina è stata portata dal punto A al punto B, tra il punto A e il punto B qualcuno ha beccato.In realtà, Paolo, ti faccio una domanda, perché mentre parlavi io immaginavo quelle che potevano essere le azioni capaci di triggerare consapevolezza.Ho sempre odiato le imposizioni, però ci sono state delle imposizioni che hanno funzionato, o almeno in tanti posti funzionato vedasi il casco, vedasi la cintura di sicurezza e credo che alcune imposizioni se non sono imposizioni funzionano ancora meglio e quindi mi chiedevo ma come sarebbe se lo stesso github impostasse di default con un meccanismo di gamification così come le stelline anche le...non so trovami un'icona per la trustability no? certo certo certifica guarda questi qui sono gli sviluppatori e le organizzazioni che sono tutte certificate salsa a livello 4 fanno le cose di security più trustable più trustable "No, io sono un Github Star, no, io sono Github Trust, oh cazzo sei figata!" Cioè, secondo me, in realtà, questa cosa potrebbe essere interessante nel mondo del source O fare delle cose divertente anche in automatico Hai citato Github, Github ha NPM, NPM è già in automatico Genera oggi le prove, anzi quando si pubblica un pacchetto Esatto Non solo cose sexy, ma che oddio, non vado a vedere i pacchetti Eh perché, perché secondo me manca proprio Guarda che bella prova che si è generato il mio pacchetto puzzano di enterprise che la meta abbasta.E' quello il problema.E' quello il problema.Però è vero che puzzano di enterprise.Io voglio fare un attimino l'avvocato.Nemmeno l'avvocato del diamo, però è giusto così per dare anche la parte del bracciante del codice.Tutto quello che noi stiamo dicendo oggi e lo vivo ogni giorno.Prima di lasciare un pacchetto in studio, abbiamo una roba interna che si occupa di fare tutta questa roba qui.Ci sono dei passaggi che sono più "lenti", tra virgolette, perché necessitano di determinare cose per determinati clienti.E che spesso, quando si parla di questa cosa, e ne parliamo anche spesso sul stesso gruppo di GitBar, viene, secondo me, fuori un messaggio sbagliato.Ovvero il messaggio che è "se non ti puoi fidare, non ti fidare di nessuno, e quindi fatti tutto da te".Che presuppone tutto un altro tipo di professionalità.E sempre che mi piace sempre fare, ed è quello più facilmente verificabile, Dici, ok, non voglio usare una libreria per fare l'autenticazione della community perché io sono bravo, ma la faccio from scratch da zero.Minimo hai tutta una serie di timing attack su login e sulla registrazione che quella libreria verificata dalla community con quella certificazione ti avrebbe tolto.E allora a quel punto cosa si fa? Che ho lo sbombo pulito, ma l'applicazione no.Quindi nel senso, ecco, è questo senso di falsa sicurezza.Ci sono cose così specifiche, secondo me, che la cosa...cioè se io dovessi imporlo nel mio mondo ideale così, per tutta una serie di cose, critiche, non te lo puoi scrivere te.A meno che tu non mi dimostri che lo sai fare.Sono totalmente d'accordo con te e i software che ho citato vanno tutti in questa direzione che non è storaggiare l'uso delle dipendenze, anzi, renderlo ancora più forte.Poi ovviamente, guarda, se tu manteni una libreria open source e vogli usare e la usano in tanti, non hai voglia di integrare cinque righe di SIGSTORE, a quel punto vuol dire c'è un problema, perché saltano le basi semplici che costano poco, magari te lo apro io in una PR, se non lo fai vuol dire che c'è un problema e quindi è meglio che vado a cercare alternative.Quindi il punto è rendere tutto frictionless, addirittura anche il più automatizzato possibile come la generazione delle provenance e sulla base di quello avere almeno la garanzia che l'integrità tra le cose che utilizziamo, fiducia è già garantita e a quel punto escludi tutti quelli che non lo vogliono fare e se non lo vogliono fare c'è un motivo che va, non lo so, non c'è niente che voglia.E come possiamo secondo voi garantire questa cosa nella nostra azienda stessa, proprio nel team di sviluppo, nella nostra supply chain umana proprio per poter arrivare al primo punto che è quello di fare lo sbomb, per esempio già in una situazione in cui c'è la trust tra noi stessi che non è una cosa scontata.Faccio sempre lo stesso esempio, quello dell'autenticazione perché sono stato io il primo a farlo male perché pensavo che fosse semplice.Che faccia? Hai un form, usi il mio pasto, vai a controllare l'excel, ok ti loghi.Oppure, non lo so, ho fatto tantissimi errori e poi me ne sono fissato.- Gesson token dove non forse la verifica sull'algoritmo - Gesson token dove non forse la verifica sull'algoritmo, assolutamente dove non si verifica nemmeno il...però nel senso ci sono tante cose che possono essere fatte le query string le query string hanno una marea di robe sfruttabili e vedo continuamente persone che fanno split sul punto interrogativo con la Regex ecco come possiamo avere nel nostro team quel tipo di trust che non significa ok io ho la trust nel mio team perché abbiamo scelto di non usare fastify ma ci siamo scritti da solo.Questa è una scelta tecnica.Esatto, questa qui è una scelta tecnica ma come possiamo avere delle delle politiche intra team che ci garantiscono che questa cosa non succeda? Dipende dalla grandezza dell'azienda, chiaramente le più torturate, le più grandi, probabilmente Suse lo avrà, è un Open Source Program Officer, il famoso OSPO all'interno dell'azienda, il cui obiettivo è quello di organizzare le policies interne e aumentare il livello di conoscenza e di sensibilità che c'è attorno all'uso, al consumo e alla produzione di software open source all'interno dell'azienda.Quindi l'obiettivo è anche quello di definire le policy che ci sono sul consumo e sul rilascio del software open source.In scenari più piccoli secondo me è come oggi si fa il codice insieme, si sviluppano le policy insieme a SCODE, quelle vanno nella pipeline e se tu domani metti, apri un APR con una dipendenza di un pacchetto in NPM o un contener o un qualcosa che non soddisfa quei requisiti, la pipeline fallirà e a quel punto dovremmo discutere o quella policy che abbiamo scelto è sbagliata, o abbiamo scelto la libreria sbagliata, oppure l'autore di quel progetto non conosce SIGSTORE, non conosce il software per fare gli SBOM, si apre una contribuzione a quel progetto facendo presente e aggiungendo quello che serve per aumentare il livello di integrity Quindi la contribuzione può arrivare anche in quel caso perché è tutto s-code integrato qualcosa nel pipeline.Quindi ci sono due livelli, secondo me c'è l'open source program officer, che secondo me può essere una figura turna all'interno d'azienda che ha questa sensibilità un po' il dev rel dell'open source e in altre situazioni più piccole policy non sono divertenti, sexy, eccetera, però non so, quanto è divertente fare il linting del codice non è divertente però a un certo punto lo devi fare perché sono diventata una monnezza quello che stai scrivendo soprattutto quando il team cresce quindi guardiamolo come il linting della integrity quanto questo approccio si presta in due condizioni che sono agli antipodi in primis la condizione del solo developer che sta facendo la sua libreria che fa qualcosa ma lo fa bene ed è piccolo usa due librerie sotto, cinque librerie sotto, ma non ha il potere economico di prendersi la responsabilità delle librerie che stanno sotto perché è un developer diciottenne in nebraska che guadagna 70 dollari alla settimana e non può permettersi un assessment.Ma si deve prendere la responsabilità perché deve fare una sbom e la sbom gli fa sbam di librerie.Tu, azienda X, che usi la libreria di quel ragazzo del Nemrasca, che devi fare il prodotto, ma quel prodotto lì ha delle mancanze, a quel punto tu spenderai del denaro, tu azienda che vai sul mercato a produrre qualcosa, e farai le contribuzioni upstream sui progetti, che è quello che doveva dire il CRI che non ha detto.Deve essere proprio shiftato il paradigma.Fino a quando io e te lo facciamo per hobby, a quel punto, amen, te ci fidiamo, facciamo delle cose, ma se quella roba lì diventa un prodotto, allora sono io che ho scelto quelle cose.Magari le ho scelte in modo transitivo perché sono arrivati a dare una libreria che ha scelto per me, ma comunque fanno parte del mio software.Dato che sono un'entità commerciale, sono io e devo spendere del tempo per andare a fare le contribuzioni prima a questi progetti.E così si sostiene anche l'economia del software open source.Andare a chiedere allo sviluppatore del Nebraska "guarda mi serve quella roba lì perché devo andare a vendere la telecamera a Taiwan e a vendere in Europa, falla, se no ti arriva la multa del CRA".E' quello dell'agenzia che fa siti web col framework, sceglietene uno dal catalogo che meglio preferite, che ha 700 milioni di dipendenze e che quel sito lo sta vendendo a 1000 euro e c'ha il dipendente pagato 1100 euro al mese o 900 euro al mese e quindi gli servono i soldi per pagare il dipendente che mette insieme i pezzi e non si può permettere il costo vero del software.Parlo bene in realtà a prescindere poi dalla security vera.Come lo risolviamo quel problema? è un problema di risoluzione.Questo problema qui non è di facile risoluzione sicuramente, ma significa anche portare in alto un po' la professionalità delle persone che si trovano lì ad impacchettare roba senza senso che va sul mercato e comunque pone dei rischi.E dall'altro, l'industria open source che si spera, si spera si adotti un progetto open source che abbia già in sé, in pancia, una serie di sue feature di integrity, di security abbastanza elevate che anche nelle mani sbagliate comunque faccia il meno danni possibile.Questa è un'industria che dà delle opportunità a tutti mai viste prima, con un computer, un editor, un corso online di qualche ora posso produrre un artefatto, cosa che nelle altre industrie probabilmente richiederebbe degli sforzi intellettuali e di investimenti molto più alti.Ovviamente ci sono le opportunità e ci sono i rischi, ma è questa un'industria che è fatta anche di fondazioni, ce ne sono tante, è super regolare, si sa regolare e sa anche poi creare i meccanismi di protezione, sono fondamentali.Sono saltati tanto perché poi si è spinto sull'innovazione negli ultimi anni, soprattutto poi dal 2020 il Covid, che lo sappiamo, ha creato comunque un'accelerazione verso la creazione di software, da ogni punto di vista che ha fatto impennare la tecnologia, l'accelerazione, gli attacchi e tutto il resto.Quindi come si risolvono i problemi lì è difficile risolverlo.Allora a questo punto, facciamo così, io mi metto dall'altra parte, sono questa persona che vuole fare questo prodotto, si sta ascoltando questa puntata e dice "ragà, però quanti cazzo sto software no? Cioè basta.Ok.Dice ma allora a questo a questo punto ha senso andare su soluzioni già pronte che garantiscono questo tipo di sicurezza, questo tipo di reliability e liability legale.Ad esempio piuttosto se mi devo fare l'e-commerce piuttosto che farmare con un commerce eccetera eccetera non vado a fare su Shopify e non ce l'ho e non c'ho proprio questo problema.Oppure devo fare il mio sistema XYZ vado su dai Rectus Cloud e non ce l'ho proprio questo questo problema.Oppure compro quel sistema operativo di un certo tipo oppure quella identity provider di un certo tipo.Perché questa è un'idea di mondo completamente commercializzato.Oppure ti propongo l'alternativa GitLab, come quando crei un progetto ti propongo una licenza e inizia a proporti "guarda, ho visto che hai pubblicato questo software, perché non aggiungi questa action che ti fa firmare il software? Perché non aggiungi anche questa cliccando qui che ti fa la scan della vulnerabilità e così gli altri possono e tu stesso puoi verificare questa roba?" Quindi rendere il processo ultra semplice usando quello che c'è.La tendenza che c'è oggi è anche quella.Oggi Github ti propone, quando crei un progetto, non lo so, ti aiuta a scegliere la licenza o ti dà una lista di licenze.Però l'obiettivo è che intanto ti faccia un sacco di cose in automatico dietro le Quint, che tu neanche vedi.Quindi ti faccio le provenance, ti faccio eccetera.Però quando hai creato il software a quel punto sono pronto a darti come dipende a bot, ma pensato per la integrity, quindi vai a rendere l'industria open source con meno friction, perché come abbiamo raccontato sembra che devi fare delle cose assurde.Infatti era a questa cosa qui a cui volevo arrivare, dovrebbero essere gli stessi grandi player a fornire.Non so se lo dovrebbero fare gratis o meno, su questo acquisto si potrebbe discutere infinitamente, ma potrebbe sicuramente essere un'opzione.Se guardiamo solo allo spazio di mercato che c'è credo che negli ultimi 4-5 anni da Snyk a Neuvector a Code Sniff, insomma a tutti a tutti a tutti quelli che sono fuori c'è grandissimo spazio, c'è grandissima richiesta anche per cose che sono assolutamente assolutamente infatti potrebbe essere sempre quel discorso lì dove diciamo i grandi attori devono garantire che l'industria open source è ormai uno standard che su cui non si tornerà indietro sia sostenibile per tutti e questo è un diciamo è avvantaggio delle piattaforme come github quindi gli investimenti su quella loro li faranno, li fanno già partecipando anche come aziende, Microsoft, Google, eccetera, alle fondazioni che poi sviluppano, hanno il tempo per sviluppare specifici software, eccetera.Esatto.E una cosa che mi vuole inventare, perché ne stavo proprio parlando in questi giorni qui, è se uso Copilot.Perché nel senso a me hanno effettivamente fatto questa domanda qui, "Sì, ok, tu utilizzi Copilot, Code Whisper, qualunque cosa".Quella roba attinge, dovrebbe attingere, poi qui non voglio entrare con il calafello di stagnola, dovrebbe attingere da del codice pubblico.Che quindi potrebbe potenzialmente avere quel lavoro nella vita, proprio in quello snippet che ti sto prendendo.Ma tu non sai da dove lo sto prendendo.Certo.Ecco, allora a quel punto, secondo voi quali sono le prossime sfide anche per questa cosa qui? perché magari non me la sto prendendo log4j, ma sto prendendo quel pezzo di log4j perché me la subito pari.Certo, quel pezzo che c'entri nella vulnerabilità.Esatto.Secondo voi a questo punto è semplicemente, si rientra sempre nella consapevolezza dello strumento oppure in un futuro verrà tenuta conto? Guarda, secondo me quello lì è, quello che hai raccontato è una leva esponenziale della stessa cosa che avresti fatto su Stack Overflow, solo che oggi te la fai direttamente in editor, così senza neanche sforzarti tanto.Però questo qui crea l'opportunità a te che puoi sviluppare software più rapidamente, ma crea un'opportunità di mercato perché comunque la static analysis è sempre più avanzata, qualcosa che magari è capace anche di proporti, riscrittura di pezzi, addirittura sostituzione di librerie che fanno quella cosa meglio e come integrarla.è un mercato che creerà, e già adesso è un mercato florido, crea opportunità per tutti.Dai grandi disastri di security degli ultimi anni, da anni solo, RuinSock, 4j, Codecorp, eccetera, le opportunità oggi dell'inlustrazione della security sono enormi.Però, quello che dicevi tu, sicuramente secondo me già lo farà probabilmente Copilot, ti porterà dentro i pezzi di codice vulnerabili.Poi magari hanno le versioni business, enterprise dove si spera che prima di suggerirti qualcosa ti sia stato passando in qualche analizzatore statico.Solo se non sei un competitor.Esatto.Questo però sarebbe un bel business, devi pagare qualcosa in più.No, vabbè, abbiamo dipinto dei tempi bui, in realtà secondo me sta per iniziare l'illuminismo del software.Tutta colpa di JavaScript comunque.O merito! JavaScript è stato in grado di stimolare questo primo passo di sviluppo di consapevolezza.Cioè altre responsabilità volete dare a JavaScript? È nato come un cazzo di linguaggio per un browser.spiegate se hai mangiato il mondo, i misteri dell'universo.Però è comunque super interessante riprendere in mano il concetto di responsabilità perché non siamo più due ragazzini che giocano con i beat davanti a un monitor a fosfori verdi.Adesso la nostra vita è guidata da questo tipo di strumenti e siccome la vita e ciò che ci circonda ha un valore molto più importante del mero lato ludico, dobbiamo imparare a ragionare proprio in un altro livello e questa sarà la sfida del futuro.Esatto, tutto quello che facciamo è guidato dal software, più del 90% del software utilizza componenti open source, il modello open source è fatto, l'abbiamo già raccontato bene quindi è fondamentale che tutti si dotino della conoscenza di base, adottino gli strumenti, contribuiscano perché è un'opportunità di business per tutti gli altri.E secondo me il vero salto si avrà quando saremo in grado di vedere il software come conoscenza e non come mero artefatto.Detto questo io devo ringraziare il donatore di questa settimana che è Luca del Puppo, il grande Luca che ci ha offerto delle birre che noi ci berremo una volta chiusa la registrazione di questo episodio e a questo punto passiamo al momento tipico e topico del nostro podcast, momento in cui condividiamo un libro, un talk, un video, un videogioco, qualunque cosa insomma abbia catturato la nostra attenzione e possa essere insomma utile condividerlo con la nostra community.Quindi Paolo hai qualcosa da condividere con noi? "E conduco nel paese dei balocchi" "Ah, il paese dei balocchi" Guarda, assolutamente sì, una cosa l'ho menzionata prima che è un paper che si aggia rapidamente, sono 4-5 pagine di Ken Thompson, immagino tutti conosciamo, se non lo conoscete andate a vedere chi è, probabilmente gli accenderà un sacco di lampadine sulle cose che usiamo oggi, che ha progettato lui all'epoca, dell'84, si chiama "Reflections on Trusting Trust", in cui dimostra, tramite codice, con un pezzo di compiler C modificato, come è possibile fare tampering, manomissione di qualcosa, che leggendolo non ti darà mai nessuna indicazione sul fatto che non fa quello che ti aspetti, dimostrando appunto il fatto che non ci si può fidare del codice, nella statica analisi si sa al 100%, ma bisogna spostare un po' la fiducia verso gli altri.Nell'84 era facile conoscere tutti i dev con cui collaboravi per mettere insieme il codice, oggi no, ma ci sono gli strumenti.La seconda cosa che voglio portare è un libro che è in fase di sviluppo, lo trovate su Manning, è sviluppato da Michael Lieberman e Brandon Lamb, sono le due persone dietro tag security, lo sviluppo di salsa e tanto altro.Si chiama Securing the Software Supply Chain, poi passerò il link a Mauro.È un libro che è in scrittura adesso, sono al terzo capitolo.Il costo per me vale la pena, uno per finanziare il progetto perché è è veramente un'enciclopedia del tema fatto da persone che oggi sono più coinvolte.Ed è anche tutto bene, ci sono un sacco di racconti storici, anche un po' quello che citavo prima sul fatto della macchina Enigma, che anche quella era in parte oggi legabile a quello che chiamano software supply chain, oltre alle cose super tecniche.Quindi, straconsigliato.Fantastico, ti chiedo poi di mandarmi i link in direct così li mettiamo nelle note dell'episodio.Saltiamo a Carmine! Io ho un libro che sto finendo di leggere, il libro che vi ho consigliato nella scorsa puntata non va di lo stesso errore, non prendete l'ebook ma prendetelo cartaceo."abbattiamo sti alberi di merda, vai!" Allora, o lo prendete il Remarkable, e allora lo leggete benissimo, ma garantisco che sul Kindle l'esperienza non è proprio così, ed è contenere la sécurity di Liz Rice.Un libro fatto benissimo, che io pensavo fosse estremamente tecnico nei prerequisiti che dovevi avere per comprare il libro, in realtà no, fa una panoramica veramente approfondita anche su tutta la parte, in questo caso Linux, insomma, che c'è dietro.Quindi, da quel punto di vista, è un libro che vi consiglio e ve lo consiglio cartaceo, Leggerlo in ebook è un po' complesso, specialmente se avete un piccolo reader.Ma per il codice o per diagrammi? C'è un po' di tutto.Diciamo che è uno di quei libri che ti fa bene leggere, diciamo, su carta, perché ci sono delle immaginine, ci sono dei elenchi puntati che sono molto molto lunghi a volte, quindi è difficile proprio starci dietro.O lo leggete sul computer, ma io non riesco a leggere il pdf sul computer, oppure potete prendere e lo potete stampare.Io ho un vero problema, magari possiamo brevettare una nuova tecnologia se non esiste.Io ho problema di duplice natura.Uso il Kobo, io sono dell'altra squadra che è molto figo, però ho un problema che io nei libri cartaci, i libri cartaci li vivo, sono un ragazzo degli anni 80, quindi i libri cartaci li pasticcio, li sporco, li segno, li taglio, io ci sono delle pagine che mi catturano l'attenzione e ne taglio un pezzo, cioè proprio faccio una ferita nel libro.E' male prestarti un libro di carta? Lo ridai tutto tagliucciato? Per chi mi segue nei social sa che ho una libreria enorme di libri cartacei.Ho un problema però, in quest'ultimo periodo io sto anche rielaborando tanto, per cui solitamente o compro entrambi l'ebook e il libro oppure quello che mi manca dal libro è prendere e mandare direttamente su readability o sul tool che mi prende lo snippet e me lo sincronizza con obsidian e con notion perché utilizzo molto il metodo zelcastan specie quando preparo un un tolco, studio un argomento, quindi mi organizzo i vari snippet che mi hanno catturato l'attenzione per poi sviluppare le idee e i ragionamenti e questa cosa ho difficoltà a farla da libro cartaceo quindi sarebbe bello se conoscete qualche tool che lo fa condividetemelo un modo per sincronizzare l'esperienza nel libro cartaceo con l'esperienza nel libro digitale che può anche essere io dopo che ho finito di leggere un'ora mi faccio le foto delle pagine che ho marcato e automaticamente gli snippet mi vengono riconosciuti e digitalizzati e buttati in questa casa.Secondo me c'è un mercato fighissimo.Possiamo aprire la nuova startup e bruciare i Venture Capital dei Remila.Elimina questi 10 minuti e 5 minuti che sono l'idea per la prossima startup.Facciamo il notario, lo facciamo dopo abbiamo di registrare il notaio.La rilasciamo open source bruciando i soldi dei Venture Capital che poi ci diranno "No, cambia la licenza!" Al primo cliente.Quello che vi ho appena detto non è il mio balocco, ho un balocco, mi è arrivato, non l'ho ancora aperto ma secondo me è molto figo, ho comprato una cassetta di queste.Sono le telecamere a testa mobile di TP-Link.Ne ho comprato un gozziliardo perché costavano pochissimo, costavano tipo 20 euro su Amazon e praticamente ci ho coperto tutta la casa.Probabilmente mi entrerà un hacker cinese e mi dirà "Mauro, buongiorno".essendo TP-Link, comunque TP-Link è un brand abbastanza conosciuto rispetto a la station 1, ZEN, Jinjang, quindi credo che abbiano fatto un certo assessment.Fino a quando non c'è il CRI, purtroppo non c'è la possibilità di sapere se hanno fatto un audit del software.Con l'etapo dovreste avere l'integrazione con Home Assistant.Yes sir, lo faremo.- Yes sir, lo so e li ho prese per quello.Però mi sa dire che ne ho preso molte in in più quindi se me ne serve una...- Quindi il balocco è il rivene del mercatino - Esatto - Il vinte di gli italiani - Esatto - Il problema di Amazon è che quella freccetta verso l'alto per aumentare il numeretto è molto facile da caricare, quando è arrivata la scatola mia moglie mi ha detto ma io ti ho detto di comprarmi due per il gatto mi è scappata la mano guardavo l'orologio siamo a un'ora e mezza precisa quindi vi ricordo rapidamente che se volete aprire o gestire la partita eve online eliminando gli ostacoli della burocrazia potete prenotare una consulenza fiscale gratuita e senza impegno con uno sperto fisco zen qua nel link in descrizione o nelle note dell'episodio.Avrete anche 50 euro di sconto sul primo anno di abbonamento detto questo io vi do appuntamento al no che cosa sto dicendo intanto devo ringraziare Paolo per essere venuto è stato divertentissimo spero che da domani putti a produrre S-Bomb come se piovesse.Sbombiamo dappertutto! Sì grazie anche per aver dato luce a un argomento che difficilmente si prende in considerazione e ricordiamo che Paolo è insieme ai suoi baldi compari tra gli gli uomini e gli owner di continuous delivery che oltre a essere una buona pratica è anche un podcast molto carino che insomma se non l'avete ancora fatto iscrivetevi e affondate quel podcast con tanti cuori no sono dei fratelli più che amici Ciao Elo, ciao Elo, ciao, dove? Ancora in viaggio da qualche parte con la febbre Lo stiamo perdendo, l'ultima volta che l'ho visto era in lì per lasciarci No comunque se non l'avete ancora fatto mi raccomando seguite il podcast di Continuous Delivery perché ne vale la pena, io sono un loro fan detto questo io ringrazio anche Carmine per avermi supportato in questo ambito dove ne sapevo veramente poco in realtà grazie per le tue domande Carmine e anche grazie per Jason Pat che mi ha salvato la vita una dipendenza che crea dipendenza detto questo io vi ricordo che potete contattarci via email a info@gitbar.it o www.gitbar.it potete mandarci un messaggio scriverci su telegram o x chiamatelo come vi pare tanto al prossimo giro Elon Musk gli tiroverà un altro nome magari lo chiamerà per la qualità più o meno quella.Oppure sul gruppo Telegram che potete trovare digitando GitPay al nostro cliente Telegram preferito, GitPay e basta e ci potete trovare lì.Siamo più di 1500 vedo? 1400 non ne vedo, ho veramente perso il conto 1480.1480 quindi al 1500esimo membro gli regaliamo un abbraccio, la prossima volta ci vediamo.a questo punto hai detto gli regaliamo, me ne faccio carico io, gli regaliamo una maglietta di geet bar, la prossima maglietta che metteremo in produzione e che sarà una sorpresa.detto questo vi ricordo anche che abbiamo un canale youtube ci trovate cercando github fatelo come come sempre si dice iscrivetevi cliccate sul campanaccio per rimanere aggiornati e insieme a paolo che ringrazio e saluto nuovamente insieme al buon carmine vi do appuntamento alla prossima settimana ciao [Musica] [Musica] [Musica] [Musica]
