Seguridad on Adur

Seguridad shift-left: integrando Trivy y Semgrep en GitLab CI

Mon, 16 Mar 2026 00:00:00 +0000

Por qué estas dos herramientas y no otras

La oferta de herramientas de seguridad para pipelines es enorme, y es fácil acabar con un pipeline que tarda veinte minutos solo en escaneos. Después de probar varias combinaciones, me quedo con Trivy y Semgrep por una razón sencilla: cubren dos superficies de ataque distintas con mínima fricción.

Semgrep analiza tu código fuente buscando patrones peligrosos — inyecciones SQL, deserialización insegura, secretos hardcodeados. Lo hace rápido y sin necesitar compilar nada. Trivy, por su parte, se encarga de todo lo que no es tu código: dependencias con CVEs conocidos, imágenes base desactualizadas, configuraciones de IaC problemáticas. Entre los dos cubres código propio y código ajeno.

Ambas son open-source, se ejecutan sin servidor externo y producen salida JSON que puedes parsear fácilmente en CI. No necesitas licencias ni dashboards de terceros para empezar.

Estructura del pipeline

La idea es que la seguridad no sea una etapa aislada al final, sino algo que se ejecuta en paralelo con el resto de checks. Este es el esquema general:

1
2
3
4
5
6
7
8
9


stages:
 - test
 - security
 - build
 - deploy

variables:
 TRIVY_SEVERITY: "HIGH,CRITICAL"
 SEMGREP_RULES: "p/owasp-top-ten p/security-audit"

La etapa security corre al mismo nivel que test. Si algún escaneo falla, el pipeline se detiene antes de construir la imagen o desplegar nada.

Configurando Semgrep

Job básico

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


semgrep:
 stage: security
 image: semgrep/semgrep:latest
 script:
 - semgrep ci --config "$SEMGREP_RULES" --json --output semgrep-results.json
 artifacts:
 paths:
 - semgrep-results.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Esto ejecuta Semgrep en cada merge request y en cada push a la rama principal. Los resultados se guardan siempre como artefacto, incluso si el pipeline falla — querrás poder revisarlos después.

Reglas personalizadas

Los rulesets genéricos están bien para empezar, pero en cuanto tengas patrones propios que quieras detectar, necesitarás reglas custom. Crea un directorio .semgrep/ en la raíz del proyecto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# .semgrep/no-env-secrets.yml
rules:
 - id: no-os-environ-secrets
 patterns:
 - pattern: os.environ[$KEY]
 - metavariable-regex:
 metavariable: $KEY
 regex: ".*(SECRET|PASSWORD|TOKEN|KEY).*"
 message: "Acceso directo a secretos desde variables de entorno. Usa el gestor de secretos."
 languages: [python]
 severity: WARNING

Y referéncialo en el pipeline:

1
2


variables:
 SEMGREP_RULES: "p/owasp-top-ten p/security-audit .semgrep/"

Gestionando falsos positivos

Va a haber falsos positivos. Es inevitable. Lo que importa es cómo los gestionas. La peor reacción es desactivar la regla entera o poner allow_failure: true. En su lugar, usa anotaciones inline:

1
2


# nosemgrep: python.lang.security.audit.hardcoded-password
TEST_PASSWORD = "dummy" # fixture de tests, no se usa en producción

Cada supresión debería tener un comentario que explique por qué es seguro ignorarla. Sin excepción. Si no puedes justificarlo, no lo suprimas.

Para supresiones más amplias, usa .semgrepignore:

1
2
3
4


# Excluir fixtures de test
tests/fixtures/
# Excluir código generado automáticamente
*_generated.py

Configurando Trivy

Escaneo de dependencias

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


trivy-fs:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy fs --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-fs.json .
 artifacts:
 paths:
 - trivy-fs.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Trivy examina los lockfiles del proyecto (package-lock.json, requirements.txt, go.sum, etc.) y cruza las versiones con bases de datos de vulnerabilidades. El flag --exit-code 1 hace que el job falle si encuentra algo HIGH o CRITICAL.

Escaneo de imágenes de contenedor

Si construyes imágenes Docker, escanéalas antes de publicarlas en el registry:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


trivy-image:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 needs:
 - job: build-image
 artifacts: true
 script:
 - trivy image --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-image.json "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
 artifacts:
 paths:
 - trivy-image.json
 when: always
 rules:
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Este job depende del build de la imagen (con needs) y solo se ejecuta en la rama principal, no en cada MR. Escanear imágenes es más lento que escanear el filesystem, así que reserva eso para lo que realmente se va a desplegar.

Escaneo de IaC

Una ventaja de Trivy que a menudo se pasa por alto es que también analiza configuraciones de infraestructura:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


trivy-iac:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy config --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-iac.json .
 artifacts:
 paths:
 - trivy-iac.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 changes:
 - "**/*.tf"
 - "**/Dockerfile"
 - "**/*.yml"
 - "**/*.yaml"

Detecta Dockerfiles que corren como root, archivos de Terraform con security groups demasiado abiertos, y configuraciones de Kubernetes sin límites de recursos. El bloque changes hace que solo se ejecute cuando se modifican archivos relevantes, evitando escaneos innecesarios.

Políticas de bloqueo

No empieces bloqueando todo desde el primer día. Eso genera frustración, workarounds creativos y al final alguien pone allow_failure: true en todos los jobs de seguridad.

Mejor hacerlo por fases:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


# Fase 1: Solo informar
semgrep:
 allow_failure: true

# Fase 2: Bloquear solo críticos
semgrep:
 script:
 - semgrep ci --config "$SEMGREP_RULES" --json --output semgrep-results.json
 - |
 CRITICAL=$(jq '[.results[] | select(.extra.severity == "ERROR")] | length' semgrep-results.json)
 if [ "$CRITICAL" -gt 0 ]; then
 echo "Bloqueado: $CRITICAL hallazgos críticos"
 exit 1
 fi
 allow_failure: false

# Fase 3: Bloquear high + critical
# ... ajustar el filtro jq

Lo mismo aplica para Trivy. El flag --severity ya te permite controlar qué niveles bloquean el pipeline. Empieza solo con CRITICAL, y cuando el equipo se haya adaptado, añade HIGH.

El pipeline completo

Poniendo todo junto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79


stages:
 - test
 - security
 - build
 - deploy

variables:
 TRIVY_SEVERITY: "HIGH,CRITICAL"
 SEMGREP_RULES: "p/owasp-top-ten p/security-audit"

semgrep:
 stage: security
 image: semgrep/semgrep:latest
 script:
 - semgrep ci --config "$SEMGREP_RULES" --json --output semgrep-results.json
 - |
 CRITICAL=$(jq '[.results[] | select(.extra.severity == "ERROR")] | length' semgrep-results.json)
 echo "Hallazgos críticos: $CRITICAL"
 if [ "$CRITICAL" -gt 0 ]; then
 echo "Pipeline bloqueado"
 exit 1
 fi
 artifacts:
 paths:
 - semgrep-results.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

trivy-fs:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy fs --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-fs.json .
 artifacts:
 paths:
 - trivy-fs.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

trivy-config:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 script:
 - trivy config --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-iac.json .
 artifacts:
 paths:
 - trivy-iac.json
 when: always
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 changes:
 - "**/*.tf"
 - "**/Dockerfile"
 - "**/*.yml"

trivy-image:
 stage: security
 image:
 name: aquasec/trivy:latest
 entrypoint: [""]
 needs:
 - job: build
 artifacts: true
 script:
 - trivy image --severity "$TRIVY_SEVERITY" --exit-code 1 --format json --output trivy-image.json "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
 artifacts:
 paths:
 - trivy-image.json
 when: always
 rules:
 - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

Semgrep y los escaneos de Trivy corren en paralelo dentro de la etapa security. Si cualquiera falla, el pipeline se detiene antes de construir o desplegar.

Integrando resultados en merge requests

Los reportes JSON están bien para auditoría, pero los desarrolladores necesitan feedback visible directamente en el MR. GitLab soporta reportes de seguridad nativos si usas las plantillas oficiales, pero con herramientas externas puedes parsear el JSON y comentar en el MR:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


comment-results:
 stage: .post
 image: alpine:latest
 script:
 - apk add --no-cache curl jq
 - |
 SEMGREP_COUNT=$(jq '.results | length' semgrep-results.json 2>/dev/null || echo "0")
 TRIVY_COUNT=$(jq '.Results[]?.Vulnerabilities // [] | length' trivy-fs.json 2>/dev/null || echo "0")

 BODY="### Resumen de seguridad\n- Semgrep: ${SEMGREP_COUNT} hallazgos\n- Trivy: ${TRIVY_COUNT} vulnerabilidades"

 curl --request POST \
 --header "PRIVATE-TOKEN: ${GITLAB_API_TOKEN}" \
 --header "Content-Type: application/json" \
 --data "{\"body\": \"$BODY\"}" \
 "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/notes"
 rules:
 - if: $CI_PIPELINE_SOURCE == "merge_request_event"
 allow_failure: true

No es lo más elegante, pero funciona. Si usas GitLab Ultimate tienes los reportes de seguridad integrados. Si no, esto da visibilidad suficiente.

Caché y rendimiento

Los escaneos añaden tiempo al pipeline, y si ese tiempo es excesivo el equipo los acabará desactivando. Algunas cosas que ayudan:

1
2
3
4
5
6
7
8


trivy-fs:
 variables:
 TRIVY_CACHE_DIR: ".trivycache/"
 cache:
 key: trivy-db
 paths:
 - .trivycache/
 # ...resto del job

Cachear la base de datos de vulnerabilidades de Trivy evita descargarla en cada ejecución. Son unos 40MB que se descarga de GitHub, y en runners compartidos esa descarga puede tardar bastante.

Para Semgrep, el propio binario ya es rápido, pero si tu repositorio es grande, limita los paths:

1
2
3


semgrep:
 script:
 - semgrep ci --config "$SEMGREP_RULES" --include="src/" --include="app/" --json --output semgrep-results.json

No pierdas tiempo escaneando node_modules/, vendor/ o directorios de assets.

Lo que aprendí configurando esto

Llevo un tiempo con esta configuración en producción y hay cosas que solo se ven con el uso:

Trivy detecta muchos CVEs en imágenes base que no tienen fix disponible. Si no filtras por --ignore-unfixed, vas a tener ruido constante. Mejor añadir ese flag y centrarte en lo que puedes corregir:

1

trivy image --ignore-unfixed --severity HIGH,CRITICAL mi-imagen:latest

Con Semgrep, los rulesets de comunidad son un buen punto de partida, pero las reglas que más valor aportan son las que escribes tú, adaptadas a los patrones de tu proyecto. Una regla que detecta que alguien usa el ORM sin parametrizar queries vale más que cien reglas genéricas.

Y lo más importante: no intentes tapar todos los agujeros a la vez. Empieza con los escaneos en modo informativo, revisa qué sale, ajusta las reglas, y solo entonces empieza a bloquear. Si el primer día bloqueas todo, el segundo día alguien habrá puesto allow_failure: true en cada job.

