Una nuova speranza per la sicurezza del software

Di Matt Asay

Collaboratore, InfoWorld |

La vulnerabilità Log4j nel dicembre 2021 ha messo in luce la catena di fornitura del software come un’area di sicurezza ampiamente trascurata. Ha rivelato quanto siano interconnessi i nostri artefatti software e come i nostri sistemi siano sicuri tanto quanto i loro collegamenti più deboli. Ha anche rafforzato l'idea che potremmo pensare che la sicurezza sia qualcosa che possiamo acquistare, ma in realtà riguarda il modo in cui funzioniamo come team di sviluppo.

Da allora, abbiamo continuato a correre per migliorare.

Forse la cosa più notevole è che il progetto Sigstore, reso open source da Google, è diventato di fatto il metodo di firma per gli artefatti software, adottato da tutti i principali ecosistemi linguistici, tra cui Java, Python, Node, Ruby e altri. È diventato uno dei progetti di sicurezza open source adottati più rapidamente nella storia e ha fornito agli sviluppatori un “sigillo di ceralacca” di autenticità per determinare le origini e la provenienza degli elementi costitutivi del loro software.

Allora, siamo già arrivati?

Non proprio. Non ancora. Il concetto di distinta base del software (SBOM) introdotto dal decreto della Casa Bianca nel maggio 2021 ha continuato a sembrare distante. Questo concetto di lingua franca per gli sviluppatori per condividere elenchi di ingredienti nei pacchetti software ha molteplici formati emergenti (SPDX, CycloneDX), il che complica le cose. Quel che è peggio, non è chiaro come le SBOM si adatterebbero effettivamente ai flussi di lavoro degli sviluppatori e quali vantaggi specifici uno sviluppatore trarrebbe dal processo.

Ciò che sta iniziando a mettere insieme tutto questo, e a creare maggiore urgenza per creare una strategia coesa attorno alla firma del software, alle SBOM e al flusso di lavoro degli sviluppatori, è la regolamentazione, che richiederebbe una proprietà più rigorosa dell’integrità della sicurezza del software.

Ad aprile, la Cybersecurity and Infrastructure Agency (CISA) ha pubblicato una richiesta di commento su un nuovo modulo di attestazione di sviluppo software sicuro che metterà a carico degli amministratori delegati delle società di software l'onere di attestare che il loro software è stato creato in ambienti sicuri e che sono stati compiuti sforzi ragionevoli e in buona fede per mantenere catene di fornitura affidabili del codice sorgente.

Cosa conta come “ragionevole”?

Finora, gli sforzi "ragionevoli" sembrano essere le linee guida stabilite nei requisiti di scansione delle vulnerabilità per i contenitori di FedRAMP e nel quadro di sviluppo software sicuro del National Institute of Standards and Technology. Ma l’interpretazione molto più sfumata e leggibile tra le righe dei nuovi requisiti di autocertificazione si trova nelle clausole che coprono il codice di terze parti incorporato nel software. In breve, i fornitori di software saranno ritenuti responsabili per il popolare open source non finanziato e non mantenuto che utilizzano nelle loro catene di fornitura.

Aspetta cosa? Responsabile del codice di qualche manutentore del progetto casuale? Apparentemente sì. È “ragionevole”?

Questa vertiginosa diffusione di considerazioni per i CISO è diventata il bersaglio di numerosi meme di Twitter:

Questo è un controllo un po' scioccante, se necessario, sull'adozione senza restrizioni dell'open source. Non sto suggerendo che le aziende non dovrebbero utilizzare l'open source, al contrario. Ti sto ricordando che non c'è nulla di gratuito, anche quando viene confezionato come software gratuito (e open source). Qualcuno deve pagare per mantenere le luci accese per i manutentori e qualcuno deve aiutare gli sviluppatori a dare un senso a tutto questo software open source in entrata.

Chainguard potrebbe essere proprio qualcuno del genere.

Chainguard è una società guidata da ex Googler dietro il progetto Sigstore. Sta cercando di riunire tutto insieme in una catena di strumenti coesa per gli sviluppatori. I primi sforzi della startup si sono concentrati sui passaggi per bloccare il processo di creazione e rendere funzionalità come firme, provenienza e SBOM native delle catene di fornitura del software e del processo di creazione del software. L'anno scorso con Wolfi hanno introdotto la prima (dis)distribuzione Linux della comunità costruita specificamente attorno alle primitive di sicurezza della catena di fornitura. Hanno anche lanciato Chainguard Images, che sono immagini di base per file binari autonomi, applicazioni come nginx e strumenti di sviluppo come compilatori Go e C.