Il quadro SDLC Secure di OPSWAT:Un impegno per la resilienza e la sicurezza della difesa in profondità

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 SDLC Framework di OPSWATdefinisce metodologie strutturate e principi di sicurezza che guidano lo sviluppo sicuro del software. 

OPSWAT segue il ciclo di vita dello sviluppo Software agile. Per essere pienamente conformi ai requisiti dei nostri clienti, abbiamo adottato il Secure SDLC Framework in base ai requisiti normativi e agli standard internazionali. Questo approccio rafforza il nostro impegno al miglioramento continuo e alla resilienza in un panorama di cybersecurity in continua evoluzione.

Il Secure SDLC Framework di OPSWATsi basa sul NIST SP 800-218 SSDFSecure Software Development 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.

Con la continua evoluzione delle normative sulla cybersecurity, OPSWAT si impegna ad allineare il proprio Secure SDLC Framework ai requisiti normativi globali, a partire dal Cyber Resilience Act dell'UE e dalla Direttiva NIS2. Adattandosi proattivamente agli standard emergenti, OPSWAT garantisce che il suo Secure SDLC rimanga completo, conforme e resiliente in un panorama normativo sempre più complesso.

Il mantenimento di una solida sicurezza delle informazioni è fondamentale sia per l'integrità operativa che per la conformità normativa. Il Secure SDLC Framework di OPSWAT incorpora i principi dell'ISMS (Information Security Management System) ISO 27001, garantendo che i controlli di sicurezza, le strategie di gestione del rischio 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, il Secure SDLC Framework di OPSWATè integrato nel QMS (Quality Management System) ISO 9001. Il QMS stabilisce controlli di qualità verificati per la governance, la gestione delle modifiche e i processi interfunzionali, supportando la definizione, la progettazione, lo sviluppo, la produzione e la manutenzione dei prodotti e delle offerte di supporto, estendendosi oltre la R&S ad aree come 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 Secure SDLC Program di OPSWAT traduce il Secure SDLC Framework in una governance strutturata, garantendo che i requisiti di sicurezza siano documentati, mantenuti, misurati e continuamente migliorati, assicurando inoltre che tutte le parti coinvolte ricevano una formazione adeguata. Stabilisce ruoli, responsabilità e misure di sicurezza per gli ambienti di sviluppo, test e produzione, nonché per la sicurezza della pipeline, definendo l'ambiente di sviluppo Secure e imponendo l'applicazione delle politiche di sicurezza nell'ambito del processo Secure SDLC.

Management di alto livello - Chief Product Officer (CPO)

Il Chief Product Officer (CPO) è responsabile della supervisione strategica e dell'applicazione del programma Secure SDLC in tutti i team di prodotto e in altri programmi di Ricerca e Sviluppo (R&S), come il programma Quality Assurance (QA) e il programma User Experience (UX), garantendo un approccio coeso allo sviluppo di software sicuro, di alta qualità e incentrato sull'utente.

In qualità di principale proprietario del rischio per tutti i prodotti e i processi di R&S, il CPO incarica le operazioni di R&S di gestire il programma Secure SDLC e si assicura che i leader di prodotto applichino il programma Secure SDLC e implementino efficacemente il processo Secure SDLC nei team di prodotto. In questo ruolo il CPO approva la modifica del Programma Secure SDLC e le deviazioni dal Processo Secure SDLC.

Il CPO controlla anche i risultati del programma Secure SDLC, monitorando la maturità della sicurezza, le vulnerabilità, la conformità e le attività di sviluppo per mantenere una solida posizione di sicurezza dei prodotti.

Inoltre, il CPO è responsabile dell'allocazione e dell'approvazione del budget per la sicurezza della R&S, garantendo che al programma Secure SDLC siano dedicate risorse adeguate.

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 SDLC, oltre ai corsi di formazione generale sulla sicurezza, tutti i membri del personale coinvolti nello sviluppo sicuro sono tenuti a seguire corsi di formazione sulla sicurezza specifici per ogni ruolo. Tutte le formazioni sono registrate negli strumenti di formazione dell'azienda. I programmi di formazione e di sensibilizzazione vengono rivisti periodicamente per incorporare le nuove tendenze in materia di sicurezza e garantire la costante conformità agli standard di sicurezza.

