L'open source è diventato il fondamento dello sviluppo software moderno. Quasi ogni applicazione oggi si basa su una complessa rete di librerie, framework, modelli e strumenti di compilazione di terze parti. Questa realtà, da sola, introduce già notevoli... software supply chain security sfide. Allo stesso tempo, l'intelligenza artificiale è entrata nel ciclo di vita dello sviluppo del software come un potente acceleratore, generando codice, suggerendo dipendenze, automatizzando correzioni e persino influenzando lo sviluppo architettonicocisioni. Insieme, l'open source e l'intelligenza artificiale hanno trasformato il modo in cui il software viene sviluppato e, inevitabilmente, il modo in cui viene attaccato. L'intersezione tra sicurezza dell'intelligenza artificiale, sicurezza dell'intelligenza artificiale e del software e software supply chain security non è più un concetto teorico. È ormai una delle principali fonti di rischio per la supply chain del software a cui sono esposte le aziende di ingegneria.
Questa realtà ha caratterizzato il nostro recente SafeDev Talk: Open Source, intelligenza artificiale e la nuova superficie di attacco: codice armato, difese più intelligenti, con la partecipazione di leader della sicurezza di Red Hat, TikTok e Xygeni. La discussione si è concentrata sulle esperienze già riscontrate dai team di sicurezza e ingegneria negli ambienti di produzione, in particolare per quanto riguarda gli attacchi alla supply chain open source, i pacchetti open source dannosi e la crescente tensione tra velocità e controllo nello sviluppo di software basato sull'intelligenza artificiale. Ciò che è emerso è un quadro chiaro: la superficie di attacco si sta espandendo più velocemente di quanto i modelli di sicurezza tradizionali possano tenere il passo, e l'intelligenza artificiale sta agendo sia come moltiplicatore di forza che come test di stress per le ipotesi di lunga data sulla sicurezza dell'intelligenza artificiale e software supply chain security.
Se questa descrizione vi sembra troppo vicina al modo in cui la vostra organizzazione sviluppa attualmente il software, non è una coincidenza. Molti team si rendono conto di quanta fiducia si sia trasferita all'automazione solo dopo che qualcosa si è rotto.
Sicurezza dell'IA e Software Supply Chain Security Ora hanno lo stesso problema
Un tema ricorrente durante la discussione è stato che la sicurezza dell'IA non può più essere trattata come una disciplina separata da software supply chain securityI sistemi di intelligenza artificiale non operano in modo isolato; sono costruiti, addestrati, distribuiti e integrati attraverso lo stesso pipelines, dipendenze e registri che già hanno difficoltà con gli attacchi alla supply chain open source.
Nello sviluppo software basato sull'intelligenza artificiale, i modelli suggeriscono codice, generano correzioni e selezionano automaticamente le dipendenze. Questi decisgli ioni influenzano direttamente gestione delle dipendenze open source, spesso senza un'intenzione umana esplicita. Di conseguenza, il rischio di dipendenza non è più determinato esclusivamente dalla scelta dello sviluppatore, ma è sempre più influenzato dal comportamento dell'IA.
Questa convergenza significa che i fallimenti nella sicurezza dell'intelligenza artificiale e del software spesso si manifestano come incidenti tradizionali della supply chain: dipendenze compromesse, artefatti di build contaminati o vulnerabilità CI/CD processi. Gli strumenti possono essere nuovi, ma il rischio nella supply chain del software è molto reale e sempre più difficile da valutare.
Se i tuoi modelli di minaccia separano ancora il "rischio di intelligenza artificiale" dal "rischio della supply chain", potrebbe valere la pena di rivedere dove tale confine esiste effettivamente nei tuoi flussi di lavoro di creazione e distribuzione.
Attacchi alla supply chain open source alla velocità della macchina
Gli attacchi open source alla supply chain non sono una novità, ma l'intelligenza artificiale ne cambia l'economia. Gli aggressori non hanno bisogno di nuove tecniche; hanno bisogno di scalabilità. L'intelligenza artificiale consente una rapida analisi dell'ecosistema, l'individuazione automatica di dipendenze deboli e una rapida iterazione dei payload di attacco.
Da un punto di vista offensivo, questa industrializzazione della ricognizione aumenta drasticamente il tasso di successo degli attacchi che coinvolgono pacchetti open source dannosi. Componenti che in precedenza sarebbero passati inosservati possono ora essere scoperti, analizzati e sfruttati rapidamente, spesso prima che i difensori si rendano conto del loro utilizzo.
Ecco perché nello studio legale software supply chain security Non si può fare affidamento solo su segnali ritardati. Registri, avvisi e divulgazioni post-facto operano su scale temporali umane, mentre gli aggressori operano sempre più alla velocità delle macchine. La finestra di esposizione che ne risulta contribuisce direttamente all'aumento del rischio nella supply chain del software.
Se il segnale di rilevamento primario è "il registro ha rimosso il pacchetto", stai già operando a valle della sequenza temporale dell'aggressore.
Vuoi approfondire gli attacchi alla supply chain del software open source?
Rischio di dipendenza nello sviluppo di software basato sull'intelligenza artificiale
Uno dei rischi più evidenti discussi durante il SafeDev Talk è stato il rischio di dipendenza, in particolare in ambienti che si basano in larga misura sullo sviluppo software basato sull'intelligenza artificiale. Gli assistenti di programmazione basati sull'intelligenza artificiale sono ottimizzati per praticità e velocità, non per ridurre al minimo la superficie di attacco.
In pratica, questo porta a un'introduzione aggressiva di dipendenze. Vengono aggiunte nuove librerie invece di riutilizzare funzionalità esistenti, dipendenze transitive espandere silenziosamente e open source gestione delle dipendenze diventa reattivo anziché intenzionale. Col tempo, i team perdono la capacità di ragionare su ciò che stanno effettivamente gestendo.
Non si tratta semplicemente di una questione di igiene. Ogni nuova dipendenza introduce ulteriori rischi per la supply chain del software, nuovi presupposti di fiducia e nuove opportunità di attacchi alla supply chain open source. Quando la dipendenza...cisQuando gli ioni vengono automatizzati e rivisti superficialmente, il rischio di dipendenza diventa sistemico anziché accidentale.
Se il grafico delle dipendenze cresce più velocemente di quanto il tuo team riesca a spiegarlo, non si tratta di un problema di strumenti, bensì di fiducia.
Assistenti di codifica AI, sicurezza e il crollo della revisione
Un altro tipo di errore discusso è stato l'erosione della revisione paritaria in presenza di codice generato dall'intelligenza artificiale. Per gli assistenti di programmazione basati sull'intelligenza artificiale, la sicurezza non riguarda solo l'iniezione tempestiva o l'uso improprio del modello; riguarda anche la quantità di logica non revisionata che entra nei sistemi di produzione.
I cambiamenti generati dall'intelligenza artificiale sono spesso ampi, coerenti e difficili da revisionare in tempi stretti. Di conseguenza, la revisione paritaria diventa superficiale o simbolica. Questo collasso silenzioso rimuove uno dei controlli più efficaci in software supply chain security.
Il problema non è la negligenza degli sviluppatori. È il disallineamento del flusso di lavoro. Quando la velocità viene premiata e l'attrito penalizzato, l'intelligenza artificiale e i controlli di sicurezza del software che dipendono dall'attenzione umana si indeboliscono inevitabilmente. Gli aggressori non hanno bisogno di aggirare la revisione se questa non funziona più come barriera.
Molti team danno per scontato che la revisione funzioni ancora perché il processo esiste. Meno si chiedono se funzioni ancora come controllo significativo.
Pacchetti open source dannosi e il mito della popolarità
Una convinzione comune nella gestione delle dipendenze open source è che i progetti popolari siano più sicuri. In realtà, la popolarità spesso aumenta l'esposizione. Le librerie ampiamente utilizzate sono obiettivi di alto valore per attacchi alla catena di fornitura open source, percissemplicemente perché il compromesso produce un impatto a valle più ampio.
Molti progetti popolari sono gestiti da piccoli team o singoli individui. Anche quando vengono rilevati problemi, i pacchetti open source dannosi rimangono spesso disponibili per ore o giorni prima di essere rimossi. Durante questo periodo, le organizzazioni continuano a ingerirli tramite build automatizzate.
Questo ritardo rafforza la necessità di un approccio proattivo software supply chain security controlli. Affidarsi esclusivamente alla popolarità, alla reputazione o alle azioni del registro non è sufficiente quando si affrontano i rischi della moderna catena di fornitura del software.
“Ampiamente utilizzato” non è sinonimo di “attivamente difeso” e trattarlo come tale è uno dei malintesi più persistenti nella catena di approvvigionamento.
Provenienza nelle catene di fornitura del software e nella sicurezza dell'intelligenza artificiale
Nel corso della discussione, è emersa ripetutamente la necessità di attribuzione della provenienza nelle catene di fornitura del software. Negli ambienti assistiti dall'intelligenza artificiale, l'attribuzione diventa confusa. Il codice può essere generato da un modello, modificato da un essere umano, integrato dall'automazione e distribuito senza una chiara responsabilità.
Senza una provenienza verificabile, le organizzazioni sono costrette a fidarsi implicitamente degli artefatti. La sicurezza dell'IA richiede un passaggio dalla fiducia alla verifica: artefatti firmati, build attestationse origini tracciabili. Sebbene la provenienza non impedisca del tutto comportamenti dannosi, riduce significativamente l'ambiguità e limita la manovrabilità degli aggressori.
Questo vale in egual modo per modelli, dati e codice. Nello sviluppo software basato sull'intelligenza artificiale, la provenienza è un requisito fondamentale sia per l'intelligenza artificiale che per la sicurezza del software.
SBOM e sicurezza dell'intelligenza artificiale nella moderna Pipelines
Il ruolo di SBOM e la sicurezza dell'IA era un altro tema implicito. SBOMforniscono visibilità nei grafici delle dipendenze, ma la visibilità da sola non è sufficiente. Negli ambienti ad alta intensità di intelligenza artificiale, SBOMdevono evolversi per catturare non solo librerie, ma anche modelli, fasi di compilazione e processi automatizzaticisioni.
Quando combinato con analisi del comportamento e provenienza, SBOM e la sicurezza dell'intelligenza artificiale diventano strumenti potenti per ridurre il rischio nella supply chain del software. Consentono alle organizzazioni di rilevare cambiamenti imprevisti, valutarne l'impatto e rispondere in modo più efficace agli attacchi alla supply chain open source.
CI/CD Pipeline Security Sotto pressione di automazione
Infine, il CI/CD pipeline security emerse come un piano di controllo critico. Pipelineeseguono sempre più azioni suggerite o innescate dai sistemi di intelligenza artificiale. Se questi pipelineIn assenza di controlli rigorosi dell'identità, verifica degli artefatti e applicazione delle policy, diventano punti di ingresso ideali per gli aggressori.
insufficiente CI/CD pipeline security consente ai pacchetti open source dannosi di influenzare non solo i sistemi di produzione, ma anche gli ambienti di sviluppo e l'infrastruttura di costruzione. Con l'aumento dell'automazione, pipelinedevono essere trattati come beni di alto valore all'interno software supply chain security programmi.
Guarda il SafeDev Talk
Per saperne di più su tutte queste intuizioni direttamente dai professionisti che stanno plasmando il campo, guarda il video completo Discussione su SafeDev: Open Source, intelligenza artificiale e la nuova superficie di attacco: codice armato, difese più intelligenti, Con Roman Zhukov (Cappello Rosso), Leon Johnson (TikTok)e Luis Rodríguez Berzosa (Xygeni).
Implicazioni pratiche per la sicurezza dell'IA e Software Supply Chain Security
Le implicazioni pratiche di questi cambiamenti vanno oltre gli strumenti. Le organizzazioni devono riconoscere che la sicurezza dell'IA, la sicurezza dell'IA e del software e software supply chain security sono ormai profondamente intrecciati. Decisioni che un tempo erano considerati a basso rischio, gli aggiornamenti delle dipendenze, la generazione di codice e l'automazione ora comportano un rischio significativo per la catena di fornitura del software, soprattutto quando talicisgli ioni sono creati implicitamente dagli strumenti piuttosto che esplicitamente dalle persone.
Durante il SafeDev Talk, questo punto è stato riassunto in modo succinto. Come ha affermato uno dei relatori: quando i sistemi di intelligenza artificiale partecipano allo sviluppo del software, i team di sicurezza non si limitano più a proteggere il codice; si occupano anche della protezione dei dati.cisioni. L'automazione non elimina la responsabilità; la ridistribuisce.
In pratica, ciò significa ripristinare l'intenzionalità laddove la praticità ha preso il sopravvento. La gestione delle dipendenze open source deve tenere conto del comportamento guidato dall'intelligenza artificiale piuttosto che presupporre la deliberazione umana. Il rischio di dipendenza non può più essere trattato come un esercizio di revisione occasionale.cise. CI/CD pipeline security Bisogna imporre la verifica, non dare per scontato un input innocuo. E la provenienza nelle catene di fornitura del software deve passare dall'aspirazione alla base.
Un'altra intuizione emersa dalla discussione è stata che la velocità in sé non è più neutrale. La maggior parte dei fallimenti della supply chain non deriva da un singolo evento catastrofico.cisione, ma da tante piccole scelte automatizzate che nessuno ha approvato esplicitamente. Questo è precisEcco perché i modelli di fiducia tradizionali falliscono nello sviluppo di software basato sull'intelligenza artificiale.
Tutto ciò non implica l'abbandono dell'open source o dell'intelligenza artificiale. Al contrario, ne riconosce il ruolo centrale nell'ingegneria moderna. Tuttavia, senza un'evoluzione dei presupposti di sicurezza, le organizzazioni rischiano di lasciare che sia l'automazione a definire la fiducia per impostazione predefinita.
Concludere…
Un modo utile per pensare a questo cambiamento è che software supply chain security non si tratta più solo di proteggere i manufatti. Si tratta di proteggere decispercorsi ioniciIn un mondo assistito dall'intelligenza artificiale, le domande di sicurezza più importanti non sono solo "Questo componente è vulnerabile?", ma "Perché è stato introdotto, da chi o da cosa e con quali vincoli?". Le organizzazioni che si adattano a questa inquadratura non elimineranno i rischi, ma ne saranno molto meno sorprese.
