“Ma chi vuole attaccare proprio noi?”

Te l’hanno mai detta questa frase? Scommetto di sì. Magari seguita da: “Siamo on-premise dai clienti, siamo già protetti.” È una di quelle convinzioni che senti ripetere nelle riunioni, nei corridoi, davanti alla macchinetta del caffè.

Il problema è che, quando si parla di sicurezza, tendiamo a immaginare sempre lo stesso scenario: il generico criminale informatico che cerca di bucare il nostro sistema sfruttando qualche vulnerabilità nel codice. Come se la sicurezza fosse solo una questione di difendersi dai “cattivi di fuori”.

Nelle software house tradizionali, la sicurezza viene trattata come quel parente scomodo che inviti solo alle occasioni importanti. Magari poco prima di una release, quando il cliente chiede il famoso “documento di sicurezza”. O quando arriva l’audit di compliance e improvvisamente tutti scoprono che servono policy, procedure e checklist.

Ti ricorda qualcosa? È lo stesso approccio che avevamo con i deployment prima che arrivasse DevOps. “Un modo per installare il software sui server lo troviamo”, “Massì, ci pensa Ops”. E così buttavamo l’applicazione “di là dal muro”, convinti che i sistemisti avrebbero fatto miracoli.

Sappiamo tutti com’è andata a finire: colli di bottiglia infiniti, notti insonni per problemi in produzione e utenti delusi.

DevOps ci ha insegnato che collaborazione e automazione eliminano questi anti-pattern. Che la responsabilità deve essere condivisa, non delegata.

Ecco il punto: con la sicurezza stiamo facendo gli stessi errori, ma le conseguenze sono molto più gravi. Se un deployment va male, al massimo hai un downtime e qualche cliente arrabbiato. Se sbagli con la sicurezza, rischi compromissioni sistemiche, perdite di dati, danni che possono affossare un’azienda e magari danni reputazionali per data leak e problemi di compliance sulla privacy (es.: GDPR).

Nei prossimi messaggi esploreremo come integrare la sicurezza nel tuo processo di sviluppo in modo sostenibile. Non come un controllo esterno che rallenta tutto, ma come una pratica nativa che diventa parte del DNA del team.

Sharing is caring

Se conosci qualcuno che potrebbe trovare utile ricevere e-mail per migliorare l’organizzazione dei team di sviluppo software, DevOps e software engineering in generale inoltragli questo post! Qui può iscriversi e cominciare a ricevere subito!