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 gitbar.it e etbrain.repo 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.it 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 Barbieri, 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 Temer 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 svolta alla mia carriera e quindi visto che genio del male non bastava come sono conosciuto su Twitter, su LinkedIn nel profilo in inglese ho messo technical wizard proprio per questo motivo perché a volte riesco a tirar 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 no 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 e in quanto 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.

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 Magso 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 API che mi servivano che non erano ancora documentate e poi sapendo il nome delle API sono riuscito a risalire in qualche modo alla documentazione.

Cioè però se uno dice disperato al potere, perché non si trovava da nessuna parte, non era nelle SDK, non era documentata nelle rest API, 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 in merito a questo, però ho proprio qualche tempo fa preparato un talk dove parlavo dell'affrontare l'ignoto, è 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 penso no, piccolo step back agli anni 90, quando si parlava di wizard si pensava delle form con gli step definiti no, 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.

Nel fine il binario faceva la magia che altrimenti avresti dovuto fare tu da riga di comando o conoscendo tutte le opzioni, per cui è vero che era un binario fisso eh, 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 no 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? Allora 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 estensioni che si chiamano 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 qui 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 e 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 io posso far passare la chiave solo ad esempio se c'è l'HTTPS abilitato altrimenti facendo una chiamata normale dammi un errore eccetera eccetera quindi andare ad analizzare il codice che viene prodotto tramite questo linguaggio CodeQL oppure sfruttando le migliaia di regole che sono già incluse la ricerca dei secret quindi password, token eccetera eccetera e 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% del codice che magari 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 repo privati invece è una funzionalità che va acquistata a parte si 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 due perché in realtà cosa succede quando si parte con un pocino 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 policy di gestione però poi cosa succede boom decidi magari parlo dei repository 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 e panico e la bisogna 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 di meno è uno molto probabilmente c'è in più la cosa che viene fatta nei progetti pubblici e anche avvisare il come si dice 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ò adesso in questo momento se tu cerchi di fare il commit o una pull request che includi 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 nell'atto 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 code scanner il secret scanner e mi trova il secret mi notifica quello che vuoi magari nasconde rende raggiungibile 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 segmentali 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à computerale...

nel documentazione che avevo studiato un po' di tempo fa quando avevo preparato le presentazioni c'era proprio scritto che proactive prevents secrets from being leaked 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 più si puoi fare tutti gli history rewrites che vuoi ma se qualcuno ha pullato quella...

esatto esatto per cui c'è visto che qui dice proactive prevents secrets from being leaked secondo me lo blocca prima però sinceramente non sono andato a vedere il dettaglio implementativo perché alla 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 fine l'errore 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' la apriranno a 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à a GitHub è molto più avanti e in questo caso per esempio l'advanced security poteva essere una di quelle però mi hai appena svelato che 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 si ha introdotto prima a 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 delle query e quindi scrivere delle regole che identificano una serie di problematiche del codice però senza dover andare a matchare 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 a vedere come è fatto il codice matchando 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 formatazione 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 anello debole per rompere una catena molto complessa ci sono centinaia di tool di sicurezza che sfruttano le feature messe a disposizione da advanced security che possono essere gratuiti o 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 identificato una vulnerabilità in una libreria viene anche analizzata soprattutto se sono un librario 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 che va a cercare quel problema perché magari c'era un bug in una certa libreria molto famosa poi magari noi avevamo bisogno di 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 o 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 Si 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 è 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 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 no spiega perché quella vulnerabilità ti da 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 Visual Studio Code almeno credo molto figo guarda mi ha aperto un mondo credimi anche perché io tempo fa avevo visto delle 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'è Sourcense forse 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ì c'è ad esempio io 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 anche se ho adotto i pattern corretti nel mondo del cloud posso andare a risparmiare parecchio se uso i pattern sbagliati posso andare a spendere di più anche se il codice è formalmente corretto per cui sì, CodeQella è 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 problemi di performance o anche per identificare una serie di pattern noti del tipo ma all'interno del mio codice come facciamo le encryption delle password e quindi posso andare a cercare tramite CodeQella 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 o 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 è ricordato una discussione che avevamo con due amici Michele Riva e Paolo Insonia in merito a un lavoro che stavano facendo loro su Orama Search dove dovettero sostituire in quel caso in javascript e in typescript tutti i map e i reduce con dei cicli for old school 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 code base dove la performance è critical quindi come dice Lorenzo non solo sicurezza rimaniamo per un attimo al mondo, a livello di sviluppo che linguaggi tratti più spesso? Ma io sono uno sviluppatore.NET old school per cui C sharp ma io sarò rimasto buo a C sharp quello di dieci anni fa perché poi da quando faccio il...

