Molti team trattano il container come una sandbox di sicurezza, ma per default non lo è. I vettori di escape su Docker: privileged mode, socket Docker montato, capability eccessive, namespace condivisi. Come un attaccante esce dal container verso l'host e l'hardening che lo previene: user namespace, capability minime, seccomp, read-only filesystem. Dalla prospettiva offensiva, per capire cosa difendere davvero in una infrastruttura containerizzata. 
La pipeline di deploy ha accesso a segreti, registry e produzione, eppure viene trattata con meno attenzione del codice applicativo. I vettori d'attacco reali sul CI/CD: workflow injection, segreti esposti nei log, dipendenze di action non pinnate, escalation da una pull request. Come un attaccante usa la pipeline per arrivare in produzione e le contromisure concrete: least-privilege dei token, CODEOWNERS sui workflow, pinning e isolamento dei runner. 
Quando colleghi un'applicazione a un identity provider, ogni utente locale guadagna una colonna con l'identificativo esterno. Quella colonna è preziosa e fragile: costa migliaia di chiamate API per essere ricostruita, e applicarla alla riga sbagliata assegna l'identità di una persona a un'altra. Come l'ho portata fra ambienti diversi con un file di poche decine di kilobyte, una guardia che aborta invece di indovinare, e un'operazione ripetibile senza conseguenze. 
L'AI scrive codice che passa i test, sembra pulito, esce in produzione. Ma quando alle 2 del mattino il sistema cade, nessuno sa più cosa stiamo guardando. Il debito tecnico lo vedi: lo accetti come scelta. Il debito di comprensione no, cresce silenzioso, e la sua compounding rate è la cosa più sottovalutata del coding 2026. Continua a leggere
PMI manifatturiera Piemonte (DA 2.000.000 EUR). Refactoring incrementale Laravel 5 → 11 in 4 mesi senza fermo produzione, su gestionale interno usato da 30 utenti operativi.
- Response time 350ms → 80ms al 95° percentile
- Deploy time 25 min → 90 sec
- Zero incidenti post-migrazione
Quando misuri l'AI coding solo sull'output dei junior, sembra un boom di produttività. Quando misuri il sistema intero, la realtà cambia: il 45% del codice AI ha falle di sicurezza, i senior perdono il 19% di produttività riassorbendo il debito, i junior smettono di costruire i modelli mentali che li renderebbero senior domani. Il sistema si squilibria sotto la velocità apparente. 
Scrivi una spec, lasci che l'AI la trasformi in codice, e quando qualcosa non va riapri solo la spec. È seducente. Non funziona: ogni iterazione produce codice peggiore. Il problema non è la spec, è che mancano le ossa del design su cui appoggiarla. Design concept, ubiquitous language, TDD: tre discipline pre-AI che oggi contano di più, non di meno. 
L'ingegnere che l'AI sostituisce non è quello che fa il lavoro che l'AI può fare. È quello che non ha mai costruito il giudizio per riconoscere quando l'AI sbaglia. Il riposizionamento da autore di codice a intent manager non è una concessione, è la skill tecnica che decide chi sopravvive a questa transizione di carriera. 
Architetture pensate per umani aiutano l'AI di più di architetture pensate per l'AI. Moduli profondi con interfacce semplici. AI integrata come dependency lenta e non deterministica, dietro circuit breaker e fallback. E la verità che spinge il mercato in direzione opposta: il debito accumulato oggi non sarà refactorato da nessun modello futuro, perché refactoring richiede intent originale, non sintassi. 
NIS2 è molto più di un acronimo o di un insieme di articoli di legge: è un imperativo strategico per le aziende europee nell'era digitale. Immagina NIS2 come uno scudo protettivo digitale, un "aggiornamento di sistema" obbligatorio nell'evoluto mondo delle tecnologie Cloud e della estrema informatizzazione della quasi totalità dei processi aziendali.