Panoramica dello sviluppo e delle operazioni di sicurezza

In che modo Microsoft implementa procedure di sviluppo sicure?

Microsoft Security Development Lifecycle (SDL) è un processo di garanzia di sicurezza incentrato sullo sviluppo e sul funzionamento di un software sicuro. SDL offre requisiti di sicurezza dettagliati e misurabili affinché sviluppatori e ingegneri di Microsoft possano ridurre il numero e la gravità delle vulnerabilità nei nostri prodotti e servizi. Tutti i team di sviluppo software Microsoft devono seguire i requisiti SDL e microsoft aggiorna continuamente SDL in modo da riflettere il panorama delle minacce, le procedure consigliate del settore e gli standard normativi per la conformità.

In che modo SDL di Microsoft migliora la sicurezza delle applicazioni?

Il processo SDL di Microsoft può essere considerato in cinque fasi di sviluppo: requisiti, progettazione, implementazione, verifica e rilascio. Inizia dalla definizione dei requisiti software tenendo conto della sicurezza. Vengono poste domande rilevanti per la sicurezza su ciò che l'applicazione deve eseguire. Ad esempio, l'applicazione deve raccogliere dati sensibili? L'applicazione eseguirà attività importanti o sensibili? L'applicazione deve accettare l'input di origini non attendibili?

Una volta identificati i requisiti di sicurezza pertinenti, progettiamo il nostro software affinché incorpori le funzionalità di sicurezza adatte a soddisfare questi requisiti. I nostri sviluppatori implementano l'SDL e i requisiti di progettazione nel codice, che poi noi verifichiamo tramite analisi manuale del codice, strumenti di sicurezza automatici e test di penetrazione. Infine, prima che il codice possa essere rilasciato, le nuove funzionalità e le modifiche materiali vengono sottoposte alla revisione finale della sicurezza e della privacy per garantire che tutti i requisiti siano soddisfatti.

Per altre informazioni su SDL, vedere Ciclo di vita dello sviluppo della sicurezza Microsoft.

In che modo Microsoft testa il codice sorgente per individuare vulnerabilità comuni?

Per supportare gli sviluppatori nell'implementazione dei requisiti di sicurezza durante lo sviluppo del codice e dopo il rilascio, Microsoft offre una suite di strumenti di sviluppo sicuri per controllare automaticamente il codice sorgente e rilevare eventuali difetti e vulnerabilità della sicurezza. Microsoft definisce e pubblica un elenco di strumenti approvati da usare per gli sviluppatori, ad esempio compilatori e ambienti di sviluppo, insieme ai controlli di sicurezza predefiniti che vengono eseguiti automaticamente all'interno delle pipeline di compilazione Microsoft.

Prima che il codice possa essere archiviato in un ramo di rilascio, SDL richiede la revisione manuale del codice da parte di un revisore separato. I revisori del codice verificano la presenza di errori di codifica e verificano che le modifiche al codice soddisfino i requisiti di progettazione e SDL, superino i test funzionali e di sicurezza e abbiano prestazioni affidabili. Esaminano anche la documentazione, le configurazioni e le dipendenze associate per garantire che le modifiche al codice siano documentate in modo appropriato e non provochino effetti collaterali imprevisti. Se un revisore rileva problemi durante la revisione del codice, può chiedere al mittente di inviare di nuovo il codice con modifiche suggerite e test aggiuntivi. I revisori del codice possono anche decidere di bloccare completamente l'archiviazione per il codice che non soddisfa i requisiti. Dopo che il codice è stato considerato soddisfacente dal revisore, il revisore fornisce l'approvazione, necessaria prima che il codice possa procedere alla fase di distribuzione successiva.

Oltre a proteggere gli strumenti di sviluppo e la revisione manuale del codice, Microsoft applica i requisiti SDL usando strumenti di sicurezza automatizzati. Molti di questi strumenti sono integrati nella pipeline di commit e analizzano automaticamente il codice per individuare eventuali difetti di sicurezza durante l'archiviazione e la compilazione di nuove compilazioni. Gli esempi includono l'analisi statica del codice per individuare errori di sicurezza comuni e scanner di credenziali che analizzano il codice per individuare i segreti incorporati. I problemi rilevati dagli strumenti di sicurezza automatizzati devono essere risolti prima che le nuove build possano superare la revisione della sicurezza e essere approvate per il rilascio.

In che modo Microsoft gestisce il software open source?

Microsoft ha adottato una strategia di alto livello per la gestione della sicurezza open source, che usa strumenti e flussi di lavoro progettati per:

  • Conoscere i componenti open source usati nei prodotti e nei servizi Microsoft.
  • Tenere traccia della posizione e del modo in cui vengono usati tali componenti.
  • Determinare se tali componenti presentano vulnerabilità.
  • Rispondere correttamente quando vengono individuate vulnerabilità che interessano tali componenti.

I team di progettazione Microsoft sono responsabili della sicurezza di tutto il software open source incluso in un prodotto o servizio. Per ottenere questa sicurezza su larga scala, Microsoft ha integrato funzionalità essenziali nei sistemi di progettazione tramite La governance dei componenti (CG), che automatizza il rilevamento open source, i flussi di lavoro dei requisiti legali e gli avvisi per i componenti vulnerabili. Gli strumenti CG automatizzati analizzano le build in Microsoft per individuare i componenti open source e le vulnerabilità di sicurezza associate o gli obblighi legali. I componenti individuati vengono registrati e inviati ai team appropriati per le verifiche aziendali e di sicurezza. Queste verifiche sono progettate per valutare eventuali obblighi legali o vulnerabilità di sicurezza associati ai componenti open source e risolverli prima di approvare la distribuzione dei componenti.

I Servizi online Microsoft vengono controllati regolarmente per verificare la conformità alle normative e alle certificazioni esterne. Per la convalida dei controlli correlati allo sviluppo e all'operazione di sicurezza, vedere la tabella seguente.

Azure e Dynamics 365

Controlli esterni Sezione Data report più recente
ISO 27001

Dichiarazione di applicabilità
Certificato
A.12.1.2: Controlli di gestione delle modifiche
A.14.2: Sicurezza nei processi di sviluppo e supporto
8 aprile 2024
ISO 27017

Dichiarazione di applicabilità
Certificato
A.12.1.2: Controlli di gestione delle modifiche
A.14.2: Sicurezza nei processi di sviluppo e supporto
8 aprile 2024
SOC 1
SOC 2
SOC 3
SDL-1: metodologia del ciclo di vita dello sviluppo della sicurezza (SDL)
SDL-2: requisiti di controllo di sicurezza documentati nelle versioni
SDL-4: Separazione degli ambienti di test e produzione
SDL-6: analisi malware nelle compilazioni di codice sorgente
SDL7: revisione semestrale di SDL
20 maggio 2024

Microsoft 365

Controlli esterni Sezione Data report più recente
FedRAMP SA-3: Ciclo di vita dello sviluppo del sistema 21 agosto 2024
ISO 27001/27017

Dichiarazione di applicabilità
Certificazione (27001)
Certificazione (27017)
A.12.1.2: Controlli di gestione delle modifiche
A.14.2: Sicurezza nei processi di sviluppo e supporto
Marzo 2024
SOC 1
SOC 2
CA-03: Gestione dei rischi
CA-18: Gestione delle modifiche
CA-19: Monitoraggio delle modifiche
CA-21: Test delle modifiche
CA-38: Configurazioni di base
CA-46: Revisione della sicurezza
1 agosto 2024

Risorse