prima facevo il crowd architect e 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 no in verità è perché mi sto divertendo con home assistant 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 home assistant, 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 non ci avevo pensato a questa prospettiva del non scrivere il 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 punta italore 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é che partivano quando volevano loro mi sono messo lì l'ho fatto con home assistant però il problema sai qual è? è che se d'inverno rimaniamo al freddo io mia moglie è il piccolo ed è colpa mia che ho programmato io il...

un conto è dire ho usato le funzionalità poi sarà sempre colpa mia perché ho fatto io la software selection 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 a...

guarda io ho installato quello e l'idea di mercadè non è un mio modulo che mi son scritto e non l'ho neanche testato troppo per cui si diciamo C sharp di sicuro di dieci anni fa e un pochettino di python perché no? javascript è lo basico 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 parts 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à esatto 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 si ama 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 no? 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 un...

dimmi Lorenzo che ho sentito no no mi ricordo quando era successo ricordi vero? avendo delle superfici così piccole se non sbaglio erano cambiate le policy di npm quando c'era stato quel problema o qualcosa del genere se non mi sbaglio si 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 è 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 no? che è uno dei topic caldi di questo periodo ne abbiamo parlato anche con l'amico Paolo di Suse e 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 da 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 l'ha condivisa quello gli manca però diciamo che sul 99% delle librerie che vengono utilizzate 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 1.2.3.1 oppure dalla 1.5.0 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 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 di nuovo jquery 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 direttamente 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 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 github la mail che ti è stata assegnata la pull request perché quella libreria lì aveva un premio di sicurezza tu puoi andare e generare, a parte aggiornare se è un progetto pubblico ma se anche nel tuo repo privato perché hai github 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ì 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 e voglio vederti fare le PR su ognuno di questi repository ah 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 allora 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 alla 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 non venivano mantenuti progetti che si, Guitar aveva aperto la Purry, questa aveva mandato la mail ma magari il maintainer non gestiva più un sacco di tempo quindi magari 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 di 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 Purrequest e magari fissare 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 viene chiamato la security overview che è una cosa che 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 da quel punto...

scusa perché...

vai scusami no no dimmi scusa vai pure no dicevo sai tutte le organizzazioni c'è chi è più attento a certi temi c'è chi è meno attento avere un repository comune dove magari il technical manager che supervisione i vari progetti oppure il security manager o 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 cioè dipende anche molto 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 e mi chiedevo ma siccome GitHub di per sé, proprio per sua natura è uno di quei tool super estensibile dalle application 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 codeql 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 codeql o non basate su codeql e c'è la possibilità di andare a scrivere dentro nel report però così a...

aspetta eh stavo guardando un attimo perché non ci avevo mai...

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 depende a bocca o scanning e second scanning per cui credo che o estendi quelli tramite i tool di estensione che ci sono e quindi te li ritrovi dentro non so se riesci a...

pushare report terzi capito però...

che sinceramente mi hai preso un po' è interessante, molto interessante la domanda ma così a naso non...

la domanda ti racconto da dove viene no? qualche tempo fa abbiamo avuto ospite qua a Gitbar anzi abbiamo fatto qua a Gitbar una puntata su...

GraphDB è uno degli utilizzi no? che mi venivano in mente di...

GraphDB era? adesso sai la sera inizio a perdere...

