El trabajo de seguridad de código abierto no es “especial”
(sethmlarson.dev)Resumen clave
- Desmitificar la seguridad: Se critica el 'excepcionalismo de la seguridad', que trata el trabajo de seguridad como un ámbito especial, y se enfatiza que debe abordarse dentro de la categoría general de la ingeniería.
- Integración de la gestión de riesgos: Los incidentes de seguridad se definen no como desastres casi mágicos, sino como un tipo de 'riesgo operativo', similar a una caída en la disponibilidad (Availability) del sistema o en el rendimiento (Performance).
- Dirección práctica: Se propone tratar la deuda de seguridad (Security Debt) igual que la deuda técnica y construir guardrails que permitan a los equipos de ingeniería resolver problemas por sí mismos sin la intervención de un equipo de seguridad especializado.
Análisis en profundidad
1. Problemas del excepcionalismo de la seguridad (Security Exceptionalism)
En muchas organizaciones, la seguridad se considera "algo especial, difícil de entender y que solo un pequeño grupo de expertos puede manejar". Esta perspectiva aísla a los equipos de seguridad del proceso de ingeniería y, como resultado, genera efectos secundarios como los siguientes.
- Trabajo en silos: El personal de seguridad crea cuellos de botella en el flujo de trabajo o exige únicamente cumplimiento normativo sin conocer el contexto de desarrollo.
- Transferencia de responsabilidad: Ante la pregunta "¿mi código es seguro?", los desarrolladores dejan de poder responder por sí mismos y pasan a depender solo de la aprobación del equipo de seguridad.
2. Redefinir la seguridad como un problema de ingeniería
El texto sostiene que la seguridad no debe verse como una habilidad especial, sino como un subconjunto de la calidad y confiabilidad del software.
- Las vulnerabilidades como bugs: La corrupción de memoria (Memory Corruption) o la inyección (Injection), antes que ser objetivos de ataques especiales, son defectos de diseño derivados de una falla en la validación de entradas.
- Introducir métricas operativas: La seguridad debe gestionarse no según el 'cumplimiento', sino con métricas operativas como 'MTTD (tiempo medio de detección)' y 'MTTR (tiempo medio de recuperación)'.
3. Solución: abstracción y guardrails (Paved Road)
La clave no es que los expertos en seguridad hagan todas las revisiones de código, sino construir un entorno donde a los ingenieros les resulte 'difícil equivocarse'.
- Configuraciones seguras por defecto: Aplicar por defecto medidas como la prevención de XSS a nivel de framework para reducir la carga cognitiva de los desarrolladores.
- Herramientas de autoservicio: Integrar análisis estático (SAST) y escaneo de dependencias dentro del pipeline de CI/CD para reflejarlo de inmediato en el ciclo de desarrollo.
Comparación de conceptos clave
| Categoría | Seguridad tradicional (Special) | Seguridad basada en ingeniería (Not Special) |
|---|---|---|
| Objetivo | Bloqueo perfecto y cumplimiento normativo | Mitigación de riesgos y resiliencia del sistema |
| Responsable | Equipo de seguridad centralizado | Todo el equipo de ingeniería de forma distribuida |
| Herramientas | Escáneres externos, revisiones manuales | Pruebas automatizadas, análisis estático, abstracciones de librerías |
| Respuesta ante fallas | Investigación del incidente y búsqueda de culpables | Mejora del sistema mediante post-mortem |
4 comentarios
Parece que algo salió mal en el resumen.
https://rosettalens.com/s/ko/security-work-isnt-special
Sería bueno que vieran el texto original con esto.
El enlace al texto original y la traducción al coreano no incluían el contenido presentado en el análisis en profundidad. ¿A qué texto se refirió para el contenido del análisis en profundidad? ¿Es un texto escrito directamente por usted?
Parece que voy a tener que crear gems nuevos... T_T Lo siento.
Ah, qué raro. Parece que Gemini tuvo algún mal funcionamiento. T_T
Creo que sería bueno revisar la traducción.