Lecciones aprendidas en DevSecOps

Mon, 20 Oct 2025 00:00:00 +0000

DevSecOps se usa mucho en ofertas de trabajo y charlas. Pero detrás del buzzword hay lecciones reales que solo vienen de hacer el trabajo. De construir pipelines que se rompen cuando añades seguridad, de ver equipos ignorar herramientas que pasaste meses desplegando, hasta finalmente encontrar qué funciona.

Estas son lecciones que aprendimos a base de golpes. Son opiniones fundamentadas, prácticas, moldeadas por experiencia real.

La seguridad es responsabilidad de todos

Suena a póster, pero es la lección más importante. Si la seguridad es solo del equipo de seguridad, ya perdiste.

Los desarrolladores toman decisiones de seguridad cada vez que escriben código, lo sepan o no. Cómo validan entrada. Cómo manejan secretos. Cómo configuran acceso de red. Cada PR es un evento de seguridad.

Lo que funciona: haz seguridad parte del flujo de desarrollo normal, no una puerta al final. Los desarrolladores aprenden cuando reciben feedback rápido sobre problemas de seguridad en su PR. Lo resientan cuando se enteran tres semanas después de un auditor.

Lo hemos visto repetidamente: equipos que tratan seguridad como responsabilidad compartida encuentran menos vulnerabilidades críticas. Los que la aíslan las encuentran en las noticias.

Automatiza todo lo que puedas

Los procesos de seguridad manuales no escalan. Punto. Si tu revisión de seguridad es un humano leyendo una checklist, se saltará bajo presión de plazos, se aplicará de forma inconsistente y será odiada por todos los involucrados.

Automatiza las cosas que se pueden automatizar:

Escaneo de dependencias en cada build de CI (Dependabot, Snyk, Trivy)
Análisis estático en cada pull request (Semgrep, SonarQube)
Detección de secretos como pre-commit hook y check de CI (gitleaks, detect-secrets)
Escaneo de imágenes de contenedores antes del despliegue (Trivy, Grype)
Escaneo de Infrastructure as Code (tfsec, Checkov, KICS)
Compliance as Code para cumplimiento de políticas en runtime (OPA, Kyverno)

El objetivo no es capturarlo todo automáticamente. El objetivo es capturar lo fácil automáticamente para que los revisores humanos puedan centrarse en lo difícil: fallos en la lógica de negocio, problemas de seguridad a nivel de diseño, modelado de amenazas.

Empieza pequeño

Uno de los mayores errores que hemos cometido es intentar asegurar todo de golpe. Despliegas SAST, DAST, SCA, escaneo de contenedores, escaneo de IaC y protección en runtime en un trimestre. El resultado: fatiga de alertas, rebelión de los desarrolladores y un muro de hallazgos sin resolver que nadie mira.

Empieza con una herramienta, un pipeline, un equipo. Haz que funcione bien. Que los desarrolladores se sientan cómodos con ello. Resuelve los falsos positivos. Ajusta las reglas. Después expande.

Una progresión práctica:

Mes 1: Detección de secretos en pre-commit hooks y CI. Esto es poco controvertido y captura problemas reales.
Mes 2: Escaneo de dependencias con creación automatizada de PRs para actualizaciones. Los desarrolladores ven el valor inmediatamente.
Mes 3: Escaneo de imágenes de contenedores bloqueando despliegues con vulnerabilidades críticas/altas.
Mes 4+: Análisis estático, expandiendo conjuntos de reglas gradualmente.

Cada paso debe ser estable antes de pasar al siguiente. Ir con prisas crea ruido, y el ruido enseña a la gente a ignorar alertas.

La cultura blameless importa

Cuando ocurre un incidente de seguridad porque alguien subió un secreto a un repo público, o porque una vulnerabilidad no se parcheó a tiempo, la respuesta importa más que el propio incidente.

Si se culpa a la gente, ocultan cosas. No reportan casi-incidentes. Tapan errores. Y el siguiente incidente será peor porque nadie compartió las lecciones del anterior.

Las postmortems blameless no consisten en librar a la gente de responsabilidad. Consisten en entender fallos sistémicos. Por qué fue posible subir un secreto? Por qué no había escaneo? Por qué el proceso de parcheo era lento? Arregla el sistema, no a la persona.

Hemos comprobado que los equipos con culturas genuinamente blameless tienen posturas de seguridad significativamente mejores. La gente reporta cosas sospechosas. Piden ayuda pronto. Señalan riesgos antes de que se conviertan en incidentes.

Las herramientas no bastan sin cambio cultural

Una vez desplegamos un pipeline de escaneo de seguridad completo con dashboards bonitos, notificaciones de Slack, creación de tickets en Jira, todo el paquete. Seis meses después, había 3.000 hallazgos sin resolver y el canal de Slack estaba silenciado por todos los desarrolladores.

Las herramientas estaban bien. La cultura no estaba preparada.

Antes de desplegar herramientas, invierte en:

Formación: Los desarrolladores necesitan entender por qué existe la herramienta y cómo actuar sobre sus hallazgos.
Ownership: Alguien necesita ser dueño del backlog de hallazgos y hacer triaje. Si nadie es dueño, nadie lo hace.
SLAs: Define plazos claros para remediar hallazgos por severidad. Críticos en 48 horas. Altos en una semana. Medios en un sprint. Bajos en un trimestre.
Bucles de feedback: Cuando una herramienta produce un falso positivo, debe haber una forma fácil de reportarlo y que se ajuste la regla. De lo contrario, los desarrolladores aprenden a ignorar todo.

Invierte en la experiencia de desarrollador de las herramientas de seguridad

Si tu herramienta de seguridad hace la vida de los desarrolladores más difícil, encontrarán la forma de esquivarla. Esto no es un defecto de carácter. Es naturaleza humana y buen instinto de ingeniería: eliminar obstáculos para entregar.

Las herramientas de seguridad que se adoptan son las que:

Ejecutan rápido: Un escaneo SAST que tarda 20 minutos será esquivado. Uno que tarda 30 segundos será tolerado.
Se integran nativamente: Muestra resultados en la PR, no en un portal separado. Nadie quiere hacer login en otro dashboard.
Tienen baja tasa de falsos positivos: Cada falso positivo erosiona la confianza. Invierte tiempo en el ajuste.
Proporcionan guía accionable: “Vulnerabilidad de SQL injection en la línea 42” es inútil sin “así es como se arregla.”
Fallan de forma elegante: Si el escáner está caído, el pipeline debe avisar, no bloquear. La disponibilidad del pipeline de desarrollo no es negociable.

Lo pensamos así: si un desarrollador tiene que cambiar su flujo de trabajo para acomodar una herramienta de seguridad, la herramienta ha fallado. Las mejores herramientas de seguridad son invisibles.

Monitorización y observabilidad no son negociables

No puedes asegurar lo que no puedes ver. La monitorización de seguridad no es opcional, y no es algo que se añade después.

Qué significa esto en la práctica:

Logging centralizado: Todos los logs de aplicación, infraestructura y herramientas de seguridad en un solo lugar. Si tienes que hacer SSH a una máquina para leer logs, ya vas por detrás.
Audit trails: Quién hizo qué, cuándo y desde dónde. Cada despliegue, cada cambio de configuración, cada solicitud de acceso.
Alertas sobre anomalías: No solo “está el servicio arriba?” sino “es este patrón de acceso normal?” Volúmenes inusuales de llamadas a API, accesos desde nuevas ubicaciones, escalaciones de privilegios.
Seguridad en runtime: Herramientas como Falco para monitorización de runtime de contenedores. Saber cuándo algo inesperado ocurre en producción.

La monitorización también es cómo demuestras a auditores y clientes que tus controles de seguridad funcionan. “Confía en nosotros” no es una estrategia de cumplimiento.

El open source es tu aliado

Algunas de las mejores herramientas de seguridad disponibles son open source. Trivy, Falco, OPA, Semgrep, gitleaks, cosign, KICS, Checkov. El ecosistema es rico y madura rápidamente.

Beneficios de las herramientas de seguridad open source:

Transparencia: Puedes leer las reglas y entender exactamente qué se está comprobando.
Comunidad: Miles de contribuidores encontrando casos límite y añadiendo reglas de detección.
Sin vendor lock-in: Puedes cambiar de herramienta sin renegociar un contrato.
Coste: Empieza gratis, escala según necesites.

Esto no significa que las herramientas comerciales no tengan su lugar. Algunas proporcionan agregación, gestión y soporte valiosos. Pero puedes construir un pipeline de seguridad muy sólido solo con herramientas open source, y creemos que todos los equipos deberían empezar por ahí.

El aprendizaje continuo es esencial

El panorama de amenazas cambia constantemente. Las herramientas cambian. Las mejores prácticas evolucionan. Lo que se consideraba seguro hace dos años puede tener un CVE hoy.

Lo que hacemos para mantenernos al día:

Dedicar tiempo al aprendizaje: Al menos unas horas por sprint para que el equipo lea sobre nuevas vulnerabilidades, herramientas y técnicas. Esto no es un nice-to-have. Es un requisito profesional.
Organizar CTFs internos y ejercicios de mesa: Nada enseña seguridad como intentar romper cosas. Los ejercicios regulares mantienen las habilidades afiladas y revelan brechas en tus defensas.
Participar en la comunidad: Asistir a meetups, contribuir a open source, leer advisories. La comunidad de seguridad es generosa con el conocimiento. Aprovéchalo.
Revisar y actualizar: Revisiones trimestrales de tu tooling de seguridad, políticas y procedimientos de respuesta a incidentes. Lo que funcionó el trimestre pasado puede no funcionar el próximo.

Reflexiones finales

DevSecOps no es un destino. No hay un punto donde digas “terminamos, somos seguros.” Es una práctica continua de reducir riesgo, mejorar visibilidad, construir una cultura donde seguridad sea tan natural como escribir tests.

La lección más importante: lo perfecto es enemigo de lo bueno. Un pipeline básico que los desarrolladores usan de verdad vale infinitamente más que uno completo que esquivan. Empieza donde estás, mejora iterativamente, nunca pares.

Seguridad en la cadena de suministro: SBOM y Sigstore

Mon, 10 Feb 2025 00:00:00 +0000

Los ataques de cadena de suministro ya no son teóricos. La brecha SolarWinds de 2020 mostró cómo un pipeline de compilación comprometido podía golpear miles de organizaciones, incluyendo agencias gubernamentales. Log4Shell en 2021 probó que una vulnerabilidad profunda en una dependencia transitiva podía amenazar todas las apps Java de la noche a la mañana. El mensaje fue claro: necesitamos visibilidad sobre qué hay en nuestro software y garantías más fuertes de integridad.

Esta guía cubre las herramientas prácticas: SBOMs, Sigstore y framework SLSA.

