Bene e benvenuti su Gitbar, nuova settimana e nuovo episodio qua sul nostro bar degli sviluppatori questo episodio un po' particolare perché in realtà è registrato in una condizione un po' estrema nel senso che mi trovo in vacanza, non ho il setup standard, mi son portato un microfono con la speranza che funzioni e vedremo però nonostante il setup un po' così arraffazzonato, la puntata di oggi sarà una super puntata, tutto merito dell'ospite che tra un po' vi presenterò.Ma prima di presentarvelo, piccola introduzione tipica del nostro podcast, il modo per contattarci è il classico.Info che ho sulla github.it e e Tweetbrain Rappo sono le due modalità che ormai da tanti anni utilizziamo ma la vera modalità è il nostro gruppo Telegram la casa, la betola dove ci incontriamo e chiacchieriamo del più e del meno e talvolta ci confrontiamo anche in modo acceso sui topic che più ci interessano quindi se non l'avete ancora fatto, io so che molti di voi non l'hanno ancora fatto mi raccomando iscrivetevi è sufficiente cercare Gitbar sul vostro client di telegram preferito e iscrivervi e di lì poi scoprirete un mondo e incontrerete tante bellissime persone ma bando alle ciance è arrivato il momento di presentare l'ospite di stasera benvenuti su Gitbar il podcast dedicato al mondo dei full stack developer i mezzo artigiani, i mezzo artisti che ogni giorno infilano le mani nel fango per creare, nel modo più efficiente possibile, quei prodotti digitali che quotidianamente usiamo.Sono super super felice di presentarvi Lorenzo Bardieri, Technical Architect in Microsoft, Autore di libri ma anche Technical Wizard.Ciao Lorenzo, benvenuto da noi.Ciao, ciao a tutti.Allora, la prima cosa che mi ha catturato dal tuo profilo LinkedIn è stato Technical Wizard.Ti chiedo perché hai voluto usare una parola che ha un non so che di magico per associarlo a un contesto che in realtà di magico ha ben poco o dovrebbe averne? Probabilmente perché dovrebbe averne poco ma in verità troppe volte le cose vanno e non sappiamo il perché o non vanno e non sappiamo il perché e non so quale delle due mi spenta di più.E comunque Technical Wizard perché spesso nella mia carriera ho risolto dei problemi o delle cose facendo quasi delle magie, cioè magie nel senso da prestigiatore del Temeleck perché magari ho fatto saltar fuori...ho trovato la soluzione a problemi arcani che si faceva fatica a trovare e questo magari in alcuni casi letteralmente ha dato la mia carriera.Visto che "Genio del male" non bastava, come sono conosciuto su Twitter, su Linkedin e nel profilo in inglese, ho messo "Technical Wizard" proprio per questo motivo, perché a volte riesco a tirare fuori delle magie che magari ci arrivo semplicemente per primo o di fortuna, però spesso mi è capitato e quindi ho voluto rimarcarlo.Poi sai sono tutti ninja, sono tutti master, sono tutti questo, tutti quell'altro, Technical Wizard mi sembrava abbastanza carino dai.Assolutamente sì e poi tra l'altro se proprio volessimo filosofare, che è una cosa che qua al Gitbar ci piace davvero fare, se ci fermassimo un attimo a pensare, fondamentalmente spesso la soluzione così come in un trucco di prestigiatore, del prestigiatore, ecco, avviene quando tu shifti il modo di vedere le cose e proprio nello spostare la prospettiva che tu spesso riesci a vedere la soluzione, tu e noi, riusciamo in quanto sviluppatori, in quanto più più che altro problem solver perché in realtà il nostro lavoro è quello e proprio shiftando questa prospettiva che riusciamo a vedere la soluzione e quindi proprio mentre ne parlavi mi ritornava in mente il fatto che spesso alimentare quel pensiero laterale, uscire dalla propria zona di comfort e provare a esplorare dei pensieri, dei meccanismi diversi sono la via per trovare spesso delle soluzioni a problemi che potrebbero a prima chitto sembrare irrisolvibili.Oggi è la giornata delle tangenti Lorenzo, quindi sappi che! Io uno degli episodi per cui, cioè uno di quelli che raccontavo prima che ha dato la svolta alla mia carriera, era un problema che nessuno riuscì a risolvere.Non trovavamo documentazione, avevamo provato a scrivere anche ai colleghi di Mexico Corporation, ma non trovavamo il contatto giusto.A un certo punto disperato ho iniziato a cercare su internet possibili soluzioni.Sono finito su un video su youtube dove nei commenti del video su youtube ho trovato il link a un progetto su github di un collega microsoft che faceva una roba simile alla mia.Andando lì dentro ho trovato le pi che mi servivano che non erano ancora documentate, poi sapendo il nome delle pi sono riuscito a risalire in qualche modo alla documentazione, cioè però se uno dice disperato perché non si trovava da nessuna parte, non era nelle sdk, non era documentata nelle restpi, non era documentata da nessuna parte, salvo trovare una sample dentro nei commenti di un video su youtube, dimmi se non è magia questa.In effetti lo è, però tieni prento io, gli ascoltatori già la conoscono la mia visione, merita questo, però ho proprio qualche tempo fa preparato un talk dove parlavo dell'affrontare l'ignoto e proprio come dicevi tu spesso una delle caratteristiche del wizard, io ho sempre detto del senior engineer, del senior developer, è quello di saper affrontare quel momento di dire "e mo' che faccio? E mo' non ho la benché minima idea di dove posso trovare questa informazione" e quella è la capacità che distingue chi sa risolvere i veri problemi in qualunque situazione da chi si arrende alla risposta non trovata di Stack Overflow ed ha un non so che di magia, lo ripeto.Però nel contempo se pensano, piccolo step back negli anni 90.Quando si parlava di wizard si pensava a delle form con gli step definiti, step 1 fai questo, step 2 fai questo, che se noi provassimo a definirlo sembra quasi l'antitesi della definizione che abbiamo appena dato di wizard, no? Cioè è proprio un binario nel quale ti muovi ben battuto, ben definito, quindi boom, mind blowing.No, no, alla fine quel binario faceva la magia che altrimenti avresti dovuto fare tu da riga di comando conoscendo tutte le opzioni, per cui è vero che era un binario fisso, però alla fine per uno che non sapeva un po' di magia c'era lo stesso.È vero, ci sta.Oggi ti ho invitato per parlare di un argomento che mi ha senza dubbio incuriosito tantissimo e infatti sappi che ti farò un gozziliardo di domande su questo e che vedo che tu insomma stai portando in giro e stai provando ad evangelizzare.Si tratta di alcune nuove feature, nuove insomma ci sono dall'anno scorso credo, non vorrei sbagliarmi, si tratta infatti di delle nuove feature di Advanced Security di GitHub.Ci puoi chiarire un attimo di cosa si tratta nello specifico? Sono una serie di feature che sono disponibili per tutti sui repo pubblici, quindi sui progetti open source sono disponibili in maniera credo illimitata, perché fino a qualche mese fa c'erano alcune limitazioni di feature ma adesso, da quello che mi ricordo, sono state eliminate.Poi attenzione non essendo io un dipendente di GitHub e soprattutto uno spokesperson magari posso dire anche qualcosa che non è esattamente preciso e perfetto perché non sto tutti i giorni a seguire le release note e rilasci però se non ricordo male sui repo pubblici tutte le funzioni sono abilitate mentre sui repo privati bisogna appunto acquistare queste all'estensione che si chiama GitHub Advanced Security e fondamentalmente sono tre le feature principali macro feature diciamo una di code scanning per trovare le problematiche nel nostro codice attenzione problematiche possono essere note oppure ci permette anche tramite un linguaggio di cui è richiamato CodeQL, di fare delle scansioni noi al nostro codice per trovare ad esempio violazioni di regole che ci siamo dati.Faccio un esempio, magari io non voglio che un parametro che arriva da una pagina web possa essere mandato subito dentro il database per evitare SQL injection posso crearmi una regola che mi va a vedere questa cosa.Poi al 99% la regola ci sarà anche tra le regole base, però era giusto per farvi un esempio perché poi magari ci possono essere dei casi un po' più complicati dove io magari dico "no, attenzione, le chiavi che passano ad esempio in HTTP devono essere per forza...io posso far passare la chiave solo ad esempio se c'è l'HTTPS abilitato altrimenti facendo una chiamata normale dà un errore eccetera eccetera quindi andare ad analizzare il codice che viene prodotto tramite questo linguaggio QL oppure sfruttando le migliaia di regole che sono già incluse la ricerca dei secret quindi password token eccetera eccetera qui potrei raccontarne mille di storie tra cui anche alcune che mi riguardano e poi invece la dependency review ovvero la ricerca di vulnerabilità note o meno note nelle librerie pubbliche o nelle librerie private di cui però è nota la storia delle vulnerabilità perché sappiamo benissimo che nessuno scrive del codice completamente da zero ma a parte i cut and paste dust e cover flow o recentemente gli aiuti di copilot però diciamo che il 90 per cento del codice che andiamo a scrivere in verità non fa nient'altro che chiamare delle librerie per cui il nostro codice potrebbe essere perfetto ma la libreria avere delle vulnerabilità e se queste vulnerabilità sono note github advanced security può segnalarcelo questo ripeto è incluso nei repo pubblici e sui riproprivati invece è una funzionalità che va acquistata a parte.Sì pensavo una cosa in realtà io tempo fa utilizzavo un tool di terze parti per andare a individuare i secrets perché non c'era progetto dove non ne dimenticavo uno o due perché in realtà cosa succede quando si parte con un un P.O.C.la prima cosa che fai è "boom" deve funzionare sta girando sulla mia macchina copy e paste il secret buttalo in una variabile che sta girando lo so che non va fatto ma tanto lo facciamo tutti quindi ragazzi perché questo podcast non te l'ho detto ma ha anche dei momenti verità dove ammettiamo le porcherie che facciamo perché le facciamo tutti.No e dicevo lo prendi poi devi condividere il repo, il repo è magari condiviso solo all'interno di poche persone quindi ci può anche stare anche se in ambiente enterprise qualunque secret deve avere delle polizie di gestione.Però poi cosa succede? Decidi, magari parlo dei repositori del nostro podcast, decidiamo di metterlo pubblico open source e di aprirci alla community in modo che anche la community volendo può contribuire o utilizzarlo se gli è necessario ecco mi dimentico quel secret e vai la panico quando ti mandano un messaggio privato ti aprono una ish e ti dicono bello mio guarda che qua c'è un secret, panico e là bisogna trovare il modo per poi fare una remediation.E non è mai un modo semplicissimo per poterlo fare.Per la gestione dei secret, in realtà, come funziona sotto il cofono? Utilizza delle espressioni regolari o sono io che devo dirgli "matchami questo secret con questo formato"? fondamentalmente lui...cioè puoi farti anche tu delle regole custom, ripeto, con delle regole quindi con una regolare expression, però lui diciamo che il secret della maggior parte di provider SaaS, provider cloud, provider non lo so, cioè di qualsiasi tipo da Postman, Dropbox, Atlasian, Microsoft Azure, Google, AWS, Alibaba, Pulumi, Stripe, Slack, Dimene1, molto probabilmente c'è.In più la cosa che viene fatta nei progetti pubblici è anche avvisare il provider di cui è stato diffuso il secret, in modo che magari possa avere il provider del servizio un modo per bloccare immediatamente il secret e avvisare l'utente.Quindi c'è una doppia regola.Allora, una volta era l'unica funzionalità che c'era per i progetti pubblici, adesso questa funzionalità è rimasta perché non si sa mai, però, come si dice, ad esempio adesso in questo momento se tu cerchi di fare il commit o un pull request che include un secret poi se hai abilitato questa funzionalità di secret scanning lui ti blocca e non te lo fa fare.Tu dici è nel lato del push del codice quindi ancora prima di renderlo disponibile? Volendo puoi farlo anche nel lato del push, oltre a fare lo scanning perché non si sa mai magari sai che cosa? Possono esserci dei provider che prima noi non gestivamo, tu hai del codice che è già stato pushato quindi poi magari ti definisci la regular expression e poi fai la ricerca per vedere se la trova, però la cosa migliore è evitare che il codice venga pushato o che venga provata la pull request dal tuo ambiente locale verso la main branch direttamente in quel momento lì viene bloccato perché c'è un secret nel codice che stai pushando.Perché prima dell'intervista di oggi io non conoscevo le advanced security di GitHub, tieni presente che vengo da un paio d'anni su Azure DevOps e quindi su GitHub ci facevo veramente poco se non i miei progettini di said project open source però mi chiedevo questa feature è fighissima quello che però pensavo è se io comunque il codice con il secret lo faccio arrivare al repository quindi pusho un branch x nel repository che ha il secret poi parte il il code scanner, il secret scanner e mi trova il secret, mi notifica quello che vuoi, magari nasconde, rende irraggiungibile il branch, però nel frattempo qualcuno ha pullato, quindi si è scaricato il mio branch, essendo git di per sé distribuito come concetto, come software proprio, come modo di ragionamento del software, io quel secret lo sto mandando in giro, quindi la prima cosa che mi è venuta è se fosse invece un pre-commit o un pre-push quindi andare ad attaccarci a Luke di Git per ascoltare questa cosa eviterei magari anche di pusharlo il secret.Come potrebbe, mi chiedevo tra le mie seghe mentali perdonami, mi chiedevo come potrebbe GitHub attaccarsi, gestire i miei hook locali, non potrebbe.Per cui mi dico, siccome io sto spingendo il codice quando faccio il push di un branch verso GitHub, potrei magari, non so se esiste questa feature, sto ragionando in piena libertà, potrei stare in ascolto, GitHub potrebbe stare in ascolto del codice appena pushato, fare un quick scan, verificare se esiste un secret, se esiste un secret non accettarmi la push del codice, altrimenti invece accettarmela e renderla disponibile.Io non so in realtà quanta capacità compone la secret.Sinceramente non sono andato a vedere il dettaglio di implementazione però nella documentazione che avevo studiato un po' di tempo fa quando avevo preparato le presentazioni c'era proprio scritto che "proactive prevents secret from being leaked" e quindi suppongo che faccia proprio come hai detto tu, cioè o lo faccio nella pull request in questo modo chi deve amministrare la pull request impedisce che la branch vada nella main branch oppure se invece non stai usando le pull request ma vai direttamente se hai abilitato questa funzione probabilmente fa come dici tu per cui prima di accettare la push fa la scansione e a quel punto te la rifiuta perché se no una volta che dentro git non la togli.Si puoi fare tutti gli history, il rewrite che vuoi ma se qualcuno ha pullato quella...Esatto esatto per cui visto che qui dice "proactive prevent secret from being leaked" secondo me lo blocca prima però sinceramente non sono andato a vedere il dettaglio implementativo perché alla fin fine io in generale anche quando lavoro da solo uso comunque le pull request con una serie di action che mi fanno vari vari controlli usavo le le policy quando usavo Azure DevOps e uso le pull request con tutta una serie di controlli anche se lavoro da solo perché alla fin fine l'errore mi scappa come mi scappa sempre quindi tra l'altro a proposito di Azure DevOps al momento è in private preview GitHub advanced security per Azure DevOps e secondo me tra un po' avremo probabilmente si aprirà anche la beta pubblica non ho nessuna notizia però però è già in private beta già da un po' per cui immagino che tra un po' l'apriranno tutti.Io per quanto riguarda Azure DevOps ho questo amore e odio cioè ci sono delle cose che rispetto a GitHub sono sono anni luce avanti e ne sono pienamente innamorato tipo l'integrazione veramente profonda con la gestione del progetto e ci sono altre cose che in realtà GitHub è molto più avanti e in questo caso per esempio l'Advanced Security poteva essere una una di quelle, però mi hai appena svelato che in realtà tra un po' ci sarà anche su Azure DevOps per la felicità dei miei colleghi.Volevo chiederti, hai parlato di code scanning, quando si parla di code scanning di cosa hai introdotto prima CodeQL, ma come funziona questa cosa, perché sembra un po' esoterica in realtà, vista da fuori.Alla fin fine quello che viene fatto è un'analisi semantica del codice, viene creato un modello e fondamentalmente viene creato un repository che descrive come funziona il tuo codice, quindi al posto di dover fare pattern matching di ad esempio codice javascript codice typescript codice c++ codice rast eccetera eccetera c'è un motore che analizza il codice e poi in CodeQL tu puoi fare le delle query e quindi scrivere delle regole che identificano una serie di problematiche del codice però senza dover andare a mecciare riga per riga, carattere per carattere il tuo codice, perché poi banalmente se viene scritto, non lo so, immagino del codice C o C++, viene scritto con le parentesi in alto piuttosto che con le parentesi a capo, piuttosto che formatato in un certo modo, se tu devi andare ad andare a vedere come è fatto il codice, mecciando proprio il codice, diventa un inferno.mentre andare a vedere usando il motore di CodeQL tu fai delle query utilizzando CodeQL e definisci il codice fondamentalmente indipendentemente dalla formattazione, indipendentemente dai commenti, indipendentemente da una serie di cose.Poi io sinceramente non sarei in grado di andare a scrivere una regola in CodeQL, la cosa buona è che come si dice ci sono migliaia e migliaia di regole per i più svariati linguaggi, ma poi soprattutto come dico sempre la security è un gioco di squadra perché basta un qualsiasi annello debole per rompere una catena molto complessa, ci sono centinaia di tool di sicurezza che sfruttano le feature messe a disposizione da Github Advanced security tool che possono essere gratuiti a pagamento che mi estendono magari anche le regole per cercare tutta una serie di cose e questa è la cosa positiva anche perché ad esempio una delle cose che viene fatta è che ad esempio se viene identificata una vulnerabilità in una libreria.Soprattutto se sono un librerì open source, viene analizzato il codice di quella vulnerabilità e poi viene pubblicata una regola, o dovrebbe essere pubblicata una regola, perché poi bisogna vedere chi ha identificato le librerie bacate che va a cercare quel problema, perché magari, dico una stupidata, c'era un bug in una certa libreria molto famosa, poi magari noi avevamo bisogna una funzione molto simile siamo andati a copiare il codice di quella libreria lì e il bug ce l'abbiamo anche noi quindi il punto qual è che se io nel momento in cui c'è una vulnerabilità in una libreria oltre a notificarlo scrivo anche la regola corrispondente poi magari se quella vulnerabilità in maniera simile perché magari qualcun altro è arrivato alla stessa implementazione banalmente perché essendo codice open source qualcuno l'ha preso, l'ha inserito dentro nel suo codice rispettando la licenza e tutto il resto questo può essere analizzato.Sì, tra l'altro pensavo in merito a CodeQL, un'altra cosa particolare, notate oggi è la giornata delle stranezze, CodeQL di per sé, ho provato a dare un'occhiata, in realtà ricorda molto SQL ed è un linguaggio di query ma la cosa figa in realtà è che ci sono degli interi database bellissimi che contengono le regole che Lorenzo stava dicendo.Io l'ho voluto provare in realtà, non ho ancora finito il setup perché è possibile provarlo anche su GitHub da quello che ho visto perché è su github scusami su visual studio code perché ho visto che esiste un'estensione che si chiama codeql qualcosa che praticamente permette di far girare codeql nel tuo repository che hai clonato locale e che hai aperto con visual studio code e la cosa la prima cosa figa che ti chiede ok vuoi scaricare dei database di regole che immagino siano delle query prefabricate come diceva Lorenzo alla quale però ho visto che ci sono anche delle informazioni di corredo che è una delle cose che GitHub Advanced Security fa, spiega perché quella vulnerabilità, ti dà un po' di insight, ti fa capire dove stai sbagliando e come puoi applicare una remediation e questa cosa oltre che su github è possibile farla anche con con visual studio code almeno credo molto figo guarda mi ha aperto un mondo credimi anche perché io tempo fa avevo ho visto, qualche tempo fa stavo studiando un modo, cercando la metodologia migliore per orientarsi all'interno delle grandi codebase, e uno degli strumenti che spesso vengono utilizzati è quello di strumenti avanzati di ricerca all'interno delle codebase, c'è SurSense un tool per la ricerca, c'è la ricerca avanzata di GitHub che non tutti conoscono e non tutti usano, però in realtà avendo la possibilità di utilizzare questo linguaggio immagino che si possa anche spingere un po' oltre per fini che non sono meramente legati alla sicurezza la ricerca all'interno della codebase.Cosa ne pensi tu di questo? Assolutamente sì, ad esempio potrei anche cercare dei pattern che voglio identificare all'interno del mio codice o anche dei pattern che voglio bloccare che magari non danno nessun problema di sicurezza ma che magari mi danno problemi di performance o anche banalmente non lo so parlando del mondo del cloud problemi di costi perché se io ho dotto i pattern corretti nel mondo del cloud posso andare anche a risparmiare parecchio, se uso i pattern sbagliati posso anche andare a spendere di più anche se il codice è formalmente corretto.Per cui sì, CodeQL è un meccanismo di analisi del codice, poi dentro GitHub Advanced Security vengono fornite di default tutte queste regole per la ricerca di vulnerabilità, ma nessuno ci vieta di utilizzarlo ad esempio per identificare ripeto problemi di performance o anche per identificare una serie di pattern noti del tipo "ah ma all'interno del mio codice come facciamo le encryption delle password?" e quindi posso andare a cercare tramite CodeQL tutte quelle parti di codice che sembra che facciano encryption delle password per andare a vedere effettivamente cosa vanno a fare e per capire se lo stanno facendo nella maniera corretta ed eventualmente crearmi poi una regola per trovare di nuovo i momenti problematici.Ripeto, non solo per problemi di sicurezza, banalmente potrei identificare algoritmi che occupano troppa memoria e che magari utilizzati su macchine locali non hanno nessun problema ma nel cloud ci portano a spendere molto di più, magari perché sto usando le lambda o le function di Azure, le lambda di AWS o soluzioni simili per cui l'utilizzo della memoria invece diventa un problema e quindi magari conviene cambiare il tipo di algoritmo eccetera eccetera cioè le potenzialità di questo strumento per chi lo sa usare sono illimitate.Mi hai ricordato una discussione che avevamo con due amici Michele Riva e Paul Insonia in merito un lavoro che stavano facendo loro su Orama Search dove dovettero sostituire, in quel caso in JavaScript, in TypeScript, tutti i Map e i Reduce con dei cicli for old school, no? E questo potrebbe essere un ottimo modo magari per trovare quel pattern e bloccare l'utilizzo magari di questi approcci un po' più functional like perché meno performanti in una codebase dove la performance è critical.Quindi come dice Lorenzo non solo sicurezza.Rimaniamo per un attimo al mondo.Tu a livello di sviluppo che linguaggi tratti più spesso? Ma io sono uno sviluppatore .NET old school, per cui C#, ma io sarò rimasto buo a C# quello di dieci anni fa, perché poi da quando faccio il...prima facevo il Cloud Architect, adesso il Technical Architect, scrivo codice per diletto, adesso ho scoperto un pochettino Python, ma solo perché tutti pensano "perché ti sei buttato nel mondo dell'artificial intelligence" in verità è perché mi sto divertendo con Omassistan.Però devo dire che a parte i primi tentativi di sviluppare plugin con Python, poi ho scoperto che basta giocare un po' di più con le funzioni native di Omassistan, sono riuscito a ottenere lo stesso tutto quello che mi serviva senza doverci sviluppare sopra e sinceramente anche qui preferisco sfruttare quello che qualcun altro ha sviluppato, almeno eventualmente i bug sono suoi e non mi...Non ci avevo pensato a questa prospettiva del non credere.Ma sai, mia ti possiamo altretto, perché se uno dice "ah scrivi del codice, poco performante" no, qui se io sbaglio, visto che una delle ultime cose che ho fatto è stata buttare via il termostato intelligente che mi hanno dato, intelligente mica tanto, che mi hanno dato quando ho messo a pompa i talore per sostituirlo con...perché non si capiva niente.Cioè la caldaia partiva di notte, di giorno e tu non sapevi mai perché.Lui non ti diceva nulla se no la temperatura delle valvole, ma che però non voleva dire nulla perché partivano quando volevano loro.Mi sono messo lì e l'ho fatto come un assistant.Però il problema sai qual è? È che se d'inverno rimaniamo al freddo, io mia moglie e il piccolo, ed è colpa mia che programmato io il...un conto è dire ho usato le funzionalità poi sarà sempre colpa mia perché ho fatto io la software selection capito però almeno non mi do del pilla per aver scritto io il codice che ci ha fatto rimanere al freddo.E soprattutto non fa incazzare la signora che è la cosa più critica.Esatto esatto cioè almeno non è...almeno puoi dare la colpa...guarda io installato quello e l'idea di mercadè non è un mio modulo che mi sono scritto e non l'ho neanche testato troppo per cui sì diciamo C# di sicuro di dieci anni fa e un pochettino di Python.Perché? JavaScript lo mastico perché se uno non mastica JavaScript non può definirsi uno sviluppatore però non è di sicuro il mio linguaggio preferito.E non è il linguaggio preferito di molti, in realtà per amare JavaScript bisogna usarlo, io dico bisogna usarlo seriamente, bisogna conoscergli ogni sua bad part e sono tantissime.Però perché ti ho fatto venire in mente quel meme, non so se te lo ricordi, quello che il libro "JavaScript Complete Guide" era 1700 pagine, "JavaScript The Good Parts" era 100 pagine.Esatto Lorenzo, ma la cosa divertente è che non è un meme, è la verità e te lo dico da sviluppatore JavaScript a livello professionale nel senso che lavoro su Node.js su progetti anche grossi però è così, JavaScript lo siamo perché il nostro amico speciale.Scherzi a parte, una delle problematiche di JavaScript sono i moduli, cioè le librerie di terze parti.Perché? Perché per una scelta di design i moduli di javascript sono sempre stati pensati come moduli con una superficie molto piccola, per cui si faceva una libreria di terze parti per la funzioncina per, non lo so, trimmare le stringhe quando magari c'era già disponibile.Mi viene in mente il Padleft per gli amici che hanno pianto a causa di quella libreria.Per cui avendo delle librerie con...dimmi Lorenzo...mi ricordo quando era successo...ricordi vero...avendo delle superfici così...se non sbaglio erano cambiate le policy di NPM quando c'era stato quel problema o qualcosa del genere? Se non mi sbaglio sì, qualcosa del genere.Comunque era stata una crisi grossissima che aveva messo a gambe all'aria tantissimi progetti.Il vero problema in realtà sta proprio su questo tipo di filosofia, quindi delle librerie piccolissime che fanno una sola cosa, solo una e veramente contenuta dallo scopo contenuto.per cui arriviamo ad avere gozziliardi di librerie.Una delle feature di GitHub Advanced Security, se ho capito bene, correggimi se sbaglio perché in realtà non ci ho dedicato tantissimo tempo perché non lo avevo, è comunque un minimo anche un'analisi della supply chain, che è uno dei topic caldi di questo periodo, ne abbiamo parlato anche con l'amico Paolo di Suse.In quel caso come funziona? Nel senso lui si fa scanning del mio file di dipendenze e a quel punto fa scanning del codice o cerca nei database di vulnerabilità? Fa entrambe le cose nel senso che lui costruisce sulla base del tuo codice un dependency graph dove identifica tutte le librerie di terze parti che stai utilizzando, ti dà anche una serie di informazioni tipo "guarda che questa libreria è vecchia, ha un database della maggior parte delle librerie, poi è logico che se stai usando una libreria esoterica che ha scritto tuo cugino e te la condivisa, quello gli manca", però diciamo che sul 99% delle librerie che vengono utilizzate e queste informazioni ci sono e poi ti può dare sia delle alert sia può generarti ad esempio una delle cose più carine è che lui ti crea in automatico una pull request dicendo guarda che la libreria non lo so jquery versione 1 2 3 che tu stai utilizzando è appena uscito una vulnerabilità di sicurezza devi migrare almeno alla 123.1 oppure dalla 1.5 non ha questo problema e tu ti ritrovi aperto una pull request.È logico che non può migrare lui in automatico perché poi magari potrebbero essere breaking changes, però già che tu arrivi la mattina e ti ritrovi una una pull request che ti viene assegnata con la vulnerabilità, con tutte le indicazioni ed eventualmente anche le eventuali breaking changes che sono state identificate nella documentazione con la libreria già ti fa un sacco di lavoro.questo diventa molto interessante.L'altra cosa è che fondamentalmente lui va anche a recuperare il file security.md che chi crea le librerie può mettere nella documentazione della libreria in modo da automatizzare questo processo per cui ad esempio viene aggiornata ripeto di nuovo jquery e i maintainer di jquery aggiornano il file security.md con le informazioni importanti e la github advanced security è in grado di andare a recuperare queste informazioni dal file della libreria e fartele avere poi attenzione, le persone che lavorano per Github prendono anche tutte le varie cv che ci sono su tutte le librerie, linguaggi, tutte le vulnerabilità che vengono tracciate e le trasformano in eventuali note da utilizzare con Dependabot, che è il nome di questa funzionalità, e viene aggiornato il GitHub Advisory Database che contiene fondamentalmente il database di tutte queste vulnerabilità note, di tutte le possibili versioni, di tutte le librerie che vengono tracciate.Io credo che non ci debba essere progetto senza Dependabot, è una delle cose che mi ha salvato la vita in buona parte, anzi in tutti i miei progetti perché lo uso dappertutto.Un'altra cosa che poi soprattutto non è tanto quando sviluppi, magari tu hai un progetto vecchio di sei mesi che stai però utilizzando, usa una libreria che non stai usando in altri progetti, esce una vulnerabilità e tu pam ti arriva da Guita la mail che ti è stata assegnata la pull request perché quella libreria lì aveva un problema di sicurezza.Tu puoi andare e generare, a parte aggiornare se è un progetto pubblico, ma se anche nel tuo repo privato perché hai gli tab advanced security puoi aggiornare il tuo codice e risolvere il tuo problema.E magari questa cosa tu non ne avevi idea, magari non ti ricordavi nemmeno che stavi usando quella libreria perché magari tu usavi una libreria che a sua volta usava quella libreria lì e quindi tu magari avevi anche visto passare su qualche sito la vulnerabilità ma non ci avevi dato peso perché non immaginavi nemmeno che un'altra libreria che tu stavi usando usava quella.Sì, vero, e quando inizia ad avere come a livello aziendale abbiamo noi centinaia, diverse centinaia di progetti open source che devi mantenere, tool di questo tipo diventano l'unico modo che poi hai per poterlo gestire tanto che in realtà non so se posso dirla questa cosa però la dico lo stesso tanto che un abbraccio al mio collega Simone ha dovuto sviluppare un sistemino dove Dependabot fa la PR dove fa il bump delle versioni e se i test passano tutti e tre i livelli di test quindi test unitari, integrazione, un eventuale end-to-end test passa, automaticamente c'era un'applicazione che faceva il merge da solo, perché, ripeto, quando hai 200, 300, 500 repository da gestire, React ti fa il bump up della versione, voglio vederti a fare le PR su ognuno di questi repository.No, no, no, chiaro, attenzione, Github non può farlo lui in automatico ovvio, perché non hai idea se tu hai il test, se hai il code coverage, se hai tutte le build automatizzate che fanno le verifiche, eccetera.È logico che un team di sviluppo strutturato come il vostro in questo caso, può permettersi di dire "prendiamo la minima versione che risolve il problema" quindi adesso faccio un esempio, se una certa libreria era bacata sia la versione 5.1 che la versione 6.0 e è uscita la 5.2 e la 6.1, io aggiornerei la 5.2 visto che stavi usando la 5.1 solo per il problema di security, in questo modo minimizzi le possibilità di breaking changes.Assolutamente d'accordo con te.Considera che c'è una statistica, non so se la conosci, che praticamente sulle vulnerabilità note di librerie la norma nella nostra industria è che vengono fissate in circa 180 giorni, vuol dire che ci sono sei mesi da quando una vulnerabilità diventa nota a quando mediamente i software che la contengono vengono aggiornati.Quando era stato lanciato Dependabot, quindi ormai parliamo di quasi un anno fa, sui progetti dove c'era Dependabot attivo la media era di 40 giorni.Magari parliamo di una media perché c'erano progetti che venivano mantenuti, progetti che si, Guitar aveva aperto la Purry, questa aveva mandato la mail, ma Mario il maintainer non gestiva più un sacco di tempo, quindi Mario c'erano tantissimi progetti che alzavano la media, però vuole anche dire che se si è passati da 180 giorni a 40 giorni vuol dire che probabilmente tutti i progetti principali, tutto quello che viene manutenuto correntemente veniva aggiornato praticamente, non dico in tempo reale, ma quasi.Sì sì sì assolutamente, poi diventa comunque abbastanza facile gestirlo con dei tool come Dependabot e quindi lo ripeto anche se il progetto dell'associazione Calcio Balilla, dell'oratorio Sotto Casa, mettete Dependabot perché tutto il resto vi viene gratis, dovete solo per buona parte dei casi immergere il pull request e magari fixare qualche breaking change e se avete fatti i test come si dovrebbe fare diventa tutto più facile.C'è un'altra cosa però che mi ha catturato l'attenzione di github advanced security che in realtà quello che si viene chiamato la security overview che è una cosa che ho notato ho notato parlando proprio di tanti repo e di organization molto grandi è una cosa che mi sono detto quando l'ho visto "Oh cribio, questa cosa è un game changer" che è una specie di dashboard che ci dà una visione generale della situazione dei nostri repository tutti insieme.Dicevo, sai, tutte le organizzazioni c'è chi è più attento a certi temi, c'è chi è meno attento.Avere un reposito di comune dove magari il technical manager che supervisione vari progetti oppure il security manager, il VP of engineering, il CTO, quello che abbia una visione che non deve dipendere dai singoli project manager, i singoli owner di progetto eccetera eccetera se stanno gestendo bene le cose ma possa vedere tutti i repository dell'organizzazione come sono messi secondo me quando hai più di dieci progetti diventa veramente un game changer perché altrimenti ripeto poi dopo c'è la security c'è dipende anche molto dalla dall'anello debole della catena quindi ne basta anche uno che sta condividendo dei secret, ne basta uno che non ha aggiornato le librerie per magari mandare a quel paese tutta la security del resto dell'azienda.chiaro, assolutamente chiarissimo.Tra l'altro ho un altro dubbio, aiutami a capire meglio là, i tool di per sé sono tre, sono super potenti integrati in una suite altrettanto figa, ma out there, là fuori ci sono tutta un'altra serie di tool interessanti e io guardavo quella dashboard che mi ha catturato l'attenzione.Mi chiedevo, siccome GitHub di per sé, proprio per sua natura, è uno di quei tool super estensibile, dalle appliche possiamo fare veramente tutto con GitHub, da quanto è d'utile e si piega poi alle esigenze, mi chiedevo se che tu sappia sia possibile integrare all'interno proprio delle funzionalità di Github Advanced Security anche tool di terze parti che fanno analisi che ne so statica del codice che non sia code QL della situazione.Immagino il prodotto XYZ io lo voglio integrare magari mi dà dei risultati ecco quei risultati possono essere visualizzati nel contesto di Github Advanced Security? Non so, magari è una domanda un po' troppo edge case per un prodotto così nuovo, però era una cosa che mi chiedevo.Sai che stavo...mi hai fatto venire la curiosità perché non ci avevo mai pensato.In teoria sì, perché come ti dicevo prima Github Advanced Security non vuole avere la pretesa di individuare tutto quindi ci sono un sacco di plugin e di estensioni per Github Advanced Security basate su QL o non basate su QL e c'è la possibilità di andare a scrivere dentro nel report però così Stavo guardando un attimo perché non ci ho mai guardato direttamente su quello, una cosa abbastanza...Sì, non è...diciamo non fa parte dell'utilizzo basic, ecco, magari sono cose che vengono in mente analizzando dei casi un po' più particolari, un po' più meno standard, però io per esempio talvolta mi sono.Guardando i report di default c'è proprio le varie alert, scanning e secondary scanning, per cui credo che o estendi quelli tramite i tool di estensione che ci sono e quindi te le ritrovi dentro, non so se riesci a uscire dai report terzi.Capito però...perché sinceramente mi hai preso un po'...è interessante, molto interessante la domanda, ma così a naso non...La domanda ti racconto da dove viene, qualche tempo fa abbiamo avuto ospite qua a Gitbar, anzi abbiamo fatto qua a Gitbar una puntata su GrafDB.È uno degli utilizzi che mi venivano in mente di GrafDB.GrafDB era? Io adesso sai la sera inizio a perdere qualche colpo, fammela recuperare così.Ok Neo4j non GraphDB, la tipologia di database, l'abbiamo registrato con Alberto De Lazzari di Dilarus Business Automation e una delle cose che Alberto ci disse era "Mauro guarda con Neo4j che è un database a grafo tu volendo puoi dampare sul sul database, dampare sul database tutta la tua codebase con le relazioni tra gli elementi dell'abstract syntax tree, no? E su quello in realtà tu puoi percorrere il grafo, visitare il grafo e andare a estrarre pattern, cosa che un po' ricorda l'approccio di CodeQL, ci sono tanti elementi in comune, almeno io le vedo e quindi mi chiedevo se io domani mattina, non lo so, uso il "se" perché è una cosa che non farei mai, però se io domani mattina dovessi farmi il mio analisi tool che mi fa queste cose, a quel punto sarebbe carino integrare l'output di questo tool per avere un risultato generale oppure mi viene in mente che ne so noi del mondo javascript usiamo tantissimo il linter per vedere che non scriviamo porcate lo usiamo come strumento di autocontrollo esogeno e mi viene in mente ok già di per il mio linter è integrato su github ma l'output dell'inter sta là e fermo cosa succede se io lo voglio integrare all'interno di questo meccanismo ecco da dove veniva la mia idea un po la mia domanda un po malsana e atipica Lorenzo.Allora sulla code scanning lo puoi fare perché ci sono c'è un formato che si chiama SARIF, Static Analysis Result Interchange Format, che fondamentalmente se il tuo tool che ti sei iscritto tu custom, magari usando il db, neon4j, che dicevi prima, trovi quello che ti interessa e non vuoi utilizzare CodeQL, tu puoi agganciare, poi produrre il report in questo formato che viene gestito da GitHub Advanced Security e lo puoi integrare quindi poi ti compare anche nella tua security overview nella sezione code scanning anche se non hai usato CodeQL e la funzionalità di code scanning di GitHub hai usato la tua, hai a disposizione The Webhook per poter fare questa integrazione come si dice, sia a livello di...quindi anche quando appunto come dicevamo prima stai facendo ad esempio le push sul tuo repo oppure puoi integrarlo dentro nei sistemi di continuous integration nativi di github ma anche quelli esterni se stai utilizzando dei sistemi di continuous integration esterni puoi integrarci il tuo strumento e all code ql e se poi alla fine prendi il tuo output di sarif e lo mandi su github te lo ritrovi nel tuo security overview chiaro mi chiedevo proprio adesso mentre dicevi quello un'altra cosa su su CodeQL perché ho visto che esiste un repository che contiene le rules di CodeQL no e mi chiedevo siccome la svolta open source di Microsoft è davanti agli occhi di tutti non la si può negare mi chiedevo se in realtà l'engine che fa girare CodeQL fosse open source o fosse qualcosa di più utilizzato? Credo di no perché il prodotto viene, cioè Github Advanced Security viene venduto quindi credo proprio di no.Però questa è una di quelle domande per cui dovresti chiederlo a qualche esperti, a qualcuno di GitHub perché alla fin fine GitHub e Microsoft, cioè è vero che GitHub è al 100% proprietà di Microsoft ma vengono divertite come società indipendenti, cioè dentro GitHub vanno anche strumenti che non sono Microsoft perché sono totalmente una società staccata.Ok adesso adesso mi spiego perché comunque Azure DevOps ha proprio una linea di sviluppo completamente diversa da quella di Guitab, perché mi chiedevo, ma hanno due prodotti che fanno la stessa cosa, forse avrebbe senso unirli no? Invece questo mi risponde...- A un duo termine è così, il problema sai qual è? Che un po' hanno approcci molto diversi, quindi mentre su alcune feature, vedi non lo so, la parte di repo o ad esempio Guitab Advanced security per Azure DevOps che al momento è in private beta, sono tutte cose...oppure non lo so cioè le GitHub Action e le Pipelines sono molto molto simili, se io vado a prendere le issues di GitHub o vado a prendere ad esempio le board di Azure DevOps sono proprio due mondi totalmente diversi.Tu considera che qualche anno fa quando abbiamo acquisito GitHub la dirigenza di Azure DevOps e quella di GitHub erano state unificate proprio per identificare una roadmap comune, cioè non comune però una roadmap che convergesse tra i due prodotti per arrivare a una convergenza probabilmente non è così semplice, ma magari ad esempio ho lavorato tanto su TFS prima e Azure DevOps dopo e ci sono veramente migliaia e migliaia di estensioni e raramente le enterprise lo usano as is, per cui anche a dirgli ok prendi migra fai è ok ma tutti i processi custom che sono creato nel corso degli anni non è così semplice quindi molto probabilmente il piano a lungo termine è comunque credo ancora a livello di convergenza non penso che sia cambiato.La fattibilità di questo piano bisogna capire, la velocità scusami di questo piano bisogna capire perché giustamente a un'azienda che magari si è creata il suo processo custom tutta una serie di toolset, tutta una serie di automazioni che funzionano, un conto ed illi sposta i repository su github ma tiene l'integrazione con le azure boards, un conto ed illi tiene tutto su azure devops anche perché la parte che ti mancava cioè quella security te la sto dando.Certo, certo chiaro è complesso specie anche in contesti dove dove si lavora in ambito enterprise dove si è importanti co-creator con chi poi mette in piedi i propri prodotti perché la responsabilità di Azure DevOps e di GitHub è enorme nei prodotti IT, cioè si parla veramente di co-creators.Lorenzo, fighissimo, mi hai fatto venire una dannata voglia di provarlo, bene, in modo sistematico, quindi sapi che lo proverò e che è merito/colpa tua il fatto che ci dedicherò un po' di ore perché mi hai incuriosito tantissimo quindi grazie di cuore.Figura ti è stato un piacere guarda.Prima però di lasciarci abbiamo due momentini il primo è ringraziare chi ci supporta, chi si fa carico dei costi del nostro podcast perché in realtà Gitbar è gratuito per gli ascoltatori ma non senza costi e questa settimana abbiamo due persone che ci hanno aiutato e e ci aiutano a pagare le bollette e per cui è che vogliamo ringraziare.Come sempre ragazzi io non so perché vengo sempre messo in mezzo in questa cosa probabilmente perché sono l'unico che non si vergogna a parlare di soldi ma non vedo perché vergognarsi a una cosa così bella, parlare di soldi perché i soldi sono veramente la cosa più bella del mondo quindi donate perché dobbiamo fare una cena da massimo bottura con i vostri soldi quindi è una cosa molto importante e siamo molto poveri quindi donate copiosamente veramente in tantissimi mi raccomando dateci i vostri soldi e noi ne faremo l'uso più responsabile che se ne possa fare ovvero metterli su delle cripto uscite da mezz'ora *musica* In primis abbiamo Roberto Rossi che ci scrive anche complimenti, continuate così buon lavoro offrendoci una birra e subito dopo abbiamo anche Luca Francesca che ci offre 5 birre noi alziamo a questo punto 6 calici in aria insieme allo Berto e beviamo le birre che ci sono state offerte rispettivamente da Roberto e da Luca Luca, grazie di cuore.Bene Lorenzo è arrivato il momento che ti anticipavo prima, no? È il momento che si chiama il Paese dei Balocchi, momento in cui i nostri guest e i nostri host condividono con noi un libro, un talk, un vino, qualunque cosa abbia catturato la loro attenzione, or reputino, importante, carino, condividere con la nostra casa.community.Per cui la domanda di Rito è hai qualcosa che ha catturato la tua attenzione per cui pensi valga la pena essere condiviso con noi? Visto che abbiamo parlato di anche contesti dell'enterprise, contesti multi cloud eccetera eccetera e anche della parte di CD riportistica sulla security di GitHub.Io volevo condividere un tool che praticamente conoscono in tre, probabilmente lo conosciamo io, una mia collega che me ne ha parlato e probabilmente il venditore di Microsoft che cerca di venderlo, probabilmente con poco successo perché non è così famoso, che è fondamentalmente Defender for DevOps.Defender for DevOps è uno strumento che fa parte Defender for Cloud, quindi fa parte della suite Defender che è uno dei prodotti in mezzo per la sicurezza.Adesso io non voglio, cioè non mi interessa adesso fare il venditore di Pentium, però se avete un ambiente multicloud, Azure, AWS, Google, risorse on premise, se avete pipeline di sviluppo multicloud e multiambiente, multi repository eccetera eccetera, Defender for DevOps ha molte più feature di reportistica ottimizzate proprio per questo scenario.Permette di collegarsi sia Azure DevOps che Agitaba, permette di gestire cross azienda tutte queste informazioni problematiche, versioni delle vulnerabilità, versioni delle librerie, però lo fa in una maniera diversa, mentre gli tab Advanced Security lo fa a livello di ripu e poi va via via ad espandersi, questo invece lo fa dall'alto, cioè prima guarda la complessità dei progetti aziendali e poi io posso andare in drill down a vedere le varie cose, quindi un approccio completamente diverso.Devo fare a mano una reportistica per capire a colpo d'occhio la security cross cloud e cross repository della mia azienda e anche cross tool perché ripeto Mario metà azienda ancora su Azure DevOps e metà la sto migrando su GitHub con Defender for DevOps che è una parte di Defender for Cloud ci sono queste funzionalità quindi io volevo segnalare non prendo un centesimo da questa mia segnalazione però magari ci sono sviluppatori che hanno queste necessità un po' più avanzate buttateli un occhio è in preview ancora quindi le cose potrebbero cambiare però a me mi è sembrato un tour molto molto interessante.Sì anche per questo mi hai incuriosito, io tra l'altro volevo consigliare un tuo tolk che si chiama Public Speaking for Geeks, giusto? È un tolk carino che vi metto nelle note dell'episodio, è un tolk che è fatto a marzo, quindi buttateci un occhio perché è molto carino.A questo aggiungo sempre in termini di video una bella playlist su youtube che parla del node event loop.Ancora mi capita di chiacchierare con sviluppatori javascript che pur lavorando in node hanno qualche difficoltà col node event loop.Questa playlist è la chiarezza, da la chiarezza definitiva di quello che è un elemento imprescindibile da conoscere quando si sviluppa in JavaScript.Io ringrazio nuovamente Lorenzo.Scusami, un'ultima cosa, visto che hai citato il mio talk su public speaking, mi hai fatto venire in mente che ne posso approfittare allora per fare la pubblicità anche ai libri che ne ho scritti due, uno è Public Speaking for Geeks succinctly e uno è Beyond Public Speaking for Geeks succinctly che è il seguito.Sono tutte e due gratuiti e li trovate nella catena succinctly di Syncfusion, basta dargli la mail ma li trovate anche, cioè sono liberamente scaricabili e li potete visualizzare.Il primo l'ho scritto diciamo pre-covid, quindi era molto più focalizzato sul diciamo sul public speaking tradizionale.Nel secondo ho affrontato anche le tematiche di public speaking online, di meet, di podcast, ma anche tematiche relative ad esempio alla sindrome dell'impostore, alla diversity, all'inclusion anche nel mondo del public speaking.Per cui se qualcuno è interessato all'argomento ve li consiglio, sono due libricini da 80 pagine, quindi si leggono veramente in un paio d'ore tutti e due, ma se li leggete poi fatemi sapere, ci sono i miei contatti e sono molto interessato a sapere cosa ne pensate.Assolutamente uno di quei topic che mi appassionano di più quindi aspettate il mio feedback.Grazie mille, non vedo l'ora.Detto questo io Lorenzo ti ringrazio infinitamente per esserci venuto a trovare, come diciamo sempre, da questo momento Gitbar è un po' anche il tuo circolo di fiducia, il circolo del dopolavoro di fiducia, per cui quando hai qualcosa di carino da condividere con noi e e ti fa piacere farlo mi raccomando pingami perché c'è sempre una birra in fresco per te.Perfetto grazie mille.Grazie di cuore.Io vi ricordo che Gitbar esce quasi ogni giovedì quando usciamo di giovedì usciamo di venerdì comunque arriviamo quasi ogni settimana.Ci trovate come sempre su www.gitbar.it @brainrepo su Twitter info@gitbar.it via email oppure sul nostro gruppo Telegram Gitbar e nulla detto questo io ringrazio nuovamente Lorenzo per esserci venuto a trovare alla prossima ciao ciao ciao Gitbar il circolo dei full stack developer una volta a settimana ci troviamo davanti a due birre e con Brain Repo parliamo di linguaggi e tecniche di sviluppo web di metodologie e di strumenti immancabili nella cassetta dell'attrezzi dei fullstack dev [Musica]
