[...]
L'open source è vitale per una varietà di attori (piccole imprese, no profit, scuola, ecc), 
credo che il fattore fiducia/sicurezza sia importante per tutti, e che questo si sia incrinato

Bisognerebbe riflettere sul fatto che questa presunta "frattura" sia da ricondurre ad una reale alterazione delle dinamiche del mondo F/OSS oppure, viceversa, ad una presa di coscienze delle relative dinamiche da parte di quelle stesse categorie di attori (piccole imprese, no profit, scuola, ecc.)

Dal mio punto di vista, quello che è recentemente accaduto _NON_ altera neanche di un epsilon lo scenario: il software è lo stesso. Chi lo sviluppa è lo stesso. Le forme di "controllo" di chi lo sviluppa, sono le stesse. _NON_ è cambiato nulla... salvo il fatto che qualche sviluppatore ha deciso di trasferire alcune sopravvenute acidita' di stomaco... sul codice che sviluppa.

Trovo particolarmente grave, da parte di chi usa quei software [indipendentemente dal fatto che ne sia cosciente o meno], che ci si accorga solo ora che --di fatto-- si è "dipendenti" di qualcuno che non si conosce... con il quale non si ha alcun rapporto di subordinazione/contrattuale... e che, proprio per questo, .... puo' fare benissimo come gli pare!
Prova ne è la numerosità di "easter-egg" noti da tempo [1]

Detto questo, non credo sia pratico né sostenibile leggersi il codice di tutti i componenti aperti che si vogliono riusare.

Non sarei cosi' tranciante. Sarà perché mi è capitato piu' volte di mettere le mani nei "sorgenti" di vari applicativi e librerie che uso... che l'idea di "guardare" e "capire", magari ex-ante... non la trovo affatto "da scartare".

Chiaramente è una questione di trade-off:

• se sto scrivendo il codice per supportare la tombolata del prossimo Natale, con tanto di Text-To-Speach, e quindi uso PERL e FESTIVAL... non mi preoccuperei troppo di un "bug". Mi basta una macro-occhiata ai parametri fondamentali di quello che uso [autore; eta' e versione delle librerie; data ultimo update; numero di commit; numero di contributori; etc. etc.]

viceversa...

• se sto contrattualizzando l'acquisto di un sistema missilistico con riconoscimento dei target, allora _VOGLIO_ avere accesso a tutto lo stack software utilizzato, fino ai disegni di tutti i PCB coinvolti ed al firmware di tutti i microcontrollori usati e di tutta la componentistica. L'obiettivo --fra gli altri-- sarebbe di verificare se --ad esempio-- chi mi vende il sistema non abbia (casualmente....) aggiunto delle feature che evitino la detonazione quando il target è nel paese del venditore (rilevato via coordinate simil-GPS, ad esempio)

o, senza arrivare a tanto:

• se sono una grossa software house (quelle di SOGEI? INPS? AGID? Dipartimento Innovazione?) allora _TUTTE_ le "dipendenze" dei miei software, dovrebbero stare "a casa mia" ed il processo di importazione/aggiornamento dovrebbe passare uno step di verifica esplicita. Insomma: non ti tiri giu' da Docker-Hub, GitHub o da NPM l'ultima release del componente e lo infili, senza colpo ferire, nel _TUO_ software. Quello che fai è: recupero i sorgenti, faccio il "diff", sottopongo il "diff" ad un umano e, quando questo umano preme un bottone... rimpacchetto il tutto e lo metto a disposizione per l'incorporazione.

Tutto questo è tecnicamente difficile? È organizzativamente difficile? ...non credo proprio. Di fatto, è "banalità". Basta solo _VOLERLO_ fare. Ovviamente soltanto _DOPO_ che si è _SAPUTO_ che è possibile farlo...

(Piccola nota a margine: questo approccio è _IMPOSSIBILE_ quando si utilizza software proprietario...)

Invece una via di mezzo dalla cieca adozione è analizzarli con strumenti che possano verificare qualità del software, 
inclusa la sicurezza, e poi testarli approfonditamente.

È certamente possibile automatizzare alcuni test di salubrita' del codice. E per software minimamente importanti potrebbero essere sufficienti. Non li vedo, pero', esaustivi: semplicemente rappresentano un punto sulla scala che va dal software non-critico al software super-critico:

• non critico: import diretto dall'esterno, senza controllo
• minimamente critico: import dall'esterno + verifica automatizzata del "diff"
• critico: import dall'esterno + verifica automatizzata del "diff" + notifica del "diff" a team di "revisione"
• molto critico: livello precedente, applicato anche alle componenti hardware

sull'ultimo punto --che a qualcuno potrebbe apparire eccessivo o, peggio, infattibile-- faccio notare che... Amazon, a suo tempo, lo fece... e trovo' cose interessanti [2]

Niente di impossibile quindi. Basta solo volerlo/doverlo fare...

Bye,
DV

[1] https://en.wikipedia.org/wiki/Easter_egg_(media)#Software

[2] https://www.bloomberg.com/news/features/2018-10-04/the-big-hack-how-china-used-a-tiny-chip-to-infiltrate-america-s-top-companies

recentemente ripreso e sviluppato anche qui:

https://www.bloomberg.com/features/2021-supermicro/

-- 
Damiano Verzulli
e-mail: damiano@verzulli.it
---
possible?ok:while(!possible){open_mindedness++}
---
"...I realized that free software would not generate the kind of
income that was needed. Maybe in USA or Europe, you may be able
to get a well paying job as a free software developer, but not
here [in Africa]..." -- Guido Sohne - 1973-2008
   http://ole.kenic.or.ke/pipermail/skunkworks/2008-April/005989.html