Por qué importa la seguridad de la cadena de suministro

La seguridad tradicional se centra en tu propio código: análisis estático, escaneo de dependencias, pruebas de penetración. La seguridad de la cadena de suministro extiende ese perímetro a todo de lo que depende tu software y a cada paso en el proceso de construcción y entrega.

La superficie de ataque incluye:

Repositorios de código fuente: cuentas de desarrolladores comprometidas, commits maliciosos
Dependencias: typosquatting, confusión de dependencias, paquetes upstream comprometidos
Sistemas de compilación: pipelines de CI/CD manipulados, pasos de build inyectados
Registros de artefactos: binarios reemplazados, paquetes sin firmar
Pipelines de despliegue: manifiestos modificados, ataques man-in-the-middle

Un solo eslabón débil en cualquiera de estas etapas puede comprometer toda la cadena.

Software Bill of Materials (SBOM)

Un SBOM es un inventario formal y legible por máquinas de todos los componentes de un software. Piensa en ello como la lista de ingredientes de tu aplicación. Incluye dependencias directas, dependencias transitivas, sus versiones, licencias y relaciones.

Por qué lo necesitas

Respuesta ante vulnerabilidades: Cuando aparece un nuevo CVE (como Log4Shell), puedes comprobar al instante si alguna de tus aplicaciones está afectada.
Cumplimiento de licencias: Saber exactamente qué licencias estás distribuyendo.
Requisitos regulatorios: La Orden Ejecutiva 14028 de EE.UU. y la Ley de Ciberresiliencia de la UE empujan hacia SBOMs obligatorios.
Transparencia: Clientes y partners pueden verificar lo que están ejecutando.

Formatos de SBOM

Dos formatos principales dominan:

SPDX (Software Package Data Exchange): Un estándar ISO (ISO/IEC 5962:2021), originalmente centrado en cumplimiento de licencias, ahora integral. Soporta formatos JSON, RDF, YAML y tag-value.
CycloneDX: Un proyecto de OWASP, diseñado desde cero para casos de uso de seguridad. Soporta JSON y XML. Más ligero y con opiniones más definidas.

Ambos son opciones sólidas. CycloneDX tiende a ser más fácil de usar para flujos de trabajo centrados en seguridad. SPDX tiene mayor adopción en industrias con requisitos de cumplimiento estrictos.

Generando SBOMs con Syft

Syft de Anchore es una de las mejores herramientas para generar SBOMs. Soporta imágenes de contenedores, sistemas de archivos y archivos comprimidos.

Instalar syft:

1

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

Generar un SBOM desde una imagen de contenedor:

1
2
3
4
5


# Formato CycloneDX (JSON)
syft packages registry.example.com/myapp:v1.2.3 -o cyclonedx-json > sbom.cdx.json

# Formato SPDX (JSON)
syft packages registry.example.com/myapp:v1.2.3 -o spdx-json > sbom.spdx.json

Generar un SBOM desde un directorio local:

1

syft packages dir:/path/to/project -o cyclonedx-json > sbom.cdx.json

Después puedes escanear el SBOM en busca de vulnerabilidades usando Grype:

1

grype sbom:sbom.cdx.json

El ecosistema Sigstore

Sigstore es un proyecto open source que hace accesible la firma y verificación criptográfica. Elimina la necesidad de gestionar claves de firma de larga duración, que históricamente ha sido la principal barrera para la adopción de la firma de artefactos.

El ecosistema tiene tres componentes centrales:

cosign: Firma y verifica imágenes de contenedores y otros artefactos OCI.
Fulcio: Una autoridad certificadora que emite certificados de corta duración basados en identidad OIDC (tu proveedor de identidad existente).
Rekor: Un log de transparencia que crea un registro inmutable y resistente a manipulaciones de los eventos de firma.

Cómo funciona

Te autentificas con un proveedor OIDC (GitHub, Google, Microsoft, etc.).
Fulcio emite un certificado de corta duración vinculado a tu identidad.
cosign usa ese certificado para firmar tu artefacto.
El evento de firma se registra en el log de transparencia de Rekor.
Cualquiera puede verificar la firma usando el log de transparencia, sin necesitar tu clave pública.

Esto se conoce como firma “keyless”. Sin claves que rotar, sin secretos que gestionar, sin infraestructura PKI que mantener.

Firmando imágenes de contenedores con Cosign

Instalar cosign:

1
2
3
4
5
6


# Usando Go
go install github.com/sigstore/cosign/v2/cmd/cosign@latest

# O descargar un release
curl -sSfL https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 -o /usr/local/bin/cosign
chmod +x /usr/local/bin/cosign

Firmar una imagen (modo keyless):

1

cosign sign registry.example.com/myapp:v1.2.3

Esto abrirá un navegador para autenticación OIDC. En CI, puedes usar identidad de carga de trabajo (por ejemplo, el token OIDC de GitHub Actions) para firma no interactiva.

Verificar una imagen:

1
2
3


cosign verify registry.example.com/myapp:v1.2.3 \
 --certificate-identity=user@example.com \
 --certificate-oidc-issuer=https://accounts.google.com

Adjuntar un SBOM a una imagen y firmarlo:

1
2
3
4
5


# Adjuntar el SBOM
cosign attach sbom --sbom sbom.cdx.json registry.example.com/myapp:v1.2.3

# Firmar el adjunto del SBOM
cosign sign --attachment sbom registry.example.com/myapp:v1.2.3

El framework SLSA

SLSA (Supply-chain Levels for Software Artifacts, pronunciado “salsa”) es un framework que define niveles crecientes de garantías de integridad en la cadena de suministro.

Niveles SLSA

Level 0: Sin garantías. Aquí es donde empiezan la mayoría de proyectos.
Level 1: El proceso de compilación está documentado y produce provenance (metadatos sobre cómo se construyó un artefacto).
Level 2: La compilación se ejecuta en un servicio de build alojado que genera provenance autenticado.
Level 3: La plataforma de compilación proporciona builds reforzados con provenance resistente a manipulaciones. El entorno de build es aislado y efímero.

Cada nivel se construye sobre el anterior. El objetivo no es saltar al Level 3 inmediatamente, sino mejorar tu postura de forma incremental.

SLSA Provenance

El provenance responde a las preguntas críticas: Quién construyó esto? Qué código fuente se usó? Qué proceso de build se siguió? Era el entorno de build a prueba de manipulaciones?

El SLSA provenance es una attestation firmada en formato in-toto que captura esta información.

Integración CI/CD: Ejemplo con GitHub Actions

Aquí tienes un workflow práctico de GitHub Actions que construye una imagen, genera un SBOM, firma todo y genera SLSA provenance:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


name: Build, Sign, and Attest

on:
 push:
 tags:
 - 'v*'

permissions:
 contents: read
 packages: write
 id-token: write  # Requerido para firma keyless

env:
 REGISTRY: ghcr.io
 IMAGE_NAME: ${{ github.repository }}

jobs:
 build-sign-attest:
 runs-on: ubuntu-latest
 steps:
 - name: Checkout
 uses: actions/checkout@v4

 - name: Log in to GHCR
 uses: docker/login-action@v3
 with:
 registry: ${{ env.REGISTRY }}
 username: ${{ github.actor }}
 password: ${{ secrets.GITHUB_TOKEN }}

 - name: Build and push image
 id: build
 uses: docker/build-push-action@v5
 with:
 push: true
 tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}

 - name: Install cosign
 uses: sigstore/cosign-installer@v3

 - name: Install syft
 uses: anchore/sbom-action/download-syft@v0

 - name: Sign the image
 run: |
 cosign sign --yes \
 ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}@${{ steps.build.outputs.digest }}

 - name: Generate SBOM
 run: |
 syft packages \
 ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}@${{ steps.build.outputs.digest }} \
 -o cyclonedx-json > sbom.cdx.json

 - name: Attach and sign SBOM
 run: |
 cosign attach sbom --sbom sbom.cdx.json \
 ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}@${{ steps.build.outputs.digest }}
 cosign sign --yes --attachment sbom \
 ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}@${{ steps.build.outputs.digest }}

 - name: Verify signature
 run: |
 cosign verify \
 --certificate-identity-regexp="https://github.com/${{ github.repository }}/*" \
 --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
 ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}@${{ steps.build.outputs.digest }}

El permiso id-token: write es lo que habilita la firma keyless en GitHub Actions. El token OIDC de GitHub se usa automáticamente por cosign sin ninguna gestión manual de claves.

Hoja de ruta práctica para la adopción

No necesitas hacer todo de golpe. Aquí tienes una progresión sensata:

Semana 1-2: Visibilidad

Empieza a generar SBOMs para tus aplicaciones más críticas usando syft.
Integra Grype en tu pipeline de CI para escaneo de vulnerabilidades contra el SBOM.

Semana 3-4: Firma

Configura la firma keyless con cosign en tus pipelines de CI/CD.
Firma tus imágenes de contenedores en cada build.

Mes 2: Verificación

Aplica verificación de firmas en tus pipelines de despliegue (por ejemplo, controladores de admisión de Kubernetes como Kyverno o Sigstore policy-controller).
Adjunta SBOMs a las imágenes y fírmalos.

Mes 3+: SLSA Provenance

Añade generación de SLSA provenance usando slsa-github-generator.
Trabaja hacia SLSA Level 2, después Level 3.
Automatiza la verificación de provenance en tu tooling de despliegue.

Conclusiones clave

SBOMs dan visibilidad - No aseguras lo que no ves. Genera SBOMs para cada artefacto.
Sigstore elimina excusas - La firma keyless elimina la sobrecarga de gestión de claves. Sin buena razón para no firmar.
SLSA es un modelo de madurez - Úsalo para mejorar la integridad de forma incremental, no como todo o nada.
Automatiza todo - Estas herramientas son para integración CI/CD. Lo manual no escala.

El ecosistema de seguridad de cadena de suministro madura rápido. Las herramientas están listas para producción, los estándares se consolidan, la presión regulatoria sigue subiendo. El mejor momento fue ayer. El segundo mejor es ahora.

Guía de bastionado de seguridad en Kubernetes

Sun, 03 Nov 2024 00:00:00 +0000

Superficie de Ataque de Kubernetes

Kubernetes por defecto no es seguro. El cluster expone múltiples vectores de ataque que necesitan atención sistemática:

API Server - Punto de control central; acceso no autorizado = compromiso total
etcd - Almacena todo el estado incluyendo secretos en base64 (sin cifrar por defecto)
Kubelet - Agente del nodo; API expuesto filtra info de pods y permite ejecutar comandos
Container runtime - Vulnerabilidades de escape dan acceso al host
Red - Los pods se comunican libremente con otros por defecto
Cadena de suministro - Imágenes maliciosas o vulnerables introducen backdoors

Esta guía cubre las medidas clave organizadas por vector de ataque.

Bastionado del API Server

El API server es el componente más crítico. Asegúralo primero:

