Exploit for devsecops-poc-workflows

## https://sploitus.com/exploit?id=09AE58F8-EF40-5E92-8D4C-75F669557E79
# Laboratorio público DevSecOps

> **Código sintético y educativo.** Este repositorio no contiene código, datos,
> identidades, secretos ni infraestructura de SaleADS. Los workflows validan el
> contrato PR → CI → build único → Trivy pre-publish. No publican en registries
> corporativos ni despliegan en ArgoCD o GKE.

# DevSecOps PoC — Reusable Workflows

Laboratorio privado y desechable para centralizar CI y seguridad reutilizable.

## Aviso de seguridad

Este repositorio pertenece a un laboratorio aislado. No debe conectarse a datos, identidades, secretos, redes ni registros corporativos.

## Arquitectura

| Workflow | Responsabilidad | Permiso máximo |
|---|---|---|
| reusable-node-ci.yml | npm ci, unit, e2e y build de NestJS | contents: read |
| reusable-maven-ci.yml | Maven Wrapper clean verify para Java 21 | contents: read |
| reusable-security.yml | Gitleaks, Semgrep, Trivy SCA e imagen, SARIF | contents: read |
| reusable-caller-integrity.yml | Detección contractual de cambios del caller y policy central | contents: read |

Ningún job solicita id-token: write. La identidad cloud se añadirá únicamente al job de despliegue de una tarea posterior.

La arquitectura, el flujo completo, las decisiones de seguridad y el procedimiento de rollback están documentados en [docs/KAN-117-roadmap-reusable-workflows.md](docs/KAN-117-roadmap-reusable-workflows.md).

La política baseline/delta compatible con Shape Up está documentada en [docs/KAN-118-baseline-delta-policy.md](docs/KAN-118-baseline-delta-policy.md).

La matriz ejecutable de casos positivos, negativos y de remediación está documentada en [docs/KAN-118-test-matrix.md](docs/KAN-118-test-matrix.md).

La validación adversarial de evasiones, falsos positivos/negativos, integridad y feedback al developer está especificada en [docs/KAN-118-adversarial-test-plan.md](docs/KAN-118-adversarial-test-plan.md).

La decisión vigente de salida del laboratorio está documentada en [docs/KAN-115-go-no-go.md](docs/KAN-115-go-no-go.md): **NO-GO para rollout en SaleADS** hasta cerrar sus bloqueadores.

La Fase 1 se materializa en `policy-pack/v1`: un contrato JSON versionado, fixtures positivos y negativos, y `scripts/validate_policy_pack.py`. El workflow `validate-policy-pack.yml` es el único ejecutor del harness; no modifica ni sustituye la lógica productiva de Semgrep, Trivy o Gitleaks.

El registro `policy-pack/v1/catalog/cases.json` enlaza los 92 casos del plan con tres estados independientes: **catalogado**, **implementado** y **validado**. Un caso validado exige evidencia inmutable de GitHub Actions; estar catalogado nunca cuenta como cobertura ejecutada.

KAN-115 cerró con **92/92 casos validados**. `validated` significa que la
evidencia fue ejecutada y aceptada; no equivale a control efectivo. Seis casos
conservan `control_outcome: unsupported` y la decisión para SaleADS sigue
siendo NO-GO.

El slice `policy-pack/v1/integrity/cases.json` implementa `INT-01` a `INT-14` como snapshots del contrato de detección. Estos casos comprueban decisiones deterministas ante bypasses, referencias mutables, permisos excesivos, artifacts no ligados y runtimes incompatibles. Los casos marcados con `platform_evidence_required` permanecen **no validados** hasta aportar evidencia real de rulesets, required workflows/checks, branch protection o comportamiento de GitHub. El snapshot no demuestra enforcement de plataforma.

El guard ejecutable del caller y sus límites de enforcement se documentan en [docs/KAN-118-caller-integrity-guard.md](docs/KAN-118-caller-integrity-guard.md). Su policy y código se fijan desde un commit central inmutable para reproducibilidad, mientras el consumidor se trata exclusivamente como input no confiable y nunca se ejecuta. En repositorios personales esto es **detección y contrato**, no una raíz de confianza: `DEVSECOPS_APPROVED_WORKFLOW_SHAS` es configuración mutable por un actor con acceso `write` al caller.

`BLOCK` significa que el detector falla su job y emite una conclusión roja. No significa que GitHub impida el merge: sin un required check, ruleset o branch protection administrado fuera del repositorio, un actor puede omitir el workflow, cambiar la variable o fusionar pese al resultado.

El rollout en SaleADS es **no-go** mientras rulesets/required workflows/branch protection y la autoridad de configuración no estén administrados fuera del repositorio consumidor y probados con intentos reales de bypass.

## Flujo paso a paso

1. El repositorio consumidor recibe push, Pull Request o ejecución manual.
2. Su workflow llamador referencia este repositorio por un SHA de 40 caracteres.
3. El job de pruebas selecciona Node o Maven según el stack.
4. Los jobs de seguridad se ejecutan en paralelo y con permisos de solo lectura.
5. Gitleaks examina el historial Git completo.
6. Semgrep combina `p/default` con una política central confiable y conserva el resultado SARIF.
7. Trivy analiza dependencias y la imagen construida en el runner de GitHub Actions.
8. El SARIF completo conserva la deuda heredada como evidencia.
9. Semgrep compara contra el commit base; Trivy escanea base y HEAD con la misma vulnerability DB.
10. Solo el delta nuevo de seguridad bloquea; Gitleaks continúa bloqueando secretos confirmados.
11. No hay continue-on-error, secrets: inherit ni bypass silencioso.

## Fijación de la cadena de suministro

Todas las Actions externas están fijadas por SHA completo. Semgrep usa una imagen fijada por digest OCI. Trivy está fijado a action v0.36.0 y binario v0.69.3, versiones posteriores a la remediación o reconocidas como seguras frente al incidente de marzo de 2026.

## Versionado y rollback

- La versión humana se marca con un tag poc-v1.x.y.
- Los consumidores usan siempre el SHA exacto, nunca main ni un tag mutable.
- Rollback: cambiar el SHA del workflow llamador al commit anterior conocido, abrir Pull Request y verificar los mismos checks.
- No borrar un commit mientras algún consumidor lo referencie.

## Límites

- Sin Terraform, OpenTofu ni escaneo IaC.
- SARIF/JSON se usa únicamente como evidencia transitoria dentro del runner. El
  feedback del PR vive en summaries y annotations. Solo el contrato scan-to-publish
  puede exportar temporalmente la imagen exacta ya escaneada.
- El baseline de Trivy es el scan del commit base ejecutado con la misma DB que HEAD; el SARIF completo conserva los hallazgos heredados y el JSON delta identifica solo regresiones del cambio.