self-host-repo-hardening-runbook
Repositorio con runbooks de ingeniería para endurecer repositorios self-host, cubriendo stacks Docker Compose y publicación de imágenes, alineados a la línea base de supply-chain de heyvaldemar.
Ficha actualizada 24 sept 2026, 5:01 · upstream 24 sept 2026, 4:44 · release v1.3.2
Qué es self-host-repo-hardening-runbook
Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.
Este repositorio ofrece dos guías de procedimiento (runbooks) documentadas para aplicar estándares de seguridad en despliegues auto-alojados. El primer runbook se centra en stacks Docker Compose, gestionando secretos, CI workflows y pinning de imágenes upstream. El segundo está dedicado a la publicación de imágenes Docker, enfocándose en hardening de Dockerfiles, SBOMs con SLSA y firmas Cosign.
Ambos comparten scripts para archivos comunitarios y configuración de OpenSSF Scorecard. Los runbooks definen fases específicas para auditoría inicial, higiene de secretos, integración de Dependabot y verificación de integridad mediante Trivy. Incluyen plantillas para LICENSE, SECURITY.md y CHANGELOG, así como guías para reescribir READMEs con estructura evaluador-primero.
El enfoque prioriza la seguridad de la cadena de suministro: pinning de digests SHA256, eliminación de privilegios en contenedores, límites de recursos y políticas de retención de tags. Se recomienda consultar los repositorios de referencia (aws-kubectl-docker y keycloak-traefik-letsencrypt-docker-compose) como ejemplos dogfood para resolver ambigüedades.
- Hardening de repositorios Docker Compose con Traefik y Let's Encrypt
- Publicación segura de imágenes Docker a Docker Hub o GHCR con SBOMs
- Implementación de auditoría OpenSSF Scorecard en workflows CI/CD
- Gestión de dependencias con Dependabot para ecosistemas GitHub Actions y Docker
- Auditoría de seguridad de supply chain mediante escaneos Trivy SARIF
- Estandarización de READMEs y políticas de seguridad (SECURITY.md, LICENSE)
- Scripts automatizados para fases comunes como gestión de secretos y configuración de Scorecard
- Plantillas reutilizables para archivos comunitarios (LICENSE, SECURITY.md, CHANGELOG)
- Integración nativa con OpenSSF Scorecard y subida de resultados a GitHub Security tab
- Enfoque en pinning de digests SHA256 para imágenes upstream y base Dockerfiles
- Guías específicas para despliegues multi-arch (linux/amd64, linux/arm64) con BuildKit
- Políticas de retención de tags y limpieza de legacy tags en Docker Hub
- No aplica directamente a repositorios de Helm charts o librerías/CLI sin cherry-pick manual
- El runbook de imágenes aún carece de plantillas Dockerfile integradas (requiere copiar de referencia)
- Requiere adaptación manual para monorepos multi-imagen que publican varias imágenes desde un solo repositorio
- Fases de auditoría inicial requieren tiempo significativo por repositorio debido a secretos únicos
- Algunas herramientas como Cosign v2.6.1 se mantienen sin migración inmediata a v3.x según el README
Perfil de infraestructura
Estimación inicial derivada del repositorio y de los servicios detectados.
Despliegue detectado
Qué señales reales de instalación hemos encontrado.
Clonar el repositorio objetivo y este junto en la misma máquina local. Seleccionar RUNBOOK.md para stacks Compose o IMAGE-PUBLISHING-RUNBOOK.md para imágenes. Ejecutar las fases como PRs individuales, fusionando entre etapas. Consultar los repositorios de referencia (keycloak-traefik-letsencrypt-docker-compose y aws-kubectl-docker) si la documentación es ambigua.
Stack y dependencias
Componentes inferidos a partir de manifests, configuración y documentación.
Puede sustituir a
Relaciones detectadas por el análisis del repositorio y su categoría.
Experiencia real de la comunidad
Ayuda a contrastar la estimación automática con instalaciones reales.
Todavía no hay datos comunitarios para este proyecto.