LOPSWAT si impegna a migliorare continuamente il suo programma SDLC Secure attraverso una misurazione strutturata delle prestazioni, valutazioni di maturità e aggiornamenti regolari per garantire l'efficacia della 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 la sicurezza delle applicazioni, OPSWAT valuta i team utilizzando metriche strutturate. La maturità della sicurezza del prodotto viene valutata per ogni team in base al quadro SAMM, fornendo una misura quantificabile del progresso della sicurezza. Inoltre, i prodotti sono sottoposti a una valutazione di conformità ASVS per garantire l'aderenza ai requisiti di verifica della sicurezza. La conformità al Secure SDLC Process è strettamente monitorata, valutata e il raggiungimento degli obiettivi KPI è basato su prove, garantendo che la postura di sicurezza e i miglioramenti della sicurezza siano misurabili e perseguibili. Tutti i team di prodotto sono tenuti a raggiungere gli obiettivi di maturità della 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, l'OPSWAT effettua una revisione annuale del framework Secure SDLC, incorporando le intuizioni derivanti dalle analisi delle cause degli incidenti di sicurezza passati, dalle valutazioni delle tendenze delle vulnerabilità e dai perfezionamenti dei processi e delle 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 Secure SDLC Process rende ulteriormente operativo il Secure SDLC Program definendo i controlli di sicurezza che i team devono seguire, comprese attività specifiche come i controlli di sicurezza automatizzati e i meccanismi di verifica in ogni fase di sviluppo. Questo processo è allineato con altri programmi chiave di R&S, come il Programma di garanzia della qualità e il Programma di esperienza utente, assicurando un approccio coesivo allo sviluppo di software sicuro, di alta qualità e incentrato sul cliente. 

Il processo SDLC Secure è descritto in dettaglio nelle sezioni seguenti:

• Progettazione Secure e valutazione del rischio
• Implementazione, costruzione e distribuzione Secure
• Test e verifica della sicurezza delle applicazioni
• Rilascio Secure
• Operazioni e manutenzione Secure

Il Secure SDLC Process è un processo di alto livello, i team possono implementarlo in modo esteso e personalizzato a condizione che la sicurezza del processo sia mantenuta allo stesso livello minimo. Le deviazioni dal Secure SDLC Process devono essere documentate e approvate.

Il programma Secure SDLC comprende varie politiche che devono essere formalmente approvate e riconosciute dai team di prodotto per garantire la conformità ai suoi requisiti. L'adesione a queste politiche è obbligatoria a livello interno e ogni team è responsabile della loro revisione, sottoscrizione 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 SDLC, i requisiti di sicurezza sono tracciati, documentati e mantenuti per tutto il ciclo di vita dello sviluppo. I fornitori di terze parti sono tenuti a riconoscere e rispettare l'ASVS, garantendo la coerenza delle aspettative di sicurezza e l'adesione alla politica di conformità alla privacy del prodotto in tutti i componenti software. 

La sicurezza è incorporata in ogni fase del ciclo di vita dello sviluppo. È responsabilità dei campioni della sicurezza tenere a mente le aspettative del processo Secure SDLC e rappresentarle all'interno dei loro team. 

Il set di requisiti per la progettazione Secure comprende requisiti di sicurezza funzionali e non funzionali basati sull'ASVS. I modelli di riferimento sono forniti da R&D Operations per supportare le decisioni di progettazione, insieme a modifiche documentate ai requisiti ASVS, se necessario (ad esempio, requisiti di crittografia più forti).

La modellazione delle minacce è un processo strutturato per identificare le minacce e le vulnerabilità nelle prime fasi del ciclo di vita dello sviluppo. È una parte integrante del processo Secure SDLC, condotta regolarmente, almeno una volta all'anno o ogni volta che vengono introdotte nuove funzionalità o modifiche architettoniche. 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 identificate.  

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.

Come parte del processo SDLC Secure , che comprende l'implementazione, la costruzione e la distribuzione, si mira a prevenire vulnerabilità e difetti, sulla base della progettazione Secure e della valutazione dei rischi. Il set di requisiti contiene aspettative sui requisiti di sicurezza funzionali e non funzionali basati sull'ASVS, sullo sviluppo sicuro e sulla metodologia di test basata sull'ambiente di sviluppo Secure .  

