Il Secure Framework OPSWAT: un impegno a favore della resilienza e della sicurezza a più livelli

Gli attori malintenzionati prendono di mira i sistemi a scopo di lucro o di disturbo, causando costi, rischi aziendali e danni alla reputazione delle organizzazioni. 

Secondo una recente indagine, il costo della correzione di un bug di sicurezza è 30 volte superiore quando viene scoperto in produzione rispetto alla fase di analisi e requisiti.

Il Secure Framework OPSWATdefinisce metodologie strutturate e principi di sicurezza che guidano lo sviluppo sicuro del software. 

OPSWAT il ciclo di vita Software agile (Agile SDLC). Al fine di garantire la piena conformità alle esigenze dei nostri clienti, abbiamo adattato il Secure Framework ai requisiti normativi e agli standard internazionali. Questo approccio rafforza il nostro impegno verso il miglioramento continuo e la resilienza in un panorama della sicurezza informatica in continua evoluzione.

Il Secure Framework OPSWATsi basa sullo standard NIST SP 800-218 SSDF (Secure Software Framework), garantendo che la sicurezza sia strutturata, misurabile e applicata in modo coerente in tutte le fasi del processo di sviluppo del software.  

Integrando le migliori pratiche SSDF, OPSWAT mantiene una postura di sicurezza proattiva, incorporando la sicurezza in ogni fase dello sviluppo del software, dalla pianificazione e progettazione all'implementazione, alla verifica e al monitoraggio continuo. 

L'attestazione di conformità di singoli prodotti viene fornita su richiesta ai nostri clienti del governo federale degli Stati Uniti. Vedere i dettagli di contatto qui sotto.

Mentre le normative in materia di sicurezza informatica continuano ad evolversi, OPSWAT il proprio impegno ad allineare il proprio Secure Framework ai requisiti normativi globali, a partire dal Cyber Resilience Act dell’UE e dalla direttiva NIS2. Adattandosi in modo proattivo agli standard emergenti, OPSWAT che il proprio Secure rimanga completo, conforme e resiliente in un panorama normativo sempre più complesso.

Garantire una solida sicurezza delle informazioni è fondamentale sia per l'integrità operativa che per la conformità normativa. Il Secure Framework OPSWAT incorpora i principi dell'ISMS (Sistema di gestione della sicurezza delle informazioni) ISO 27001, assicurando che i controlli di sicurezza, le strategie di gestione dei rischi e le misure di conformità siano perfettamente integrati nel funzionamento dei nostri prodotti cloud. 

In qualità di fornitore e consumatore delle nostre soluzioni di sicurezza, OPSWAT applica le politiche di sicurezza aziendali applicate internamente, garantendo che i nostri prodotti certificati siano conformi alle aspettative di sicurezza di livello aziendale prima della distribuzione.  

Maggiori dettagli su Conformità e certificazioni.

Per garantire i più elevati standard di qualità del software, Secure Framework OPSWATè integrato nel Sistema di Gestione della Qualità (SGQ) conforme alla norma ISO 9001. L’SGQ stabilisce controlli di qualità sottoposti a verifica per la governance, la gestione delle modifiche e i processi interfunzionali, supportando la definizione, la progettazione, lo sviluppo, la produzione e la manutenzione del prodotto e dei servizi di assistenza, estendendosi oltre la ricerca e sviluppo ad aree quali le vendite, l’assistenza clienti, l’informatica e le risorse umane.  

Questo approccio rafforza il nostro impegno verso un approccio strutturato e basato sul rischio alla gestione della qualità, garantendo che la sicurezza delle applicazioni rimanga una considerazione integrale in tutte le funzioni aziendali.

Maggiori dettagli su Conformità e certificazioni.

L'OWASP Software Assurance Maturity Model (SAMM) è un framework completo progettato per aiutare le organizzazioni a valutare, formulare e implementare strategie efficaci di sicurezza del software all'interno del loro SDLC esistente.