a perdere qualche colpo fammela recuperare così ok Neo4j non GraphDB la tipologia di database l'abbiamo registrato con Alberto De Lazzari di Larus 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 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 no? 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 ste 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 sé 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 la mia domanda un po' malsana è atipica Lorenzo e allora sulla code scanning lo puoi fare perché c'è un formato che si chiama sarif static analysis result interchange format che fondamentalmente se il tuo tool che ti sei scritto tu custom magari usando il db neon4j che dicevi prima trovi quello che ti interessa e non vuoi utilizzare CodeQL tu puoi agganciare cioè puoi produrre il report in questo formato che viene gestito da come si dice da github advanced security e lo puoi integrare quindi poi ti compare anche come si dice nel tuo la tua security overview nella sezione code scanning anche se non hai usato CodeQL e la funzionalità di code scanning di github ma 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 o il CodeQL e se poi alla fine prendi il tuo output di sarif e lo mandi su github te lo ritrovi nel tuo nel tuo security overview chiaro io mi chiedevo proprio adesso mentre dicevi quello un'altra cosa su CodeQL perché ho visto che esiste un repository che contiene le rules di CodeQL 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 qualcuno di github perché alla fine github e Microsoft è vero che github è al 100% proprietà di Microsoft ma vengono advertite come società indipendenti dentro github vengono anche strumenti che non sono Microsoft perché sono totalmente una società staccata ok adesso mi spiego perché comunque Azure DevOps ha proprio una linea di sviluppo completamente diversa da quella di github perché mi chiedevo ma hanno due prodotti che fanno la stessa cosa forse avrebbe senso unirli no? invece questo mi risponde al mio 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 github advanced security per Azure DevOps che al momento è in private beta sono tutte cose oppure non lo so 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 le non dico che non è così semplice ma magari ad esempio ho lavorato tanto su TFS prima Azure DevOps dopo e ci sono veramente migliaia migliaia di estensioni e raramente le enterprise lo usano as is per cui anche a dirgli ok prendimi grafai e ok ma tutti i processi custom che mi sono creato nel corso degli anni non è così semplice quindi molto probabilmente cioè 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 ha un'azienda che magari si è creata al suo processo custom tutta una serie di toolset tutta una serie di automazioni che funzionano un conto è di gli sposta i repository su github ma tiene l'integrazione con le azure boards un conto è di gli tieni 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 barra colpa tua il fatto che ci dedicherò un po' di ore perché mi hai incuriosito tantissimo quindi grazie, grazie di cuore figura, ti è stato un piacere prima però di lasciarci abbiamo due momentini il primo è ringraziare chi ci supporta chi si fa carico di parte dei costi del nostro podcast perché in realtà github è gratuito per gli ascoltatori ma non senza costi questa settimana abbiamo due persone che ci hanno aiutato e ci aiutano a pagare le bollette e per cui 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 a 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 crypto che non ci riuscire da mezz'ora 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 all'Uberto e beviamo le birre che ci sono state offerte rispettivamente da Roberto e da Luca grazie di cuore bene Lorenzo è arrivato il momento che ti anticipavo prima è il momento che si chiama il paese dei balocchi il 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 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 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 di Defender for Cloud, quindi fa parte della suite Defender che è uno dei prodotti in mezzo per la sicurezza adesso io non voglio non mi interessa adesso fare il venditore di Pentium, però se avete un ambiente multi cloud Azure, AWS, Google risorse on premise se avete pipeline di sviluppo multi cloud, multi ambiente 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 a tutte queste informazioni problematiche versioni delle vulnerabilità versioni delle librerie però lo fa in una maniera diversa Agitaba Advanced Security lo fa a livello di repo e poi va via via ad espandere 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 e se c'è qualcuno che dice che devo fare a mano una reportistica per capire a colpo d'occhio la security verso questo allora io la visito con ajordevphis 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 è sembrato un tool molto interessante.

Sì, anche per questo mi hai incuriosito.

Io tra l'altro volevo consigliare un tuo talk, che si chiama Public Speaking for Geeks, giusto? È un talk carino che vi metto nelle note dell'episodio, è un talk 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à con Node Event Loop, questa playlist dà la chiarezza definitiva di quello che è un elemento imprescindibile da conoscere quando si sviluppa in JavaScript.

Io ringrazio nuovamente Lorenzo.

Scusa, l'ultima cosa.

Visto che hai citato il mio talk su Public Speaking, mi hai fatto venire in mente, quindi posso approfittare 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, sono liberamente scaricabili e li potete visualizzare.

Il primo l'ho scritto pre-Covid, quindi era molto più focalizzato 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 che 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, 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 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, su Twitter, su www.gitbar.it via email oppure sul nostro gruppo Telegram Gitbar.

Detto questo, io ringrazio nuovamente Lorenzo per esserci venuto a trovare e alla prossima.

Ciao ciao! Ciao! Gitbar, il circolo dei full stack developer.

Una volta a settimana ci troviamo davanti a due birre e con BrinRepo parliamo di linguaggi e tecniche di sviluppo web, di metodologie e di strumenti immancabili nella cassetta degli attrezzi dei full stack dev..