DevSecOps consiste en ejecutar controles de seguridad automáticos dentro del pipeline CI/CD, de modo que cada cambio de código se revise en busca de vulnerabilidades, dependencias inseguras, secretos expuestos y configuraciones peligrosas antes de llegar a producción. Para empezar no necesitas comprar nada: con herramientas open source como Semgrep, Trivy, gitleaks y ZAP, más reglas de protección de ramas y credenciales temporales para la nube, cubres lo esencial en pocas semanas.
Qué es DevSecOps y por qué importa en una empresa pequeña
DevSecOps es la práctica de integrar la seguridad en cada etapa del ciclo de desarrollo y despliegue, automatizándola en el mismo pipeline que compila, prueba y publica el software. La idea es detectar los problemas cuando cuestan minutos arreglar (en el pull request) y no cuando cuestan semanas (después de un incidente o de una auditoría).
Para una empresa en Ecuador que desarrolla su propia app, su API o su plataforma web, el pipeline es además el lugar donde se concentran las llaves del reino: acceso al repositorio, a la nube y a la base de datos de producción. Un pipeline inseguro es una puerta trasera hacia todos tus sistemas. Por eso DevSecOps tiene dos partes: seguridad en el pipeline (escanear lo que construyes) y seguridad del pipeline (proteger la propia cadena de construcción).
Los controles de seguridad del pipeline, uno por uno
SAST: análisis estático del código
Revisa el código fuente sin ejecutarlo y detecta patrones como inyección SQL, validaciones ausentes o uso inseguro de criptografía. Es rápido y da retroalimentación en el pull request. Su debilidad son los falsos positivos, así que conviene empezar con un conjunto reducido de reglas.
SCA: análisis de dependencias
La mayor parte del código de una aplicación moderna viene de librerías de terceros. El análisis de composición de software (SCA) compara tus dependencias contra bases de vulnerabilidades conocidas y propone actualizaciones. Es, con frecuencia, el control con mejor relación esfuerzo-beneficio.
Escaneo de secretos
Busca llaves de API, contraseñas y tokens dentro del código y del historial de git. Lo ideal es bloquearlos antes del commit (pre-commit hook o protección de push del proveedor de git), porque una vez publicados hay que considerarlos comprometidos y rotarlos.
Escaneo de infraestructura como código (IaC)
Revisa plantillas de Terraform, CloudFormation o Kubernetes en busca de buckets públicos, puertos de administración abiertos a internet o cifrado deshabilitado. Es la forma de aplicar un checklist de hardening de AWS antes de desplegar, no después.
Escaneo de imágenes de contenedores
Analiza las imágenes Docker en busca de paquetes del sistema operativo vulnerables y malas prácticas (ejecutar como root, imágenes base desactualizadas).
DAST: pruebas dinámicas
Ataca la aplicación desplegada en un entorno de pruebas, como lo haría un atacante externo, y encuentra fallas que el análisis estático no ve: cabeceras de seguridad ausentes, problemas de sesión o endpoints expuestos. No reemplaza una prueba de intrusión manual; si tu producto expone APIs, complementa con lo que explicamos en seguridad de APIs y OWASP API Top 10.
SBOM, firma y procedencia
Un SBOM (Software Bill of Materials) es el inventario de todos los componentes de tu software; te permite responder en minutos si estás afectado cuando se publica una vulnerabilidad crítica en una librería. La firma de artefactos y la procedencia (provenance) demuestran que una imagen o un binario salió de tu pipeline y no fue alterado. El marco SLSA (Supply-chain Levels for Software Artifacts) organiza estas garantías en niveles; su versión 1.2 incluye un track de Build y uno de Source.
Etapas del pipeline y herramientas open source de ejemplo
| Etapa | Control | Ejemplos de herramientas | Cuándo bloquear |
|---|---|---|---|
| Antes del commit | Secretos | gitleaks (pre-commit), protección de push del proveedor de git | Siempre |
| Pull request | SAST | Semgrep Community Edition u Opengrep, CodeQL | Hallazgos críticos con regla validada |
| Pull request | SCA | Dependabot, Renovate, OSV-Scanner, Trivy | Vulnerabilidades críticas con parche disponible |
| Pull request | IaC | Checkov, Trivy | Recursos públicos o sin cifrado |
| Build | Imagen de contenedor | Trivy, Grype | Críticas con parche disponible |
| Build | SBOM y firma | Syft (SBOM en CycloneDX o SPDX), Sigstore cosign, attestations del proveedor de CI | Falta de firma en producción |
| Staging | DAST | ZAP (Zed Attack Proxy) | Solo alertar al inicio |
| Despliegue | Verificación | Política que solo admite imágenes firmadas | Siempre, una vez madura |
Las herramientas son ejemplos, no una lista obligatoria. Lo importante es cubrir cada control con algo que tu equipo realmente mantenga.
Seguridad del propio pipeline
- Protección de ramas: nadie hace push directo a main; todo cambio pasa por pull request con al menos una revisión y con los checks de seguridad en verde.
- Tokens de CI con mínimo privilegio: configura los permisos por defecto del token del pipeline en solo lectura y súbelos solo en el job que lo necesite.
- OIDC hacia la nube en vez de llaves de larga duración: GitHub Actions, GitLab y otros pueden obtener credenciales temporales de AWS, Azure o Google Cloud mediante OpenID Connect. Así eliminas las access keys guardadas como secretos, que son uno de los hallazgos más comunes en una prueba de intrusión.
- Fija las acciones de terceros por commit SHA: GitHub indica que fijar una acción a su SHA completo es la única forma de usarla como versión inmutable. No es teoría: en marzo de 2025 se comprometió la acción tj-actions/changed-files (CVE-2025-30066) y en marzo de 2026 se reescribieron tags de la acción de Trivy; en ambos casos, quien apuntaba a un tag ejecutó código malicioso que buscaba secretos.
- Separa entornos: los pull requests de forks o ramas no confiables no deben acceder a secretos de producción.
Cómo implementarlo sin bloquear a los desarrolladores
El error clásico es encender todos los escáneres en modo bloqueo el primer día. El equipo recibe cientos de hallazgos, la mitad irrelevantes, y empieza a ignorarlos o a desactivarlos. Un despliegue gradual funciona mejor:
- Semana 1-2: escaneo de secretos en modo bloqueo (casi no tiene falsos positivos) y SCA con actualizaciones automáticas.
- Semana 3-4: SAST, IaC y contenedores en modo solo alerta. Revisa los resultados, ajusta reglas y marca falsos positivos.
- Mes 2: bloquea solo hallazgos críticos nuevos (no la deuda histórica) con solución conocida.
- Mes 3 en adelante: DAST en staging, SBOM y firma de imágenes; plan para reducir la deuda existente por prioridad.
Define también un proceso de excepciones: quién puede aceptar un riesgo, por cuánto tiempo y con qué justificación. Sin eso, las excepciones se vuelven permanentes.
Errores comunes que conviene evitar:
- Comprar una plataforma antes de decidir quién revisa sus hallazgos; una herramienta sin responsable genera tableros que nadie lee.
- Escanear solo la rama principal, de modo que los problemas aparecen después del merge y no en la revisión.
- Asegurar el código de la aplicación mientras los secretos del CI, los runners y los roles de despliegue siguen con permisos excesivos.
Métricas para saber si funciona
- Tiempo medio de remediación de vulnerabilidades críticas y altas, desde que se detectan hasta que se despliega la corrección.
- Hallazgos críticos abiertos en producción y su tendencia mes a mes.
- Porcentaje de repositorios con todos los controles activos.
- Tasa de falsos positivos por herramienta: si supera lo que el equipo tolera, las alertas dejan de leerse.
- Secretos detectados antes del push frente a los encontrados después.
Estas métricas además son evidencia directa para auditorías de ISO 27001 y para demostrar medidas técnicas de seguridad bajo la LOPDP. Si prefieres no montarlo solo, nuestro equipo de ciberseguridad puede configurarlo junto a tus desarrolladores.
Preguntas frecuentes
¿Qué diferencia hay entre DevOps y DevSecOps?
DevOps une desarrollo y operaciones para entregar software de forma rápida y automatizada. DevSecOps añade la seguridad a esa misma cadena: los controles (análisis de código, dependencias, secretos, configuración e imágenes) se ejecutan automáticamente en el pipeline, en lugar de depender de una revisión manual al final del proyecto. El objetivo es entregar igual de rápido, pero con menos vulnerabilidades.
¿Cuánto cuesta implementar DevSecOps?
Las herramientas base pueden ser gratuitas y open source; el costo real está en el tiempo de configuración, el ajuste de reglas y la remediación de hallazgos. Para un equipo pequeño con pocos repositorios, la puesta en marcha de los controles esenciales suele tomar algunas semanas de trabajo. El alcance depende del número de repositorios, lenguajes, nubes y del nivel de deuda existente.
¿DevSecOps reemplaza a una prueba de intrusión?
No. Los escáneres automáticos encuentran patrones conocidos, pero no entienden la lógica de negocio: no detectan que un usuario pueda ver los pedidos de otro cliente cambiando un identificador. Un pentest manual sigue siendo necesario antes de lanzamientos importantes y al menos una vez al año. DevSecOps reduce lo que el pentest encuentra y abarata la corrección.
¿Qué es un SBOM y por qué me lo piden?
Un SBOM es la lista de todos los componentes y librerías que forman tu software, con sus versiones. Clientes corporativos y del sector público lo solicitan cada vez más porque permite saber en minutos si un producto está afectado por una vulnerabilidad nueva. Se genera automáticamente en el pipeline con herramientas como Syft, en formatos estándar como CycloneDX o SPDX.
¿Por dónde empiezo si mi equipo es de dos o tres desarrolladores?
Empieza por lo que más riesgo elimina con menos ruido: escaneo de secretos con bloqueo, actualizaciones automáticas de dependencias, protección de la rama principal con revisión obligatoria y OIDC para desplegar en la nube sin llaves guardadas. Con eso cubres los incidentes más comunes. SAST, IaC y DAST pueden llegar después, primero en modo alerta.
Conclusión
DevSecOps no es una herramienta sino un hábito: cada cambio pasa por controles automáticos que el equipo entiende y confía, y el pipeline se protege como lo que es, un acceso privilegiado a producción. Empieza por secretos, dependencias y credenciales temporales, mide el tiempo de remediación y endurece los bloqueos a medida que bajan los falsos positivos.
En MisterProSoft diseñamos e implementamos pipelines seguros, auditamos código y configuraciones de nube, y hacemos las pruebas de intrusión que complementan la automatización. Conoce nuestro servicio de ciberseguridad o agenda una consulta gratuita.