Come framework open-source, SAMM beneficia di contributi globali, garantendo un approccio collaborativo e in continua evoluzione alla sicurezza delle applicazioni. La sua metodologia strutturata consente alle organizzazioni un modo efficace e misurabile per analizzare e migliorare il proprio ciclo di vita di sviluppo. SAMM supporta l'intero ciclo di vita dello sviluppo. SAMM è agnostico rispetto alla tecnologia e ai processi. SAMM è evolutivo e orientato al rischio. Sfruttando SAMM, i team ottengono informazioni utili sulle lacune di sicurezza e possono migliorare sistematicamente la loro posizione di sicurezza durante l'intero ciclo di vita dello sviluppo.

L'Application Security Verification Standard (ASVS) di OWASP è un framework riconosciuto a livello mondiale, progettato per stabilire un approccio strutturato, misurabile e attuabile alla sicurezza delle applicazioni web. Fornisce agli sviluppatori e ai team di sicurezza un insieme completo di requisiti di sicurezza e linee guida di verifica per garantire che le applicazioni soddisfino le best practice del settore. 

Essendo un framework open-source, ASVS beneficia di ampi contributi da parte della comunità globale della sicurezza, assicurando che rimanga aggiornato con le minacce emergenti e gli standard di sicurezza in evoluzione.

Il programma Secure OPSWAT traduce il quadro di riferimento Secure in un sistema di governance strutturato, garantendo che i requisiti di sicurezza siano documentati, mantenuti, misurati e continuamente migliorati, assicurando al contempo che tutte le parti coinvolte ricevano una formazione adeguata. Il programma definisce ruoli, responsabilità e misure di sicurezza per gli ambienti di sviluppo, test e produzione, nonché per la sicurezza della pipeline, definendo l’ambiente Secure e rendendo obbligatoria l’applicazione delle politiche di sicurezza all’interno del processo Secure .

Management di alto livello - Chief Product Officer (CPO)

Il Chief Product Officer (CPO) è responsabile della supervisione strategica e dell'attuazione del programma Secure in tutti i team di prodotto, nonché di altri programmi di Ricerca e Sviluppo (R&S) quali il programma di Garanzia della Qualità (QA) e il programma di Esperienza Utente (UX), garantendo un approccio coerente allo sviluppo di software sicuro, di alta qualità e incentrato sull'utente.

In qualità di principale responsabile della gestione dei rischi per tutti i prodotti e i processi di ricerca e sviluppo, il CPO incarica la divisione R&D Operations di gestire il programma Secure e garantisce che i responsabili di prodotto ne assicurino l’applicazione e implementino efficacemente il processo Secure all’interno dei team di prodotto. In questo ruolo, il CPO approva le modifiche al programma Secure e le deroghe al processo Secure .

Il CPO monitora inoltre i risultati del programma Secure , tenendo traccia della maturità in materia di sicurezza, delle vulnerabilità, della conformità e delle attività di sviluppo, al fine di garantire un elevato livello di sicurezza dei prodotti.

Inoltre, il CPO è responsabile dell'assegnazione e dell'approvazione del budget destinato alla sicurezza nel settore della ricerca e sviluppo, garantendo che vengano destinate risorse adeguate al programma Secure .

Priorità strategiche

Il piano strategico dell'OPSWATper la sicurezza delle applicazioni è allineato alle priorità aziendali e alla propensione al rischio, considerando il livello di maturità di ciascun prodotto e la sua esposizione alle minacce alla sicurezza. L'attenzione principale è rivolta alla salvaguardia dei prodotti ad alto rischio, in particolare quelli con un'ampia base di clienti, implementazioni rivolte al pubblico o integrazione in infrastrutture critiche.

Nell’ambito del programma Secure , oltre ai corsi di formazione generali sulla sicurezza organizzati dall’azienda, è obbligatoria una formazione specifica per ruolo per tutto il personale coinvolto nello sviluppo sicuro. Tutti i corsi di formazione vengono registrati negli strumenti di gestione della formazione dell’azienda. I programmi di formazione e sensibilizzazione vengono rivisti periodicamente per integrare le nuove tendenze in materia di sicurezza e garantire la conformità continua agli standard di sicurezza.