Deshabilitar autenticación anónima: establece --anonymous-auth=false
Habilitar audit logging: rastrea quién hizo qué (cubierto en detalle más adelante)
Restringir acceso: usa reglas de firewall o security groups para limitar quien puede alcanzar el API server
Habilitar admission controllers: PodSecurity, NodeRestriction, ResourceQuota y LimitRanger deben estar activos
Usar OIDC para autenticación: integra con tu proveedor de identidad en lugar de depender de certificados de cliente

1
2


# Comprobar los flags actuales del API server (en clusters kubeadm)
kubectl -n kube-system get pod kube-apiserver-<node> -o jsonpath='{.spec.containers[0].command}' | tr ',' '\n'

Buenas Prácticas de RBAC

RBAC es tu mecanismo de autorización principal. Aplica el mínimo privilegio rigurosamente.

Reglas Clave

Nunca usar cluster-admin para workloads – otorga acceso ilimitado
Usar Roles (con namespace) sobre ClusterRoles siempre que sea posible
Evitar wildcards en especificaciones de recursos o verbos
Vincular a ServiceAccounts, no a usuarios para workloads automatizados
Revisar bindings regularmente – los permisos se acumulan con el tiempo

Ejemplo: Rol Restringido para Despliegues

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: production
 name: deployment-manager
rules:
 # Puede gestionar deployments
 - apiGroups: ["apps"]
 resources: ["deployments"]
 verbs: ["get", "list", "watch", "create", "update", "patch"]
 # Puede ver pods y logs
 - apiGroups: [""]
 resources: ["pods", "pods/log"]
 verbs: ["get", "list", "watch"]
 # Puede ver services
 - apiGroups: [""]
 resources: ["services"]
 verbs: ["get", "list", "watch"]
 # Explicitamente SIN acceso a secrets, escritura de configmaps, o exec
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 namespace: production
 name: deployment-manager-binding
subjects:
 - kind: ServiceAccount
 name: ci-deployer
 namespace: production
roleRef:
 kind: Role
 name: deployment-manager
 apiGroup: rbac.authorization.k8s.io

Audita el RBAC existente con:

1
2
3
4
5
6


# Listar todos los bindings de cluster-admin
kubectl get clusterrolebindings -o json | \
 jq '.items[] | select(.roleRef.name == "cluster-admin") | {name: .metadata.name, subjects: .subjects}'

# Comprobar que puede hacer una service account especifica
kubectl auth can-i --list --as=system:serviceaccount:production:ci-deployer -n production

Pod Security Standards

Los PSS (Pod Security Standards) de Kubernetes definen tres niveles de restricciones. Desde 1.25, Pod Security Admission (PSA) es el mecanismo integrado (reemplaza PodSecurityPolicy).

Los Tres Niveles

Nivel	Descripción	Caso de Uso
Privileged	Sin restricciones	Workloads de sistema (CNI, drivers de almacenamiento)
Baseline	Bloquea escalaciones de privilegios conocidas	Workloads generales
Restricted	Bastionado máximo	Workloads sensibles, clusters multi-tenant

Aplicacion de Pod Security Standards

Aplica los estandares a nivel de namespace usando labels:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


apiVersion: v1
kind: Namespace
metadata:
 name: production
 labels:
 # Enforce restricted: rechazar pods que violen
 pod-security.kubernetes.io/enforce: restricted
 pod-security.kubernetes.io/enforce-version: latest
 # Warn en violaciones baseline (muestra aviso pero permite)
 pod-security.kubernetes.io/warn: restricted
 pod-security.kubernetes.io/warn-version: latest
 # Audit: registrar violaciones
 pod-security.kubernetes.io/audit: restricted
 pod-security.kubernetes.io/audit-version: latest

Ejemplo de Pod Conforme

Un pod que pasa el nivel restricted:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


apiVersion: v1
kind: Pod
metadata:
 name: secure-app
 namespace: production
spec:
 securityContext:
 runAsNonRoot: true
 seccompProfile:
 type: RuntimeDefault
 containers:
 - name: app
 image: myregistry.com/app:v1.2.3@sha256:abc123...
 securityContext:
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 runAsUser: 1000
 runAsGroup: 1000
 capabilities:
 drop:
 - ALL
 resources:
 limits:
 memory: "256Mi"
 cpu: "500m"
 requests:
 memory: "128Mi"
 cpu: "250m"

Configuraciones de seguridad clave que siempre incluir:

runAsNonRoot: true – nunca ejecutar contenedores como root
readOnlyRootFilesystem: true – prevenir modificaciones del sistema de archivos
allowPrivilegeEscalation: false – bloquear setuid/setgid
capabilities.drop: ["ALL"] – eliminar todas las capabilities de Linux
seccompProfile.type: RuntimeDefault – aplicar perfil seccomp por defecto
Siempre especificar limites de recursos para prevenir DoS

NetworkPolicies

Por defecto, todos los pods pueden comunicarse con todos los demas pods en un cluster. Las NetworkPolicies restringen esto a solo el trafico necesario.

Denegacion Total por Defecto

Comienza cada namespace con una política de denegacion por defecto:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-all
 namespace: production
spec:
 podSelector: {}
 policyTypes:
 - Ingress
 - Egress

Permitir Trafico Especifico

Luego permite explicitamente solo lo que se necesita:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-api-to-db
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: database
 policyTypes:
 - Ingress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: api-server
 ports:
 - protocol: TCP
 port: 5432
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-server-egress
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: api-server
 policyTypes:
 - Egress
 egress:
 # Permitir resolucion DNS
 - to: []
 ports:
 - protocol: UDP
 port: 53
 - protocol: TCP
 port: 53
 # Permitir conexion a la base de datos
 - to:
 - podSelector:
 matchLabels:
 app: database
 ports:
 - protocol: TCP
 port: 5432
 # Permitir HTTPS externo
 - to:
 - ipBlock:
 cidr: 0.0.0.0/0
 except:
 - 10.0.0.0/8
 - 172.16.0.0/12
 - 192.168.0.0/16
 ports:
 - protocol: TCP
 port: 443

Nota: las NetworkPolicies requieren un plugin CNI que las soporte (Calico, Cilium, Weave Net). El kubenet por defecto no aplica NetworkPolicies.

Gestion de Secretos

Los Secrets de Kubernetes estan codificados en base64, no cifrados. Cualquiera con acceso de lectura a Secrets en un namespace puede decodificarlos trivialmente. La gestion adecuada de secretos requiere herramientas adicionales.

Opcion 1: Sealed Secrets

Sealed Secrets (de Bitnami) cifra secretos del lado del cliente para que puedan almacenarse de forma segura en Git:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# Instalar CLI kubeseal
# Cifrar un secreto
kubectl create secret generic db-creds \
 --from-literal=password=supersecret \
 --dry-run=client -o yaml | \
 kubeseal --format yaml > sealed-db-creds.yaml

# El sealed secret puede commitearse en Git
# Solo el controlador del cluster puede descifrarlo
kubectl apply -f sealed-db-creds.yaml

Opcion 2: External Secrets Operator

External Secrets Operator sincroniza secretos desde proveedores externos (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) en Kubernetes:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
 name: db-credentials
 namespace: production
spec:
 refreshInterval: 1h
 secretStoreRef:
 name: aws-secrets-manager
 kind: ClusterSecretStore
 target:
 name: db-credentials
 data:
 - secretKey: password
 remoteRef:
 key: production/database
 property: password

Habilitar Cifrado en Reposo

Asegurate de que etcd cifre los secretos en reposo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
 - resources:
 - secrets
 providers:
 - aescbc:
 keys:
 - name: key1
 secret: <base64-encoded-32-byte-key>
 - identity: {}

Audit Logging

Los audit logs de Kubernetes registran cada peticion al API server, proporcionando un rastro detallado de quien hizo que y cuando.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
 # Registrar todas las peticiones a secrets a nivel Metadata
 - level: Metadata
 resources:
 - group: ""
 resources: ["secrets"]
 # Registrar pod exec/attach a nivel RequestResponse
 - level: RequestResponse
 resources:
 - group: ""
 resources: ["pods/exec", "pods/attach"]
 # Registrar todas las operaciones de escritura a nivel Request
 - level: Request
 verbs: ["create", "update", "patch", "delete"]
 # Registrar todo lo demas a nivel Metadata
 - level: Metadata
 omitStages:
 - RequestReceived

Habilita en el API server con:

1
2
3
4
5


--audit-policy-file=/etc/kubernetes/audit-policy.yaml
--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100

Envia los audit logs a tu SIEM o sistema de agregacion de logs (Loki, Elasticsearch) para analisis y alertas.

Politicas de Imagenes con Kyverno

Kyverno es un motor de políticas para Kubernetes que valida, muta y genera recursos basándose en políticas. Es mas sencillo de adoptar que OPA Gatekeeper porque las políticas se escriben como recursos de Kubernetes en lugar de Rego.

Requerir Digest de Imagen y Registro de Confianza

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
 name: require-image-digest
spec:
 validationFailureAction: Enforce
 rules:
 - name: require-digest
 match:
 any:
 - resources:
 kinds:
 - Pod
 validate:
 message: "Las imágenes deben usar un digest (@sha256:...) en lugar de un tag"
 pattern:
 spec:
 containers:
 - image: "*@sha256:*"
 - name: require-trusted-registry
 match:
 any:
 - resources:
 kinds:
 - Pod
 validate:
 message: "Las imágenes deben provenir del registro de confianza"
 pattern:
 spec:
 containers:
 - image: "myregistry.com/*"

Esta política asegura que solo se desplieguen imágenes de tu registro de confianza con digests fijados, previniendo tanto ataques a la cadena de suministro como problemas de mutabilidad de tags.

CIS Kubernetes Benchmark

El CIS Kubernetes Benchmark proporciona un conjunto completo de recomendaciones de seguridad. Ejecuta comprobaciones automatizadas con kube-bench:

1
2
3
4
5


# Ejecutar comprobaciones del benchmark CIS
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml

# Ver resultados
kubectl logs job/kube-bench

Aborda los hallazgos por prioridad: elementos criticos primero (autenticacion del API server, cifrado de etcd), luego altos (RBAC, network policies), despues medios y bajos.

Checklist de Bastionado

Usa esta checklist como punto de partida para asegurar tu cluster:

API server: autenticacion anonima deshabilitada, audit logging habilitado
etcd: cifrado en reposo, acceso restringido solo al API server
RBAC: sin bindings innecesarios de cluster-admin, minimo privilegio aplicado
Pod Security: PSS restricted aplicado en namespaces de produccion
NetworkPolicies: denegacion por defecto en todos los namespaces, reglas de permiso explicitas
Secretos: gestor de secretos externo o sealed secrets, cifrado en reposo
Imagenes: imágenes firmadas, aplicación de registro de confianza, fijación de digest
Nodos: actualizaciones de seguridad automaticas, SO bastionado segun CIS
Auditoria: audit logs del API server enviados al SIEM
Monitorizacion: alertas sobre cambios de RBAC, creacion de pods privilegiados, exec en pods
Cadena de suministro: escaneo de vulnerabilidades en CI/CD, escaneo de imágenes en tiempo de admisión
Red: TLS entre todos los componentes, service mesh para mTLS entre pods

