O modelo tradicional e os seus custos
No modelo clásico de desenvolvemento de software, a seguridade era dominio dun equipo especializado que probaba o sistema xusto antes do despregamento en produción. As vulnerabilidades atopadas xeraban custosos desvíos de traballo — os programadores tiñan que volver a tarefas pechadas hai tempo, entender o contexto de semanas atrás e introducir cambios que afectaban outros elementos xa probados. A frustración era mutua: o equipo de seguridade era percibido como un bloqueo, os programadores como non preparados para escribir código seguro.
A filosofía shift-left
Shift-left significa literalmente desprazar as actividades de seguridade cara á esquerda no eixe temporal do proxecto — da fase de probas e despregamento á fase de deseño e codificación. Canto máis cedo se detecte unha vulnerabilidade, máis económico e sinxelo é eliminalá. Un programador que ve unha alerta de vulnerabilidade no seu contorno de desenvolvemento segundos despois de escribir o código problemático corríxea inmediatamente, sen perder o contexto e sen interromper o fluxo de traballo de todo o equipo.
Automatización no pipeline CI/CD
Shift-left materializándose integrando controis de seguridade automáticos en cada etapa do pipeline de integración e entrega continuas. Cada commit desencadea unha secuencia de verificacións de seguridade que bloquea o paso á etapa seguinte se se detectan vulnerabilidades graves.
- SAST (análise estática do código) — detecta vulnerabilidades no código fonte sen executalo: inxeccións SQL, deserializacións non seguras, uso de funcións perigosas
- SCA (análise de composición do software) — escanea dependencias para detectar vulnerabilidades coñecidas, comproba licenzas, detecta bibliotecas obsoletas
- Escaneado de segredos — bloquea a confirmación accidental de contrasinais, chaves API e certificados no repositorio
- DAST (análise dinámica) — proba a aplicación en funcionamento nun contorno de proba, simulando ataques ás interfaces API e web
- Probas de contenedores e infraestrutura — verificación da configuración de imaxes Docker e definicións de infraestrutura para detectar erros de seguridade
A seguridade como código
As organizacións maduras tratan as políticas de seguridade como código — defínenas en ficheiros de configuración almacenados no repositorio, sometidos a revisión e probas. Isto significa que as regras WAF, as políticas de rede, as configuracións de sistemas de detección de anomalías e as políticas RBAC se xestionan co mesmo rigor que o código da aplicación. Os cambios requiren revisión, o historial é auditable e o rollback é posible en minutos.
A cultura como fundamento
As ferramentas sen cultura non dan resultados. DevSecOps require que os programadores entendan as consecuencias das decisións de deseño para a seguridade e traten as alertas non como obstáculos, senón como feedback valioso. Isto implica investimento en formación, dispoñibilidade de expertos de seguridade como socios no deseño (non auditores), métricas claras e responsabilidade compartida das vulnerabilidades. ESKOM.AI aplica o modelo DevSecOps no desenvolvemento dos seus propios sistemas, combinando a automatización de probas cunha cultura de responsabilidade compartida pola seguridade en cada etapa do ciclo de desenvolvemento.