OPSWAT impegna a migliorare costantemente il proprio programma Secure attraverso una misurazione strutturata delle prestazioni, valutazioni di maturità e aggiornamenti periodici, al fine di garantire un’efficacia continua in materia di sicurezza.  

Per mantenere una solida posizione di sicurezza, OPSWAT impiega un approccio sistematico per monitorare e migliorare le prestazioni di sicurezza. Ciò include valutazioni trimestrali della maturità della sicurezza dei prodotti, revisioni interne della sicurezza per verificare l'aderenza alle best practice e la definizione di indicatori di prestazione chiave (KPI) annuali, che vengono misurati trimestralmente.  

Per misurare efficacemente lo stato di sicurezza delle applicazioni, OPSWAT i team utilizzando metriche strutturate. La maturità di sicurezza dei prodotti viene valutata per ciascun team sulla base del framework SAMM, fornendo una misura quantificabile dei progressi in materia di sicurezza. Inoltre, i prodotti vengono sottoposti a una valutazione di conformità ASVS per garantire il rispetto dei requisiti di verifica della sicurezza. La conformità al processo Secure viene attentamente monitorata e valutata, e il raggiungimento degli obiettivi KPI è basato su dati concreti, garantendo che lo stato di sicurezza e i miglioramenti in materia siano sia misurabili che attuabili. Tutti i team di prodotto sono tenuti a raggiungere gli obiettivi di maturità in materia di sicurezza nell’ambito della loro valutazione annuale delle prestazioni. 

Nell'ambito dei suoi sforzi di miglioramento continuo, OPSWAT introduce periodicamente nuove iniziative di sicurezza dei prodotti per aumentare i livelli di maturità e rafforzare la sicurezza delle applicazioni. Queste iniziative comprendono l'aggiornamento delle politiche di sicurezza per affrontare le minacce emergenti, l'integrazione di nuovi strumenti di sicurezza per migliorare il rilevamento e la prevenzione e l'ampliamento degli obiettivi KPI per guidare i progressi continui. 

Per rafforzare ulteriormente la governance della sicurezza, OPSWAT una revisione annuale del quadro Secure , integrando i risultati delle analisi delle cause alla radice degli incidenti di sicurezza verificatisi in passato, le valutazioni delle tendenze relative alle vulnerabilità e i perfezionamenti apportati ai processi e alle politiche esistenti.  

Questo approccio strutturato al miglioramento continuo assicura che OPSWAT mantenga una postura di sicurezza del prodotto proattiva e resiliente, adattandosi efficacemente alle sfide della cybersecurity in evoluzione e soddisfacendo al contempo gli obiettivi di sicurezza normativa e operativa.

Il processo Secure rende ulteriormente operativo il programma Secure definendo i controlli di sicurezza che i team devono seguire, comprese attività specifiche quali controlli di sicurezza automatizzati e meccanismi di verifica in ogni fase dello sviluppo. Questo processo è allineato ad altri programmi chiave di ricerca e sviluppo, quali il programma di garanzia della qualità e il programma dedicato all’esperienza utente, assicurando un approccio coerente allo sviluppo di software sicuro, di alta qualità e incentrato sul cliente. 

Il processo Secure è descritto in dettaglio nelle sezioni seguenti:

• Secure e valutazione dei rischi
• Secure , compilazione e distribuzione Secure
• Test e verifica della sicurezza delle applicazioni
• Secure
• Secure e manutenzione Secure

Il processo Secure è un processo di alto livello; i team possono implementarlo in modo esteso e personalizzato, a condizione che il livello di sicurezza del processo sia mantenuto almeno allo stesso livello minimo. Eventuali deviazioni dal processo Secure devono essere documentate e approvate.

Il programma Secure comprende diverse politiche che devono essere formalmente approvate e accettate dai team di prodotto per garantire la conformità ai relativi requisiti. Il rispetto di tali politiche è obbligatorio a livello interno e ciascun team è responsabile della loro revisione, firma e implementazione nell'ambito dei propri processi di sviluppo. 

Di seguito è riportato un elenco delle politiche chiave con le rispettive finalità. Per le politiche con rilevanza esterna, ulteriori dettagli sono incorporati nel presente documento.

