DevSecOps seguridad integrada en CI/CD

DevOps + un escáner al final es lo que muchos llaman DevSecOps en marketing pero no lo es. DevSecOps real significa integrar seguridad en cada etapa del ciclo: cultura de equipo (devs + ops + sec hablan a diario, comparten métricas y propiedad), tooling integrado en el flujo natural de trabajo (no escaneos manuales de auditoría), políticas como código, automatización de controles. El escáner al final genera fricción y se ignora; el control bien integrado pre-commit, en PR y en pipeline encuentra el problema cuando aún cuesta minutos arreglarlo, no semanas.

Tres líneas de trabajo. Diagnóstico: medimos madurez DevSecOps actual contra OWASP SAMM o BSIMM y devolvemos roadmap priorizado. Implantación: añadimos controles en cada etapa del pipeline (pre-commit hooks, SAST, SCA, secrets scanning, IaC scanning, DAST, container scanning, firma de artefactos, gestión de secretos, policy as code). Operación: el equipo asume el flujo y nosotros lo gobernamos: triaje de hallazgos, ajuste de reglas para bajar falsos positivos, mejora continua. Dos modelos contractuales: programa continuo de operación o auditorías puntuales periódicas.

Lo que use el cliente. CI/CD: GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Bitbucket Pipelines, CircleCI, ArgoCD. SAST/SCA/secrets: Semgrep, SonarQube, CodeQL, Snyk, OSV-Scanner, Trivy, Gitleaks, TruffleHog. IaC scanning: Checkov, tfsec, KICS, Terrascan. Container/K8s: Trivy, Grype, Falco, Kyverno, OPA Gatekeeper. DAST: ZAP, Burp Suite Enterprise, Nuclei. Firma y SBOM: cosign/sigstore, syft, CycloneDX, SPDX. Gestión de secretos: Vault, AWS/Azure/GCP Secrets Manager, CyberArk. No imponemos herramienta: trabajamos con lo que el equipo ya conoce o lo más cercano al stack.

Bien implantado, lo contrario: reduce el tiempo total de entrega porque atrapa problemas en minutos en lugar de en semanas. Mal implantado sí frena, y por eso el primer mes se dedica a ajustar reglas para bajar falsos positivos por debajo del umbral que el equipo tolera (típicamente <15%), priorizar controles bloqueantes solo en lo crítico (secretos, dependencias críticas), y darle al equipo de desarrollo visibilidad y control sobre qué se ejecuta y cuándo. El criterio: el desarrollador medio nunca debería ver una alerta absurda.

Un diagnóstico de madurez: 2-3 semanas, 6-12 mil euros. Implantación inicial para un stack típico (1-3 repos, GitHub/GitLab Actions, cloud principal): 6-12 semanas, 1-2 ingenieros, 24-60 mil euros. Plataformas grandes con múltiples lenguajes, monorepos y varios entornos cloud se mueven en 12-24 semanas y 60-140 mil euros. La operación continua posterior se factura como suscripción mensual; las auditorías periódicas como proyecto cerrado. Antes de presupuestar pedimos diagnóstico inicial para dimensionar el alcance real.

Cinco que miden el equipo de seguridad y otras cinco que miden los equipos de desarrollo y operación. Seguridad: % vulnerabilidades detectadas pre-producción, MTTR de vulnerabilidades por severidad, % builds bloqueados por hallazgo crítico, % secretos prevenidos vs detectados a posteriori, cobertura de controles por servicio. Desarrollo/Operación: lead time to secure deploy (tiempo total desde commit a producción aprobada), tasa de despliegues por semana (DORA metric clásica), tasa de fallos en cambio, tiempo medio de recuperación, satisfacción del equipo dev con los controles de seguridad (medida formalmente, no asumida).

Encaja directamente con el bloque de gestión de desarrollo seguro. ISO 27001:2022 (A.8.25 a A.8.30) cubre planificación, separación de entornos, configuración y testing de seguridad en el desarrollo. NIS2 art. 21.2.f exige políticas y procedimientos para evaluar la eficacia. DORA art. 9 + 24-27 cubre programa de pruebas y resiliencia. PCI DSS v4 req. 6 entero es desarrollo y mantenimiento seguro. Lo que entregamos —pipeline documentado, evidencia de controles ejecutados, gestión de hallazgos, mejora continua medida— es exactamente la evidencia que pide cada auditor.

Sobre lo existente siempre que sea viable. Si ya hay GitHub Actions/GitLab CI/Jenkins con flujos consolidados, añadimos los controles dentro de esos flujos sin reescribirlos. Si la base es muy débil (sin CI/CD real, builds manuales, despliegues a mano), recomendamos consolidar primero el flujo DevOps y después añadir la capa Sec. No imponemos herramienta de CI/CD: trabajamos con lo que el equipo va a mantener después de irnos nosotros.

El programa continuo es la opción para clientes que quieren tratar DevSecOps como práctica viva: nosotros operamos el flujo, triamos hallazgos, ajustamos reglas, levantamos alertas estructurales, formamos al equipo. Es lo que da mejor resultado en términos de madurez sostenida. Las auditorías puntuales son la opción para clientes con equipo capaz que prefiere asumir la operación y contratar revisiones externas periódicas (típicamente trimestrales o semestrales): el alcance es revisar el pipeline, identificar drift, validar que los controles siguen activos y operativos, y entregar informe ejecutivo + plan de mejora. Mismo equipo Hard2bit, mismo nivel técnico, modelos contractuales distintos.

Llamada de 30 minutos para entender vuestro stack, el momento (post-incidente, exigencia regulatoria, modernización, escala) y el modelo que os encaja. Si tiene sentido, walkthrough técnico de 1-2 horas con un tech lead y un sysadmin/SRE. Con eso emitimos propuesta firme en 48-72 horas: diagnóstico inicial, alcance de implantación, equipo asignado, entregables y precio cerrado. Si vemos que conviene combinar con auditoría de código puntual antes de implantar pipeline, lo decimos honestamente.