El bastionado de seguridad no es una actividad puntual. Programa revisiones trimestrales para reevaluar tu postura, ejecutar benchmarks CIS, revisar bindings RBAC y actualizar políticas a medida que tu cluster evoluciona.

Modelo de madurez de DevSecOps

Sun, 08 Oct 2023 10:00:00 +0100

Por qué un modelo de madurez ayuda

La mayoría de los equipos saben que deberían “desplazar la seguridad a la izquierda”, pero saber por dónde empezar es la parte difícil. Un modelo de madurez proporciona una forma estructurada de evaluar el estado actual, identificar brechas y planificar una hoja de ruta realista para mejorar.

Sin un modelo, las mejoras de seguridad tienden a ser reactivas (desencadenadas por incidentes o hallazgos de auditoría en lugar de por una planificación deliberada). Un modelo de madurez convierte la seguridad de un simulacro de incendio en una disciplina de ingeniería con progreso medible.

El modelo descrito aquí tiene cinco niveles. El objetivo no es correr al nivel más alto, sino hacer un progreso constante y sostenible. Cada nivel se construye sobre el anterior.

Los cinco niveles de madurez

Nivel 1: Ad-Hoc

En este nivel, la seguridad es algo secundario. No existen procesos formales y las actividades de seguridad ocurren de forma esporádica, si es que ocurren.

Cómo se ve:

Sin pruebas de seguridad en los pipelines de CI/CD.
Las vulnerabilidades se descubren en producción o por terceros.
Sin herramientas de seguridad dedicadas.
Los desarrolladores tienen poca o ninguna formación en seguridad.
La respuesta a incidentes es improvisada.
El cumplimiento normativo se aborda manualmente antes de las auditorías.

Herramientas típicas: Ninguna específica de seguridad. Quizás un firewall y un antivirus.

Nivel 2: Reactivo

La seguridad se reconoce como importante, pero el enfoque es reactivo. El equipo responde a vulnerabilidades e incidentes pero no los previene de manera proactiva.

Cómo se ve:

El análisis estático básico (SAST) se ejecuta ocasionalmente, pero los hallazgos no siempre se abordan.
El escaneo de dependencias se hace de forma manual o ad-hoc.
Hay documentación de seguridad, pero está desactualizada.
La respuesta a incidentes existe como un proceso documentado, aunque se practica raramente.
Las revisiones de seguridad ocurren tarde en el ciclo de desarrollo (justo antes del lanzamiento).

Herramientas típicas: SonarQube (reglas básicas), OWASP Dependency-Check, pruebas de penetración manuales.

Nivel 3: Proactivo

La seguridad está integrada en el flujo de trabajo de desarrollo. El equipo busca activamente prevenir vulnerabilidades en lugar de solo reaccionar ante ellas.

Cómo se ve:

SAST y DAST se ejecutan automáticamente en los pipelines de CI/CD.
Escaneo de dependencias con alertas automáticas para vulnerabilidades conocidas.
Escaneo de imágenes de contenedores antes del despliegue (Trivy, Grype).
La Infrastructure as Code se escanea en busca de configuraciones incorrectas (Checkov, tfsec).
Se realiza threat modeling para nuevas funcionalidades y cambios de arquitectura.
Existen security champions dentro de los equipos de desarrollo.
Se realizan postmortems sin culpa después de incidentes de seguridad.
Formación regular en seguridad para desarrolladores.

Herramientas típicas: Semgrep, Trivy, Checkov, OWASP ZAP, HashiCorp Vault, Falco.

Nivel 4: Optimizado

La seguridad está profundamente integrada en cada etapa del ciclo de vida del software. Las métricas guían las decisiones y el equipo mejora continuamente basándose en datos.

Cómo se ve:

Puertas de seguridad en los pipelines que bloquean el despliegue si se encuentran problemas críticos.
El tiempo medio de remediación (MTTR) se rastrea y se reduce continuamente.
Se genera un Software Bill of Materials (SBOM) para cada release.
Artefactos firmados y cadena de suministro verificada.
Comprobaciones de cumplimiento automatizadas mapeadas a frameworks (SOC2, ISO 27001, PCI-DSS).
Monitorización de seguridad en runtime con respuesta automatizada (Falco + reglas personalizadas).
Ejercicios regulares de red team y chaos engineering para seguridad.
Las métricas de seguridad forman parte de los dashboards de ingeniería.

Herramientas típicas: Sigstore/cosign, OPA/Gatekeeper, Kyverno, integración con SIEM, plataformas de cumplimiento automatizado.

Nivel 5: Innovador

La seguridad es una ventaja competitiva. El equipo contribuye a la comunidad de seguridad en general y empuja el estado del arte.

Cómo se ve:

Programas de bug bounty gestionados activamente.
Herramientas de seguridad personalizadas desarrolladas para riesgos específicos de la organización.
Machine learning aplicado a detección de anomalías y threat hunting.
La seguridad es una característica que se vende a los clientes (certificaciones, informes de transparencia).
Participación activa en proyectos de seguridad open-source.
Arquitectura zero-trust completamente implementada.
Policy as code gobierna toda la seguridad de infraestructura y aplicaciones.

Herramientas típicas: Plataformas construidas a medida, herramientas de seguridad basadas en eBPF, SIEM avanzado con ML, service mesh zero-trust.

Dimensiones clave

Un modelo de madurez no es unidimensional. Evalúa tu organización en estas dimensiones, ya que el progreso rara vez es parejo:

Seguridad del código

Nivel	Prácticas
Ad-Hoc	Sin escaneo de código
Reactivo	SAST ocasional, revisiones de código manuales orientadas a seguridad
Proactivo	SAST/DAST automatizado en CI, directrices de revisión de código enfocadas en seguridad
Optimizado	Reglas personalizadas para patrones específicos de la organización, MTTR rastreado
Innovador	Revisión de código asistida por IA, sugerencias automáticas de corrección

Seguridad de la infraestructura

Nivel	Prácticas
Ad-Hoc	Configuración manual de servidores, sin estándares de hardening
Reactivo	Checklists básicas de hardening, auditorías ocasionales
Proactivo	Escaneo de IaC, hardening automatizado, CIS benchmarks
Optimizado	Policy as code (OPA), detección de drift, remediación automatizada
Innovador	Infraestructura auto-reparable, redes zero-trust

Monitorización y detección

Nivel	Prácticas
Ad-Hoc	Sin monitorización de seguridad
Reactivo	Recopilación básica de logs, revisión manual después de incidentes
Proactivo	Logging centralizado, alertas sobre patrones conocidos, monitorización en runtime
Optimizado	SIEM con reglas de correlación, playbooks de respuesta automatizada
Innovador	Detección de anomalías basada en ML, programas de threat hunting

Respuesta a incidentes

Nivel	Prácticas
Ad-Hoc	Sin proceso, respuesta improvisada
Reactivo	Runbooks documentados, raramente probados
Proactivo	Ejercicios regulares de simulación, postmortems sin culpa, rotación de guardia
Optimizado	Clasificación automatizada de incidentes, tiempos de respuesta basados en SLA
Innovador	Chaos engineering para seguridad, contención automatizada

Cumplimiento normativo

Nivel	Prácticas
Ad-Hoc	Recopilación manual de evidencias antes de auditorías
Reactivo	Seguimiento en hojas de cálculo, revisiones periódicas
Proactivo	Recopilación automatizada de evidencias, monitorización continua
Optimizado	Compliance as code, dashboards en tiempo real, informes automatizados
Innovador	Certificación continua, informes públicos de transparencia

Checklist de autoevaluación

Califica tu organización en cada punto (Sí / Parcial / No):

Fase de build:

SAST se ejecuta automáticamente en cada pull request.
El escaneo de dependencias alerta sobre CVEs conocidos.
Las imágenes de contenedores se escanean antes de publicarse en un registry.
Las plantillas de IaC se escanean en busca de configuraciones incorrectas.
La detección de secretos impide que se hagan commit de credenciales.

Fase de despliegue:

Las puertas de seguridad pueden bloquear el despliegue por hallazgos críticos.
Los artefactos están firmados y las firmas se verifican.
Se genera un SBOM para cada release.
Los cambios de infraestructura pasan por validación de policy-as-code.

Fase de ejecución:

La monitorización de seguridad en runtime está activa (Falco, Sysdig, etc.).
Logging centralizado con alertas relevantes para seguridad.
La segmentación de red limita el radio de impacto.
Los secretos se gestionan a través de un vault dedicado.

Cultura y procesos:

Los desarrolladores reciben formación regular en seguridad.
Hay security champions integrados en los equipos de desarrollo.
Se realizan postmortems sin culpa después de los incidentes.
El threat modeling es parte del proceso de diseño de nuevas funcionalidades.
Las métricas de seguridad se rastrean y revisan regularmente.

Hoja de ruta para la progresión

Subir de nivel de madurez no ocurre de la noche a la mañana. Aquí tienes una hoja de ruta práctica:

De Ad-Hoc a Reactivo (3-6 meses)

Añade una herramienta SAST a tu pipeline de CI (empieza con Semgrep, tiene buenos valores por defecto y es rápido).
Habilita el escaneo de dependencias (GitHub Dependabot, o trivy fs en CI).
Documenta tu proceso de respuesta a incidentes, aunque sea básico.
Realiza una sesión de formación en seguridad para el equipo.

De Reactivo a Proactivo (6-12 meses)

Añade escaneo de imágenes de contenedores y escaneo de IaC a los pipelines.
Implementa detección de secretos en pre-commit hooks (gitleaks, detect-secrets).
Nombra security champions en cada equipo.
Comienza a hacer threat modeling para funcionalidades importantes.
Realiza tu primer postmortem sin culpa después de un incidente.
Despliega monitorización en runtime (Falco).

De Proactivo a Optimizado (12-18 meses)

Implementa puertas de seguridad que puedan bloquear despliegues.
Rastrea el MTTR y establece objetivos de reducción.
Genera SBOMs y firma los artefactos.
Implementa policy-as-code para infraestructura (OPA/Gatekeeper).
Mapea las comprobaciones automatizadas a frameworks de cumplimiento.
Integra las métricas de seguridad en los dashboards de ingeniería.

De Optimizado a Innovador (18+ meses)

Lanza un programa de bug bounty.
Construye herramientas de seguridad personalizadas para riesgos específicos de la organización.
Implementa arquitectura zero-trust.
Realiza ejercicios regulares de red team.
Contribuye a proyectos de seguridad open-source.

Aspectos culturales

Las herramientas y los procesos son necesarios pero insuficientes. La cultura determina si las prácticas de seguridad realmente se mantienen.

Postmortems sin culpa