Nell’ambito del processo Secure , i requisiti di sicurezza vengono monitorati, documentati e mantenuti per tutto il ciclo di vita dello sviluppo. I fornitori terzi sono tenuti a prendere atto e a rispettare gli standard ASVS, garantendo la coerenza delle aspettative in materia di sicurezza e l’adesione alla Politica di conformità sulla privacy dei prodotti in tutti i componenti software. 

La sicurezza è integrata in ogni fase del ciclo di vita dello sviluppo. È responsabilità dei responsabili della sicurezza tenere presenti le aspettative del processo Secure e rappresentarle all’interno dei propri team. 

L'insieme dei requisiti Secure comprende requisiti di sicurezza funzionali e non funzionali basati sull'ASVS. I modelli di riferimento sono forniti dal reparto Ricerca e Sviluppo per supportare le decisioni di progettazione, insieme ad adeguamenti documentati ai requisiti ASVS, se necessario (ad esempio, requisiti di crittografia più rigorosi).

La modellazione delle minacce è un processo strutturato volto a identificare minacce e vulnerabilità nelle fasi iniziali del ciclo di vita dello sviluppo. È parte integrante del processo Secure e viene condotta regolarmente, almeno una volta all’anno o ogni volta che vengono introdotte nuove funzionalità o modifiche architetturali. I team di prodotto eseguono la modellazione delle minacce definendo gli obiettivi di sicurezza, identificando le risorse e le dipendenze, analizzando i potenziali scenari di attacco e mitigando le minacce individuate.  

Un approccio migliorato incorpora l'analisi del flusso di dati e le pratiche consolidate di modellazione delle minacce (ad esempio, il modello STRIDE), garantendo una valutazione completa dei prodotti. Se necessario, vengono avviate revisioni di sicurezza per convalidare la conformità ai requisiti di sicurezza e affrontare in modo proattivo i rischi potenziali. Le decisioni di progettazione sono accuratamente documentate e i rischi residui sono costantemente monitorati durante il ciclo di vita del prodotto.

I rischi per la sicurezza delle applicazioni vengono valutati utilizzando diverse fonti, tra cui le minacce residue identificate durante la modellazione delle minacce, le vulnerabilità di sicurezza ampiamente riconosciute, come quelle della OWASP Top 10 e della SANS Top 25, e i controlli di sicurezza mancanti basati sulle linee guida ASVS. Altri fattori di rischio includono le debolezze nella gestione dei segreti durante i processi di creazione, distribuzione e rilascio, nonché le vulnerabilità nei componenti open-source e di terze parti. 

In seguito alla valutazione dei rischi, vengono sviluppati piani di mitigazione per ridurre la gravità dei rischi identificati, tenendo conto sia dell'impatto che della probabilità. Questi piani, insieme ai rischi corrispondenti e alle fasi di mitigazione, sono accuratamente documentati. 

I rischi residui vengono monitorati durante tutto il ciclo di vita del prodotto, sono soggetti a revisione periodica e devono essere riconosciuti formalmente dai proprietari del rischio. Vengono inoltre incorporati nei rapporti di rilascio interni per mantenere la visibilità e la responsabilità. 

Se necessario, vengono avviate revisioni di sicurezza per garantire la conformità ai requisiti di sicurezza e affrontare in modo proattivo i rischi potenziali, rafforzando la sicurezza generale del prodotto.

Nell’ambito del processo Secure , che comprende le fasi di implementazione, compilazione e distribuzione, l’obiettivo è prevenire vulnerabilità e difetti, sulla base della Secure e della valutazione dei rischi. L’insieme dei requisiti comprende le aspettative relative ai requisiti di sicurezza funzionali e non funzionali basati su ASVS, nonché una metodologia di sviluppo e test sicura che si avvale dell’ambiente Secure .  

