Secure Delivery Pipeline
A DevSecOps release design with scoped cloud access, container checks and explicit deployment approvals.
GitHub Actions · OIDC · Trivy
Scope: architecture and validation design. The indicators summarize design targets. Implementation evidence will be added as the lab develops.
The scenario
A fictional team shares a permanent AWS key between build and deployment jobs. Releases use mutable image tags, so it is difficult to establish which artifact is running.
Architecture
The proposed workflow tests the service, scans source and container configuration, builds an image and records its digest. A protected environment gates deployment. The deployment job exchanges a GitHub OIDC token for a temporary AWS session scoped to the target environment.
Key decisions
Build and deployment jobs have different permissions. Actions should be pinned to reviewed revisions. Scan findings need a triage policy, an owner and an expiry for exceptions; a green scan alone is not proof of security.
Validation plan
Test that a non-approved branch cannot assume the deployment role. Introduce a known failing check and confirm deployment is blocked. Record the source revision, image digest and environment for each rehearsal release.
Trade-offs
Stricter checks can add friction if ownership is unclear. Keep the deployment path small, make exceptions visible and reserve production permissions for the job that actually needs them.
Next iteration
Publish a sample repository and failure demonstrations. The diagram and narrative describe a fictional design rather than an audited production security posture.
El escenario
Un equipo ficticio comparte una clave permanente de AWS entre jobs de construcción y despliegue. Las releases usan tags mutables, por lo que es difícil establecer qué artefacto está ejecutándose.
Arquitectura
El flujo propuesto prueba el servicio, revisa código y configuración del contenedor, construye una imagen y registra su digest. Un entorno protegido controla el despliegue. El job de entrega intercambia un token OIDC de GitHub por una sesión temporal de AWS acotada al entorno destino.
Decisiones técnicas
Los jobs de construcción y despliegue tienen permisos distintos. Las actions deben fijarse a revisiones evaluadas. Los hallazgos requieren criterios de triage, un responsable y caducidad de excepciones; un análisis en verde no demuestra seguridad por sí solo.
Plan de validación
Comprobar que una rama no autorizada no pueda asumir el rol de despliegue. Introducir una comprobación fallida y verificar que bloquee la entrega. Registrar revisión fuente, digest y entorno para cada release de ensayo.
Concesiones del diseño
Las comprobaciones estrictas añaden fricción si no hay responsables claros. Conviene mantener pequeño el flujo de entrega, hacer visibles las excepciones y reservar permisos de producción al job que los necesita.
Próxima iteración
Publicar un repositorio de ejemplo y demostraciones de fallos. El diagrama y la narrativa describen un diseño ficticio, no una postura de seguridad de producción auditada.