Cuando ocurre un incidente de seguridad, el instinto suele ser buscar a alguien a quien culpar. Esto lleva a la gente a ocultar errores y encubrir casi-incidentes. Los postmortems sin culpa le dan la vuelta a esto: se centran en los fallos sistémicos y las mejoras de procesos en lugar de la responsabilidad individual. La pregunta cambia de “quién cometió este error” a “qué permitió que este error ocurriera y cómo lo prevenimos”.

Security Champions

Un security champion es un desarrollador que asume responsabilidad adicional en materia de seguridad dentro de su equipo. No son ingenieros de seguridad a tiempo completo — son desarrolladores que actúan como puente entre el equipo de seguridad y el equipo de desarrollo. Su papel incluye:

Revisar pull requests relevantes para seguridad.
Mantenerse al día en temas de seguridad y compartir conocimiento.
Participar en sesiones de threat modeling.
Ser el primer punto de contacto para preguntas de seguridad.

Este modelo escala mucho mejor que tener un equipo central de seguridad revisando todo.

Hacer la seguridad fácil

Si las prácticas de seguridad son dolorosas, la gente buscará atajos. El objetivo es hacer que la seguridad sea el camino más fácil:

Proporciona plantillas seguras y proyectos de inicio.
Automatiza tanto como sea posible para que los desarrolladores no tengan que recordar pasos manuales.
Da feedback rápido. Un escaneo SAST que tarda 30 minutos será ignorado; uno que tarda 30 segundos será utilizado.
Celebra las mejoras de seguridad igual que celebras la entrega de funcionalidades.

Conclusión

Un modelo de madurez DevSecOps es una brújula, no un destino. El valor viene de una autoevaluación honesta, establecer objetivos realistas y hacer un progreso constante. Empieza donde estás, elige la dimensión donde la mejora tendrá mayor impacto y construye a partir de ahí. La seguridad es un deporte de equipo. Las mejores culturas de seguridad se construyen de forma incremental, una práctica a la vez.

Cómo bastioné mi homelab con K3s

Thu, 14 Sep 2023 00:00:00 +0000

Punto de partida

Llevo un tiempo corriendo K3s en un par de máquinas físicas en casa. Al principio lo instalé para aprender Kubernetes sin montar algo pesado, y lo fui usando para proyectos pequeños: algunas aplicaciones web, servicios de monitorización, cosas así. La instalación era perfectamente funcional pero nunca me había sentado a pensar en la seguridad con calma.

Hace unos meses decidí hacer ese ejercicio. Sin prisa, sin checklist genérica de internet. Solo mirar lo que tenía, entender qué estaba mal y arreglarlo.

Lo que encontré no era catastrófico, pero había bastantes cosas que no me gustaron. Lo escribo aquí porque K3s tiene particularidades respecto a un cluster Kubernetes estándar, y la mayoría de guías de bastionado hablan de kubeadm o clusters gestionados, no de instalaciones caseras con un binario único.

Lo que K3s tiene de diferente

Antes de entrar en lo que hice, vale la pena entender qué hace distinto a K3s desde el punto de vista de seguridad.

K3s empaqueta todo en un único binario: el API server, el scheduler, el controller manager, kubelet, kube-proxy y containerd. En lugar de etcd usa SQLite por defecto. El CNI por defecto es Flannel. El ingress controller por defecto es Traefik. Todo esto simplifica mucho la instalación, pero también significa que hay componentes activos que quizás no necesitas, y que algunas decisiones de diseño están pensadas para facilitar el uso, no para maximizar la seguridad.

El archivo de configuración está en /etc/rancher/k3s/config.yaml. Ahí es donde vive la mayoría de lo que voy a tocar.

El nodo antes que el cluster

Antes de tocar nada de Kubernetes, el sistema operativo. El cluster corre en Debian, así que empecé por ahí.

SSH

Tenía autenticación por contraseña activa. Es lo primero que hay que quitar:

1
2
3
4


# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
AllowUsers miusuario

También cambié el puerto por defecto. No evita que alguien determinado te encuentre, pero sí elimina una cantidad enorme de ruido en los logs.

Firewall con nftables

La máquina tenía las interfaces de red completamente abiertas. Con un cluster K3s en casa, el API server (puerto 6443) no debería ser accesible desde fuera de tu red local. Mis reglas básicas con nftables:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


# Listar reglas activas
nft list ruleset

# Política por defecto restrictiva
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Permitir loopback y conexiones establecidas
nft add rule inet filter input iifname lo accept
nft add rule inet filter input ct state established,related accept

# SSH solo desde red local
nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 22 accept

# API server K3s solo desde red local
nft add rule inet filter input ip saddr 192.168.1.0/24 tcp dport 6443 accept

# Kubernetes node ports
nft add rule inet filter input tcp dport 30000-32767 accept

# Traefik (si lo usas como ingress)
nft add rule inet filter input tcp dport { 80, 443 } accept

# ICMP
nft add rule inet filter input icmp type echo-request accept

Lo que me sorprendió al revisar esto: el API server estaba escuchando en todas las interfaces y era alcanzable directamente desde la WAN porque el router tenía un port forward de otro servicio que arrastraba algo de tráfico. Pequeño susto, nada explotado, pero no era algo que quería dejar.

Parámetros del kernel

K3s con el flag --protect-kernel-defaults verifica que ciertos parámetros del kernel estén configurados correctamente. Si no los tienes bien, el arranque falla con un mensaje claro. Mejor configurarlos antes:

1
2
3
4
5
6
7


# /etc/sysctl.d/90-k3s-hardening.conf
kernel.panic = 10
kernel.panic_on_oops = 1
vm.overcommit_memory = 1
vm.panic_on_oom = 0
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 512

1

sysctl --system

Configuración de K3s

Con el nodo en orden, al cluster.

Archivo de configuración base

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


# /etc/rancher/k3s/config.yaml
write-kubeconfig-mode: "0600"
protect-kernel-defaults: true
secrets-encryption: true
kube-apiserver-arg:
 - "anonymous-auth=false"
 - "audit-log-path=/var/log/k3s/audit.log"
 - "audit-log-maxage=30"
 - "audit-policy-file=/etc/rancher/k3s/audit-policy.yaml"
kube-controller-manager-arg:
 - "terminated-pod-gc-threshold=10"
kubelet-arg:
 - "streaming-connection-idle-timeout=5m"
 - "protect-kernel-defaults=true"
 - "make-iptables-util-chains=true"

Las tres líneas más importantes aquí:

secrets-encryption: true habilita el cifrado en reposo de los secrets de Kubernetes. Con K3s es un flag de primera clase, no hay que configurar un EncryptionConfiguration manual como en kubeadm.
anonymous-auth=false elimina el acceso anónimo al API server.
write-kubeconfig-mode: "0600" fuerza permisos restrictivos en el kubeconfig que K3s genera en /etc/rancher/k3s/k3s.yaml.

Política de auditoría

Sin audit logs, no sabes qué pasa en el cluster. Este es el mínimo razonable:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


# /etc/rancher/k3s/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
 - level: Metadata
 resources:
 - group: ""
 resources: ["secrets"]
 - level: RequestResponse
 resources:
 - group: ""
 resources: ["pods/exec", "pods/attach"]
 - level: Request
 verbs: ["create", "update", "patch", "delete"]
 - level: None
 users: ["system:kube-proxy"]
 verbs: ["watch"]
 resources:
 - group: ""
 resources: ["endpoints", "services", "services/status"]
 - level: Metadata
 omitStages:
 - RequestReceived

Los logs van a /var/log/k3s/audit.log. En mi caso los recojo con Promtail y los mando a Loki, así puedo hacer queries desde Grafana cuando necesito revisar algo.

Kubeconfig

El kubeconfig que genera K3s en /etc/rancher/k3s/k3s.yaml tiene credenciales de administrador. Un error que vi en mi propia configuración: tenía ese archivo copiado en ~/.kube/config con permisos 644. Cualquier proceso corriendo bajo mi usuario podía leerlo.

1
2


# Permisos correctos
chmod 600 ~/.kube/config

Si tienes usuarios adicionales que necesitan acceso al cluster, crea ServiceAccounts o usa certificados de cliente con RBAC limitado. No distribuyas el kubeconfig de admin.

CNI: de Flannel a Cilium

Flannel viene por defecto en K3s. Funciona, pero no soporta NetworkPolicies por defecto. Eso significa que todos los pods se comunican entre sí sin restricciones.

Cambié a Cilium. El proceso con K3s requiere deshabilitar Flannel primero:

1
2
3


# /etc/rancher/k3s/config.yaml (añadir)
flannel-backend: none
disable-network-policy: true

Y luego instalar Cilium con Helm:

1
2
3
4
5
6
7
8
9


helm repo add cilium https://helm.cilium.io/

helm install cilium cilium/cilium \
 --namespace kube-system \
 --set operator.replicas=1 \
 --set ipam.mode=kubernetes \
 --set kubeProxyReplacement=strict \
 --set k8sServiceHost=192.168.1.10 \
 --set k8sServicePort=6443

Con kubeProxyReplacement=strict Cilium también reemplaza kube-proxy, lo que da mejor rendimiento con eBPF y mejor visibilidad del tráfico de red.

Después del cambio, empecé a aplicar NetworkPolicies. La primera y más importante: denegación por defecto en todos los namespaces de aplicaciones:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: default-deny-all
 namespace: apps
spec:
 podSelector: {}
 policyTypes:
 - Ingress
 - Egress

A partir de ahí, permitir solo lo necesario explícitamente.

Secrets: qué hacer cuando solo tienes K3s

En un entorno corporativo usarías Vault o External Secrets Operator con AWS Secrets Manager o similar. En un homelab eso es overkill. Mi solución fue más simple:

El cifrado en reposo de K3s ya protege los secrets en la base de datos. Para los manifiestos en Git, uso age para cifrar los valores sensibles antes de commitearlos:

1
2


# Cifrar un valor
echo "mi-contraseña-real" | age -r $(cat ~/.config/age/recipient.txt) | base64

Y el valor cifrado va al repositorio. Para desplegarlo hay un paso manual de descifrado. No es tan cómodo como un operador automático, pero para un homelab es suficiente y no añade complejidad operativa.

Falco para detección en tiempo de ejecución

Todo lo anterior es prevención. Falco es detección: monitoriza las llamadas al sistema y genera alertas cuando algo sospechoso ocurre en un contenedor.

Lo instalé con Helm:

1
2
3
4
5


helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
 --namespace falco \
 --create-namespace \
 --set driver.kind=ebpf

Las reglas por defecto ya cubren bastante: ejecución de shells en contenedores, escrituras en directorios del sistema, cambios de privilegios, conexiones de red inesperadas. Añadí algunas reglas propias para mi caso de uso específico.

Las alertas van a Loki también. Así tengo en el mismo lugar los audit logs del API server y las alertas de Falco.

Pod Security Standards

