Dominio 2: Gestión del ciclo de vida de software seguro
Dominio 2: Gestión del ciclo de vida de software seguro
Peso en el examen: 11%.
Si el Dominio 1 te dio el vocabulario, el Dominio 2 te enseña a gestionar la seguridad como un programa a lo largo de todo el SDLC. Aquí el CSSLP piensa como un líder de programa de seguridad: define la estrategia, elige estándares, mide, reporta, coloca gates de decisión y se asegura de que la seguridad viva en cada metodología, hasta el retiro de la aplicación.
La idea rectora del dominio: la seguridad no es una fase, es una propiedad transversal del ciclo de vida. No existe “la fase de seguridad al final”; existe seguridad en cada fase.
Subdominios oficiales:
- 2.1 Gestionar seguridad dentro de las metodologías de desarrollo.
- 2.2 Identificar y adoptar estándares de seguridad.
- 2.3 Delinear estrategia y roadmap de seguridad.
- 2.4 Definir y desarrollar documentación de seguridad.
- 2.5 Definir métricas de seguridad.
- 2.6 Desmantelamiento/decommission de aplicaciones.
- 2.7 Mecanismos de reporte de estado de seguridad.
- 2.8 Gestión de riesgos integrada (security gates, go/no-go).
- 2.9 Prácticas operacionales seguras promovidas desde el ciclo de vida.
2.1 Seguridad dentro de las metodologías de desarrollo
La seguridad debe adaptarse a la metodología del equipo, no imponer un proceso ajeno. Las tres grandes familias son waterfall, agile y DevOps/DevSecOps.
Waterfall
Modelo secuencial y por fases: requisitos → diseño → implementación → verificación → mantenimiento. La seguridad se inserta como actividades y entregables definidos por fase (requisitos de seguridad, threat model en diseño, revisión de código en implementación, pruebas de seguridad en verificación). Es predecible y documentado, pero rígido: un hallazgo tardío es caro de corregir porque implica retroceder fases.
Agile
Trabajo iterativo e incremental en sprints. El reto: la seguridad no puede ser un “gran documento por adelantado”. Se integra con:
- Security user stories y abuse/misuse stories en el backlog.
- Definition of Done (DoD) que incluye criterios de seguridad (p. ej. “pasó SAST”, “sin vulns críticas”).
- Un security champion en el equipo.
- Threat modeling incremental por feature.
El riesgo del agile es que “no hay tiempo para seguridad”; el CSSLP lo resuelve integrando la seguridad dentro de las ceremonias existentes, no como algo aparte.
DevOps y DevSecOps
DevOps une desarrollo y operaciones con automatización y entrega continua (CI/CD). DevSecOps inserta la seguridad en el pipeline automatizado: la seguridad se convierte en código y en controles automáticos que corren en cada commit/merge.
- Security as code: políticas, escaneos y controles versionados y automatizados.
- Gates automáticos en el pipeline: SAST, SCA, DAST, IaC scanning, secret scanning.
- Shift-left llevado al extremo, pero también shift-right (seguridad en runtime/observabilidad).
- Cultura de responsabilidad compartida: “todos somos responsables de la seguridad”.
flowchart TB
subgraph W[Waterfall]
w1[Requisitos<br/>+ req. seguridad] --> w2[Diseno<br/>+ threat model] --> w3[Implementacion<br/>+ code review] --> w4[Verificacion<br/>+ pruebas seguridad] --> w5[Mantenimiento]
end
subgraph A[Agile]
a1[Backlog con<br/>security stories] --> a2[Sprint con<br/>DoD de seguridad] --> a3[Incremento<br/>revisado] --> a1
end
subgraph D[DevSecOps]
d1[Commit] --> d2[SAST/SCA/secret scan] --> d3[Build] --> d4[DAST/IaC scan] --> d5[Deploy] --> d6[Monitoreo runtime] --> d1
end💡 Tip de examen: el principio transversal es shift-left: mover la seguridad lo más temprano posible en el ciclo, porque corregir en requisitos/diseño es órdenes de magnitud más barato que en producción. En cualquier metodología, “encontrarlo antes” es la respuesta preferida.
| Aspecto | Waterfall | Agile | DevSecOps |
|---|---|---|---|
| Ritmo | Fases largas y secuenciales | Sprints iterativos | Continuo (CI/CD) |
| Seguridad se inserta como… | Entregables por fase | Stories + DoD + champion | Gates automatizados en el pipeline |
| Threat modeling | Una vez, en diseño | Incremental por feature | Continuo / automatizado donde se pueda |
| Fortaleza | Trazabilidad y documentación | Flexibilidad, feedback rápido | Velocidad + automatización de controles |
| Riesgo | Hallazgos tardíos y caros | ”No hay tiempo para seguridad” | Herramientas mal calibradas frenan el pipeline |
2.2 Identificar y adoptar estándares de seguridad
El profesional CSSLP no reinventa la rueda: adopta estándares y marcos reconocidos y los adapta al contexto. Debes reconocer para qué sirve cada uno.
| Estándar / marco | Qué es | Para qué sirve |
|---|---|---|
| ISO/IEC 27034 | Estándar de application security | Integra seguridad en el ciclo de vida vía Application Security Controls (ASC) y el ONF/ANF (marcos organizacional y de aplicación) |
| NIST SSDF — SP 800-218 | Secure Software Development Framework | Conjunto de prácticas de alto nivel agrupadas en 4 grupos: PO (Prepare the Organization), PS (Protect the Software), PW (Produce Well-Secured Software), RV (Respond to Vulnerabilities) |
| PCI DSS | Estándar de la industria de tarjetas de pago | Requisitos de seguridad para software/entornos que procesan datos de tarjetas |
| ISO/IEC 27001/27002 | SGSI y controles de seguridad de la información | Marco de gestión y catálogo de controles organizacionales |
| OWASP ASVS | Application Security Verification Standard | Requisitos verificables por niveles para apps web/APIs |
| NIST SP 800-53 / 800-160 | Catálogo de controles / ingeniería de sistemas seguros | Referencia de controles y de security engineering |
| NIST Cybersecurity Framework (CSF) | Marco de gestión de ciberriesgo | Funciones: Identify, Protect, Detect, Respond, Recover (+ Govern) |
El NIST SSDF (SP 800-218) merece atención especial porque el examen actualizado lo referencia como marco de facto para desarrollo seguro y porque conecta con exigencias de cadena de suministro (Executive Order 14028 en EE.UU.).
flowchart LR
subgraph SSDF[NIST SSDF - SP 800-218]
PO[PO - Preparar la organizacion] --> PS[PS - Proteger el software]
PS --> PW[PW - Producir software bien asegurado]
PW --> RV[RV - Responder a vulnerabilidades]
end💡 Tip de examen: no confundas el propósito de los marcos. ISO 27034 = seguridad de aplicaciones (ASC/ONF/ANF); NIST SSDF (800-218) = prácticas de desarrollo seguro (PO/PS/PW/RV); PCI DSS = datos de tarjetas de pago; OWASP SAMM/BSIMM = madurez del programa (no de una app puntual). Reconocer “para qué sirve cada uno” resuelve muchas preguntas.
Cómo elegir y adoptar un estándar
Adoptar un estándar no es copiarlo tal cual; es un proceso de selección y adaptación:
flowchart TD
A[Identificar drivers:<br/>regulacion, contratos, riesgo] --> B[Seleccionar estandar/marco<br/>segun proposito y contexto]
B --> C[Gap analysis:<br/>estado actual vs estandar]
C --> D[Adaptar al contexto<br/>tailoring]
D --> E[Implementar e integrar<br/>en el SDLC]
E --> F[Medir cumplimiento<br/>y mejorar]
F -.-> CLos drivers (motivadores) determinan qué estándar es obligatorio: si procesas tarjetas de pago, PCI DSS no es opcional; si vendes al gobierno de EE.UU., el NIST SSDF y las exigencias de SBOM aplican. El resto se elige por ajuste al riesgo y al contexto. Un buen programa suele combinar varios: un marco de desarrollo (SSDF), uno de app security (ISO 27034/ASVS) y uno de madurez (SAMM/BSIMM).
💡 Tip de examen: cuando un estándar es exigido por ley, regulación o contrato (como PCI DSS para datos de tarjeta), su adopción es obligatoria, no una decisión de riesgo interna. Distingue lo obligatorio por cumplimiento de lo elegido por buenas prácticas.
2.3 Estrategia y roadmap de seguridad
La estrategia define la dirección de largo plazo del programa de seguridad de software y su alineación con los objetivos del negocio; el roadmap la traduce en iniciativas priorizadas en el tiempo.
Elementos de una estrategia de seguridad del SDLC:
- Objetivos alineados al negocio y al apetito de riesgo.
- Estado actual vs objetivo (gap analysis), a menudo usando un modelo de madurez (SAMM/BSIMM).
- Iniciativas priorizadas por riesgo y por retorno.
- Recursos, roles y presupuesto.
- Métricas para medir avance (ver 2.5).
flowchart LR
E[Estado actual<br/>madurez] --> G[Gap analysis]
G --> R[Roadmap priorizado<br/>por riesgo]
R --> M[Metricas de avance]
M -.retroalimenta.-> E💡 Tip de examen: una buena estrategia prioriza por riesgo, no por “lo que esté de moda” ni por lo más fácil. Ante opciones, elige la que ataca primero el mayor riesgo para el negocio.
2.4 Documentación de seguridad
El programa vive en su documentación. El CSSLP distingue tipos de documentos y su carácter obligatorio (visto en el Dominio 1: política → estándar → procedimiento → guideline).
| Documento | Rol en el SDLC seguro |
|---|---|
| Política de desarrollo seguro | El “deber ser” obligatorio del programa |
| Estándares de codificación segura | Reglas técnicas concretas (p. ej. cómo manejar entrada, errores, secretos) |
| Procedimientos | Pasos exactos (cómo correr un threat model, cómo triar un hallazgo) |
| Guidelines | Buenas prácticas recomendadas |
| Documentación de arquitectura de seguridad | Threat models, decisiones de diseño, controles |
| Runbooks / playbooks | Respuesta a incidentes, despliegue seguro, rollback |
La documentación habilita repetibilidad, auditoría y onboarding: sin ella, la seguridad depende de personas concretas y no escala.
2.5 Métricas de seguridad
“No puedes gestionar lo que no mides”. Las métricas convierten la seguridad en algo medible, comparable y reportable.
| Métrica | Qué mide | Por qué importa |
|---|---|---|
| Defect density | Defectos de seguridad por unidad de código (p. ej. por KLOC) | Compara calidad entre módulos/releases |
| MTTR (Mean Time To Remediate/Repair) | Tiempo medio para remediar una vulnerabilidad | Mide agilidad de respuesta |
| MTTD (Mean Time To Detect) | Tiempo medio para detectar un problema | Mide capacidad de detección |
| Cobertura (coverage) | % de código/componentes cubiertos por pruebas/escaneos | Mide el alcance del aseguramiento |
| Vulnerabilidades por severidad | Distribución crítica/alta/media/baja | Prioriza remediación |
| % de hallazgos remediados en SLA | Cumplimiento de plazos de remediación | Mide disciplina del programa |
Además, dos categorías de indicadores de gestión:
- KPI (Key Performance Indicator): mide desempeño hacia un objetivo (p. ej. ”% de proyectos con threat model”).
- KRI (Key Risk Indicator): es una señal temprana de riesgo creciente (p. ej. “número de vulnerabilidades críticas abiertas > umbral”).
flowchart LR
KPI[KPI<br/>mide DESEMPENO] --> Dash[Dashboard de<br/>gestion]
KRI[KRI<br/>alerta de RIESGO creciente] --> Dash
Dash --> Dec[Decisiones de<br/>direccion]💡 Tip de examen: distingue KPI (mide desempeño/eficacia) de KRI (anticipa riesgo). Y recuerda: una buena métrica es específica, medible y accionable; una métrica que nadie usa para decidir es ruido. El MTTR es la métrica estrella para medir capacidad de respuesta a vulnerabilidades.
2.6 Desmantelamiento (decommission) de aplicaciones
El ciclo de vida incluye el final. Retirar una aplicación de forma insegura es una fuente clásica de fugas de datos (bases de datos huérfanas, backups olvidados, endpoints aún vivos). El decomisionado seguro cubre:
| Actividad | Descripción |
|---|---|
| Retención de datos | Determinar qué datos deben conservarse y por cuánto (obligaciones legales/regulatorias) |
| Archivado (archival) | Mover a almacenamiento de largo plazo lo que debe conservarse, de forma segura |
| Sanitización / data disposal | Borrado seguro de los datos que ya no se conservan (wiping, criptoborrado, destrucción de medios) |
| EOL / EOS (End of Life / End of Support) | Planificar el fin de soporte y las dependencias afectadas |
| Revocación de accesos y credenciales | Cerrar cuentas de servicio, rotar/eliminar secretos, cerrar integraciones |
| Actualizar inventario y DNS | Retirar endpoints, registros y referencias para evitar activos huérfanos |
flowchart TD
A[Decision de retiro] --> B[Determinar retencion<br/>legal/regulatoria]
B --> C[Archivar lo que se conserva]
C --> D[Sanitizar/destruir el resto]
D --> E[Revocar accesos,<br/>rotar/eliminar secretos]
E --> F[Retirar endpoints,<br/>DNS e inventario]
F --> G[Aplicacion retirada<br/>de forma segura]💡 Tip de examen: en el decomisionado, la sanitización/destrucción segura de datos y la retención según obligaciones legales son los dos pilares. Un error típico de examen es “apagar el servidor” sin sanitizar; los datos residuales siguen siendo un riesgo. Primero decides qué conservar (retención) y luego destruyes de forma segura el resto.
2.7 Reporte de estado de seguridad
La dirección necesita visibilidad del estado de seguridad para tomar decisiones. Los mecanismos de reporte traducen las métricas a las distintas audiencias:
- Dashboards ejecutivos: postura de riesgo en lenguaje de negocio (para C-level/board).
- Reportes técnicos: hallazgos, severidades, remediación (para equipos).
- Reportes de cumplimiento: evidencia frente a auditores y reguladores.
La clave es adaptar el mensaje a la audiencia: la junta directiva quiere riesgo e impacto de negocio; el equipo de desarrollo quiere hallazgos accionables. Un buen reporte es oportuno, veraz y orientado a la decisión.
2.8 Gestión de riesgos integrada: security gates y go/no-go
La gestión de riesgo del Dominio 1 se materializa aquí como puntos de decisión (gates) dentro del ciclo de vida. Un security gate es un punto donde se verifica el cumplimiento de criterios de seguridad antes de avanzar de fase.
- En cada gate se evalúan criterios (p. ej. “sin vulnerabilidades críticas abiertas”, “threat model aprobado”, “pruebas de seguridad pasadas”).
- La decisión es go / no-go: se avanza solo si se cumplen los criterios, o si el dueño del riesgo acepta formalmente el riesgo residual.
- En DevSecOps, muchos gates son automáticos (el pipeline falla si un escaneo detecta algo crítico).
flowchart LR
Fase1[Diseno] --> G1{Gate:<br/>threat model ok?}
G1 -->|Go| Fase2[Implementacion]
G1 -->|No-go| Fix1[Remediar]
Fase2 --> G2{Gate:<br/>SAST/SCA limpios?}
G2 -->|Go| Fase3[Release]
G2 -->|No-go| Fix2[Remediar o<br/>aceptar riesgo formalmente]💡 Tip de examen: un gate no es un checkbox burocrático: es una decisión de riesgo. Si no se cumplen los criterios, la salida no es “avanzar igual”, sino remediar o que el propietario del negocio acepte el riesgo residual por escrito. La decisión de go/no-go pertenece al dueño del riesgo, informado por seguridad.
2.9 Prácticas operacionales seguras desde el ciclo de vida
El ciclo de vida debe promover prácticas que faciliten una operación segura aguas abajo: logging y monitoreo adecuados, manejo seguro de configuración y secretos, capacidad de parcheo, y diseño para la detección y respuesta. La idea: lo que se construye en desarrollo condiciona lo que se puede defender en operación. Diseñar “para operar de forma segura” es parte del trabajo del SDLC, no algo que se improvisa en producción.
Marcos y modelos de referencia
Microsoft SDL (Security Development Lifecycle)
El Microsoft SDL fue pionero (surgido tras el memo de Trustworthy Computing de 2002) y ofrece un conjunto de prácticas de seguridad integradas por fase. Popularizó ideas hoy estándar: threat modeling, análisis de superficie de ataque, revisión de código de seguridad, security push, y el Final Security Review (FSR) antes de release. Es un modelo prescriptivo de actividades a lo largo del ciclo.
Modelos de madurez: OWASP SAMM y BSIMM
A diferencia de un estándar de actividades, un modelo de madurez te dice qué tan maduro es tu programa y cómo evolucionarlo. Los dos grandes son SAMM y BSIMM.
| Aspecto | OWASP SAMM | BSIMM |
|---|---|---|
| Naturaleza | Prescriptivo: te dice qué deberías hacer para madurar | Descriptivo: te dice qué hacen de facto las organizaciones observadas |
| Origen | Comunidad OWASP (abierto) | Estudio de firmas reales (Synopsys), datos observados |
| Estructura | 5 funciones de negocio (Governance, Design, Implementation, Verification, Operations), con prácticas y 3 niveles de madurez | 12 prácticas en 4 dominios (Governance, Intelligence, SSDL Touchpoints, Deployment) |
| Uso típico | Autoevaluación y roadmap de mejora | Benchmarking contra la industria |
| Pregunta que responde | ”¿Qué debería implementar para mejorar?" | "¿Qué hacen las empresas maduras y cómo me comparo?” |
flowchart TB
subgraph SAMM[OWASP SAMM - prescriptivo]
s1[Governance] --- s2[Design] --- s3[Implementation] --- s4[Verification] --- s5[Operations]
end
subgraph BSIMM[BSIMM - descriptivo]
b1[Governance] --- b2[Intelligence] --- b3[SSDL Touchpoints] --- b4[Deployment]
end💡 Tip de examen: la distinción de oro es SAMM = prescriptivo (“qué deberías hacer”, te da un roadmap) vs BSIMM = descriptivo (“qué hacen realmente las organizaciones”, te da un benchmark). Si la pregunta habla de comparar tu programa contra la industria, es BSIMM; si habla de una guía para mejorar, es SAMM.
Shift-left y security champions
- Shift-left: desplazar las actividades de seguridad hacia la izquierda del ciclo (más temprano), donde corregir es más barato y efectivo. Es el principio operativo que une todo el dominio.
- Security champions: desarrolladores dentro de cada equipo que actúan como puente y multiplicador de seguridad. No son el equipo de seguridad; escalan la cultura de seguridad porque están dentro del equipo de producto y hablan su idioma. Resuelven el cuello de botella de “pocos expertos de seguridad para muchos equipos”.
flowchart LR
Cost[Costo de corregir]
R[Requisitos<br/>1x] --> D[Diseno<br/>~5x] --> I[Implementacion<br/>~10x] --> T[Testing<br/>~15x] --> P[Produccion<br/>~30x+]
R -.shift-left: corrige aqui.-> R💡 Tip de examen: los security champions escalan la seguridad en organizaciones donde el equipo de AppSec es pequeño frente a muchos equipos de desarrollo. Son facilitadores embebidos, no auditores externos ni reemplazo del equipo de seguridad.
Cultura de seguridad y capacitación
Ningún proceso ni herramienta compensa una cultura débil. El Dominio 2 subraya que la formación (security awareness y secure coding training) es un control administrativo clave y un habilitador de todo lo demás:
- Awareness general para toda la organización (phishing, manejo de datos).
- Secure coding training específico para desarrolladores, ligado a los lenguajes y frameworks que usan.
- Formación por rol: arquitectos en threat modeling, QA en pruebas de seguridad, PMs en gestión de riesgo.
- Los security champions como mecanismo de difusión continua de esa cultura.
La lógica: la seguridad falla en el eslabón más débil (Dominio 1), y muchas veces ese eslabón es una persona que no sabía. Capacitar es reducir riesgo de forma costo-efectiva.
RACI de seguridad
Una matriz RACI aclara quién hace qué en las actividades de seguridad, evitando el clásico “pensé que lo hacía el otro equipo”.
| Letra | Rol | Significado |
|---|---|---|
| R — Responsible | Ejecuta | Quien hace la tarea |
| A — Accountable | Rinde cuentas | El único dueño final; aprueba y responde por el resultado |
| C — Consulted | Consultado | Aporta input (comunicación bidireccional) |
| I — Informed | Informado | Se le comunica el resultado (unidireccional) |
Ejemplo aplicado a un threat model:
| Actividad | Dev | Security Champion | Equipo AppSec | Product Owner |
|---|---|---|---|---|
| Ejecutar el threat model | R | R | C | I |
| Aprobar el threat model | A | C | ||
| Remediar hallazgos | R | C | C | A |
💡 Tip de examen: en RACI, la clave es que solo puede haber un “A” (Accountable) por actividad: una única persona rinde cuentas. Puede haber varios “R”. Confundir “Accountable” (responde por el resultado) con “Responsible” (ejecuta) es un error típico.
Cómo se integra todo el dominio
flowchart TD
Estr[Estrategia + roadmap<br/>priorizados por riesgo] --> Est[Adoptar estandares<br/>ISO 27034 / NIST SSDF]
Est --> Met[Metodologia<br/>waterfall/agile/DevSecOps]
Met --> Doc[Documentacion:<br/>politicas, estandares, procedimientos]
Doc --> Gate[Security gates<br/>go/no-go]
Gate --> Metr[Metricas + reporte<br/>KPI/KRI, MTTR]
Metr --> Mad[Modelo de madurez<br/>SAMM/BSIMM]
Mad -.retroalimenta.-> Estr
Gate --> Dec[Decommission seguro<br/>al final del ciclo]El dominio describe un ciclo de mejora continua: defines estrategia, adoptas estándares, los integras en tu metodología, los documentas, colocas gates, mides y reportas, evalúas tu madurez y retroalimentas la estrategia, hasta retirar la aplicación de forma segura.
Antipatrones de gestión del ciclo de vida
El examen contrasta la buena gestión con errores clásicos de programa:
| Antipatrón | Por qué falla | Enfoque correcto |
|---|---|---|
| Seguridad como “fase final” | Hallazgos tardíos y caros | Shift-left: seguridad en cada fase |
| Gates como checkbox burocrático | No frenan riesgo real | Gate = decisión go/no-go de riesgo |
| Métricas que nadie usa | Ruido sin decisión | Métricas accionables (MTTR, cobertura) |
| Copiar un estándar sin adaptarlo | No encaja con el contexto | Tailoring al riesgo y la realidad del equipo |
| Retirar una app “apagando el servidor” | Datos residuales expuestos | Decommission con retención + sanitización |
| Depender de pocos expertos de AppSec | No escala | Security champions embebidos |
| Confundir SAMM con BSIMM | Elección de herramienta errónea | SAMM = mejorar; BSIMM = comparar |
Checklist mental del líder de S-SDLC
Un profesional CSSLP, al gestionar el ciclo de vida, se pregunta constantemente:
flowchart TD
A[Esta la seguridad<br/>integrada en cada fase?] --> B[Que estandares<br/>me obligan o convienen?]
B --> C[Tengo gates de<br/>go/no-go por riesgo?]
C --> D[Estoy midiendo<br/>lo que importa?]
D --> E[Se como retirar<br/>la app de forma segura?]
E --> F[Estoy escalando la cultura<br/>via champions y formacion?]Este recorrido resume el dominio: integración por fase, estándares, gates, métricas, decommission y cultura. Si puedes responder afirmativamente a cada punto con evidencia, tu programa de ciclo de vida es maduro.
Puntos clave
- La seguridad es transversal a todo el SDLC, no una fase final. Se adapta a la metodología: entregables por fase (waterfall), stories + DoD + champion (agile), gates automatizados en el pipeline (DevSecOps).
- Shift-left es el principio operativo: corregir temprano es órdenes de magnitud más barato.
- Reconoce el propósito de los estándares: ISO 27034 (app security/ASC), NIST SSDF SP 800-218 (prácticas PO/PS/PW/RV), PCI DSS (datos de tarjetas), OWASP ASVS (requisitos verificables).
- La estrategia prioriza por riesgo; el roadmap la temporaliza; la documentación (política → estándar → procedimiento → guideline) la hace repetible y auditable.
- Métricas: defect density, MTTR (respuesta a vulnerabilidades), cobertura; distingue KPI (desempeño) de KRI (riesgo creciente).
- Decommission seguro: primero retención legal/regulatoria, luego archivado de lo que se conserva y sanitización/destrucción del resto; revocar accesos y retirar activos huérfanos.
- Los security gates son decisiones go/no-go de riesgo: si no se cumplen criterios, se remedia o el dueño del negocio acepta el riesgo residual por escrito.
- Microsoft SDL es prescriptivo por fases (threat modeling, FSR). OWASP SAMM = prescriptivo (roadmap de mejora) vs BSIMM = descriptivo (benchmark de la industria).
- Security champions escalan la seguridad como facilitadores embebidos en los equipos; RACI aclara responsabilidades, con un único “A” (Accountable) por actividad.