Introducción al desarrollo y las operaciones de seguridad

  • Artículo

¿Cómo implementa Microsoft prácticas de desarrollo seguras?

El ciclo de vida de desarrollo de seguridad (SDL) de Microsoft es un proceso de garantía de seguridad centrado en el desarrollo y el funcionamiento de software seguro. El SDL proporciona requisitos de seguridad detallados y medibles para que los desarrolladores e ingenieros de Microsoft reduzcan el número y la gravedad de las vulnerabilidades en nuestros productos y servicios. Todos los equipos de desarrollo de software de Microsoft deben seguir los requisitos de SDL y actualizamos continuamente el SDL para reflejar el panorama cambiante de amenazas, los procedimientos recomendados del sector y los estándares normativos para el cumplimiento.

¿Cómo mejora el SDL de Microsoft la seguridad de las aplicaciones?

El proceso de SDL en Microsoft se puede considerar en términos de cinco fases de desarrollo: requisitos, diseño, implementación, verificación y lanzamiento. Comienza definiendo los requisitos de software teniendo en cuenta la seguridad. Para lograr este objetivo, formulamos preguntas relevantes para la seguridad sobre lo que debe lograr la aplicación. ¿La aplicación necesita recopilar datos confidenciales? ¿La aplicación realizará tareas confidenciales o importantes? ¿La aplicación debe aceptar entradas de orígenes que no son de confianza?

Una vez identificados los requisitos de seguridad pertinentes, diseñamos nuestro software para incorporar características de seguridad que cumplan estos requisitos. Nuestros desarrolladores implementan el SDL y requisitos de diseño en el código, que se comprueban mediante la revisión manual del código, las herramientas de seguridad automatizadas y las pruebas de penetración. Por último, antes de que se pueda publicar el código, las nuevas características y los cambios materiales se someten a una revisión final de seguridad y privacidad para asegurarse de que se cumplen todos los requisitos.

¿Cómo prueba Microsoft el código fuente para detectar vulnerabilidades comunes?

Para ayudar a nuestros desarrolladores a implementar los requisitos de seguridad durante el desarrollo de código y después del lanzamiento, Microsoft proporciona un conjunto de herramientas de desarrollo seguras para comprobar automáticamente el código fuente en busca de errores y vulnerabilidades de seguridad. Microsoft define y publica una lista de herramientas aprobadas para que nuestros desarrolladores las usen, como compiladores y entornos de desarrollo, junto con las comprobaciones de seguridad integradas que se ejecutan automáticamente en las canalizaciones de compilación de Microsoft. Nuestros desarrolladores usan las versiones más recientes de las herramientas aprobadas para aprovechar las nuevas características de seguridad.

Antes de que el código se pueda registrar en una rama de versión, el SDL requiere la revisión manual del código por parte de un revisor independiente. Los revisores de código comprueban si hay errores de codificación y comprueban que los cambios de código cumplen los requisitos de diseño y SDL, pasan pruebas funcionales y de seguridad y funcionan de forma confiable. También revisan la documentación, las configuraciones y las dependencias asociadas para asegurarse de que los cambios de código se documentan correctamente y no provocarán efectos secundarios imprescriptibles. Si un revisor encuentra problemas durante la revisión del código, puede pedir al remitente que vuelva a enviar el código con los cambios sugeridos y pruebas adicionales. Los revisores de código también pueden decidir bloquear la inserción en el repositorio por completo para el código que no cumple los requisitos. Una vez que el revisor considera que el código es satisfactorio, el revisor proporciona aprobación, que es necesaria para que el código pueda pasar a la siguiente fase de implementación.

Además de proteger las herramientas de desarrollo y la revisión manual de código, Microsoft aplica los requisitos de SDL mediante herramientas de seguridad automatizadas. Muchas de estas herramientas se integran en la canalización de confirmación y analizan automáticamente el código en busca de errores de seguridad a medida que se registra y a medida que se compilan nuevas compilaciones. Entre los ejemplos se incluyen el análisis de código estático para errores de seguridad comunes y escáneres de credenciales que analizan el código de los secretos incrustados. Los problemas detectados por las herramientas de seguridad automatizadas deben corregirse antes de que las nuevas compilaciones puedan pasar la revisión de seguridad y aprobarse para su lanzamiento.

¿Cómo administra Microsoft el software de código abierto?

Microsoft ha adoptado una estrategia de alto nivel para administrar la seguridad de código abierto, que usa herramientas y flujos de trabajo diseñados para:

  • Comprender qué componentes de código abierto se usan en nuestros productos y servicios.
  • Realizar un seguimiento de dónde y cómo se usan esos componentes.
  • Determinar si esos componentes tienen vulnerabilidades.
  • Responder correctamente cuando se detecten vulnerabilidades que afecten a esos componentes.

Los equipos de ingeniería de Microsoft mantienen la responsabilidad de la seguridad de todo el software de código abierto incluido en un producto o servicio. Para lograr esta seguridad a escala, Microsoft ha integrado funcionalidades esenciales en sistemas de ingeniería a través de La gobernanza de componentes (CG), que automatiza la detección de código abierto, los flujos de trabajo de requisitos legales y las alertas de componentes vulnerables. Las herramientas de CG automatizadas examinan las compilaciones de Microsoft en busca de componentes de código abierto y vulnerabilidades de seguridad asociadas o obligaciones legales. Los componentes detectados se registran y envían a los equipos adecuados para revisiones empresariales y de seguridad. Estas revisiones están diseñadas para evaluar las obligaciones legales o las vulnerabilidades de seguridad asociadas a los componentes de código abierto y resolverlas antes de aprobar los componentes para la implementación.

Regulaciones externas relacionadas & certificaciones

Los servicios en línea de Microsoft se auditan periódicamente para comprobar el cumplimiento de las normativas y certificaciones externas. Consulte la tabla siguiente para la validación de controles relacionados con el desarrollo y la operación de seguridad.

Azure y Dynamics 365

Auditorías externas Section Fecha del informe más reciente
ISO 27001/27002

Declaración de aplicabilidad
Certificado		 A.12.1.2: Controles de administración de cambios
A.14.2: Seguridad en los procesos de desarrollo y soporte técnico		 6 de noviembre de 2023
ISO 27017

Declaración de aplicabilidad
Certificado		 A.12.1.2: Controles de administración de cambios
A.14.2: Seguridad en los procesos de desarrollo y soporte técnico		 6 de noviembre de 2023
SOC 1
SOC 2
SOC 3		 SDL-1: metodología de ciclo de vida de desarrollo de seguridad (SDL)
SDL-2: Requisitos de control de seguridad documentados en las versiones
SDL-4: segregación de entornos de prueba y producción
SDL-6: Análisis de malware en compilaciones de código fuente
SDL7: revisión semestral de SDL		 17 de noviembre de 2023

Microsoft 365

Auditorías externas Section Fecha del informe más reciente
FedRAMP (Office 365) SA-3: Ciclo de vida de desarrollo del sistema 31 de julio de 2023
ISO 27001/27002/27017

Declaración de aplicabilidad
Certificación (27001/27002)
Certificación (27017)		 A.12.1.2: Controles de administración de cambios
A.14.2: Seguridad en los procesos de desarrollo y soporte técnico		 Marzo de 2024
SOC 1
SOC 2		 CA-03: Administración de riesgos
CA-18: Administración de cambios
CA-19: Supervisión de cambios
CA-21: Pruebas de cambios
CA-38: Configuraciones de línea base
CA-46: Revisión de seguridad		 23 de enero de 2024

Recursos