Durante la fase di implementazione, è necessario applicare le migliori pratiche Secure , la revisione Secure e il rilevamento precoce delle vulnerabilità. I team devono attenersi alla Politica Supply Chain (compresi gli aspetti relativi all’inserimento dei fornitori e al software open source), alla Politica sull’uso dell’intelligenza artificiale e alla Politica sulla gestione dei campioni di malware. Durante le fasi di compilazione e distribuzione, sono richiesti Secure e una distribuzione Secure , con l’utilizzo di una pipeline CI/CD centralizzata e il principio della separazione dei compiti.

Durante l'implementazione, i team di prodotto devono seguire le migliori pratiche di codifica sicura indipendenti dalla lingua. Sono tenuti a convalidare i dati di input, a sanificare i dati inviati ad altri sistemi, a eliminare gli avvisi del compilatore, a impostare messaggi di errore sicuri, ad applicare la codifica dell'output, ove applicabile, a implementare una registrazione sicura senza esporre dati sensibili e a seguire le linee guida per la gestione degli errori e delle eccezioni. I team devono anche assicurarsi che la crittografia, se utilizzata, si basi su algoritmi approvati e su una generazione sicura di numeri casuali, e gestire in modo sicuro le risorse di sistema gestendo la memoria in modo sicuro, prevenendo le condizioni di gara ed evitando i deadlock attraverso una corretta sincronizzazione. 

Si consiglia inoltre ai team di prodotto di seguire le linee guida per la codifica sicura specifiche della lingua, applicate dagli strumenti SAST, come illustrato di seguito: 

Per Java, i team devono assicurarsi che le chiavi usate nelle operazioni di confronto siano immutabili, usare SecureRandom invece di Random ed evitare la deserializzazione non sicura convalidando o limitando le classi di input.

In C++, si raccomanda di rilevare e gestire gli errori di allocazione della memoria, di prevenire i buffer overflow attraverso il controllo dei limiti e l'uso di puntatori intelligenti come std::unique_ptr() e di evitare funzioni non sicure come strcpy() e sprintf(). 

Per Python, gli sviluppatori dovrebbero evitare di usare funzioni come eval() o exec() per mitigare i rischi di iniezione di codice e preferire formati di serializzazione sicuri come il modulo json rispetto a pickle quando si elaborano dati non attendibili.

Nell’ambito delle revisioni di sicurezza previste dalla Politica di verifica della sicurezza delle applicazioni, la revisione del codice sicuro riveste un ruolo importante e viene eseguita in base alla tecnologia di sviluppo utilizzata, applicando diverse liste di controllo per la revisione Secure basatesulla serie OWASP Cheatsheet.

Come richiesto dalla Politica di verifica della sicurezza delle applicazioni, il rilevamento precoce delle falle di sicurezza è una componente critica del processo di sviluppo. Per ridurre al minimo i potenziali problemi di sicurezza, è obbligatorio un approccio "fail to build", che garantisce che il codice non sicuro non proceda attraverso la pipeline. Inoltre, viene applicato l'approccio "fail to merge", che impone ai team di correggere i problemi rilevati prima che le modifiche possano essere integrate. Risolvere i difetti rilevati è essenziale per soddisfare i criteri di rilascio.

Nell’ambito del processo Secure , l’uso di una pipeline CI/CD centralizzata e orchestrata è obbligatorio per garantire la sicurezza delle build ed evitare attacchi alla catena di approvvigionamento. I log relativi agli audit, alle build e alle distribuzioni vengono generati, conservati e revisionati secondo quanto definito nelle politiche di sicurezza aziendali. 

Ogni team di prodotto è responsabile di seguire le configurazioni di compilazione e compilazione sicure, ove applicabili. Deve utilizzare opzioni sicure del compilatore, disabilitare il codice di debug, rendere più rigidi i runtime per i linguaggi interpretati, bloccare le versioni delle dipendenze, garantire build riproducibili e rendere più rigide le immagini dei container. Le configurazioni utilizzate devono essere documentate e riviste periodicamente. 

In linea con il principio della separazione dei compiti, gli sviluppatori e gli altri membri del team che hanno accesso al codice o alla creazione non possono accedere all'ambiente di produzione. Nel caso di prodotti cloud, solo i tecnici dell'affidabilità del sito del prodotto sono autorizzati a distribuire nell'ambiente di produzione.

