Seguridad desde el diseño: integrar DevSecOps en la cultura del desarrollo.

En tecnología, la velocidad se ha convertido casi en una religión. Los equipos corren por desplegar antes, automatizar más y reducir al mínimo ese ciclo interminable entre “el qué” y la producción. Y claro, en esa carrera siempre hay un peaje que se acaba pagando: la seguridad. Y como siempre… el susto llega tarde.

Hoy todo pasa tan rápido que ya se mide a los equipos por un único indicador: la velocidad con la que entregan. Automatizamos despliegues, recortamos ciclos y nos apoyamos en arquitecturas cada vez más repartidas. Aun así, en esa obsesión por optimizarlo todo, la seguridad sigue viéndose como un obstáculo, algo que se revisa cuando el código ya está en el aire.

Y entonces pasa lo previsible: vulnerabilidades detectadas cuando ya no hay margen y la vieja excusa flotando en el aire: “eso es cosa del equipo de Seguridad”. Esto, a bastantes os resultará familiar.

DevSecOps nace precisamente para romper con esa forma de pensar.

No se trata de llenar el pipeline de herramientas ni de poner más pasos en rojo, sino de cambiar la mentalidad: hacer que la seguridad sea parte del crecimiento natural del proyecto, tan integrada como las pruebas unitarias o el control de versiones.

De DevOps a DevSecOps: un cambio necesario

DevOps nació con una idea clara: que desarrollo y operaciones dejaran de ir cada uno por su lado. La meta, en teoría, era sencilla: entregar software más rápido y con menos sustos. Y durante un tiempo funcionó. ¡Vaya que si funcionó!

Hasta que llegó el cloud y con él, mis queridos (y temidos) microservicios, las dependencias externas y esa sensación permanente de que todo podía romperse con un simple terraform apply.

Y ahí, claro, apareció la invitada que nunca falla: la Seguridad, esperándonos en la puerta con su sonrisa de “os lo dije”.
DevSecOps no es un nombre bonito para otra moda del sector; es un recordatorio.Nos recuerda que la seguridad no puede seguir siendo la auditoría del final, sino una tarea compartida desde el primer commit por cualquiera del equipo.

Eso significa que quienes desarrollan, prueban o despliegan deben tener presente lo esencial, contar con las herramientas adecuadas y detectar los fallos cuando todavía huelen a nuevo.

Porque ya no basta con que el equipo de seguridad revise el resultado final, jure en arameo y se lleve la culpa. Cada parte del proceso, cada pipeline, contenedor o variable, tiene que nacer bajo el principio de seguridad por defecto.

Pero incluso con todo eso, el obstáculo no es solo técnico: también es mental. Y ese cambio de chip no se impone con políticas, se gana con ejemplos. Cuando el equipo ve que integrar seguridad no frena nada, sino que evita dolores de cabeza y ahorra dinero, el resto llega solo.

Seguridad desde el diseño: el principio olvidado

La idea de Security by Design no es algo recién inventado. Ya se veía en los estándares de OWASP y en leyes europeas como el GDPR. Pero, sinceramente, casi nunca se aplica bien cuando se está programando.

Seguridad desde el diseño no es solo ponerle parches al final. Significa que cada vez que decides algo sobre la parte técnica, piensas en cómo afectará la privacidad, la integridad y si el sistema estará siempre disponible.

Desde cómo los servicios comprueban quién eres, hasta cómo guardas las contraseñas o controlas los cambios de los secretos en los sitios donde los guardas. Un sistema seguro no se arregla con parches: se crea así desde el principio.

Así que lo importante de DevSecOps no son las herramientas, sino que toda persona técnica se acostumbre a preguntarse: ¿esto es seguro? y ¿cómo puedo asegurarme de eso?

Tres pilares para integrar la seguridad en el ciclo de vida del software

1 Automatización y detección temprana.

La automatización es la mejor “herramienta” del equipo de desarrollo. Si las comprobaciones de seguridad se integran en los pipelines, se convierten en el flujo de trabajo.

• SAST (Static Application Security Testing): revisa el código en busca de vulnerabilidades antes del despliegue.
• DAST (Dynamic Application Security Testing): realiza pruebas en entornos de staging o QA.
• SCA (Software Composition Analysis): encuentra librerías y dependencias vulnerables.
• Infra as Code Scanning: examina configuraciones Terraform, Kubernetes o CloudFormation para asegurar cumplimiento de políticas.

