Build vs Buy: una PMI dovrebbe costruirsi lo stack di sicurezza?

Prima o poi ogni responsabile tecnico si trova davanti alla stessa domanda. C'è un bisogno di sicurezza da coprire - un SIEM, un EDR, della threat intelligence, un sistema di deception - e due strade: comprare un prodotto, o assemblarlo da componenti open source. I vendor hanno la risposta pronta ("compra il nostro"); i puristi dell'open source ne hanno un'altra ("costruisci tutto"). Sono entrambe sbagliate, perché la risposta giusta è "dipende" - e il fattore che decide non è quasi mai quello su cui tutti si fissano: il prezzo della licenza.

Il costo che vedi e quello che non vedi

La licenza è il costo visibile, ed è anche l'unico che di solito finisce nel confronto. Ma il costo vero di un sistema di sicurezza non è quanto lo paghi: è quanto ti costa possederlo nel tempo. Comprare sposta il costo dal tuo tempo al tuo portafoglio: paghi, e qualcun altro si occupa di aggiornamenti, integrazioni, sicurezza del prodotto, supporto a mezzanotte. Costruire fa l'opposto: azzeri la licenza e paghi in tempo, manutenzione e rischio. Il time-to-value, la curva di apprendimento, il bridge che si rompe al primo aggiornamento, la persona sola che sa come funziona tutto: sono costi reali, solo che non hanno una fattura. Chi confronta i prezzi di listino sta confrontando la parte sbagliata.

Quando comprare è la scelta giusta

Comprare vince più spesso di quanto a un ingegnere piaccia ammettere. Conviene quando la capability è una commodity: protezione delle email, baseline EDR, gestione dei dispositivi sono problemi risolti, e bene, da prodotti maturi - rifarli da zero è regalare tempo a una cosa che qualcun altro ha già chiuso. Conviene quando la compliance richiede un prodotto certificato, e una soluzione fatta in casa, per quanto buona, non porta il bollino che l'auditor vuole vedere. Conviene quando non hai ingegneria interna - o non hai la continuità per mantenerla nel tempo. E conviene quando il time-to-value conta più del controllo: se ti serve detection domani, non fra tre mesi, comprare è la risposta onesta.

Quando costruire (o assemblare) ha senso

Costruire vince quando il mercato non ti calza. Ogni responsabile che ha lavorato abbastanza a lungo conosce quel momento: l'integrazione che non esiste, il workflow che non si piega, il prezzo enterprise che per una PMI uccide il progetto prima ancora di iniziare. È lì che il "compra" smette di avere senso. Costruire conviene quando hai l'ingegneria e vuoi possedere il problema invece di aprire un ticket e aspettare; quando la capability è un differenziatore e non una commodity; quando il vendor lock-in è un rischio strategico reale; e - il caso più comune e sottovalutato - quando il vero valore non è un singolo tool ma incollare tool diversi tra loro.

Il terzo modo: assemblare, non reinventare

Qui sta il punto che la dicotomia "build vs buy" nasconde: i migliori stack di sicurezza non sono né completamente comprati né scritti da zero. Sono componenti open source maturi, cablati insieme con codice di integrazione tuo. Non scrivi un SIEM - prendi un SIEM provato e lo colleghi a un SOAR provato. Il lavoro di ingegneria, e il valore, è nella colla, non nei mattoni.

È esattamente come ho costruito le piattaforme con cui lavoro ogni giorno. Presidio, la piattaforma XDR, non contiene una riga di SIEM scritta da me: è Wazuh per la detection, Velociraptor per l'EDR, Shuffle per l'orchestrazione, DFIR-IRIS per i casi, MISP per la threat intelligence - sei sistemi open source solidi, tenuti insieme da bridge che ho scritto io. Lì sta il "build": non nel reinventare componenti che esistono già e funzionano, ma nel farli parlare in un modo che nessun prodotto chiavi-in-mano offriva al prezzo che una PMI può sostenere. Possiedi l'integrazione, non l'infrastruttura.

Il prezzo onesto del possedere il codice

Detto questo, chi ti vende il "costruisci tutto" come scelta sempre vincente ti sta nascondendo metà del conto. Quando costruisci o assembli, lo possiedi alle 3 di notte. Non c'è un vendor da chiamare quando un bridge si rompe in produzione: c'è il tuo sorgente, e ci sei tu. C'è il bus factor: se la persona che ha costruito tutto se ne va, chi lo mantiene? Ci sono gli aggiornamenti che rompono le integrazioni, la sicurezza della tua stessa colla, il debito tecnico che cresce in silenzio. La regola che mi porto dietro è semplice: non costruire ciò che non puoi mantenere. Costruire è una scelta che si paga per anni, non solo il giorno del deploy.

Una checklist per decidere

• Commodity o differenziatore? Se è un problema risolto e standard, compra. Se è ciò che ti rende diverso, valuta di costruire.
• Hai l'ingegneria - e la continuità? Non basta saperlo costruire oggi: serve qualcuno che lo mantenga quando chi l'ha fatto non c'è più.
• Qual è il TCO a tre anni? Somma licenza e tempo, manutenzione, on-call. Confronta i totali, non i prezzi di listino.
• Il prodotto si adatta davvero, o lo stai forzando? Piegare l'azienda al tool è un costo nascosto enorme.
• La compliance richiede un certificato? Se sì, una soluzione fatta in casa può non bastare a prescindere dalla qualità.
• Il lock-in è un rischio strategico? Se restare ostaggio di un vendor ti spaventa, l'assemblaggio open source ti ridà leva.

La lezione

"Build vs buy" è la domanda sbagliata. Quella giusta è: dove vuoi spendere - soldi, oppure tempo e responsabilità? Per una PMI il punto di equilibrio è quasi sempre lo stesso: compra ciò che è commodity, assembla e possiedi la colla per ciò che è strategico, e costruisci perché è l'unico modo per far calzare le cose - mai perché costruire dà soddisfazione. Il software che protegge la tua azienda non deve essere il più elegante: deve essere quello che, fra tre anni, sarai ancora in grado di gestire.