Gestión de requisitos de seguridad
La mayoría de los problemas de seguridad no son errores de codificación — son requisitos faltantes. Nadie especificó que el flujo de restablecimiento de contraseña debería caducar los tokens. Nadie documentó que los endpoints de API necesitan rate limiting. El desarrollador construyó lo que se le pidió. La seguridad no se pidió.
Los requisitos de seguridad convierten las suposiciones implícitas en especificaciones explícitas y verificables. Cuando "el usuario debe estar autenticado" se convierte en "la autenticación debe usar bcrypt con factor de coste 12, las sesiones deben caducar después de 30 minutos de inactividad, y los intentos fallidos de inicio de sesión deben tener rate limiting a 5 por hora" — entonces puede verificar la implementación.
Este capítulo cubre cómo definir requisitos de seguridad usando estándares de la industria, integrarlos en su flujo de trabajo de desarrollo y verificar que están implementados correctamente.
Por qué importan los requisitos de seguridad
Sin requisitos explícitos:
- Los desarrolladores toman sus propias decisiones de seguridad (de forma inconsistente)
- Las revisiones de seguridad encuentran problemas tarde, cuando las correcciones son costosas
- Las pruebas no cubren la seguridad porque no hay nada contra qué probar
- Las auditorías de cumplimiento requieren ingeniería inversa de lo que realmente se construyó
Con requisitos explícitos:
- Las decisiones de seguridad se toman una vez, se documentan y se reutilizan
- Los desarrolladores saben exactamente qué se espera
- El equipo de QA puede probar la seguridad como cualquier otra funcionalidad
- El cumplimiento es demostrable
El coste de corregir un problema de seguridad aumenta drásticamente cuanto más tarde se encuentra. Un requisito detectado en el diseño no cuesta casi nada corregirlo. El mismo problema encontrado en producción podría requerir parches de emergencia, notificación a clientes y semanas de remediación.
OWASP Application Security Verification Standard (ASVS)
El OWASP ASVS es un catálogo completo de requisitos de seguridad para aplicaciones web. En lugar de inventar sus propios requisitos, use ASVS como línea base.
Estructura del ASVS
El ASVS organiza los requisitos en capítulos:
| Capítulo | Tema | Requisitos de ejemplo |
|---|---|---|
| V1 | Arquitectura | Modelado de amenazas, patrones de diseño seguro |
| V2 | Autenticación | Políticas de contraseñas, MFA, almacenamiento de credenciales |
| V3 | Gestión de sesiones | Tokens de sesión, tiempos de espera, cierre de sesión |
| V4 | Control de acceso | Acceso basado en roles, autorización a nivel de objeto |
| V5 | Validación | Validación de entrada, codificación de salida |
| V6 | Criptografía | Selección de algoritmos, gestión de claves |
| V7 | Manejo de errores | Registro, mensajes de error |
| V8 | Protección de datos | Clasificación de datos, manejo de PII |
| V9 | Comunicación | Configuración TLS, validación de certificados |
| V10 | Código malicioso | Integridad de dependencias, revisión de código |
| V11 | Lógica de negocio | Casos de abuso, seguridad del flujo de trabajo |
| V12 | Archivos | Carga de archivos, path traversal |
| V13 | API | Seguridad REST, GraphQL, WebSocket |
| V14 | Configuración | Cabeceras de seguridad, endurecimiento del build |
Niveles del ASVS
El ASVS define tres niveles de verificación:
Nivel 1 — Línea base mínima Seguridad básica para todas las aplicaciones. Cubre las vulnerabilidades más comunes (OWASP Top 10). Puede verificarse mediante pruebas automatizadas.
Nivel 2 — Estándar Recomendado para la mayoría de las aplicaciones, especialmente las que manejan datos sensibles. Requiere alguna revisión manual.
Nivel 3 — Avanzado Para aplicaciones de alta seguridad (banca, salud, infraestructura crítica). Requiere revisión exhaustiva y pruebas avanzadas.
Para la mayoría de las empresas pequeñas: empiece con el Nivel 1, amplíe al Nivel 2 para las funcionalidades sensibles.
Ejemplos de requisitos ASVS
De autenticación (V2):
V2.1.1: Verify that user set passwords are at least 12 characters in length.
V2.1.5: Verify users can change their password.
V2.1.7: Verify that passwords submitted during account registration,
login, and password change are checked against a set of breached
passwords either locally or using an external API.
V2.2.1: Verify that anti-automation controls are effective at mitigating
breached credential testing, brute force, and account lockout attacks.
Cada requisito tiene:
- Identificador único (p.ej., V2.1.1)
- Declaración clara y verificable
- Nivel ASVS aplicable
OWASP Cheat Sheet Series
La OWASP Cheat Sheet Series proporciona orientación de implementación para temas de seguridad. Mientras que el ASVS le dice qué hacer, las hojas de referencia explican cómo hacerlo.
Hojas de referencia útiles para desarrolladores:
| Tema | Hoja de referencia |
|---|---|
| Autenticación | Authentication Cheat Sheet |
| Almacenamiento de contraseñas | Password Storage Cheat Sheet |
| Gestión de sesiones | Session Management Cheat Sheet |
| Validación de entrada | Input Validation Cheat Sheet |
| Inyección SQL | Query Parameterization Cheat Sheet |
| Prevención XSS | Cross Site Scripting Prevention Cheat Sheet |
| CSRF | Cross-Site Request Forgery Prevention Cheat Sheet |
| JWT | JSON Web Token Cheat Sheet |
| Carga de archivos | File Upload Cheat Sheet |
| Seguridad de API | REST Security Cheat Sheet |
| Criptografía | Cryptographic Storage Cheat Sheet |
| Manejo de errores | Error Handling Cheat Sheet |
| Registro | Logging Cheat Sheet |
Vincule las hojas de referencia relevantes a sus requisitos — se convierten en guías de implementación para los desarrolladores.
Otros recursos de OWASP
| Recurso | Propósito |
|---|---|
| OWASP Top 10 | Riesgos de seguridad más críticos en aplicaciones web |
| OWASP Testing Guide | Metodología de pruebas manuales |
| OWASP SAMM | Software Assurance Maturity Model |
| OWASP Security Knowledge Framework | Plataforma de formación y mapeo de requisitos |
| OWASP Proactive Controls | Las 10 técnicas de seguridad principales para desarrolladores |
ASVS y marcos de cumplimiento
Los requisitos de ASVS se asignan a estándares de cumplimiento comunes. Si está buscando una certificación, el ASVS le da ventaja:
| Cumplimiento | Capítulos ASVS relevantes | Notas |
|---|---|---|
| SOC 2 | V2, V3, V4, V7, V8, V14 | Control de acceso, registro, protección de datos |
| PCI-DSS | V2, V3, V4, V6, V7, V8, V9 | Auth fuerte, cifrado, registro |
| GDPR | V8, V7, V6 | Protección de datos, registro de brechas, cifrado |
| HIPAA | V2, V3, V6, V7, V8 | Control de acceso, pistas de auditoría, cifrado |
| ISO 27001 | Todos los capítulos | Superposición completa |
Cómo ayuda esto:
- Cuando los auditores preguntan "¿cómo garantiza la autenticación segura?", señala los requisitos V2 y las evidencias
- Los cuestionarios de seguridad de clientes a menudo se asignan directamente a los requisitos ASVS
- El cumplimiento se convierte en la verificación de los requisitos existentes, no en un proyecto separado
Herramientas y plataformas ASVS
No reinvente la rueda — existen herramientas para ayudar a gestionar los requisitos ASVS:
Herramientas gratuitas
| Herramienta | Descripción | Enlace |
|---|---|---|
| OWASP ASVS Checklist | Lista de verificación interactiva | GitHub |
| ASVS Excel/CSV | Hoja de cálculo descargable | ASVS GitHub |
| Security Knowledge Framework | Formación + mapeo de requisitos | SKF |
| OWASP Cornucopia | Juego de cartas de modelado de amenazas | Cornucopia |
Plataformas comerciales con soporte ASVS
| Herramienta | Funcionalidades ASVS |
|---|---|
| IriusRisk | Requisitos ASVS automáticos a partir de modelos de amenazas |
| SD Elements | La biblioteca de requisitos incluye ASVS |
| Jira with Security Requirements Plugin | Seguimiento de ASVS en Jira |
| DefectDojo | Código abierto, rastrea hallazgos contra ASVS |
Selección de requisitos para su proyecto
No necesita implementar los 286 requisitos de ASVS el primer día. Empiece con lo que importa para su aplicación.
Inicio rápido: requisitos esenciales
Para una aplicación web típica con cuentas de usuario, empiece con estos 25 requisitos:
Autenticación (V2)
- V2.1.1: Contraseñas de mínimo 12 caracteres
- V2.1.7: Verificar contraseñas contra listas de brechas
- V2.2.1: Rate limiting en el inicio de sesión
- V2.4.1: Contraseñas hasheadas con bcrypt/argon2
Gestión de sesiones (V3)
- V3.2.1: Tokens de sesión generados con aleatoriedad segura
- V3.3.1: Sesión invalidada al cerrar sesión
- V3.7.1: Tiempo de espera de sesión implementado
Control de acceso (V4)
- V4.1.1: Control de acceso aplicado en el servidor
- V4.1.2: Denegar por defecto
- V4.2.1: Protección contra IDOR
Validación (V5)
- V5.1.1: Validación de entrada del lado del servidor
- V5.2.1: Sanitizar entrada HTML
- V5.3.1: Codificación de salida para prevención XSS
- V5.3.4: Codificación de salida contextual
Criptografía (V6)
- V6.2.1: Solo algoritmos de cifrado fuertes
- V6.4.1: Secretos no codificados en duro
Registro (V7)
- V7.1.1: Registrar eventos de autenticación
- V7.1.2: Registrar fallos de control de acceso
- V7.2.1: Sin datos sensibles en los registros
Protección de datos (V8)
- V8.3.1: Datos sensibles cifrados en reposo
- V8.3.4: Datos sensibles cifrados en tránsito
Comunicación (V9)
- V9.1.1: TLS para todas las conexiones
- V9.1.2: Configuración TLS fuerte
Configuración (V14)
- V14.4.1: Cabeceras de seguridad configuradas
- V14.4.3: Cabecera Content-Security-Policy
- V14.4.5: Cabecera Strict-Transport-Security
Implemente estos 25 primero. Cubren los vectores de ataque más comunes y llevan a un equipo pequeño 2-4 semanas.
Priorización de requisitos por riesgo
No todos los requisitos son igualmente importantes. Use una puntuación de riesgo simple:
Impacto (si falta el requisito):
- Crítico (4): Brecha directa de datos, compromiso total del sistema, violación regulatoria
- Alto (3): Exposición significativa de datos, apropiación de cuentas
- Medio (2): Exposición limitada, requiere otras vulnerabilidades
- Bajo (1): Impacto mínimo, defensa en profundidad
Probabilidad (de explotación):
- Alta (3): Vector de ataque común, fácil de explotar
- Media (2): Requiere cierta habilidad o condiciones específicas
- Baja (1): Ataque raro, requiere esfuerzo significativo
Puntuación de riesgo = Impacto × Probabilidad
| Puntuación | Prioridad | Acción |
|---|---|---|
| 9-12 | Crítico | Implementar inmediatamente |
| 5-8 | Alto | Implementar en el sprint actual |
| 3-4 | Medio | Planificar para el próximo trimestre |
| 1-2 | Bajo | Backlog |
Ejemplo de priorización:
| Requisito | Impacto | Probabilidad | Puntuación | Prioridad |
|---|---|---|---|---|
| V2.4.1 Hashing de contraseñas | 4 (brecha) | 3 (ataque común) | 12 | Crítico |
| V5.3.1 Prevención XSS | 3 (apropiación) | 3 (común) | 9 | Crítico |
| V4.1.1 Control de acceso del lado del servidor | 4 (brecha) | 2 (requiere auth) | 8 | Alto |
| V14.4.5 Cabecera HSTS | 2 (riesgo MITM) | 2 (ataque dirigido) | 4 | Medio |
Paso 1: Clasifique su aplicación
¿Qué datos gestiona?
- Solo datos públicos → Requisitos menores
- PII de usuarios → V8 (Protección de datos) es crítico
- Datos financieros → V6 (Criptografía), V2 (Autenticación) son críticos
- Datos de salud → V8 completo, V2, V3, más requisitos regulatorios
¿Cuál es su superficie de ataque?
- Herramienta interna → Menor perfil de amenaza externo
- API pública → V13 (API) es crítico
- Procesamiento de archivos → V12 (Archivos) es crítico
- E-commerce → V11 (Lógica de negocio) es crítico
Paso 2: Empiece con los esenciales del Nivel 1
Para cualquier aplicación web, empiece con estos capítulos ASVS en el Nivel 1:
- V2 Autenticación — Manejo de contraseñas, bloqueo
- V3 Gestión de sesiones — Seguridad de tokens, caducidad
- V4 Control de acceso — Verificaciones de autorización
- V5 Validación — Validación de entrada, codificación de salida
- V14 Configuración — Cabeceras de seguridad, HTTPS
Esto cubre las vulnerabilidades más comunes con un esfuerzo razonable.
Paso 3: Agregue requisitos específicos de funcionalidad
Al construir nuevas funcionalidades, identifique las secciones ASVS relevantes:
| Funcionalidad | Secciones ASVS relevantes |
|---|---|
| Registro de usuarios | V2.1 (Seguridad de contraseñas) |
| Login / SSO | V2.2 (Autenticación), V3 (Sesiones) |
| Carga de archivos | V12.1 (Carga de archivos) |
| Endpoints de API | V13 (API), V4 (Control de acceso) |
| Procesamiento de pagos | V6 (Criptografía), V8 (Protección de datos) |
| Restablecimiento de contraseña | V2.5 (Recuperación de credenciales) |
| Panel de administración | V4 (Control de acceso), V7 (Registro) |
| Funcionalidad de búsqueda | V5.3 (Codificación de salida) |
Paso 4: Documente su línea base
Cree un documento que liste qué requisitos ASVS aplican a su proyecto:
# Security Requirements Baseline
## Scope
This document defines security requirements for [Project Name].
## ASVS Level
Level 1 for all features, Level 2 for authentication and payment.
## Applicable Chapters
- V2 Authentication: Full
- V3 Session Management: Full
- V4 Access Control: Full
- V5 Validation: 5.1, 5.2, 5.3 only
- V7 Error Handling: 7.1 only
- V8 Data Protection: 8.1, 8.3
- V13 API Security: Full
- V14 Configuration: Full
## Excluded (with justification)
- V12 Files: No file upload functionality
- V11 Business Logic: Simple CRUD, no complex workflows
Last reviewed: [Date]
Modelado de amenazas y requisitos
El modelado de amenazas identifica qué podría salir mal. Los requisitos ASVS especifican cómo prevenirlo. Trabajan juntos.
Modelado de amenazas simple para funcionalidades
Antes de agregar requisitos ASVS a una funcionalidad, haga estas preguntas:
STRIDE para cada componente:
| Amenaza | Pregunta | Requisito de ejemplo |
|---|---|---|
| Suplantación | ¿Puede alguien hacerse pasar por otro usuario? | V2, V3 (auth, sesiones) |
| Tampering | ¿Puede alguien modificar datos que no debería? | V4, V5 (control de acceso, validación) |
| Repudio | ¿Puede alguien negar sus acciones? | V7 (registro) |
| Información divulgada | ¿Puede alguien acceder a datos que no debería? | V4, V8 (acceso, protección de datos) |
| Denegación de servicio | ¿Puede alguien romper la disponibilidad? | V2.2 (rate limiting) |
| Elevación de privilegios | ¿Puede alguien obtener acceso no autorizado? | V4 (control de acceso) |
Para cada amenaza identificada:
- Encuentre la sección ASVS relevante
- Agregue esos requisitos a la funcionalidad
- Verifique que están probados
Plantilla de modelado de amenazas rápido
## Threat Model: [Feature Name]
### Assets
What are we protecting?
- [ ] User credentials
- [ ] User PII
- [ ] Financial data
- [ ] Business logic
- [ ] Other: ___
### Entry points
How do users interact with this feature?
- [ ] Web form
- [ ] API endpoint
- [ ] File upload
- [ ] Webhook
- [ ] Other: ___
### Trust boundaries crossed
- [ ] Internet → Web server
- [ ] Web server → Database
- [ ] Web server → External API
- [ ] User role → Admin role
### Threats identified
| Threat | Category | Mitigation | ASVS requirement |
|--------|----------|------------|------------------|
| | | | |
### Security requirements
Based on threats, apply these ASVS requirements: [List]
Seguimiento de requisitos en su flujo de trabajo
Los requisitos de seguridad deben rastrearse como cualquier otro elemento de trabajo. Use sus herramientas existentes.
Usando Jira (o similar)
Cree un tipo de issue personalizado "Security Requirement" con campos:
| Campo | Opciones |
|---|---|
| ASVS ID | V2.1.1, V2.1.2, etc. |
| Estado | No Aplicable, No Implementado, En Progreso, Implementado, Verificado |
| Prioridad | Crítico, Alto, Medio, Bajo |
| Funcionalidades aplicables | Lista de funcionalidades afectadas |
| Método de verificación | Prueba automatizada, Revisión de código, Prueba de penetración, Verificación manual |
| Última verificación | Fecha |
| Evidencia | Enlace a resultados de pruebas o notas de revisión |
Flujo de trabajo de estados:
┌─────────────────┐
│ Not Applicable │ ← Requirement doesn't apply to this project
└────────┬────────┘
│ (applies)
▼
┌─────────────────┐
│ Not Implemented │ ← Requirement applies but isn't done
└────────┬────────┘
│ (work started)
▼
┌─────────────────┐
│ In Progress │ ← Implementation underway
└────────┬────────┘
│ (code complete)
▼
┌─────────────────┐
│ Implemented │ ← Code done, needs verification
└────────┬────────┘
│ (tested/reviewed)
▼
┌─────────────────┐
│ Verified │ ← Confirmed working
└─────────────────┘
Creando tickets de requisitos
Para cada requisito ASVS aplicable, cree un ticket:
Title: [V2.1.1] Minimum password length of 12 characters
Description:
ASVS Requirement: V2.1.1
Level: 1
Requirement text:
"Verify that user set passwords are at least 12 characters in length."
Implementation notes:
- Update password validation in registration and password change flows
- Update user-facing error messages
- See: OWASP Password Storage Cheat Sheet
Acceptance criteria:
- [ ] Registration rejects passwords under 12 characters
- [ ] Password change rejects passwords under 12 characters
- [ ] Error message explains minimum length
- [ ] Automated test covers both flows
Verification method: Automated Test
Vinculando requisitos a funcionalidades
Al planificar una nueva funcionalidad, vincule los requisitos de seguridad relevantes:
Feature: User Registration
Security requirements:
- V2.1.1: Password minimum 12 characters
- V2.1.5: Users can change password
- V2.1.7: Check passwords against breach list
- V2.1.9: No password composition rules (just length)
- V2.4.1: Bcrypt for password storage
- V5.1.1: Server-side input validation
- V7.1.1: Log authentication events
Definition of Done:
- [ ] All linked security requirements verified
Herramientas especializadas para requisitos de seguridad
Para equipos más grandes o entornos con mucho cumplimiento, las herramientas especializadas ayudan:
Plataformas GRC y cumplimiento
| Herramienta | Descripción | Mejor para |
|---|---|---|
| Drata | Automatización de cumplimiento SOC 2, ISO 27001 | Startups que buscan SOC 2 |
| Vanta | Monitoreo de seguridad continuo + cumplimiento | Similar a Drata |
| Secureframe | Automatización de cumplimiento | SOC 2, HIPAA, PCI |
| Tugboat Logic | Plataforma de garantía de seguridad | Empresas en crecimiento |
| Hyperproof | Operaciones de cumplimiento | Cumplimiento empresarial |
| OneTrust | Plataforma GRC | Grandes empresas |
Modelado de amenazas y requisitos
| Herramienta | Descripción | Mejor para |
|---|---|---|
| OWASP Threat Dragon | Modelado de amenazas de código abierto | Gratuito, amigable para desarrolladores |
| Microsoft Threat Modeling Tool | Modelado de amenazas de escritorio | Stack Microsoft |
| IriusRisk | Modelado de amenazas + requisitos | DevSecOps empresarial |
| SD Elements | Requisitos de seguridad desde el diseño | SDLC empresarial |
| Foreseeti | Simulación de ataques | Modelado de amenazas avanzado |
Plataformas de pruebas de seguridad
| Herramienta | Descripción | Mejor para |
|---|---|---|
| Snyk | Plataforma de seguridad para desarrolladores | DevSecOps, SCA |
| Checkmarx | SAST + seguimiento de requisitos | Empresarial |
| Veracode | Pruebas de seguridad + política | Empresarial |
| Contrast Security | IAST + RASP | Protección en tiempo de ejecución |
| StackHawk | DAST para desarrolladores | Pruebas de seguridad de API |
Enfoques simples para equipos pequeños
Hoja de cálculo: Exporte ASVS a CSV (disponible en GitHub), filtre los requisitos aplicables, realice el seguimiento del estado en columnas.
GitHub Issues: Cree issues para cada requisito, use etiquetas para el estado, vincule a los PRs que los implementan.
Notion/Confluence: Base de datos de requisitos con estado, vinculada a la documentación de funcionalidades.
Para la mayoría de los equipos pequeños, Jira + una hoja de cálculo de línea base funciona bien. Pase a herramientas especializadas cuando tenga requisitos de cumplimiento o personal de seguridad.
Plantillas listas para usar
Plantilla de Issue de GitHub (.github/ISSUE_TEMPLATE/security-requirement.md):
---
name: Security Requirement
about: Track ASVS security requirement implementation
title: '[ASVS] '
labels: security, requirement
assignees: ''
---
## ASVS Requirement
**ID:** V0.0.0
**Level:** 1 / 2 / 3
**Chapter:**
## Requirement Text
> [Paste requirement text from ASVS]
## Implementation Notes
- Where does this apply in our codebase?
- What changes are needed?
- Related cheat sheet: [link]
## Acceptance Criteria
- [ ] Requirement implemented
- [ ] Automated test written
- [ ] Code reviewed
- [ ] Verified in staging
## Verification Method
- [ ] Automated test
- [ ] Code review
- [ ] Manual testing
- [ ] Penetration test
## Evidence
[Link to test results / review / audit]
Adición de plantilla PR (.github/pull_request_template.md):
## Security Checklist
- [ ] No secrets in code
- [ ] Input validation added for new inputs
- [ ] Output encoding for new outputs
- [ ] Access control checks in place
- [ ] Logging added for security events
- [ ] Security requirements linked: #
### Security Champion Review
- [ ] Required for: auth changes, access control, crypto, data handling
- [ ] Reviewer: @security-champion
Cuestionarios de seguridad de clientes
Cuando los clientes o socios envían cuestionarios de seguridad, el ASVS facilita las respuestas.
Preguntas comunes y mapeo ASVS
| Categoría de pregunta | Evidencia ASVS |
|---|---|
| "¿Cómo gestiona la autenticación?" | Requisitos V2 + verificación |
| "¿Cómo se almacenan las contraseñas?" | V2.4 + implementación bcrypt |
| "¿Cifra los datos en reposo?" | V6, V8.3 + detalles de cifrado |
| "¿Tiene registro de auditoría?" | V7 + muestras de registros |
| "¿Cómo gestiona la gestión de sesiones?" | Requisitos V3 |
| "¿Qué pruebas de seguridad realiza?" | Registros de verificación ASVS |
| "¿Sigue prácticas de codificación segura?" | V5, V10 + resultados SAST |
Preparación para cuestionarios
-
Cree una biblioteca de evidencias:
- Para cada sección principal de ASVS, prepare un documento resumen
- Incluya: ID del requisito, estado de implementación, enlace de evidencia
-
Plantillas de respuesta estándar:
**Authentication Security**
We follow OWASP ASVS Level 2 for authentication (V2).
Specific controls include:
- Password minimum 12 characters (V2.1.1)
- Passwords checked against breach databases (V2.1.7)
- Bcrypt with cost factor 12 for storage (V2.4.1)
- Rate limiting on login attempts (V2.2.1)
- MFA available for all users (V2.8)
Evidence: [Link to ASVS verification records] -
Mantenga la verificación actualizada:
- Los cuestionarios preguntan sobre el estado actual
- Las revisiones mensuales garantizan que sus respuestas sigan siendo precisas
Flujo de trabajo de respuesta a cuestionarios
- Recibir el cuestionario
- Mapear las preguntas a las secciones ASVS
- Verificar el estado de verificación actual
- Escribir la respuesta con enlaces de evidencia
- El Security Champion la revisa antes de la presentación
- Registrar en el sistema CRM/de gestión de acuerdos
Integración en el flujo de trabajo de desarrollo
Los requisitos de seguridad solo funcionan si forman parte de cómo usted construye software.
El rol del Security Champion
El Security Champion debe estar involucrado en estas etapas:
1. Diseño de funcionalidades (antes de codificar)
- Revisar la especificación de la funcionalidad en busca de implicaciones de seguridad
- Identificar los requisitos ASVS aplicables
- Agregar requisitos de seguridad al ticket de la funcionalidad
- Señalar las funcionalidades que necesitan modelado de amenazas
2. Planificación del sprint
- Asegurar que los requisitos de seguridad estén incluidos en las estimaciones
- Identificar las funcionalidades que necesitan revisión de seguridad antes del merge
3. Revisión de código
- Verificar que los requisitos de seguridad están implementados
- Comprobar vulnerabilidades comunes
4. Pruebas
- Verificar que existen pruebas de seguridad y que pasan
- Revisar la cobertura de pruebas para los requisitos de seguridad
Lista de verificación de planificación de funcionalidades
Antes de que una funcionalidad entre en desarrollo:
## Security Review Checklist
Feature: [Name]
Security Champion: [Name]
Date: [Date]
### Data handling
- [ ] What user data does this feature process?
- [ ] Does it introduce new PII fields?
- [ ] Does it involve file uploads?
- [ ] Does it expose data via API?
### Authentication/Authorization
- [ ] Does it require authentication?
- [ ] What authorization checks are needed?
- [ ] Does it change authentication flows?
### Applicable ASVS requirements
[List requirements with IDs]
### Threat considerations
- [ ] How could this feature be abused?
- [ ] What's the worst-case impact?
### Testing requirements
- [ ] What security tests are needed?
- [ ] Can they be automated?
### Notes
[Any special considerations]
Agregando seguridad a las historias de usuario
Incluya la seguridad en la definición de hecho:
As a user, I want to upload a profile picture.
Acceptance criteria:
- [ ] Only JPEG, PNG, GIF allowed (V12.1.1)
- [ ] Maximum file size 5MB (V12.1.2)
- [ ] File type validated by content, not extension (V12.1.3)
- [ ] Files stored outside web root (V12.4.1)
- [ ] Filename sanitized (V12.3.1)
Security requirements: V12.1.1, V12.1.2, V12.1.3, V12.3.1, V12.4.1
Seguridad en CI/CD
Automatice lo que pueda:
# .github/workflows/security.yml
name: Security Checks
on: [push, pull_request]
jobs:
security:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
# Dependency scanning (V10.3)
- name: Run Snyk
uses: snyk/actions/node@master
# SAST scanning (V10.2)
- name: Run Semgrep
uses: returntocorp/semgrep-action@v1
# Secrets detection (V6.4)
- name: Run Gitleaks
uses: gitleaks/gitleaks-action@v2
# Security headers check (V14)
- name: Check security headers
run: |
# Custom script to verify headers in test environment
Seguimiento de la cobertura de requisitos
Mantenga visibilidad sobre su postura de seguridad:
| Métrica | Qué mide |
|---|---|
| % de requisitos verificados | Progreso hacia la línea base |
| Días desde la última verificación | Antigüedad de los controles de seguridad |
| Requisitos por funcionalidad | Deuda de seguridad en la planificación |
| Cobertura de pruebas de requisitos | Nivel de automatización |
| Requisitos de seguridad abiertos | Brecha actual |
Pruebas de requisitos de seguridad
Los requisitos no están completos hasta que se verifican.
Métodos de verificación
Diferentes requisitos necesitan diferentes verificaciones:
| Método | Cuándo usarlo | Ejemplos |
|---|---|---|
| Pruebas automatizadas | Verificaciones repetibles | Longitud de contraseña, validación de entrada, cabeceras de seguridad |
| Revisión de código | Lógica e implementación | Control de acceso, uso criptográfico |
| SAST/DAST | Escaneo amplio de vulnerabilidades | Inyección SQL, XSS, configuraciones incorrectas |
| Pruebas manuales | Escenarios complejos | Abuso de lógica de negocio, omisión de autenticación |
| Pruebas de penetración | Evaluación completa | Todo lo anterior + problemas desconocidos |
Escritura de pruebas de seguridad
Política de contraseñas (V2.1.1):
def test_password_minimum_length():
# Too short - should fail
response = client.post('/register', data={
'email': '[email protected]',
'password': 'short123' # 8 chars
})
assert response.status_code == 400
assert 'password' in response.json['errors']
# Minimum length - should pass
response = client.post('/register', data={
'email': '[email protected]',
'password': 'validpassword1' # 14 chars
})
assert response.status_code == 201
Verificación de autorización (V4.1.1):
def test_user_cannot_access_other_user_data():
# Create two users
user1 = create_user('[email protected]')
user2 = create_user('[email protected]')
# Login as user1
token = login('[email protected]')
# Try to access user2's data
response = client.get(
f'/api/users/{user2.id}/profile',
headers={'Authorization': f'Bearer {token}'}
)
# Should be forbidden
assert response.status_code == 403
Rate limiting (V2.2.1):
def test_login_rate_limiting():
# Make 5 failed login attempts
for i in range(5):
response = client.post('/login', data={
'email': '[email protected]',
'password': 'wrongpassword'
})
# 6th attempt should be blocked
response = client.post('/login', data={
'email': '[email protected]',
'password': 'wrongpassword'
})
assert response.status_code == 429 # Too Many Requests
Cabeceras de seguridad (V14.4):
def test_security_headers():
response = client.get('/')
assert response.headers.get('X-Content-Type-Options') == 'nosniff'
assert response.headers.get('X-Frame-Options') == 'DENY'
assert 'max-age=' in response.headers.get('Strict-Transport-Security', '')
assert response.headers.get('Content-Security-Policy') is not None
Lista de verificación de pruebas ASVS
Para cada requisito implementado, verifique:
## Requirement: V2.1.1 - Password minimum length
### Test coverage
- [ ] Unit test for validation function
- [ ] Integration test for registration endpoint
- [ ] Integration test for password change endpoint
- [ ] UI test for error message display
### Test cases
- [ ] Password exactly 11 characters → rejected
- [ ] Password exactly 12 characters → accepted
- [ ] Password 50+ characters → accepted
- [ ] Password with only spaces → rejected
- [ ] Unicode password → handled correctly
### Verification date
Last verified: [Date]
Verified by: [Name]
Evidence: [Link to test run]
Verificación periódica
Los requisitos de seguridad pueden retroceder. Programe verificaciones regulares:
Semanalmente (automatizado):
- Escaneos de seguridad en CI/CD
- Verificaciones de vulnerabilidades de dependencias
- Verificación de cabeceras de seguridad
Mensualmente (Security Champion):
- Revisar las nuevas funcionalidades en busca de cobertura de requisitos de seguridad
- Comprobar la deriva de requisitos
- Actualizar el estado de los requisitos
Trimestralmente (revisión del equipo):
- Revisión completa de la línea base ASVS
- Verificar que los requisitos "Verificados" de muestra aún pasan
- Actualizar la lista de requisitos excluidos
Anualmente (externo):
- Prueba de penetración contra los requisitos ASVS
- Auditoría de cumplimiento si aplica
- Actualización completa de requisitos
Taller: configurar el seguimiento de requisitos de seguridad
Reserve 3-4 horas.
Parte 1: crear su línea base (60 minutos)
- Descargue el CSV de ASVS 4.0.3 desde GitHub
- Ábralo en una hoja de cálculo
- Para cada requisito, marque:
- Aplicable / No aplicable
- Estado actual
- Prioridad
- Guárdelo como su línea base del proyecto
Entregable: Hoja de cálculo con requisitos aplicables marcados
Parte 2: configurar el seguimiento (45 minutos)
En Jira (o su rastreador de issues):
- Cree el tipo de issue "Security Requirement"
- Agregue campos personalizados (ASVS ID, Estado, Método de verificación)
- Cree issues para los 20 requisitos de mayor prioridad
- Vincule a las funcionalidades existentes donde aplique
Entregable: Sistema de seguimiento configurado, requisitos iniciales introducidos
Parte 3: crear pruebas de verificación (60 minutos)
Elija 5 requisitos que estén "Implementados" y escriba pruebas:
- Escriba una prueba automatizada
- Agréguela a la suite de pruebas
- Verifique que la prueba detecta las violaciones
- Actualice el estado del requisito a "Verificado"
Entregable: 5 requisitos de seguridad con pruebas automatizadas
Parte 4: integrar en el flujo de trabajo (30 minutos)
- Cree una plantilla de lista de verificación de planificación de funcionalidades
- Agregue el paso de revisión de seguridad a su plantilla de PR
- Programe una revisión mensual de requisitos de seguridad
- Documente el proceso
Entregable: Documentación de flujo de trabajo actualizada
Lista de verificación del taller
- Línea base ASVS creada
- Sistema de seguimiento configurado
- Los 20 requisitos principales están en el rastreador
- Al menos 5 requisitos tienen pruebas automatizadas
- La plantilla de planificación de funcionalidades incluye seguridad
- La plantilla de PR incluye revisión de seguridad
- Revisión mensual programada
Consejos prácticos
Tratar con requisitos "No aplicables"
Al marcar un requisito como "No aplicable", documente siempre el porqué:
## V12.1.1 - File Upload Validation
Status: Not Applicable
Justification: Application does not accept file uploads.
Verified by: [Name]
Date: [Date]
Review trigger: If file upload feature is added, this requirement becomes applicable.
Revise los requisitos "No aplicables" trimestralmente — las funcionalidades cambian, y los requisitos previamente excluidos podrían ahora aplicar.
Hacer visibles los requisitos
Integración con Slack/Teams:
- Publique el estado semanal de los requisitos de seguridad
- Alerte sobre requisitos atascados en "En Progreso" durante más de 2 semanas
- Celebre cuando los requisitos pasen a "Verificado"
Panel:
- Cree un panel simple que muestre:
- % de requisitos verificados
- Requisitos por estado
- Requisitos por prioridad
- Tiempo desde la última revisión completa
Revisiones de sprint:
- Incluya los requisitos de seguridad en las demos de sprint
- Muestre qué requisitos se verificaron
- Destaque los nuevos requisitos agregados
Manejo del código heredado
Para aplicaciones existentes sin requisitos de seguridad:
- No intente corregirlo todo de una vez — se abrumará
- Empiece con las nuevas funcionalidades — aplique requisitos al nuevo código
- Aborde primero los requisitos críticos — V2.4 (almacenamiento de contraseñas), V5.3 (XSS)
- Use los incidentes como desencadenantes — si encuentra una vulnerabilidad, agregue el requisito y corrija en todos lados
- Asigne el 10-20% de la capacidad del sprint — el progreso constante supera los esfuerzos heroicos
Requisitos para integraciones de terceros
Al agregar servicios externos, verifique su seguridad:
## Third-Party Security Checklist
Service: [Name]
Purpose: [What it does]
### Data handling
- [ ] What data do we send to this service?
- [ ] Is data encrypted in transit? (V9.1.1)
- [ ] Is data encrypted at rest? (V8.3.1)
- [ ] Where is data stored geographically?
- [ ] What is their data retention policy?
### Authentication
- [ ] How do we authenticate to the service?
- [ ] API keys stored in Passwork (V6.4.1)
- [ ] Keys rotated periodically (V6.4.2)
### Security posture
- [ ] SOC 2 or equivalent certification?
- [ ] Security contact available?
- [ ] Vulnerability disclosure program?
### Incident response
- [ ] How will they notify us of breaches?
- [ ] What is their SLA for security issues?
Approved by: [Security Champion]
Date: [Date]
Review date: [Annual review]
Usando Passwork para la gestión de requisitos
El trabajo de requisitos de seguridad genera muchos artefactos sensibles — credenciales, claves, informes, evidencias de auditoría. Tenerlos dispersos por Google Drive, hilos de correo y laptops individuales es en sí mismo un fallo de requisitos de seguridad.
Passwork es un gestor de contraseñas y secretos empresarial que encaja naturalmente en este flujo de trabajo:
Almacene artefactos de seguridad sensibles:
- Claves API para herramientas de escaneo de seguridad (SAST, DAST, SCA) — con seguimiento de caducidad y registro de auditoría
- Credenciales para pruebas de seguridad y cuentas de staging
- Credenciales de acceso para paneles de seguridad y herramientas de monitoreo
- Claves de cifrado para datos de seguridad sensibles
Organice por nivel de acceso. Cree una bóveda dedicada para herramientas de seguridad con acceso limitado al Security Champion y a los líderes de equipo relevantes. Los permisos granulares de Passwork le permiten compartir elementos específicos sin exponer toda la bóveda — útil cuando un desarrollador necesita acceso temporal a una cuenta de prueba pero no a los secretos de producción.
Adjunte documentación. Passwork admite notas seguras y archivos adjuntos, por lo que los informes de pruebas de penetración, evidencias de auditoría y aprobaciones de requisitos pueden vivir junto a las credenciales con las que se relacionan — no en una carpeta compartida con acceso más amplio.
Rastree quién accedió a qué. El registro de auditoría registra cada acceso, cambio y exportación. Si un requisito de seguridad implica demostrar el control de acceso a un auditor, los registros de Passwork son evidencias que puede exportar directamente.
Rote al dar de baja empleados. Cuando un desarrollador que tenía acceso a las credenciales de herramientas de seguridad se va, Passwork le muestra exactamente a qué tenía acceso — para que rote las credenciales correctas inmediatamente, no semanas después cuando alguien note que algo está mal.
Errores comunes
Error 1: todos los requisitos, sin priorización
Intentar implementar todos los requisitos ASVS a la vez. El equipo se abruma, nada se hace.
Corrección: Empiece con el Nivel 1 para las funcionalidades críticas. Amplíe gradualmente. Algunos requisitos importan más que otros para su aplicación.
Error 2: requisitos sin verificación
Los requisitos están documentados pero nunca probados. El estado dice "Implementado" basándose en la memoria de alguien.
Corrección: Cada estado "Verificado" necesita evidencia — resultados de pruebas, notas de revisión o hallazgos de auditoría.
Error 3: seguridad después del desarrollo
El Security Champion revisa después de que la funcionalidad está construida. Los cambios son costosos y apresurados.
Corrección: Incluya al Security Champion en el diseño de la funcionalidad. Agregue requisitos de seguridad antes de que comience la codificación.
Error 4: ejercicio de una sola vez
La línea base de requisitos se crea, nunca se actualiza. Las nuevas funcionalidades no obtienen requisitos.
Corrección: La revisión de requisitos es continua. Cada funcionalidad obtiene requisitos de seguridad. Revisiones mensuales.
Error 5: sin participación de desarrolladores
El equipo de seguridad crea requisitos. Los desarrolladores no saben que existen.
Corrección: Los desarrolladores deben ayudar a seleccionar e implementar los requisitos. Deben escribir pruebas de seguridad. Responsabilidad compartida.
Cómo explicarlo al liderazgo
Si alguien le pregunta por qué dedica tiempo a los requisitos de seguridad:
"Estamos implementando un enfoque estructurado de seguridad usando OWASP ASVS — un catálogo estándar de la industria de requisitos de seguridad. En lugar de esperar que nuestro código sea seguro, estamos definiendo exactamente qué significa la seguridad para nuestra aplicación y verificando que está implementada. Esto detecta los problemas durante el desarrollo en lugar de en producción, reduce el coste de las correcciones de seguridad y nos proporciona evidencia para el cumplimiento y los cuestionarios de seguridad de los clientes."
Versión corta: "Estamos definiendo los requisitos de seguridad de antemano para construirlo correctamente la primera vez en lugar de tener que corregirlo más tarde."
Autocomprobación
Línea base de requisitos
- Descargado y revisado el OWASP ASVS
- Identificados los requisitos aplicables para su proyecto
- Creado el documento de línea base con justificaciones
- Requisitos priorizados (crítico, alto, medio, bajo)
Seguimiento
- Requisitos rastreados en el sistema de issues
- Flujo de trabajo de estados definido
- Estado actual conocido para cada requisito
Integración
- La planificación de funcionalidades incluye requisitos de seguridad
- El Security Champion revisa las funcionalidades antes del desarrollo
- La plantilla de PR incluye lista de verificación de seguridad
- Los requisitos de seguridad están en la definición de hecho
Verificación
- Pruebas automatizadas para los requisitos clave
- Calendario de verificación regular
- Evidencia documentada para los requisitos verificados
Marque al menos 10 de 13 elementos antes de continuar.
Qué sigue
Tiene un marco para definir y hacer seguimiento de los requisitos de seguridad. Próximo capítulo: gestión de secretos — mover los secretos fuera del código y hacia un almacenamiento adecuado con rotación y controles de acceso.