Cuanto antes se encuentre un fallo, menor es el precio para arreglarlo y el peligro de mostrarlo.

2 Responsabilidad compartida.

El anterior modelo de seguridad como “puente de control” ha pasado de moda. Ahora, cada rol dentro del ciclo de desarrollo tiene responsabilidad variada.

• El equipo de desarrollo debe comprender y entender las implicaciones de seguridad del código que suben.
• Operaciones debe asegurar que los despliegues, secretos y permisos se manejen con el principio de menor privilegio.
• El equipo de arquitectura tiene que definir patrones que incorporen la seguridad by default.
• Y los equipos de seguridad deben acompañar y formar, así como dotar de herramientas en vez de bloquear, asumiendo que les tendrán una manía intrínseca por parte del resto de equipos.

El éxito de DevSecOps depende de un mensaje simple:

“La seguridad no es un departamento (o equipo, o un círculo): es una práctica de todo el mundo

3 Cultura y formación continua.

Ninguna herramienta sustituye al criterio humano. Ni siquiera nuestra querida nueva mejor amiga, la IA, aunque nos aporte un valor adicional. La mejor defensa sigue siendo un equipo consciente y con medios tecnológicos.

La seguridad debe formar parte de las retros y de los sprints reviews, así como de la planificación. Incluir cápsulas de formación, talleres de simulacros de respuesta ante incidentes crea reflejos técnicos/humanos y un lenguaje común. Convertir la seguridad en un hábito requiere constancia.

Cuando la dirección técnica refuerza este mensaje, el cambio cultural se consolida.

Herramientas y prácticas clave (sin perder el enfoque humano)

Existen centenas de herramientas que pueden formar parte de una cadena DevSecOps, pero lo importante es la integración coherente y no la repetición. Ejemplos frecuentes en entornos cloud-native:

• GitLab CI, GitHub Actions, Jenkins con jobs de seguridad automatizados.
• Trivy, Checkov o tfsec para analizar imágenes y código IaC.
• Vault, Secret Manager o AWS KMS para la gestión segura de secretos.
• OPA, Conftest para políticas de cumplimiento automatizadas.
• SonarQube, OWASP ZAP, Dependabot para análisis de código y dependencias.

Sin embargo, el factor diferencial está en el proceso y la cultura. No basta con configurar alertas, hay que interpretarlas, priorizarlas y resolverlas.

Un pipeline seguro no es el que nunca falla, sino aquel que enseña al equipo a fallar antes y aprender , aplicando los aprendizajes a posteriori para reducir esos tiempos de respuesta.

Caso práctico: pipeline seguro con Terraform y GitLab CI

Un ejemplo real de integración DevSecOps puede verse en la construcción de un pipeline para IaC.

Supongamos un proyecto que utiliza Terraform para desplegar recursos en GCP y que orquesta sus despliegues a través de GitLab CI. No es difícil la suposición, ya que existe un expertise muy alto precisamente en este objetivo. El escenario es garantizar que todos los merge request pasen controles de seguridad y cumplimiento antes de aplicarse al entorno que corresponda.

Para aportar el siguiente ejemplo hago uso de la primera anécdota que tuve con mis primeros pipelines: tfsec saltaba por todo. Recuerdo que casi todos los commits fallaban al detectar recursos sin etiquetas y buckets abiertos. Pero también, sobre esta anécdota, cabe decir que aunque inicialmente fue extremadamente frustrante, no pasó más de una semana hasta que el equipo ya escribía el código pensando en pasar todas las pruebas. Y lo mejor: no hubo que obligar a nadie, sino que el hábito se creó solo.

1 Escaneo estático del código IaC (Terraform)

Usando herramientas como tfsec, cada commit se valida frente a un conjunto de políticas:

• No permitir instancias sin etiquetas.
• Evitar recursos públicos (por ejemplo, buckets o bases de datos con public_access = true).
• Verificar que los secretos no estén hardcodeados.

Cada commit activa un escaneo automático con tfsec para detectar configuraciones inseguras:

stages:
  - validate
  - security
  - deploy
 
validate:
  stage: validate
  script:
    - terraform fmt -check
    - terraform validate
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
 