In base alla nostra Politica di verifica della sicurezza delle applicazioni, implementiamo una documentazione formale e un sistema di tracciamento per i problemi individuati e utilizziamo strumenti automatizzati per la verifica continua. Nell’ambito del processo Secure , vengono applicati e monitorati controlli di sicurezza in ogni fase del ciclo di vita dello sviluppo del software (SDLC) al fine di soddisfare i requisiti di conformità. Lo scopo di tali controlli è individuare in modo efficiente eventuali falle di sicurezza. I problemi di sicurezza emersi vengono analizzati dai team e risolti entro i tempi previsti. Tali tempistiche fanno parte degli indicatori chiave di prestazione (KPI) di sicurezza definiti.

• Revisioni dell'architettura e della progettazione: Gli ingegneri senior e i membri dell'Application Security Virtual Team valutano gli aspetti della sicurezza nelle modifiche alla progettazione, tra cui la crittografia, l'autenticazione, l'autorizzazione, l'auditing, l'hardening del sistema, l'architettura di sistema e di rete. 
• Revisioni del codice: oltre alle regolari revisioni del codice da parte di ingegneri peer e senior, i membri dell'Application Security Virtual Team rivedono le modifiche per prevenire difetti comuni come l'iniezione, la gestione degli errori e le configurazioni non sicure.

• Scansione dei segreti per evitare l'esfiltrazione dei segreti e garantire una buona progettazione e un'implementazione sicura della gestione dei segreti.
• Strumenti SAST (Static Application Security Testing) per rilevare le vulnerabilità (ad es. SQL Injection, Buffer Overflow).
• SCA (Software Composition Analysis) è utilizzato per rilevare le vulnerabilità delle risorse aperte.
• Il DAST (Dynamic Application Security Testing) viene utilizzato per trovare problemi di runtime (ad esempio, falle nella memoria) e di ambiente.

Gli strumenti definiti nella sezione Rilevamento precoce dei problemi di sicurezza devono essere utilizzati obbligatoriamente nella pipeline CI/CD. Tutte le vulnerabilità identificate devono essere risolte seguendo la Politica di Vulnerability Management del prodotto.

Vengono utilizzate metodologie di test di sicurezza sia automatizzate che manuali, in linea con il programma di garanzia della qualità che esegue il piano di test di sicurezza.

• Gli strumenti DAST sono utilizzati per rilevare le vulnerabilità in fase di esecuzione, testare le configurazioni predefinite e verificare la resilienza del sistema dopo l'applicazione dei suggerimenti di hardening. I test riguardano sia il software che l'infrastruttura sottostante. 
• Per evitare la regressione dei requisiti e delle funzionalità di sicurezza, utilizziamo strumenti di test automatizzati per verificare continuamente l'integrità delle funzionalità e dei controlli di sicurezza. 
• I test manuali vengono applicati laddove gli strumenti automatizzati non sono all'altezza, come ad esempio nella verifica dei controlli per la fuga di informazioni, nell'identificazione delle falle nella logica aziendale e nelle vulnerabilità contestuali. 
• Anche la scansione automatica del malware degli artefatti nel ciclo di vita dello sviluppo fa parte delle fasi che si concentrano sulla prevenzione dei problemi di sicurezza.

Nell’ambito del processo Secure , il processo di rilascio applica criteri di rilascio che garantiscono sia il rispetto del processo Secure sia la sicurezza complessiva del prodotto, sulla base dei risultati emersi dai test e dalla verifica della sicurezza delle applicazioni. La gestione delle versioni del prodotto svolge un ruolo cruciale nel mantenere i miglioramenti in materia di sicurezza tra una versione e l’altra, prevenendo regressioni legate alla sicurezza e preservando il livello di sicurezza raggiunto, come requisito fondamentale per ogni versione. 

Il processo di rilascio comprende la generazione di rapporti interni sul rilascio, che documentano i rischi residui e qualsiasi problema di sicurezza in sospeso. Questi rapporti devono essere formalmente approvati dal responsabile del prodotto. Inoltre, le note di rilascio esterne comunicano le modifiche e le correzioni relative alla sicurezza come parte del rilascio ufficiale del prodotto. 

