Condivisione della tecnologia

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

fonte:https://thehackernews.com/2024/06/guida-pratica-per-proteggere-i-tuoi-dati.html

Non sorprende che le organizzazioni di produzione di software si trovino ad affrontare una crescente pressione normativa e legale per proteggere le proprie catene di fornitura e garantire l’integrità del proprio software. Negli ultimi anni, la catena di fornitura del software è diventata un obiettivo sempre più attraente per gli aggressori, che vedono un’opportunità per aumentare i loro attacchi in modo significativo. Ad esempio, guarda le vulnerabilità Log4j nel 2021. Log4j (un framework di registrazione open source gestito da Apache e utilizzato in innumerevoli applicazioni diverse) è stato la fonte di vulnerabilità che hanno messo a rischio migliaia di sistemi.

La funzionalità di comunicazione di Log4j è vulnerabile, offrendo così agli aggressori l'opportunità di inserire codice dannoso nei log, che può poi essere eseguito sul sistema. Dopo la sua scoperta, i ricercatori di sicurezza hanno riscontrato milioni di tentativi di exploit, molti dei quali si sono trasformati in attacchi Denial of Service (DoS) riusciti. Secondo una nuova ricerca di Gartner, entro il 2025 quasi la metà delle organizzazioni aziendali sarà presa di mira da attacchi alla catena di fornitura del software.

Ma cos’è una catena di fornitura del software? Innanzitutto, è definito come la somma di tutto il codice, le persone, i sistemi e i processi all’interno e all’esterno di un’organizzazione che contribuiscono allo sviluppo e alla distribuzione degli artefatti software. Ciò che rende così impegnativa la sicurezza della catena di fornitura del software è la complessità e la natura altamente distribuita dello sviluppo di applicazioni moderne. Le organizzazioni impiegano team globali di sviluppatori che fanno affidamento su un numero senza precedenti di dipendenze open source, nonché su estesi repository di codici e registri di artefatti, pipeline CI/CD e risorse infrastrutturali per la creazione e la distribuzione di applicazioni.

Sebbene la sicurezza e la conformità siano sempre state le principali preoccupazioni per le organizzazioni aziendali, proteggere la catena di fornitura del software di un'organizzazione è sempre più impegnativo. Tuttavia, molte organizzazioni hanno compiuto progressi sostanziali nell’implementazione delle pratiche DevSecOps e molte di loro si trovano ancora nelle fasi iniziali per capire cosa fare.

Questo è esattamente il motivo per cui abbiamo messo insieme questo articolo. Anche se quello che segue non è affatto un elenco esaustivo, ecco quattro principi guida che possono far sì che gli sforzi per la sicurezza della catena di fornitura del software si muovano nella giusta direzione.

Considerare tutti gli aspetti della catena di fornitura del software quando si applica la sicurezza

Dato che oltre l’80% delle basi di codice contiene almeno una vulnerabilità open source, le dipendenze OSS sono diventate naturalmente un obiettivo centrale della sicurezza della catena di fornitura del software. Tuttavia, la moderna catena di fornitura del software comprende altre entità il cui livello di sicurezza è trascurato o non è ampiamente compreso all'interno dell'organizzazione per essere adeguatamente gestito. Queste entità sono repository di codici, pipeline CI e CD, infrastrutture e registri di artefatti, ognuno dei quali richiede controlli di sicurezza e valutazioni periodiche di conformità.

Framework come OWASP Top-10 per i benchmark di sicurezza della catena di fornitura di software CI/CD e CIS. Il rispetto di questi framework richiederà un RBAC a grana fine, l'applicazione del principio del privilegio minimo, la scansione dei contenitori e dell'infrastruttura come codice per individuare vulnerabilità e configurazioni errate, l'isolamento delle build, l'integrazione dei test di sicurezza delle applicazioni e la corretta gestione dei segreti, solo per citarne alcuni.

SBOM è fondamentale per risolvere i problemi zero-day e altri componenti

Parte dell'ordine esecutivo 14028, emesso dalla Casa Bianca a metà del 2021 per rafforzare la posizione di sicurezza informatica della nazione, richiede ai produttori di software di fornire una distinta base del software (SBOM) ai propri clienti federali. Le SBOM sono essenzialmente record formali progettati per fornire visibilità su tutti i componenti che compongono il software. Forniscono un elenco dettagliato, leggibile dalla macchina, di tutte le librerie, le dipendenze e i componenti open source e di terze parti utilizzati per creare il software.

Indipendentemente dal fatto che un'organizzazione abbia o meno il mandato EO 14028, la generazione e la gestione di SBOM per gli artefatti software è una pratica preziosa. SBOM è uno strumento indispensabile per risolvere i problemi dei componenti o le vulnerabilità zero-day. Se archiviato in un repository ricercabile, SBOM fornisce una mappa della presenza di dipendenze specifiche e consente ai team di sicurezza di risalire rapidamente alle vulnerabilità fino ai componenti interessati.

Gestire il ciclo di vita dello sviluppo del software utilizzando la policy come codice

Nel mondo dello sviluppo di applicazioni moderne, i guardrail solidi come la roccia sono uno strumento essenziale per eliminare errori e azioni intenzionali che compromettono la sicurezza e la conformità. Una corretta governance lungo tutta la catena di fornitura del software significa che le organizzazioni hanno reso facile fare le cose giuste ed estremamente difficile fare quelle sbagliate.

Mentre molte piattaforme e strumenti forniscono policy pronte all'uso che possono essere eseguite rapidamente, Policy-as-Code, basato sullo standard di settore Open Policy Agent, consente la creazione e l'esecuzione di policy completamente personalizzabili. Gestisci policy che vanno dalle autorizzazioni di accesso al consentire o negare l'uso delle dipendenze OSS in base a criteri quali fornitore, versione, URL del pacchetto e licenza.

Capacità di verificare e garantire l'affidabilità degli artefatti software utilizzando SLSA

Come fanno gli utenti e i consumatori a sapere che un software è affidabile? Quando determini l'affidabilità di un artefatto software, ti consigliamo di sapere chi ha scritto il codice, chi lo ha creato e su quale piattaforma di sviluppo è stato creato. Anche sapere quali componenti sono presenti all'interno è qualcosa che dovresti sapere.

Una volta verificata la provenienza (una registrazione delle origini del software e della catena di custodia), puoi decidere se fidarti del software. A tal fine è stato creato il framework Supply Chain Level of Software Artifacts (SLSA). Consente alle organizzazioni di produzione di software di acquisire informazioni da qualsiasi aspetto della catena di fornitura del software, verificare le proprietà degli artefatti e delle loro build e ridurre il rischio di problemi di sicurezza. In pratica, le organizzazioni di produzione del software devono adottare e rispettare i requisiti del quadro SLSA e implementare un metodo di convalida e generazione di attestazioni software, che sono affermazioni autenticate (metadati) sugli artefatti software lungo tutta la catena di fornitura del software.