security_scan:
  stage: security
  image: aquasec/tfsec:latest
  script:
    - tfsec --format json --out tfsec-report.json .
  artifacts:
    paths:
      - tfsec-report.json
  allow_failure: false
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

Este bloque de código obliga a que cualquier cambio en los ficheros .tf sea validado antes de desplegar, evitando malas configuraciones como buckets públicos o recursos sin cifrado.

2 Validación de cumplimiento (Policy as Code)

Con Conftest o OPA (Open Policy Agent) se definen reglas que el código debe respetar antes de ser aprobado. Por ejemplo, en el fichero policies/terraform.rego:

package terraform.security
 
deny[msg] {
  input.resource_type == "google_compute_disk"
  not input.values.disk_encryption_key
  msg = sprintf("El recurso %s no tiene cifrado habilitado", [input.name])
}
 
deny[msg] {
  input.resource_type == "google_compute_instance"
  not startswith(input.values.zone, "europe-")
  msg = sprintf("La instancia %s no está en una región permitida", [input.name])
}

Y en el pipeline:

policy_check:
  stage: security
  image: openpolicyagent/conftest
  script:
    - conftest test terraform-plan.json --policy ./policies/
  needs:
    - job: security_scan
  allow_failure: false

3 Gestión de secretos

Los pipelines nunca exponen credenciales en texto plano, totalmente prohibido para nuestra salud y la de nuestros clientes. Se integran con Secret Manager o HashiCorp Vault, recuperando las claves mediante variables protegidas que rotan automáticamente. Como ejemplo de código:

deploy:
  stage: deploy
  image: hashicorp/terraform:1.7
  script:
    - export TF_VAR_db_password=$(gcloud secrets versions access latest --secret="db-password")
    - terraform init
    - terraform plan -out=plan.out
    - terraform apply -auto-approve plan.out
  environment:
    name: production
  when: manual
  needs:
    - job: policy_check

Con when: manual se exige una aprobación antes de aplicar cambios, lo que nos garantiza la trazabilidad, y lo que nos lleva al siguiente paso.

4 Despliegue controlado

El job de terraform apply solo se ejecuta si las fases anteriores pasan satisfactoriamente. Esto requiere approval manual por parte de una persona responsable, garantizando trazabilidad y doble validación.

5 Auditoría y reporting

Cada ejecución genera un informe de seguridad que queda guardado en el repositorio, y que nos será útil para futuras auditorías.

Con este enfoque el equipo gana velocidad y sin perder control, lo cual es muy importante ya que un cliente no mide únicamente esa velocidad, sino que valora enormemente el control y gestión de esto mismo.

Los equipos de desarrollo pueden desplegar con autonomía, mientras las políticas aseguran cumplimiento en todos los entornos.

reports:
  stage: security
  script:
    - cat tfsec-report.json | jq '.results | length'
    - echo "Generando informe de seguridad..."
  artifacts:
    when: always
    expire_in: 7 days
    paths:
      - tfsec-report.json

Este informe puede archivarse o integrarse en una herramienta, por ejemplo en un SIEM, permitiendo auditorías periódicas y métricas de cumplimiento.

Conclusión: de la política al hábito

Adoptar DevSecOps no va de redactar una nueva política corporativa ni de dar por cerrado el trabajo cuando el documento está firmado. Va de algo mucho más simple, y a la vez más difícil: cambiar hábitos.

El verdadero avance se nota cuando cada decisión técnica lleva implícita una pregunta: “¿es seguro esto?” Cuando los pipelines no castigan, sino que enseñan. Y cuando los equipos dejan de ver la seguridad como una piedra en el camino y empiezan a verla como un acelerador de calidad. Es ahí cuando el cambio empieza a ser real.

Porque al final, la madurez de una organización no se mide por cuántas herramientas usa, sino por cómo las personas las entienden y las aplican para construir software confiable.

Recuerdo aquel entorno del ejemplo anterior: la verdadera señal de madurez no fue tener más escaneos, sino cuando el propio equipo dejó de preguntar “¿tenemos que pasar el escaneo?” y empezó a decir “¿por qué este control aún no está automatizado?”. Ese cambio de actitud valió más que cualquier herramienta nueva.

En ese momento comprendí que DevSecOps ya no era un rol ni un proceso, sino una forma de pensar compartida por todo el mundo.