Per i prodotti cloud, la distribuzione segue un approccio di automazione "fail to deploy", garantendo che vengano rilasciate solo build sicure. I test e la verifica della sicurezza delle applicazioni sono integrati nella pipeline di distribuzione, con una strategia operativa di "pull" piuttosto che di "push", rafforzando la convalida della sicurezza prima della distribuzione in produzione. 

In base alla politica di gestione delle SBOM, ogni release include unaBill of Materials (SBOM) Software Bill of Materials (SBOM) per mantenere la tracciabilità della provenienza dei componenti, sostenendo la trasparenza e la sicurezza della catena di fornitura. Tutti i file di release necessari sono archiviati in modo sicuro per garantire l'accessibilità a lungo termine.

Secondo la Release Integrity Policy, per sostenere l'integrità e la sicurezza dei rilasci dei prodotti, viene applicato un sistema di versioning strutturato (ad esempio Semantic Versioning), che garantisce una chiara tracciabilità delle modifiche e un periodo di conservazione definito per tutti gli artefatti rilasciati, compresa la documentazione. Per migliorare ulteriormente la sicurezza, gli artefatti software sono firmati digitalmente con il nome dell'azienda, con impronte digitali SHA pubblicate che consentono agli utenti di verificare l'autenticità e individuare eventuali tentativi di manomissione. 

Ogni release è accompagnata da una documentazione aggiornata che fornisce indicazioni dettagliate sui metodi di verifica dell'integrità, sulle procedure di installazione sicura, sulle best practice di configurazione e sulle misure di hardening del sistema. Queste risorse aiutano gli utenti a implementare efficacemente i controlli di sicurezza, riducendo le potenziali superfici di attacco. Inoltre, il Contratto di licenza con l'utente finale (EULA) è incluso per stabilire gli obblighi di conformità e mantenere la trasparenza legale. 

La SBOM per i singoli prodotti viene fornita ai nostri clienti su richiesta. Contattateci.

Gli ambienti di sviluppo, test e produzione sono separati in modo sicuro per evitare accessi non autorizzati. Ogni ambiente segue rigorose linee di base di hardening e protocolli di sicurezza degli endpoint. Gli ambienti di sviluppo devono essere conformi alle politiche di sicurezza aziendali.

Nell'ambito della protezione degli endpoint, tutti i dispositivi di proprietà di OPSWAT vengono monitorati per verificarne le vulnerabilità, il software installato, le patch installate e la conformità alle politiche di sicurezza aziendali. In caso di non conformità, vengono intraprese azioni restrittive per limitare l'accesso alle risorse aziendali. 

Le risorse classificate come ad alto rischio possono essere raggiunte solo attraverso percorsi di accesso controllati (VPN). I dispositivi esterni alla rete aziendale devono utilizzare canali sicuri per accedere alle risorse di R&S.

La sicurezza della pipeline CI/CD si attiene a rigide direttive di sicurezza per mitigare le minacce in evoluzione. La fonte delle minacce potrebbe essere costituita da elementi infrastrutturali obsoleti (come sistemi operativi, strumenti di analisi, ecc.), accessi non autorizzati dovuti a controlli deboli dei privilegi e ambienti scarsamente isolati. Mantenere l'infrastruttura CI/CD aggiornata, accuratamente verificata e strettamente controllata è una pietra miliare del nostro SDLC sicuro. 

A livello regionale, i server con sede negli Stati Uniti sono utilizzati per tutti i servizi centralizzati, tra cui l'archiviazione del codice, la pipeline CI/CD, gli strumenti di analisi e test e la firma sicura degli artefatti. La configurazione di tutti gli strumenti centralizzati è sotto il controllo di R&D Operations. 

Applichiamo meccanismi di autenticazione forte (Multi-Factor Authentication - MFA) e controlli di autorizzazione (Role-Based Access Control - RBAC). Vengono condotti controlli di accesso regolari e di minimo privilegio. 

