--- title: "Supply chain del software nel 2026: lezioni da xz-utils, tj-actions e il threat model che applico alle PMI PHP/Node" description: "Dalla backdoor xz-utils al compromise di tj-actions marzo 2025: cinque regole di supply chain security che applico alle PMI italiane nel 2026 su PHP, Node e CI." canonical: "https://www.mauriziofonte.it/blog/post/attacchi-supply-chain-software-minacce-flusso-sviluppo-protezione-pmi-cybersecurity.html" author: "Maurizio Fonte" date: "2025-06-04T11:23:43+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Sicurezza Applicazioni" tags: ["Sicurezza Applicazioni", "Penetration Testing"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) # [Supply chain del software nel 2026: lezioni da xz-utils, tj-actions e il threat model che applico alle PMI PHP/Node](https://www.mauriziofonte.it/blog/post/attacchi-supply-chain-software-minacce-flusso-sviluppo-protezione-pmi-cybersecurity.html) Mercoledì 4 Giugno 2025, alle 11:23 ![Supply chain del software nel 2026: lezioni da xz-utils, tj-actions e il threat model che applico alle PMI PHP/Node](https://www.mauriziofonte.it/image/001660200-attacchi-supply-chain-software-minacce-flusso-sviluppo-protezione-pmi-cybersecurity.jpg) Il 29 marzo 2024, alle 19:32 ora italiana, mi ha scritto su Telegram il CTO di un cliente che segue una piattaforma e-commerce B2B in Laravel su server Debian 12: "Maurizio, ho appena letto della backdoor di xz-utils, siamo affected? Ho `liblzma` linkata in `systemd-resolved` e `sshd` sta aperto su 22". Ho passato le successive quattro ore a rispondere alla stessa domanda per sei clienti diversi. Nessuno di loro - per fortuna - girava `xz` 5.6.0 o 5.6.1 perché Debian 12 stable era ancora su 5.4.1; la backdoor di [Jia Tan documentata da Andres Freund sulla mailing list oss-security](https://www.openwall.com/lists/oss-security/2024/03/29/4) non li aveva toccati. Ma ho capito quella sera che la mia concezione di "supply chain security" era vecchia di dieci anni: fino ad allora pensavo alla supply chain come "le dipendenze del mio Composer lock"; dopo quella notte l'ho dovuta ridefinire come "l'intera catena di fiducia che porta un byte dal cervello di uno sviluppatore al processo che gira in produzione sul mio server". Nei diciotto mesi che sono seguiti, quella definizione è stata messa alla prova due volte ancora: dal compromise di tj-actions/changed-files del marzo 2025 che ha esposto i secrets di centinaia di pipeline GitHub Actions, e da una sfilza di incidenti minori - Polyfill.io, Ultralytics, pacchetti npm di Solana - che hanno tutti in comune una cosa. L'attaccante non ha sfruttato un bug in una libreria: si è inserito *prima* nel flusso che produce la libreria. Questo articolo raccoglie le lezioni operative che ho estratto da questi due anni, e il threat model che oggi propongo a ogni PMI italiana che voglia seriamente mettere in sicurezza la propria catena di build senza diventare paranoica. ## xz-utils (CVE-2024-3094): due anni di social engineering e il bypass del code review La cosa importante di xz-utils non è la backdoor in sé - quella è tecnicamente elegante ma ormai nota. La cosa importante è *come* è entrata nel codice, perché quel metodo è ripetibile e quasi certamente in corso su altri progetti mentre scrivi queste righe. L'account "Jia Tan" ha iniziato a contribuire a `xz` nel 2021, partecipando alla mailing list, proponendo patch ragionevoli, guadagnando la fiducia di Lasse Collin, il manutentore unico (e sovraccaricato) del progetto. Dopo circa due anni di contributi legittimi, Jia Tan è diventato co-manutentore. Poi, nel febbraio 2024, ha rilasciato le versioni 5.6.0 e 5.6.1 con una backdoor nel tarball di release - *non nel repository git*. La backdoor era nascosta in un file binario di test (`bad-3-corrupt_lzma2.xz`), scompattato e attivato da uno script di build che rendeva [praticamente impossibile individuarla leggendo il sorgente su GitHub](https://research.swtch.com/xz-timeline), perché su GitHub il tarball malevolo non c'era. La backdoor è stata scoperta per puro caso. Andres Freund, engineer di PostgreSQL presso Microsoft, stava facendo benchmark su PostgreSQL e ha notato che `sshd` consumava il 600% di CPU in più del normale e che `ssh localhost` aveva un ritardo di circa 500 millisecondi. Con una sensibilità che molti sviluppatori non hanno, invece di dire "strano" e passare oltre, è andato a fondo. Ha scoperto che `liblzma` (parte di xz-utils) era linkata indirettamente in `sshd` su Debian tramite il patch di `libsystemd`, e che la backdoor hookava una funzione di autenticazione di OpenSSH permettendo a chi avesse la chiave privata corretta di bypassare tutto. L'[entry NIST NVD per CVE-2024-3094](https://nvd.nist.gov/vuln/detail/CVE-2024-3094) assegna CVSS 10.0 - il punteggio massimo. Le lezioni di xz-utils per una PMI sono tre, e nessuna di esse è "patcha velocemente" (che è ovvia): 1. **Il code review su GitHub non è sufficiente se il tarball di release è diverso dal repository.** L'unico modo di rilevare questa classe di attacchi è *build from source* direttamente dal tag git verificato, non dal tarball pubblicato. Oppure, più realisticamente per una PMI: consumare solo package della distro (Debian stable, Ubuntu LTS) che fanno loro questa verifica, oppure pre-compilare internamente da git. 2. **Le dipendenze transitive sono la tua vera superficie di attacco.** Nessuno dei clienti che avevo installa `xz-utils` esplicitamente; ce l'avevano tutti perché `systemd` lo tira dentro. Il tuo `composer.json` o `package.json` di primo livello è la punta dell'iceberg. Un SBOM completo ti mostra l'iceberg intero. 3. **I progetti open source con un manutentore singolo e sovraccarico sono un risk pattern.** Non è colpa dei manutentori: è un problema strutturale della community open source, dove critical infrastructure è mantenuta da volontari non pagati e quindi vulnerabile a social engineering mirato da attaccanti che possono investirci anni. Nel triage della tua supply chain, contare i "bus factor" dei progetti critici è diventato uno standard. ## tj-actions/changed-files, marzo 2025: quando un GitHub Action compromesso espone 200+ repository Il 14 marzo 2025 GitHub Security Lab ha pubblicato un advisory su un compromise del popolare action `tj-actions/changed-files` (usato da 23.000+ repository all'epoca) in cui un attaccante aveva ottenuto il controllo di un personal access token del manutentore, aveva pushed un commit malevolo al tag `v35` (che puntava a un SHA non verificato) e aveva modificato l'action per dumpare i secrets della pipeline in chiaro nei log di GitHub Actions di chiunque la eseguisse. L'attacco è stato scoperto in circa 24 ore perché alcuni utenti hanno notato output strani nei log, ma nel frattempo si stima che almeno 200 organizzazioni abbiano eseguito la versione compromessa con i loro secrets (AWS keys, Docker Hub tokens, npm publish tokens, e altro) finiti in log pubblici di repository open source. Il pattern di attacco è importante perché la fix apparentemente ovvia - "pin il tag" - non funziona. Quasi tutti i tutorial di GitHub Actions dicono di usare `uses: tj-actions/changed-files@v35`, dove `v35` è un tag mobile che il manutentore può spostare in qualsiasi momento. Quando l'attaccante controlla l'account del manutentore (o si inserisce come maintainer via social engineering come in xz), può spostare `v35` su un commit malevolo e ogni pipeline che fa un pull fresco prenderà la versione compromessa. **L'unica mitigation reale è pinnare all'hash SHA-1 del commit**, non al tag: ```yaml - uses: tj-actions/changed-files@0f3f1ed45c3f1b48f96d2f3f2bf9e6d8c1a4e2b7 # v35.7.2 ``` Questo pattern ha un costo: ogni dependabot update deve verificare l'hash, e gli upgrade sono più rumorosi. Ma è l'unico modo di dire veramente "voglio *questo* codice esatto, niente sostituzioni". Per i miei clienti PMI che usano GitHub Actions ho consolidato questa regola come hard gate: niente tag mobili nei workflow di CI, mai. La lezione più grande di tj-actions è che la CI è parte della supply chain allo stesso titolo del codice applicativo. Se la tua GitHub Actions ha accesso a `AWS_ACCESS_KEY_ID` nell'environment, un action compromesso li può esfiltrare. Se ha accesso a `NPM_TOKEN` per pubblicare, un action compromesso può pubblicare malware a tuo nome sul registry. L'incident di [tj-actions è trattato in profondità nel mio articolo sulla minimizzazione dei repository git e dei rischi dei git hooks](https://www.mauriziofonte.it/blog/post/minacce-repository-git-hooks-alias-difesa-pmi-cybersecurity.html), dove spiego come un pre-commit hook può essere trasformato in RCE con tre righe. ## SBOM, SLSA e provenance: perché nel 2026 "ho il lockfile" non è più sufficiente Fino al 2023 il mio baseline per una PMI era "commit del `composer.lock`, commit del `package-lock.json`, `composer audit` in CI, dependabot o renovate per gli update". Nel 2026 questo non è più sufficiente, e i motivi sono due: il lockfile verifica cosa installerai la prossima volta che fai `composer install`, ma non dice nulla sulla provenance del codice (chi l'ha prodotto? è il tarball originale o è stato manipolato?); e il lockfile non copre la pipeline di build, solo le dipendenze runtime. xz-utils ha aggirato il primo livello (il tarball era diverso dal repository), tj-actions ha colpito il secondo (le dipendenze della build, non del runtime). Il framework di riferimento che ho adottato si chiama [SLSA - Supply-chain Levels for Software Artifacts](https://slsa.dev/), un'iniziativa della Open Source Security Foundation che definisce quattro livelli di assurance per la supply chain. Senza entrare nei dettagli, il livello SLSA 2 richiede che ogni build sia riproducibile e firmata da una sorgente verificabile (tipicamente, i logs di GitHub Actions con Sigstore). Il livello SLSA 3 aggiunge la non-forgeability della provenance. Per una PMI italiana, l'obiettivo realistico è SLSA 2 sui progetti critici - niente più di questo, perché SLSA 3/4 richiede infrastrutture dedicate che solo grandi organizzazioni possono permettersi. Il secondo strumento operativo è il **SBOM** (Software Bill of Materials), ovvero un elenco formale di tutte le dipendenze - dirette e transitive - con versioni, hash, e provenance. Il formato standard de facto è [CycloneDX](https://cyclonedx.org/), e per PHP/Composer il tool `cyclonedx-php-composer` genera un SBOM in JSON partendo dal `composer.lock`; per Node esiste `@cyclonedx/cyclonedx-npm`. Il pattern che applico in CI è: genera il SBOM a ogni build, confrontalo col precedente, fallisci la build se sono comparse dipendenze nuove senza approvazione esplicita. Questo trasforma il classico `composer install` da operazione "silenziosa" in un gate di review obbligatorio. La combinazione SBOM + osv-scanner + diff CI è dettagliata per il versante Composer nel mio [playbook supply chain security per Laravel e Symfony](https://www.mauriziofonte.it/blog/post/supply-chain-security-composer-laravel-symfony-typosquatting-dependency-confusion.html), che include anche le policy `allow-plugins` e il blocco degli script in CI - altri due vettori di attacco che il lockfile da solo non mitiga. ## Cinque regole operative che applico su ogni cliente PMI dal 2025 Dopo xz-utils, tj-actions e una manciata di incidenti minori, ho consolidato cinque regole che applico a ogni nuovo progetto PMI e a ogni audit di legacy infrastructure. Non sono "best practice teoriche" - sono il livello minimo sotto il quale mi rifiuto di firmare una consegna. 1. **Pin hash, non tag.** Ogni dipendenza di CI (GitHub Actions, GitLab CI include, Jenkins shared libraries) deve essere pinnata all'hash SHA, non al tag mobile. Dependabot/renovate configurati per proporre aggiornamenti in PR che il team approva manualmente - niente auto-merge, nemmeno per "patch releases". Il costo operativo è tollerabile, il ritorno è infinito. 2. **Proxy registry privato con lista di allow esplicita.** Per Composer uso un Satis o un [Packagist.com privato; per npm uso Verdaccio o Nexus come proxy. Tutto il traffico di `composer install` e `npm install` passa per il proxy, che ha una whitelist di package autorizzati. Un `composer require nuovo/pacchetto` non funziona finché un senior non lo approva nella whitelist del proxy. Questo blocca sul nascere il 90% degli attacchi di typosquatting e dependency confusion. 3. **Secrets scanning bloccante su pre-commit e CI.** `gitleaks` su pre-commit client-side, e `gitleaks` come gate bloccante in CI. Nessun secret in git, mai. Se uno scappa, la CI fallisce, il commit non arriva a main, e parte una rotazione immediata. Il mio hook gitleaks è configurato per rilevare anche i token GitHub e Docker Hub anche quando sono offuscati con base64 triviale. 4. **Dependency review obbligatoria in PR.** GitHub ha un'action `dependency-review-action` che blocca le PR se introducono dipendenze con CVE noti o con licenze non whitelisted. Integrata con CVE database multipli (NIST NVD, OSV, GitHub Advisory Database) per ridurre il single-point-of-failure dopo la [crisi del sistema CVE di aprile 2025](https://www.mauriziofonte.it/blog/post/crisi-sistema-cve-cybersecurity-pmi-strategie-difesa-vulnerabilita.html). Se il gate blocca, la PR non si merge. 5. **SBOM versionato come artifact di release.** Ogni release di produzione produce un SBOM CycloneDX che viene salvato in un bucket di artifacts separato, con retention 5 anni. Questo è fondamentale per la parte "obblighi di documentazione" della NIS2 art. 21: in caso di incidente, devi poter rispondere alla domanda "quale versione di quale libreria girava in produzione il giorno X?" senza dover ricostruire il deploy a memoria. Queste cinque regole insieme alzano il costo di un attacco alla supply chain di un ordine di grandezza senza richiedere investimenti infrastrutturali significativi. Il tempo di setup iniziale è circa 3-5 giorni per un progetto PMI medio; l'overhead operativo dopo è marginale - un'ora la settimana per review delle PR di dependency update. ## Il threat model che propongo: quattro perimetri anziché uno L'errore mentale più frequente che vedo nei clienti è pensare alla supply chain come a un'unica entità monolitica. In realtà sono *quattro perimetri distinti*, ognuno con attaccanti, motivazioni e mitigations diverse. Quando faccio un audit di supply chain security, chiedo al team di mappare il rischio separatamente su ognuno: - **Perimetro 1: dev endpoint.** Le workstation degli sviluppatori. Attacco tipo: estensioni VS Code malevole, `npm install -g` senza verification, credenziali GitHub esposte. Mitigation: MDM sui laptop, password manager aziendale, U2F hardware key per GitHub, controllo delle estensioni IDE via policy. Per le PMI italiane questa parte è spesso la più trascurata perché "tanto siamo in 5". I 5 laptop sono 5 porte d'ingresso. - **Perimetro 2: SCM (git repository).** Attacco tipo: repo jacking, push di commit non firmati, compromise di account di maintainer. Mitigation: branch protection rules con required reviewers e required signed commits, CODEOWNERS, audit log di GitHub con alert su eventi sensibili, SSO + SCIM per onboarding/offboarding automatico, U2F obbligatorio per tutti. - **Perimetro 3: registry (Composer/npm/Docker Hub).** Attacco tipo: typosquatting, dependency confusion, package planting, compromise di maintainer. Mitigation: proxy privato con whitelist, lockfile + hash, `composer audit` e `npm audit` e `osv-scanner` in CI, policy `allow-plugins` esplicita per Composer, `--ignore-scripts` in CI. - **Perimetro 4: CI/CD.** Attacco tipo: GitHub Actions compromessi, runners self-hosted compromessi, secrets esfiltrati dai log, poisoned build cache. Mitigation: actions pinnate ad hash, runners effimeri (mai self-hosted persistenti per progetti open source!), secrets scoped al minimo privilegio possibile, OIDC federation verso cloud provider invece di long-lived keys, audit log dei workflow run. Il runtime non è un perimetro di *supply chain* - è il perimetro di *application security*. Una volta che il codice è in produzione, i rischi sono altri (SQL injection, XSS, broken authentication). La supply chain si ferma al momento in cui l'artifact è deployato, ed è su quello che devo garantirne l'integrità. Per il pezzo successivo della catena - cosa fare quando qualcosa va storto - rimando al mio [piano di incident response in 72 ore per Laravel e Symfony allineato a NIS2](https://www.mauriziofonte.it/blog/post/incident-response-72-ore-laravel-symfony-nis2-pmi.html), che copre il flusso di contenimento, forensics e comunicazione post-breach. La sicurezza della supply chain del software non è un problema che si risolve comprando un tool. È un cambio di postura: passare da "mi fido del mio lockfile" a "verifico l'integrità di ogni byte dalla sorgente al runtime, e ho un audit trail per dimostrarlo". Per una PMI italiana nel 2026, questo cambio è diventato obbligatorio non solo per ragioni di rischio reale ma anche per conformità a NIS2, al Cyber Resilience Act e agli obblighi contrattuali con i clienti enterprise che sempre più spesso richiedono evidenza documentata delle pratiche di secure development. L'integrazione di queste pratiche nel flusso di sviluppo quotidiano è quello che chiamo [DevSecOps operativo](https://www.mauriziofonte.it/blog/post/devsecops-integrare-sicurezza-sviluppo-azienda.html), e sul versante hardening applicativo si salda con la mia [checklist NIS2-ready per Laravel e Symfony](https://www.mauriziofonte.it/blog/post/hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.html). Se la tua PMI sviluppa o mantiene software in PHP, Laravel, Symfony o Node, e non hai ancora fatto un audit serio della tua supply chain - dai dev endpoint fino all'artifact in produzione - [scopri come lavoro con i clienti su questi temi](https://www.mauriziofonte.it/pages/about): dieci anni di consulenza a PMI italiane mi hanno insegnato che la supply chain è il rischio più sottostimato e più asimmetrico che esiste, perché un incident può fermare tutta l'operatività per settimane mentre la prevenzione costa giorni. Se vuoi partire con un audit concreto del tuo flusso di sviluppo e delle tue dipendenze, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami): in due settimane di lavoro ti consegno mapping completo dei quattro perimetri, SBOM di tutti i progetti critici, piano di adozione delle cinque regole con tempistiche realistiche per il tuo team. Dall'articolo al lavoro vero Questo problema di sicurezza, sul tuo sistema Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti. [Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteregreSSHion (CVE-2024-6387) un anno e mezzo dopo: anatomia tecnica, lezioni dalla patching delle PMI e hardening SSH che applico oggi4 Giugno 2025](https://www.mauriziofonte.it/blog/post/vulnerabilita-critica-openssh-analisi-tecnica-race-condition-protezione.html)[Articolo successivo »Architettura cybersecurity per PMI: cinque principi che spiego a ogni nuovo cliente (e uno che uccide chi ci crede)5 Giugno 2025](https://www.mauriziofonte.it/blog/post/architettura-cybersecurity-pmi-principi-fondamentali-difesa-sicurezza-informatica.html) ### Articoli correlati a Supply chain del software nel 2026: lezioni da xz-utils, tj-actions e il threat model che applico alle PMI PHP/Node - [Supply chain security con Composer per Laravel e Symfony: come prevenire typosquatting, dependency confusion e script malevoli](https://www.mauriziofonte.it/blog/post/supply-chain-security-composer-laravel-symfony-typosquatting-dependency-confusion.html) Dopo la backdoor xz utils e il compromise di tj actions del 2025, ho auditato le dipendenze Composer di 12 clienti PHP: 3 avevano pacchetti con · 24 Settembre 2025 ![Supply chain security con Composer per Laravel e Symfony: come prevenire typosquatting, dependency confusion e script malevoli](https://www.mauriziofonte.it/image/002200070-supply-chain-security-composer-laravel-symfony-typosquatting-dependency-confusion.jpg) - [CI/CD sicuro: proteggere la pipeline da injection e supply chain attack](https://www.mauriziofonte.it/blog/post/cicd-sicuro-proteggere-pipeline-injection-supply-chain-attack.html) Le pipeline CI/CD sono diventate un vettore di attacco privilegiato: compromettere un'action GitHub condivisa significa comprometterne tutti · 28 Gennaio 2026 ![CI/CD sicuro: proteggere la pipeline da injection e supply chain attack](https://www.mauriziofonte.it/image/003160070-cicd-sicuro-proteggere-pipeline-injection-supply-chain-attack.jpg) - [Supply chain security di applicazioni AI: pinning dei modelli, audit di Langchain e LlamaIndex, integrity checks](https://www.mauriziofonte.it/blog/post/supply-chain-security-ai-pinning-modelli-audit.html) L'ecosistema AI è diventato un target di supply chain attack: modelli pubblicati su Hugging Face con backdoor, librerie Langchain/LlamaIndex · 10 Marzo 2026 ![Supply chain security di applicazioni AI: pinning dei modelli, audit di Langchain e LlamaIndex, integrity checks](https://www.mauriziofonte.it/image/003940070-supply-chain-security-ai-pinning-modelli-audit.jpg) - [Container image security: vulnerabilità nelle immagini Docker che usi ogni giorno](https://www.mauriziofonte.it/blog/post/container-image-security-vulnerabilita-docker-produzione.html) Un'immagine Docker pinnata a un tag e mai più ricostruita accumula decine di CVE nelle librerie di sistema, anche se il tuo codice PHP è impeccabile. · 2 Gennaio 2026 ![Container image security: vulnerabilità nelle immagini Docker che usi ogni giorno](https://www.mauriziofonte.it/image/003200070-container-image-security-vulnerabilita-docker-produzione.jpg) - [Crisi del sistema CVE un anno dopo: cosa è cambiato per la cybersecurity delle PMI nel 2026 e come ridurre la dipendenza da MITRE](https://www.mauriziofonte.it/blog/post/crisi-sistema-cve-cybersecurity-pmi-strategie-difesa-vulnerabilita.html) Un anno dopo la quasi shutdown del programma CVE/MITRE del 16 aprile 2025, il finanziamento è stato rinnovato ma la fragilità strutturale resta. · 3 Giugno 2025 ![Crisi del sistema CVE un anno dopo: cosa è cambiato per la cybersecurity delle PMI nel 2026 e come ridurre la dipendenza da MITRE](https://www.mauriziofonte.it/image/001650070-crisi-sistema-cve-cybersecurity-pmi-strategie-difesa-vulnerabilita.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Supply chain del software nel 2026: lezioni da xz-utils, tj-actions e il threat model che applico alle PMI PHP/Node", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/attacchi-supply-chain-software-minacce-flusso-sviluppo-protezione-pmi-cybersecurity.html Pubblicato: 2025-06-04 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.