Con K3s en versión >= 1.25 puedes usar Pod Security Admission directamente. Apliqué el nivel baseline en los namespaces de aplicaciones y restricted donde era posible:

1
2
3
4
5
6
7


apiVersion: v1
kind: Namespace
metadata:
 name: apps
 labels:
 pod-security.kubernetes.io/enforce: baseline
 pod-security.kubernetes.io/warn: restricted

El nivel restricted es estricto: requiere que los contenedores no corran como root, que el sistema de archivos raíz sea de solo lectura, y que se eliminen todas las capabilities de Linux. Algunas aplicaciones que tenía desplegadas no cumplían. Fui arreglándolo de una en una antes de subir el nivel de enforce.

Lo que dejé para después

No todo está perfecto. Hay cosas que sé que debería hacer y todavía no he hecho:

Rootless K3s: se puede correr K3s completamente sin root, lo que reduce el impacto de una posible escalada de privilegios. Lo he mirado, tiene algunas limitaciones con ciertas características de red, pero para mi caso de uso debería funcionar.

Verificación de imágenes con cosign: firmar y verificar imágenes antes de desplegarlas. Tengo un registro privado para mis imágenes y las de terceros que uso, pero no estoy verificando firmas todavía.

CIS Benchmark: K3s tiene documentación oficial para el benchmark CIS K3s. Lo he revisado parcialmente pero no he pasado kube-bench de forma sistemática para ver qué queda pendiente.

Lo que aprendí

La instalación por defecto de K3s es sorprendentemente razonable para lo que es: una distribución pensada para ser fácil de desplegar. Pero “razonable” no es lo mismo que “bastionada”.

Lo que más me sorprendió fue lo fácil que resultó hacer la mayoría de cambios. K3s tiene flags de primera clase para muchas cosas que en kubeadm requieren configuración manual. El secrets-encryption, el protect-kernel-defaults, la política de auditoría directamente en el archivo de configuración. No es tan difícil si te sientas a leer la documentación.

El mayor riesgo en un homelab no es que alguien en internet te ataque directamente. Es que tienes un montón de servicios corriendo en la misma red que tu vida personal, y si alguno se compromete, el radio de explosión puede ser mayor de lo que parece. Vale la pena tomárselo en serio aunque sea un entorno de juguete.

Buenas prácticas de seguridad en contenedores

Fri, 14 Jul 2023 10:00:00 +0100

La superficie de ataque de los contenedores

Los contenedores dan aislamiento de procesos, no de seguridad. Un contenedor mal configurado puede exponer el kernel, filtrar secretos o servir como punto de pivote. Primero, entiende la superficie de ataque:

Imágenes - Librerías vulnerables, credenciales hardcodeadas, herramientas innecesarias
Runtime - Vulnerabilidades que permiten escapes
Orquestador (RBAC de Kubernetes, network policies) - Servicios expuestos, permisos excesivos
Cadena de suministro - Imágenes base o dependencias comprometidas
Secretos - En imágenes o variables de entorno que cualquier proceso puede leer

La seguridad requiere defensa en profundidad: build, ship, run.

Seguridad de las imágenes

Usa imágenes base mínimas

Cada paquete adicional en una imagen de contenedor es una vulnerabilidad potencial. Prefiere imágenes base mínimas:

1
2
3
4


# Preferir distroless o Alpine sobre distribuciones completas
FROM gcr.io/distroless/static-debian11
# o
FROM alpine:3.18

Las imágenes distroless contienen solo tu aplicación y sus dependencias de runtime — sin shell, sin gestor de paquetes, sin binarios innecesarios. Esto reduce drásticamente la superficie de ataque.

Multi-Stage Builds

Los multi-stage builds permiten compilar en una etapa y copiar solo el artefacto final a una imagen de runtime mínima:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Build stage
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app/server

# Runtime stage
FROM gcr.io/distroless/static-debian11
COPY --from=builder /app/server /server
USER nonroot:nonroot
ENTRYPOINT ["/server"]

Las herramientas de compilación, el código fuente y los archivos intermedios nunca llegan a la imagen final.

Nunca ejecutes como root

Ejecutar contenedores como root significa que un escape del contenedor le da al atacante acceso root en el host. Siempre especifica un usuario no-root:

1
2
3


# Crear un usuario no-root
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

En Kubernetes, esto se refuerza con Pod Security Standards (más detalles abajo).

Comparación de Dockerfile seguro vs. inseguro

Aquí hay una comparación lado a lado de errores comunes frente a prácticas seguras:

1
2
3
4
5
6
7
8


# INSEGURO - NO hagas esto
FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl wget vim
COPY . /app
RUN echo "DB_PASSWORD=supersecret" > /app/.env
EXPOSE 22 80 443
USER root
CMD ["python3", "/app/main.py"]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# SEGURO - Sigue este patrón
FROM python:3.11-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --user -r requirements.txt

FROM python:3.11-slim
RUN groupadd -r appgroup && useradd -r -g appgroup appuser
WORKDIR /app
COPY --from=builder /root/.local /home/appuser/.local
COPY --chown=appuser:appgroup . .
ENV PATH=/home/appuser/.local/bin:$PATH
EXPOSE 8080
USER appuser
HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost:8080/health || exit 1
CMD ["python3", "main.py"]

Diferencias clave: imagen base mínima, multi-stage build, sin secretos en la imagen, usuario no-root, solo los puertos necesarios expuestos, health check incluido.

Escaneo de imágenes con Trivy

Trivy es un escáner de vulnerabilidades open-source que analiza imágenes de contenedores, sistemas de archivos y configuraciones de IaC. Intégralo en tu pipeline de CI para detectar vulnerabilidades antes del despliegue.

Escaneo básico de imagen

1
2
3
4
5
6
7
8


# Escanear una imagen en busca de vulnerabilidades
trivy image python:3.11-slim

# Escanear con filtro de severidad
trivy image --severity HIGH,CRITICAL myapp:latest

# Fallar el CI si se encuentran vulnerabilidades críticas
trivy image --exit-code 1 --severity CRITICAL myapp:latest

Escaneo en CI/CD

Añade Trivy a tu pipeline para que ninguna imagen con vulnerabilidades críticas llegue a producción:

1
2
3
4
5
6
7
8


# Ejemplo de paso en GitHub Actions
- name: Run Trivy vulnerability scanner
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: 'myapp:${{ github.sha }}'
 format: 'table'
 exit-code: '1'
 severity: 'CRITICAL,HIGH'

Escaneo de IaC y sistemas de archivos

Trivy va más allá de las imágenes de contenedores:

1
2
3
4
5


# Escanear manifiestos de Kubernetes en busca de configuraciones incorrectas
trivy config ./k8s-manifests/

# Escanear un sistema de archivos en busca de secretos y vulnerabilidades
trivy fs --security-checks vuln,secret ./

Seguridad en runtime con Falco

Mientras que el escaneo detecta vulnerabilidades en tiempo de build, Falco monitoriza los contenedores en tiempo de ejecución. Utiliza instrumentación a nivel de kernel para detectar comportamientos sospechosos:

Ejecuciones inesperadas de shell dentro de contenedores.
Procesos que leen archivos sensibles (/etc/shadow, /etc/passwd).
Conexiones de red salientes a destinos inesperados.
Intentos de escalada de privilegios.

Ejemplo de reglas Falco

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


- rule: Terminal shell in container
 desc: Detect a shell being spawned in a container
 condition: >
 spawned_process and container and
 proc.name in (bash, sh, zsh, dash)
 output: >
 Shell spawned in container
 (user=%user.name container=%container.name
 shell=%proc.name parent=%proc.pname)
 priority: WARNING

- rule: Read sensitive file in container
 desc: Detect reads of sensitive files
 condition: >
 open_read and container and
 fd.name in (/etc/shadow, /etc/passwd)
 output: >
 Sensitive file read in container
 (user=%user.name file=%fd.name container=%container.name)
 priority: ERROR

Despliega Falco como un DaemonSet en tu cluster de Kubernetes para obtener visibilidad sobre el comportamiento en runtime en todos los nodos.

Seguridad en Kubernetes

Pod Security Standards

Los Pod Security Standards de Kubernetes definen tres niveles de restricción:

Privileged — Sin restricciones (solo para cargas de trabajo a nivel de sistema).
Baseline — Previene escaladas de privilegios conocidas.
Restricted — Altamente restringido, siguiendo las mejores prácticas de seguridad.

Aplícalos a nivel de namespace:

1
2
3
4
5
6
7
8


apiVersion: v1
kind: Namespace
metadata:
 name: production
 labels:
 pod-security.kubernetes.io/enforce: restricted
 pod-security.kubernetes.io/audit: restricted
 pod-security.kubernetes.io/warn: restricted

NetworkPolicies

Por defecto, todos los pods en Kubernetes pueden comunicarse entre sí. Las NetworkPolicies permiten restringir el tráfico:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: api-allow
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: api
 policyTypes:
 - Ingress
 - Egress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 app: frontend
 ports:
 - protocol: TCP
 port: 8080
 egress:
 - to:
 - podSelector:
 matchLabels:
 app: database
 ports:
 - protocol: TCP
 port: 5432

Esta política asegura que el pod de la API solo recibe tráfico del frontend y solo envía tráfico a la base de datos.

RBAC

Sigue el principio de mínimo privilegio. Evita dar cluster-admin a service accounts. Crea roles específicos:

1
2
3
4
5
6
7
8
9


apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: production
 name: deployment-manager
rules:
 - apiGroups: ["apps"]
 resources: ["deployments"]
 verbs: ["get", "list", "watch", "update", "patch"]

Audita regularmente los RBAC bindings con herramientas como kubectl-who-can o rbac-tool.

Gestión de secretos

Nunca almacenes secretos en imágenes de contenedores, variables de entorno en Dockerfiles en texto plano ni en control de versiones. En su lugar:

Usa Kubernetes Secrets (cifrados en reposo con KMS).
Usa gestores de secretos externos: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault.
Usa el External Secrets Operator para sincronizar secretos de proveedores externos en Kubernetes.
Rota los secretos regularmente y audita el acceso.

Seguridad de la cadena de suministro

Imágenes firmadas

Firma tus imágenes de contenedores con cosign (parte del proyecto Sigstore) y verifica las firmas antes del despliegue:

1
2
3
4
5


# Firmar una imagen
cosign sign --key cosign.key myregistry/myapp:v1.0

# Verificar una firma
cosign verify --key cosign.pub myregistry/myapp:v1.0

SBOM (Software Bill of Materials)

Genera un SBOM para cada imagen para poder verificar rápidamente si un CVE recién publicado afecta a tus contenedores en ejecución:

1
2
3
4
5


# Generar SBOM con Trivy
trivy image --format spdx-json --output sbom.json myapp:latest

# O usar syft
syft myapp:latest -o spdx-json > sbom.json

Checklist de seguridad de contenedores

Usa esta checklist para evaluar tu postura de seguridad en contenedores:

Las imágenes base son mínimas (distroless o Alpine).
Se usan multi-stage builds para excluir herramientas de compilación.
Los contenedores se ejecutan como usuarios no-root.
Las imágenes se escanean en busca de vulnerabilidades en CI/CD.
No se almacenan secretos en imágenes ni en variables de entorno en texto plano.
Los Pod Security Standards de Kubernetes están habilitados.
Las NetworkPolicies restringen la comunicación entre pods.
RBAC sigue el mínimo privilegio.
La monitorización de seguridad en runtime está activa (Falco o equivalente).
Las imágenes están firmadas y las firmas se verifican antes del despliegue.
Se generan y almacenan SBOMs para todas las imágenes en producción.
Los secretos se gestionan a través de un gestor de secretos externo.
Las políticas de pull de imágenes están configuradas como Always para tags mutables.
Se realizan auditorías de seguridad y pruebas de penetración de forma regular.

Conclusión

La seguridad en contenedores es una práctica continua, no una tarea puntual. Empieza con lo básico: imágenes mínimas, usuarios no-root, escaneo. Luego añade monitorización en runtime, network policies, verificación de cadena de suministro, aplicación automatizada. Cada capa reduce el impacto y te acerca a seguridad real.

Seguridad en pipelines CI/CD: enfoque shift-left

Mon, 20 Jun 2022 00:00:00 +0000

¿Qué es la seguridad shift-left?

La seguridad shift-left consiste en adelantar las prácticas de seguridad en el ciclo de vida del desarrollo de software. En lugar de tratar la seguridad como una puerta final antes de producción (o peor, como algo que se piensa después), integras comprobaciones de seguridad directamente en tus pipelines CI/CD. Así las vulnerabilidades se detectan cuando son más baratas de corregir: en tiempo de desarrollo.

El modelo tradicional de “constrúyelo primero, audítalo después” no escala. Las aplicaciones modernas se despliegan docenas de veces al día. Si tu revisión de seguridad es un proceso manual que ocurre una vez al trimestre, estás desplegando código vulnerable la mayoría del tiempo.

Vectores de amenaza en pipelines CI/CD

Antes de securizar tu pipeline, entiende contra qué te estás defendiendo. Los sistemas CI/CD son objetivos de alto valor porque tienen acceso a credenciales de producción, código fuente y artefactos de build.

Los vectores de amenaza comunes incluyen:

Dependencias comprometidas: Un paquete malicioso en tu árbol de dependencias (ataque a la cadena de suministro).
Secretos filtrados: Claves API, tokens o contraseñas commiteados en el código fuente o expuestos en logs de build.
Vulnerabilidades en el código: Inyección SQL, XSS, deserialización insegura y otros problemas del OWASP Top 10 introducidos en el código de la aplicación.
Configuración insegura del pipeline: Acceso excesivamente permisivo en runners, reglas de protección de ramas ausentes o puertas de aprobación faltantes.
Vulnerabilidades en imágenes de contenedor: Imágenes base con CVEs conocidos que se propagan a producción.
Manipulación de artefactos de build: Artefactos no firmados o no verificados que pueden ser reemplazados por un atacante.

Integrando SAST en tu pipeline

Static Application Security Testing (SAST) analiza el código fuente sin ejecutarlo. Detecta vulnerabilidades temprano, antes de que el código siquiera se ejecute.

Herramientas recomendadas

Semgrep: Rápido, flexible, soporta reglas personalizadas. Funciona con muchos lenguajes. Mi principal recomendación para la mayoría de equipos.
Bandit: Específico para Python. Excelente para proyectos Python ya que entiende patrones de seguridad propios de Python.
SonarQube: Alcance más amplio (calidad de código + seguridad). Más pesado de configurar pero útil si quieres un panel unificado.

Ejecutando Semgrep localmente

1
2
3
4
5
6
7
8


# Instalar
pip install semgrep

# Ejecutar con rulesets por defecto
semgrep --config auto .

# Ejecutar con reglas OWASP Top 10 específicamente
semgrep --config "p/owasp-top-ten" .

Ejecutando Bandit para proyectos Python

1
2


pip install bandit
bandit -r ./src -f json -o bandit-report.json

La clave es ejecutar estas herramientas en cada pull request, no solo en la rama principal. Los desarrolladores deberían ver los hallazgos antes de que el código se fusione.

Integrando DAST en tu pipeline

Dynamic Application Security Testing (DAST) prueba la aplicación en ejecución desde el exterior, simulando un atacante. Detecta problemas que SAST no puede — errores de configuración, fallos de autenticación y vulnerabilidades en tiempo de ejecución.

OWASP ZAP

OWASP ZAP es la herramienta DAST de código abierto estándar. Puedes ejecutarla en tu pipeline contra un despliegue de staging:

1
2
3
4
5
6
7


# Descargar la imagen Docker de ZAP
docker pull ghcr.io/zaproxy/zaproxy:stable

# Ejecutar un escaneo baseline contra una URL objetivo
docker run -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py \
 -t https://staging.example.com \
 -r zap-report.html

DAST es típicamente más lento que SAST. Ejecútalo después del despliegue en un entorno de staging en lugar de en cada commit. Una cadencia nocturna o por release funciona bien para la mayoría de equipos.

Escaneo de secretos

Los secretos filtrados son uno de los fallos de seguridad más comunes y dañinos. Una vez que un secreto está en el historial de Git, considéralo comprometido — incluso si lo eliminas en un commit posterior.

Herramientas

gitleaks: Escanea repositorios Git en busca de secretos usando regex y detección basada en entropía.
trufflehog: Busca en el historial de Git cadenas de alta entropía y patrones de secretos conocidos.

Ejecutando gitleaks

1
2
3
4
5
6
7
8


# Instalar
brew install gitleaks # o descargar el binario desde GitHub releases

# Escanear el repo actual
gitleaks detect --source . --report-path gitleaks-report.json

# Escanear en CI (detectar solo nuevas fugas en el PR)
gitleaks detect --source . --log-opts="origin/main..HEAD"

Hook de pre-commit

Bloquea secretos antes de que lleguen al remoto:

1
2
3
4
5
6


# .pre-commit-config.yaml
repos:
 - repo: https://github.com/gitleaks/gitleaks
 rev: v8.16.1
 hooks:
 - id: gitleaks

Escaneo de dependencias

Tu aplicación es tan segura como su dependencia más débil. Los ataques a la cadena de suministro están en aumento y debes escanear tu árbol de dependencias regularmente.

Herramientas

Trivy: Escanea imágenes de contenedor, sistemas de archivos y repos Git en busca de vulnerabilidades. Rápido y completo.
Snyk: Opción comercial con un tier gratuito generoso. Buena experiencia de desarrollador.
OWASP Dependency-Check: Maduro, código abierto, soporta múltiples ecosistemas.

1
2
3
4
5


# Escanear una imagen de contenedor con Trivy
trivy image my-app:latest

# Escanear el sistema de archivos en busca de dependencias vulnerables
trivy fs --severity HIGH,CRITICAL .

Workflow de GitHub Actions con etapas de seguridad

Aquí tienes un workflow práctico de GitHub Actions que integra todas las etapas de seguridad discutidas:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87


name: Secure CI/CD Pipeline

on:
 pull_request:
 branches: [main]
 push:
 branches: [main]

jobs:
 secret-scan:
 name: Secret Scanning
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 with:
 fetch-depth: 0
 - name: Run gitleaks
 uses: gitleaks/gitleaks-action@v2
 env:
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

 sast:
 name: Static Analysis
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Run Semgrep
 uses: returntocorp/semgrep-action@v1
 with:
 config: >-
 p/security-audit
 p/owasp-top-ten
 - name: Run Bandit (Python)
 run: |
 pip install bandit
 bandit -r ./src -f json -o bandit-report.json || true
 - name: Upload SAST reports
 uses: actions/upload-artifact@v4
 with:
 name: sast-reports
 path: "*.json"

 dependency-scan:
 name: Dependency Scanning
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Run Trivy filesystem scan
 uses: aquasecurity/trivy-action@master
 with:
 scan-type: fs
 severity: HIGH,CRITICAL
 exit-code: 1

 build-and-scan-image:
 name: Build & Scan Image
 needs: [secret-scan, sast, dependency-scan]
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Build Docker image
 run: docker build -t my-app:${{ github.sha }} .
 - name: Scan image with Trivy
 uses: aquasecurity/trivy-action@master
 with:
 image-ref: my-app:${{ github.sha }}
 severity: HIGH,CRITICAL
 exit-code: 1

 deploy-staging:
 name: Deploy to Staging
 needs: [build-and-scan-image]
 runs-on: ubuntu-latest
 environment: staging
 steps:
 - name: Deploy to staging
 run: echo "Deploy to staging environment"

 dast:
 name: Dynamic Analysis
 needs: [deploy-staging]
 runs-on: ubuntu-latest
 steps:
 - name: OWASP ZAP Baseline Scan
 uses: zaproxy/action-baseline@v0.9.0
 with:
 target: "https://staging.example.com"

Observa el orden deliberado: el escaneo de secretos, SAST y escaneo de dependencias se ejecutan en paralelo (feedback rápido). El escaneo de imagen se ejecuta después del build. DAST se ejecuta después del despliegue en staging.

Checklist de buenas prácticas

Aquí tienes una checklist para evaluar la madurez de seguridad de tu pipeline CI/CD:

El escaneo de secretos se ejecuta en cada PR y bloquea el merge ante hallazgos.
Los hooks de pre-commit previenen que se commiteen secretos localmente.
SAST se ejecuta en cada PR con reglas que cubren OWASP Top 10.
El escaneo de dependencias se ejecuta en cada PR y marca CVEs HIGH/CRITICAL.
El escaneo de imágenes de contenedor se ejecuta antes de publicar imágenes en un registry.
DAST se ejecuta contra staging en cada release (o como mínimo cada noche).
La protección de ramas requiere que pasen las comprobaciones de seguridad antes del merge.
El principio de mínimo privilegio se aplica en permisos de CI runners y acceso a secretos.
Los commits firmados y artefactos firmados se exigen para releases de producción.
Los logs de build se revisan para asegurar que no se filtran secretos en la salida.
Se usa pinning de dependencias (versiones exactas, no rangos) para prevenir ataques a la cadena de suministro.
Se realiza rotación regular de todos los secretos de CI/CD y claves de cuentas de servicio.

Reflexiones finales

La seguridad shift-left no se trata de comprar una herramienta, sino de cambiar la cultura. Las comprobaciones de seguridad en CI/CD deben ser rápidas, automatizadas e innegociables. Empieza con el escaneo de secretos (tiene el mayor ROI), añade SAST, y luego incorpora el escaneo de dependencias y DAST.

El objetivo no es detectar todo en el pipeline. Lo importante es elevar el listón lo suficiente para que los problemas obvios nunca lleguen a producción, liberando a tu equipo de seguridad para enfocarse en las amenazas sutiles y de alto impacto que requieren juicio humano.