Le nostre pipeline incorporano diversi strumenti di analisi e automazione dei test, tra cui i test statici di sicurezza delle applicazioni (SAST), l'analisi della composizione Software (SCA), i test dinamici di sicurezza delle applicazioni (DAST), la scansione segreta e la scansione del malware. 

Nella nostra soluzione di firma sicura del codice, utilizziamo moduli di sicurezza Hardware ) per proteggere il materiale chiave da accessi non autorizzati e per generare la firma. La soluzione di firma fa parte dell'infrastruttura CI/CD, ma la rete è segregata. Solo il reparto R&D Operations è autorizzato ad accedere agli HSM per brevi periodi. Ogni azione di firma viene registrata e può essere esaminata in un audit trail. 

Il set di strumenti utilizzato per la creazione, la compilazione o il collaudo del software deve essere corredato di informazioni sulla provenienza e provenire da una fonte convalidata. Il numero di strumenti utilizzati nella pipeline CI/CD è limitato; vengono installati solo quelli necessari. Per le fasi di compilazione e creazione nella pipeline è consentito l’uso esclusivo di software LTS. Nel funzionamento dei servizi centralizzati sono definiti periodi regolari di manutenzione e di rotazione delle chiavi. Gli strumenti sviluppati internamente rientrano nel processo Secure .

L'hardening dell'ambiente per tutti i servizi centralizzati è continuo e i requisiti di sicurezza vengono rivisti periodicamente. Le linee guida per l'hardening vengono comunicate ai team di prodotto per garantire che siano preparati e possano adattare i loro processi di sviluppo di conseguenza. In caso di incidente di sicurezza, viene condotta una RCA per adottare misure preventive e aggiornare i requisiti.

La protezione del codice sorgente è una parte fondamentale dello sviluppo del software per garantire la riservatezza e l'integrità del codice sorgente all'interno dell'azienda. 

Il codice sorgente è conservato secondo il principio del minimo privilegio, consentendo l'accesso solo al personale e agli strumenti autorizzati. Il codice sorgente è sottoposto a controllo di versione. Il sistema di gestione del controllo di versione garantisce la tracciabilità e la responsabilità delle modifiche al codice. I depositi di codice sorgente sono criptati con crittografia conforme a FIPS 140-3 e protetti con una chiave di lunghezza appropriata.

Il rispetto di questa politica è obbligatorio per tutti i team interni. Questo documento è subordinato alle politiche aziendali, il che significa che in caso di contraddizioni le politiche aziendali hanno la precedenza e devono essere seguite. 

Procedura di escalation per le violazioni Secure : eventuali violazioni della presente politica vengono gestite internamente, a partire dal reparto R&D Operations, con escalation fino al Chief Product Officer (CPO) qualora necessario.

I fornitori che forniscono componenti o servizi per prodotti rientranti nell’ambito di applicazione delle norme ISO 27001, SOC2 e NIST SSDF sono tenuti a rispettare i requisiti indicati di seguito, tratti dal Secure Framework. La conformità è soggetta ad audit periodici sulla sicurezza, valutazioni da parte di terzi e agli obblighi di ciascuna parte previsti dai contratti stipulati. 

Tutti i fornitori sono tenuti a fornire informazioni sulla provenienza e sull'integrità, insieme alla documentazione di supporto, come definito nella sezione Integrità della release. 

I fornitori di componenti e librerie devono predisporre ambienti di sviluppo conformi alle nostre prassi, come descritto nella sezione “Ambiente Secure ”. Devono inoltre sottoporre i propri componenti e le proprie librerie a test di sicurezza, come descritto nella sezione “Test e verifica della sicurezza delle applicazioni”. 

I fornitori di componenti della pipeline devono inoltre predisporre ambienti di sviluppo in linea con le nostre pratiche, come descritto nella sezione “Ambiente Secure ”. Inoltre, i loro processi di sviluppo devono essere in linea con il processo Secure OPSWAT. 

I fornitori di servizi sono tenuti a utilizzare ambienti con sede negli Stati Uniti che garantiscano un livello di sicurezza paragonabile a quello offerto dai servizi OPSWAT. Il loro Secure deve includere sia un programma Secure che un processo Secure che rispecchino le aspettative OPSWAT.