[{"data":1,"prerenderedAt":437},["ShallowReactive",2],{"has-blog-posts":3,"blog-categories":4,"category-posts-devops":17},true,[5,8,11,14],{"slug":6,"name":7},"architettura","Architettura",{"slug":9,"name":10},"devops","DevOps",{"slug":12,"name":13},"sviluppo","Sviluppo",{"slug":15,"name":16},"testing","Testing",[18,220],{"id":19,"title":20,"body":21,"category":10,"date":203,"description":204,"extension":205,"image":206,"meta":207,"navigation":3,"path":208,"published":3,"seo":209,"seoTitle":210,"slug":211,"stem":212,"tags":213,"updated":218,"__hash__":219},"blog/blog/2026-01-27-dipendenze-open-source-costo-nascosto.md","Dipendenze open source: il costo nascosto che non vedi nell'invoice",{"type":22,"value":23,"toc":185},"minimark",[24,36,39,44,49,58,61,64,68,71,74,88,92,99,102,106,113,117,120,123,127,130,134,144,148,155,159,162,169,172,176,182],[25,26,27],"p",{},[28,29,30,31,35],"strong",{},"Le dipendenze open source sono ovunque nel tuo progetto. Il tuo progetto ha 47 dipendenze dirette. Quelle 47 dipendenze hanno 847 dipendenze transitive, cioè pacchetti che non hai scelto tu direttamente ma che arrivano insieme agli altri. Ognuna di queste è mantenuta da qualcuno che non conosci, che potrebbe smettere domani, e il cui codice finisce direttamente nel tuo processo di build e nel software che metti in produzione. ",[32,33,34],"code",{},"npm install"," è gratis. Tutto il resto no.",[25,37,38],{},"C'è un paradosso nell'open source: lo usiamo perché è gratuito, affidabile e comunitario. Ma gratuito non significa senza costi, affidabile non significa per sempre, e comunitario non significa che qualcuno si prende la responsabilità quando qualcosa va storto.",[40,41,43],"h2",{"id":42},"il-costo-che-non-vedi","Il costo che non vedi",[45,46,48],"h3",{"id":47},"manutenzione-continua","Manutenzione continua",[25,50,51,52,57],{},"Ogni dipendenza nel tuo progetto è codice che qualcun altro ha scritto e che tu devi mantenere aggiornato. Non perché vuoi le ultime feature — perché ogni versione non aggiornata è un potenziale problema di ",[53,54,56],"a",{"href":55},"/blog/sicurezza-backend-produzione","sicurezza",".",[25,59,60],{},"Un progetto Laravel o React reale può facilmente arrivare a centinaia di dipendenze tra dirette e transitive. Anche un sito molto semplice può superare diverse centinaia di pacchetti installati. Pensi che stia esagerando il conteggio? Questo piccolo sito web ha un totale di 788 dipendenze tra dirette e transitive! Molte rilasciano aggiornamenti frequenti, alcune introducono breaking changes, e nel tempo possono emergere vulnerabilità.",[25,62,63],{},"Il tempo che il tuo team spende ad aggiornare dipendenze, verificare compatibilità, risolvere conflitti di versione e testare che nulla si sia rotto è tempo che non spende sulle feature. Ed è un costo ricorrente: non finisce mai.",[45,65,67],{"id":66},"vulnerabilità-nella-supply-chain","Vulnerabilità nella supply chain",[25,69,70],{},"Nel 2024, l'attacco a xz/liblzma ha dimostrato che un singolo maintainer compromesso può inserire una backdoor in una libreria usata da milioni di sistemi. Non è un caso isolato, ma un esempio concreto di quanto la supply chain open source possa essere un punto delicato.",[25,72,73],{},"Il tuo progetto dipende da centinaia di pacchetti. Tu verifichi quelli che installi direttamente. Ma verifichi anche le loro dipendenze? E le dipendenze delle dipendenze? Un attaccante non deve compromettere il pacchetto più popolare — basta una libreria di utility sepolta tre livelli sotto che nessuno guarda.",[25,75,76,79,80,83,84,87],{},[32,77,78],{},"npm audit"," e ",[32,81,82],{},"composer audit"," trovano le vulnerabilità ",[28,85,86],{},"note",". Quelle che non sono state ancora scoperte — o che sono state inserite intenzionalmente — passano inosservate.",[45,89,91],{"id":90},"il-rischio-di-abbandono","Il rischio di abbandono",[25,93,94,95,57],{},"L'open source dipende dalla volontà di individui. Maintainer che lavorano gratis nel tempo libero, che possono stancarsi, cambiare lavoro, o semplicemente perdere interesse. Quando un pacchetto viene abbandonato, hai tre opzioni: forkarlo e mantenerlo tu (costo enorme), migrare a un'alternativa (costo significativo), o restare su una versione non mantenuta (rischio crescente). Nessuna è gratuita. E se la dipendenza critica la conosce solo una persona nel team, hai anche un bel problema di ",[53,96,98],{"href":97},"/blog/bus-factor-developer-indispensabile","bus factor",[25,100,101],{},"E non parliamo di pacchetti oscuri. Librerie molto popolari sono state abbandonate, oppure hanno cambiato maintainer nel tempo senza che la maggior parte degli utilizzatori se ne accorgesse. Il tuo package-lock.json potrebbe contenere rischi di cui non sospetti l’esistenza.",[40,103,105],{"id":104},"meno-è-meglio-il-principio-della-dipendenza-minima","Meno è meglio: il principio della dipendenza minima",[25,107,108,109,112],{},"La soluzione è usare l'open source ",[28,110,111],{},"con consapevolezza",", non rinunciarci.",[45,114,116],{"id":115},"chiediti-mi-serve-davvero","Chiediti: mi serve davvero?",[25,118,119],{},"Prima di aggiungere una dipendenza, la domanda è: posso fare la stessa cosa con il linguaggio o il framework che ho già? Un pacchetto per formattare le date? Forse le API native del linguaggio bastano. Un pacchetto per validare le email? Spesso poche righe di codice ben scritte possono coprire il tuo caso d’uso senza introdurre un’ulteriore dipendenza. Un pacchetto per fare il left-pad di una stringa? Quella è una riga di codice.",[25,121,122],{},"Ogni dipendenza che non aggiungi è una dipendenza che non devi manutenere, aggiornare, e monitorare. Il codice più sicuro e più affidabile è quello che non esiste.",[45,124,126],{"id":125},"valuta-la-salute-del-pacchetto","Valuta la salute del pacchetto",[25,128,129],{},"Se decidi che una dipendenza serve, guardane prima lo stato reale. Conta quanti maintainer ha, perché se ne dipende uno solo il rischio di abbandono è alto. Guarda quando è stato aggiornato l’ultima volta: se l’ultimo commit è di un anno fa, vale la pena fermarsi un attimo. Controlla se esiste una policy di sicurezza e chiediti quante dipendenze transitive porta con sé, perché ogni pacchetto aggiuntivo aumenta il tuo livello di esposizione.",[45,131,133],{"id":132},"blocca-le-versioni","Blocca le versioni",[25,135,136,137,79,140,143],{},"Non fidarti di ",[32,138,139],{},"^",[32,141,142],{},"~"," nel tuo file di dipendenze. Un minor update \"compatibile\" può introdurre bug o cambiamenti di comportamento. Usa lockfile (sempre), e aggiorna manualmente con test dopo ogni update.",[45,145,147],{"id":146},"monitora-automaticamente","Monitora automaticamente",[25,149,150,151,154],{},"Attiva Dependabot su GitHub. Non per aggiornare automaticamente — per essere ",[28,152,153],{},"informato"," quando escono aggiornamenti e vulnerabilità. L'aggiornamento lo fai tu, consapevolmente, dopo aver testato.",[40,156,158],{"id":157},"il-costo-per-il-business","Il costo per il business",[25,160,161],{},"Per chi gestisce budget e roadmap, le dipendenze open source sono un costo operativo nascosto. C’è innanzitutto il tempo del team: aggiornare pacchetti, risolvere conflitti, gestire deprecation. In un progetto maturo questa attività può consumare una parte rilevante della capacità di sviluppo, anche se spesso non compare in nessun ticket visibile.",[25,163,164,165,57],{},"Poi c’è il rischio di incidenti. Una vulnerabilità critica in una dipendenza può costringere a un aggiornamento d’emergenza: il team lascia tutto quello che sta facendo, testa la compatibilità, deploya, e brucia un pomeriggio o una giornata intera. Quel tempo perso peggiora ancora di più le ",[53,166,168],{"href":167},"/blog/stime-sviluppo-sbagliate-perche","stime di sviluppo già fragili",[25,170,171],{},"Infine esiste un lock-in invisibile, cioè una dipendenza crescente da scelte fatte da altri. Più dipendenze hai, più il progetto è legato a decisioni di terzi. Quando un pacchetto cambia API, depreca feature o cambia licenza, devi adattarti ai loro tempi e alle loro scelte.",[40,173,175],{"id":174},"la-regola-pratica","La regola pratica",[25,177,178,179],{},"Per ogni dipendenza nel tuo progetto, dovresti poter rispondere a questa domanda: ",[28,180,181],{},"\"Se domani questo pacchetto sparisse, quanto ci costerebbe?\"",[25,183,184],{},"Se la risposta è “nulla, lo riscrivo in un’ora”, allora va bene averlo: ti sta davvero facendo risparmiare tempo. Se la risposta è “settimane di lavoro”, allora hai un rischio che dovresti gestire in modo attivo, con un fork interno, un piano di migrazione o almeno con una consapevolezza chiara di cosa perderesti. Se la risposta è “non lo so”, è il momento di scoprirlo prima che te lo faccia scoprire un problema in produzione.",{"title":186,"searchDepth":187,"depth":187,"links":188},"",2,[189,195,201,202],{"id":42,"depth":187,"text":43,"children":190},[191,193,194],{"id":47,"depth":192,"text":48},3,{"id":66,"depth":192,"text":67},{"id":90,"depth":192,"text":91},{"id":104,"depth":187,"text":105,"children":196},[197,198,199,200],{"id":115,"depth":192,"text":116},{"id":125,"depth":192,"text":126},{"id":132,"depth":192,"text":133},{"id":146,"depth":192,"text":147},{"id":157,"depth":187,"text":158},{"id":174,"depth":187,"text":175},"2026-01-27","Le dipendenze open source nel tuo progetto costano più di quello che pensi: manutenzione, sicurezza, rischio abbandono. npm install è gratis, il resto no.","md","/images/blog/dipendenze-open-source-costo-nascosto.jpg",{},"/blog/2026-01-27-dipendenze-open-source-costo-nascosto",{"title":20,"description":204},"Dipendenze open source: il costo nascosto nel progetto","dipendenze-open-source-costo-nascosto","blog/2026-01-27-dipendenze-open-source-costo-nascosto",[214,56,215,216,217],"open-source","dipendenze","npm","debito-tecnico",null,"3uEV4U18-9OpSQVklz3bwmQIRyGx4KdKDZklCByWV4w",{"id":221,"title":222,"body":223,"category":10,"date":424,"description":425,"extension":205,"image":426,"meta":427,"navigation":3,"path":428,"published":3,"seo":429,"seoTitle":430,"slug":431,"stem":432,"tags":433,"updated":218,"__hash__":436},"blog/blog/2026-01-06-sicurezza-backend-produzione.md","Sicurezza del backend: tre errori comuni e come mitigarli",{"type":22,"value":224,"toc":412},[225,228,231,239,242,246,249,252,255,258,261,265,268,272,275,278,282,285,288,294,298,305,308,312,315,318,330,334,337,346,352,362,366,374,377,383,387,393,396,399,402,405],[25,226,227],{},"La sicurezza backend è un tema che troppi team sottovalutano fino a quando non è troppo tardi. Dipendenze vecchie, configurazioni di sviluppo finite in produzione, secret messi ovunque come coriandoli: ecco come nasce un disastro, e come evitarlo anche se il tuo team non è formato da venti persone.",[25,229,230],{},"Parliamoci chiaro: se il tuo prodotto gira su un framework web moderno — Laravel, Django, Rails, Express, scegli tu — è molto probabile che il tuo server di produzione abbia dipendenze con vulnerabilità note. È una situazione più comune di quanto si pensi.",[25,232,233,234,238],{},"E la cosa peggiore? Probabilmente lo sapete già. Chi gestisce il tech pensa \"prima o poi aggiorniamo tutto\". Quel famoso task su Jira, \"",[53,235,237],{"href":236},"/blog/dipendenze-open-source-costo-nascosto","aggiornamento dipendenze","\", che ormai da sei mesi slitta di sprint in sprint. Nessuno lo mette mai tra le priorità, tanto non porta nessuna funzionalità visibile. Poi arriva quel martedì mattina in cui ti arriva una email che ti informa che il tuo token è stato revocato in quanto apparso su un repo Github privato, e il \"prima o poi\" si trasforma di colpo in \"doveva essere ieri\".",[25,240,241],{},"Questo articolo è per chi deve prendere decisioni su un prodotto software. È una triste storia vista troppe volte. E il finale, spesso, è lo stesso.",[40,243,245],{"id":244},"come-si-buca-un-server-nel-2026","Come si buca un server nel 2026",[25,247,248],{},"Lasciate stare l’immagine dell’hacker col cappuccio e la maschera di Guy Fawkes, lo schermo nero pieno di codice verde e il computer che fa bip-bip ogni volta che appare il testo. Gli attacchi di oggi sono spesso noiosi, metodici, e sfruttano la pigrizia di chi gestisce i server più che l’ingegno di chi li attacca.",[25,250,251],{},"Di solito funziona così. Un framework web famoso ha una libreria che si installa di default o perché serve per una feature secondaria. Esce una CVE critica, cioè una vulnerabilità di sicurezza riconosciuta e catalogata pubblicamente, tipo la recente CVE-2025-54068, che permette a un attaccante di eseguire codice sul server con una richiesta ben costruita. Il fix spesso esce in tempi brevi, e aggiornare di solito basta. Sei mesi dopo, capita di trovare server ancora sulla versione bucata.",[25,253,254],{},"L’attaccante non ha bisogno di essere un genio. L’exploit è pubblico, ci sono già gli script pronti. Scannerizza automaticamente migliaia di server, identifica versioni vulnerabili tramite fingerprinting e prova exploit già pronti. Spesso in tempi più rapidi di un vostro deploy, è già dentro.",[25,256,257],{},"Se riesce a eseguire codice o leggere file sul server, può accedere al file .env con tutte le variabili d’ambiente. Quel file è un tesoro per chi attacca: ci trova molto, dalle credenziali del database ai token API di GitHub, dalle chiavi AWS ai token del servizio di hosting, ai segreti OAuth. Informazioni critiche sulla tua infrastruttura possono trovarsi tutte concentrate in un unico file.",[25,259,260],{},"A quel punto diventa un disastro completo, ben oltre il \"semplice incidente di sicurezza\". Dovete cambiare tutte le credenziali esposte, controllare che non abbia installato backdoor, verificare che non abbia girato su altri server con i token rubati, avvisare chi va avvisato. Giorni di lavoro bruciati e la paranoia che qualcosa vi sia sfuggito.",[40,262,264],{"id":263},"le-tre-vulnerabilità-che-vedo-più-spesso-nei-backend","Le tre vulnerabilità che vedo più spesso nei backend",[25,266,267],{},"I disastri, per quello che ho visto, nascono spesso da tre errori ricorrenti. Presi singolarmente, si gestiscono. Ma insieme diventano una vera e propria kill chain.",[45,269,271],{"id":270},"_1-debug-attivo-in-produzione","1. Debug attivo in produzione",[25,273,274],{},"Ogni framework ha la modalità debug, cioè la configurazione che mostra molti dettagli tecnici utili a chi sviluppa. Quando la lasci attiva, in caso di errore mostra stack trace dettagliati, variabili d’ambiente, percorsi del filesystem, a volte informazioni sensibili che aiutano molto un attaccante. Serve tantissimo in sviluppo. In produzione, è come lasciare le chiavi di casa infilate nella porta con un post-it sopra: \"entrate pure\".",[25,276,277],{},"E succede più spesso di quanto si voglia ammettere. Un deploy fatto di corsa, un copia-incolla sbagliato del file di configurazione, un \"lo sistemo dopo\" che resta lì per mesi. E spesso nessuno se ne accorge, il sito continua a funzionare uguale — la modalità debug può passare inosservata all’utente normale, ma fornire informazioni molto utili a chi attacca. Per dire, mi è capitato di trovare due deploy fatti così in una settimana (non sto romanzando ai fini del post, sono serio!). Prima di mettere in produzione, controlla tutto due volte!",[45,279,281],{"id":280},"_2-dipendenze-fantasma","2. Dipendenze fantasma",[25,283,284],{},"Alcuni pacchetti possono registrare automaticamente route, endpoint o middleware senza che tu debba scrivere una riga di codice. È uno degli effetti collaterali dei framework moderni: tutto funziona subito.",[25,286,287],{},"Il problema è che queste route possono finire in produzione e diventare pubbliche, e tu magari non te ne accorgi nemmeno perché non le hai scritte tu. Alcuni pacchetti possono esporre endpoint o funzionalità accessibili via web senza che tu li abbia scritti direttamente.",[25,289,290,293],{},[28,291,292],{},"Quante route ha davvero il tuo server di produzione?"," Se pensi \"quelle che abbiamo scritto noi\", probabilmente ti sbagli. Fatevi un audit!",[45,295,297],{"id":296},"_3-i-segreti-nello-stesso-cestino","3. I segreti nello stesso cestino",[25,299,300,301,304],{},"Il file ",[32,302,303],{},".env"," è una comodità che ti si può ritorcere contro. Un unico file con dentro tutte le chiavi: database, cloud, API, servizi di deploy, OAuth. Se qualcuno mette le mani su quel file, può potenzialmente accedere a gran parte della tua infrastruttura. Se lì dentro c’è il token del tuo hosting, l’attaccante può entrare in più punti: leggere le variabili degli altri progetti, aggiungere SSH key, cambiare gli script di deploy, piazzare backdoor che possono resistere anche a pulizie superficiali.",[25,306,307],{},"Può bastare un solo file compromesso e, come niente, l’attaccante si trova la strada molto più aperta verso tutta l’infrastruttura. Se il server è già stato bucato, puoi ragionevolmente temere che quel file ora sia in mani sbagliate.",[40,309,311],{"id":310},"perché-la-sicurezza-viene-sempre-dopo","Perché la sicurezza viene sempre dopo",[25,313,314],{},"Arriviamo al punto dolente. Tutti e tre gli errori di cui ho parlato si risolvono in modo relativamente banale. Disattivare il debug può richiedere una sola configurazione. Aggiornare una dipendenza può essere questione di un comando. Vault per i segreti? Esiste già, e in molti casi basta integrarlo.",[25,316,317],{},"Il problema? Spesso non c'è tempo, mandato o voglia di farlo. Chi guida il tech ha almeno altre 15 priorità. Il team corre per consegnare la feature che il cliente aspetta da mesi. Nessuno metterà “aggiornamento librerie” in cima al backlog: non si vede, non si vende, non fa scena in demo.",[25,319,320,321,324,325,329],{},"La sicurezza è uno degli ambiti dell'ingegneria dove ",[28,322,323],{},"non fare nulla sembra andare benissimo"," — fino al giorno in cui tutto esplode, tutto insieme. È un po' come i ",[53,326,328],{"href":327},"/blog/costi-manutenzione-software","costi di manutenzione del software",": invisibili finché non ti presentano il conto. È come l’assicurazione sulla casa: è una spesa inutile. Finché non viene un alluvione.",[40,331,333],{"id":332},"cosa-fare-davvero-anche-senza-un-team-dedicato","Cosa fare davvero (anche senza un team dedicato)",[25,335,336],{},"Non ti serve un esercito. Bastano poche pratiche ben impostate che, una volta messe in piedi, continuano a lavorare da sole.",[25,338,339,340,342,343,345],{},"La prima è un gate automatico nella pipeline di deploy, cioè nella sequenza di controlli e passaggi che porta il codice in produzione. Prima di ogni rilascio deve esserci un controllo che faccia almeno due cose: verificare che non esistano CVE gravi note nelle dipendenze e controllare che le configurazioni sensibili siano corrette. Se qualcosa non va, il deploy si ferma. Se avete già una CI/CD, cioè un sistema che automatizza test e rilasci, aggiungere un ",[32,341,82],{}," o un ",[32,344,78],{}," può portarvi via poco tempo; se partite da zero servono alcuni giorni per farlo bene, ma poi quel controllo continua a lavorare in modo costante.",[25,347,348,349,351],{},"La seconda pratica è un audit mensile molto semplice. Non serve per forza un penetration test da migliaia di euro. Spesso basta dedicare mezz’ora al mese a lanciare ",[32,350,82],{}," o l’equivalente, controllare gli endpoint realmente esposti in produzione, verificare che debug ed error reporting siano configurati correttamente e attivare strumenti come Dependabot su GitHub. È un controllo leggero, ma evita molti problemi grossi.",[25,353,354,355,358,359,361],{},"La terza riguarda i secret. Tenerli tutti in un file di testo è comodo, ma non è una soluzione matura per la produzione. Meglio usare strumenti come AWS Secrets Manager e, quando possibile, attivare una ",[28,356,357],{},"rotazione automatica",". Se un secret viene rubato ma cambia ogni trenta giorni, l’attaccante ha una finestra molto più stretta per fare danni. Se invece resta nello stesso ",[32,360,303],{}," per due anni, il rischio cresce enormemente.",[40,363,365],{"id":364},"il-discorso-scomodo-per-chi-decide","Il discorso scomodo per chi decide",[25,367,368,369,373],{},"Se sei arrivato fin qui e prendi decisioni sul prodotto, questa parte è per te. Ogni sprint in cui rimandi la manutenzione di sicurezza, stai facendo debiti. Non è debito tecnico vago: sono interessi veri, in giorni persi a rimediare, costi legali se ci scappano dati personali, danni alla reputazione, e quella settimana in cui il team migliore non fa feature ma corre a ruotare chiavi e a cercare backdoor. E se pensi di risolvere ",[53,370,372],{"href":371},"/blog/aggiungere-sviluppatori-progetto","aggiungendo più sviluppatori"," alla gestione di una crisi in corso, il risultato è spesso l'opposto di quello sperato.",[25,375,376],{},"Il conto è abbastanza chiaro. Qualche giorno per impostare i controlli automatici, mezz’ora al mese per un audit. Dall’altra parte, una settimana di lavoro buttata per un incidente, più i soldi della notifica GDPR, più il danno d’immagine.",[25,378,379,382],{},[28,380,381],{},"Non è solo \"se\" succede. Spesso è \"quando\"."," E quel quando dipende anche da quanto è sveglio chi ti sta scannerizzando.",[40,384,386],{"id":385},"incident-response-cosa-fare-quando-ti-hanno-bucato","Incident response: cosa fare quando ti hanno bucato",[25,388,389,390,392],{},"Se sei qui perché il problema è già esploso, la prima cosa da fare è revocare tutto subito. Ogni token, ogni API key, ogni credenziale che era nel file ",[32,391,303],{}," va considerata compromessa. Non “appena riesci”: adesso.",[25,394,395],{},"Subito dopo vanno cambiate tutte le password e le credenziali dei servizi collegati. Se nel file c’erano token di Forge, DigitalOcean, Hetzner o servizi simili, devi partire dal presupposto che qualcuno possa già muoversi sui tuoi server. Guarda i log di accesso e controlla ogni servizio collegato.",[25,397,398],{},"Poi bisogna cercare le backdoor. Controlla cron job, chiavi SSH autorizzate, file modificati di recente. Chi entra in un sistema spesso prova a lasciarsi una strada aperta per tornare. E non fidarti mai della sensazione che “sembra tutto ok”: se non trovi niente, può semplicemente voler dire che non l’hai ancora trovato.",[25,400,401],{},"Infine scrivi tutto. Segna orari, azioni eseguite e ciò che hai scoperto. Ti servirà sia per ricostruire l’incidente sia, se ci sono dati personali coinvolti, per tutto ciò che riguarda la GDPR.",[25,403,404],{},"La prima reazione è mettere tutto a posto in fretta e poi far finta di niente. Ma resisti. Se fai le cose bene ora, eviti di ripetere lo stesso incubo tra tre mesi.",[25,406,407,408,411],{},"Il tuo backend non è una bomba a orologeria per colpa di come l’hanno progettato. ",[28,409,410],{},"Diventa davvero pericoloso soprattutto se lo trascuri."," E oggi, nel 2026, puoi automatizzare quasi tutta la fatica della manutenzione.",{"title":186,"searchDepth":187,"depth":187,"links":413},[414,415,420,421,422,423],{"id":244,"depth":187,"text":245},{"id":263,"depth":187,"text":264,"children":416},[417,418,419],{"id":270,"depth":192,"text":271},{"id":280,"depth":192,"text":281},{"id":296,"depth":192,"text":297},{"id":310,"depth":187,"text":311},{"id":332,"depth":187,"text":333},{"id":364,"depth":187,"text":365},{"id":385,"depth":187,"text":386},"2026-01-06","Sicurezza backend: vulnerabilità nelle dipendenze, secrets esposti e debug in produzione. Guida pratica per proteggere il tuo server.","/images/blog/sicurezza-backend-produzione.jpg",{},"/blog/2026-01-06-sicurezza-backend-produzione",{"title":222,"description":425},"Sicurezza backend in produzione: errori comuni e mitigazioni","sicurezza-backend-produzione","blog/2026-01-06-sicurezza-backend-produzione",[56,434,9,435],"backend","best-practice","L60YusAPF68P5dcsSTDpGPzVBA-NbNaKfB0PEL4yesI",1779395073446]