Durante l'implementazione devono essere applicate le migliori pratiche di codifica Secure , la revisione Secure del codice e il rilevamento precoce delle falle di sicurezza. I team devono aderire alla politica di sicurezza Supply Chain (compresi gli argomenti relativi all'onboarding dei fornitori e al software open source), alla politica di utilizzo dell'intelligenza artificiale e alla politica di gestione dei campioni di malware. Durante la creazione e l'implementazione sono richiesti Build e Deployment Secure con utilizzo di pipeline CI/CD centralizzate e 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.

Come parte delle revisioni di sicurezza richieste dalla politica di verifica della sicurezza delle applicazioni, la revisione del codice sicuro è importante e viene eseguita a seconda della tecnologia di sviluppo con l'applicazione di vari elenchi di controllo della revisione del codice Secure basati sulla serie diCheatsheet di OWASP.

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 SDLC, l'uso di una pipeline CI/CD centralizzata e orchestrata è obbligatorio per garantire build sicure ed evitare attacchi alla supply chain. I registri di audit, di compilazione e di distribuzione vengono generati, conservati e rivisti come 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 la documentazione formale e il tracciamento dei problemi scoperti e assegniamo strumenti automatizzati per la verifica continua. Nell'ambito del processo Secure SDLC, i controlli di sicurezza vengono eseguiti e monitorati in ogni fase dell'SDLC per soddisfare i requisiti di conformità. Lo scopo di questi controlli è quello di individuare efficacemente le possibili falle di sicurezza. I problemi di sicurezza che emergono vengono analizzati dai team e affrontati entro i tempi previsti. I tempi fanno parte dei 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 SDLC, il processo di rilascio applica criteri di rilascio che assicurano sia l'aderenza al processo Secure SDLC sia la sicurezza complessiva del prodotto, in base ai risultati dei test e delle verifiche di sicurezza delle applicazioni. Il versioning del prodotto svolge un ruolo cruciale nel mantenere i miglioramenti della sicurezza tra le varie release, nel prevenire le regressioni legate alla sicurezza e nel preservare la postura di sicurezza raggiunta, come requisito fondamentale per ogni release. 

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 utilizzati per costruire, compilare o testare il software deve avere informazioni di provenienza e provenire da una fonte convalidata. Gli strumenti utilizzati nella pipeline CI/CD sono in numero limitato e vengono installati solo quelli necessari. Per le fasi di compilazione e costruzione della pipeline è consentito solo il software LTS. Nel funzionamento dei servizi centralizzati sono definiti periodi di manutenzione regolare e di rotazione delle chiavi. Gli strumenti sviluppati internamente rientrano nel processo Secure SDLC.

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. 

Processo di escalation per le violazioni del Secure SDLC: Qualsiasi violazione di questa politica viene gestita internamente, a partire dalle operazioni di R&S e, se necessario, fino al Chief Product Officer (CPO).

I fornitori che forniscono componenti o servizi per prodotti che rientrano nell'ambito di applicazione delle norme ISO 27001, SOC2 e NIST SSDF sono tenuti a rispettare i requisiti delineati di seguito dal Secure SDLC Framework. La conformità è soggetta a verifiche periodiche della sicurezza, a valutazioni di terzi e agli obblighi di ciascuna parte in base ai 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 creare ambienti di sviluppo in linea con le nostre pratiche, come descritto nella sezione Ambiente di sviluppo Secure . Devono applicare test di sicurezza ai loro componenti e librerie, come descritto nella sezione Test e verifica della sicurezza delle applicazioni. 

I fornitori di componenti della pipeline devono anche creare ambienti di sviluppo allineati alle nostre pratiche, come descritto nella sezione Ambiente di sviluppo Secure . Inoltre, i loro processi di sviluppo devono essere in linea con il processo SDLC Secure di OPSWAT. 

I fornitori di servizi devono utilizzare ambienti con sede negli Stati Uniti che offrano una sicurezza paragonabile a quella dei servizi dell'OPSWAT. Il loro Secure SDLC deve includere sia un Secure SDLC Program che un Secure SDLC Process che rispecchiano le aspettative di OPSWAT.