Una settimana fa su LinkedIN, chiedevo quale dei due modelli, open vs closed, desse il software più sicuro.

La domanda è assolutamente mal posta e serve solo per far nascere un brainstorming che, se non controllato, può degenerare nel più classico dei flame.

L’idea nasce dall’ennesima difesa a spada tratta fatta da una persona in un thread dove ho commentato, al grido di “l’opensource è più sicuro perché il codice è aperto”. Vero un paio di ciufoli.

Mi sono lanciato quindi in questa domanda acchiappaclick, 1300 views in realtà, neanche tante e 13 commenti, decisamente pochi per un wannabe-influencer de noartri, con lo scopo di far ragionare su una cosa tanto basilare quanto spesso ignorata: se il codice è a disposizione, ma nessuno ne fa una review, allora quel codice potrebbe avere problemi di sicurezza.

Da qui poi nasce il corollario: perché nessuno (o meglio, statisticamente in pochi) fa review di codice open?

1. costa
2. è time consuming
3. molti sedicenti security experts non hanno mai visto codice in vita loro

Dal thread che ne è seguito, sono saltati fuori spunti interessanti.

Secondo Giordano si deve, per prima cosa chiarire cosa si intende per “sicuro”. Assolutamente d’accordo. Diciamo che nella discussione, col termine “sicuro” indichiamo un software con “poche” vulnerabilità degne di nota usate in attacchi reali. Giordano poi conclude con un’opinione che condivido pienamente: “la mia opinione è che uno non sia migliore dell’altro”

Di questa stessa opinione, ovvero che i due modelli di sviluppo producono software di qualità equivalente dal punto di vista della security, se implementati in maniera egualmente rigorosa e soprattutto, una volta sul campo, amministrati in maniera competente, è anche Christian.

Disclaimer: Christian e Giordano sono miei amici di lunga data ed il primo è da sempre legato al mondo del software di casa Microsoft.

Antonio ha invece le idee molto chiare: “Open… tutti possono contribuire a trovare/fissare vulns…”. La mia seguente domanda è tuttavia rimasta senza risposta: è vero che tutti possono contribuire, ma quanti realmente lo fanno? In percentuale chi proattivamente fa code review sui tanti progetti opensource? Statisticamente pochi e la mancanza di risorse è il driver principale.

Non è economicamente, né professionalmente sostenibile un modello best effort dove faccio una code review quando capita a tempo perso.

Il mondo closed ha invece dei processi aziendali, con un proprio budget, per allocare risorse per affrontare il problema della sicurezza del codice. Non a caso, molto del materiale su threat modeling e ssdlc, nasce proprio dalla casa di Redmond.

Ma allora perché anche il codice proprietario, pur avendo risorse adeguate ha delle vulnerabilità?

Provo a buttarla lì: perché non è il modello di licenza quello che garantisce che il software sia sicuro o meno.

Secondo me quindi, ha davvero poco senso chiedersi se a priori un modello sia vincente sull’altro. Ha veramente tanto senso, mettersi a supportare i progetti upstream su Github o Gitlab e cercare e riportare issue di sicurezza, magari contribuendo con una patch. Allora sì che il modello open, assume un ruolo fondamentale.

Quando poi implementiamo il nostro software, assicuriamoci sempre di seguire linee guida di hardening: passo fondamentale per la messa in sicurezza di qualsiasi servizio.

Cosa faccio io di lavoro?

Da marzo 2021 lavoro in SUSE, come product security engineer. Al di là di avermi cambiato completamente la vita in meglio, mi ha permesso finalmente di arrivare in una società di prodotto, dove la security gioca un ruolo fondamentale.

Quello che faccio, insieme ai miei colleghi, è prendere il codice che sta per andare nella distribuzione, farne una revisione ed eventualmente entrare in contatto con gli sviluppatori nel caso alcune vulnerabilità vengano rilevate.

Parte quindi il processo di responsible disclosure che si conclude con la patch e con l’integrazione di quel particolare pacchetto nei repositori.

L’ho un po’ semplificata ma a grandi linee realizziamo sul supporto sul mondo open che permette di alzare un po’ l’asticella. Come noi anche le altre distribuzioni hanno team analoghi ma così come noi, anche i vendor di software con licenze proprietarie fanno esattamente la stessa cosa.

Di quello che succede nel mio mondo, spero di ricominciare presto con dei contenuti video.

Off by one

Quindi, la mia personale risposta alla domanda del flame del secolo è che non è il LICENSE.md del caso a rendere un software più sicuro di un altro e che, vero che il codice è lì, però bisogna anche guardarci e guardarci con competenza.

Voglio lanciare un’iniziativa per tutti i miei lettori. Prendete un progetto opensource a piacere, non serve sia enorme, anche una libreria che usate nel vostro lavoro.

Dedicate a questo progetto il 10% del vostro tempo settimanale, contribuendone alla sicurezza.

Scrivete poi un report su come è andata, condividetelo coi social usando l’hastag #takecarefoross, spargete la voce e cerchiamo di far crescere il numero di persone che contribuisce a tutto questo codice aperto che c’è nel mondo.

Vogliamo il codice sicuro? Allora collaboriamo!

Enjoy it.