Política de Desarrollo Seguro (SSDLC)

Versión: 1.0 | Última actualización: [Fecha] | Responsable del documento: [Cargo, ej: Head de Ingeniería/CISO]

1. Objetivo

Establecer prácticas obligatorias de seguridad en todas las fases del ciclo de desarrollo de software de [Nombre de la Empresa], reduciendo las vulnerabilidades introducidas en el código antes de llegar a producción.

2. Alcance

Aplica a todo código desarrollado internamente, incluyendo aplicaciones web, APIs, scripts de automatización e infraestructura como código (IaC), sin importar el lenguaje o stack utilizado.

3. Seguridad por Fase del Ciclo de Desarrollo

3.1 Planificación y Diseño:** modelado de amenazas obligatorio para funcionalidades que procesan datos sensibles o autenticación. Los requisitos de seguridad deben definirse junto con los requisitos funcionales.

3.2 Desarrollo:** uso obligatorio de análisis estático de código (SAST) en cada pull request antes del merge. Los secretos (claves de API, credenciales) nunca deben confirmarse en el repositorio — el uso de un gestor de secretos es obligatorio.

3.3 Revisión de Código:** todo código debe pasar por revisión de al menos un par antes del merge, con atención específica a la validación de entrada, control de acceso y manejo de errores.

3.4 Pruebas:** las pruebas de seguridad automatizadas (SCA para dependencias, DAST cuando aplique) deben ejecutarse en el pipeline de CI/CD antes del despliegue en producción.

3.5 Despliegue y Operación:** segregación obligatoria entre entornos de desarrollo, staging y producción, con controles de acceso distintos para cada uno.

4. Gestión de Vulnerabilidades en Código

Las vulnerabilidades identificadas deben tratarse según su severidad: Críticas en un plazo de [ej: 24–72h], Altas en [7 días], Medias/Bajas en el ciclo normal de sprint.

5. Dependencias de Terceros

Las bibliotecas y paquetes de terceros deben escanearse en busca de vulnerabilidades conocidas (CVE) antes de incluirse en el proyecto y monitorearse continuamente después.

6. Roles y Responsabilidades

• [Cargo, ej: Head de Ingeniería]: garantiza que los controles de SSDLC estén implementados en el pipeline de CI/CD.
• Desarrolladores: responsables de seguir prácticas seguras de codificación y corregir las vulnerabilidades identificadas dentro de los plazos definidos.
• [Cargo, ej: CISO/AppSec]: define los criterios de severidad y aprueba excepciones.

7. Capacitación

Todos los desarrolladores deben completar capacitación en seguridad de aplicaciones (ej: OWASP Top 10) en el onboarding y anualmente.

8. Revisión de la Política

Revisión anual, o después de un incidente de seguridad relacionado con una vulnerabilidad de código.