El escaneo de secretos que Trivy hace por defecto sobre toda la imagen
(node_modules incluido) hizo timeout (context deadline exceeded, 15m) en
el gate CRITICAL del backend el 2026-09-27; el propio log de Trivy
recomienda --scanners vuln. Aplicado a los 6 pasos trivy image (CRITICAL
bloqueante y HIGH informativo — un FATAL por timeout tumba el job aunque
--exit-code sea 0) de build.yaml, build-medusa.yaml y deploy-docs.yaml.
Sin pérdida real de cobertura (auditado por devsecops-auditor): Gitleaks
ya escanea todo el árbol de cada workload antes del build (needs:
gitleaks), ningún build recibe --build-arg/--secret con credenciales, los
ENV build-only del backend no llegan al stage final, y 11 corridas
recientes de image secret-scan tuvieron 0 hallazgos. Hueco residual
aceptado: secretos en capas de imágenes base oficiales.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018r19s4H8MBGegqToqw5guP
El paso "Validar navegación real del catálogo" buscaba la key exacta
`${category}:${collection}:${query}` en app/catalog/page.tsx; desde
franquicias/personajes la key también incluye franquicia/saga/personaje y
el pipeline del frontend fallaba (2 veces) aunque el comportamiento
protegido se cumple. Ahora valida por prefijo + exige los parámetros de
taxonomía. No toca ningún gate de seguridad.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018r19s4H8MBGegqToqw5guP
Agrega el step "Promover a Produccion (CD)" al mismo job que ya
despliega a Staging en build.yaml -- misma logica de
scripts/promote-to-production.sh (sed/perl sobre el manifest de
Produccion) pero sin el read -rp interactivo, gateado por la misma
verificacion de promocion segura (merge-base --is-ancestor) que ya usa
el step de Staging.
Decision explicita del usuario 2026-09-20: cero gate humano entre
Staging y Produccion -- la promocion manual deja de ser el camino
normal, scripts/promote-to-production.sh queda solo como herramienta
de excepcion/rollback.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01QMP7ULbxbsB5g1vELNAT3D
El footer mostraba "v4.1" fijo -- inutil para distinguir a simple
vista si Staging y Produccion estan en la misma version. Ahora lee
process.env.APP_VERSION, que el propio CD (.gitea/workflows/build.yaml)
bumpea junto con el tag de la imagen en cada auto-deploy a Staging.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012Y4df3Z7odr9Cg8F2nw6uV
Decisión del usuario 2026-09-14: dejar de validar cambios directo
contra shop.cruzcloud.net (producción real).
- workloads/ecommerce-staging/: overlay del frontend, mismo Dockerfile
e imagen que Producción, backend compartido (Medusa/Postgres/
Meilisearch de "ecommerce" via FQDN cross-namespace
medusa-svc.ecommerce.svc.cluster.local -- decisión del usuario, evita
duplicar el consumo de la NAS con un backend propio para Staging).
1 réplica en vez de 2, resources mas chicos.
- apps/ecommerce-staging-app.yaml + ecommerce-staging-governance-app.yaml:
Applications de Argo CD para el workload y la governance (en
platform-infra), mismo patrón que ecommerce-app/ecommerce-governance.
- Ingress en staging.cruzcloud.net -- cubierto por el wildcard DNS
*.cruzcloud.net que ya existe en Cloudflare, sin cambios de DNS.
- .gitea/workflows/build.yaml: MANIFEST_FILE/KUSTOMIZE_DIR pasan a
apuntar a Staging -- todo push a main promueve ahí automáticamente
desde ahora. Promover a Producción (workloads/ecommerce, sin cambios
en este commit) queda como acción manual aparte, ver
scripts/promote-to-production.sh.
Secrets commerce-storefront y gitea-registry-secret ya copiados a mano
al namespace ecommerce-staging (no versionados, mismo criterio que el
resto de los secrets reales del repo).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_012Y4df3Z7odr9Cg8F2nw6uV
El guard de "Validar navegación real del catálogo" en build.yaml seguia
pinneado a la implementacion vieja de navbar.tsx: greppeaba literalmente
"collection=Marvel", "category=Mochilas" y "currentCollection", que eran
exactamente los valores hardcodeados que PR #32 elimino por estar rotos
(ya no correspondian a ningun dato real desde que se quito
legacyProductMeta en PR #29). El guard quedo validando el bug, no la
correccion, y bloqueo el build post-merge de PR #32.
Ahora valida el comportamiento real nuevo: que el nav arma su arbol
desde datos reales (buildCategoryTree), que linkea por nombre real de
categoria (encodeURIComponent(root.name)) y que expone el item activo
(aria-current={isActive(...)}). El check de remontaje en
app/catalog/page.tsx tambien se actualizo: la key ya no incluye
":${section}" porque ese query param nunca se usaba (dead code
eliminado en PR #32).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_013dunTcReWMKhWgCPkvAVHD
- Trivy IaC escaneaba solo el patch aislado de Kustomize
(workloads/ecommerce/frontend/patches/deployment.yaml), no lo que
realmente corre en el clúster. Eso generaba falsos positivos en todo
lo heredado del base remoto de platform-templates (runAsNonRoot,
seccompProfile) porque el patch nunca los repite. Se instala kubectl,
se renderiza el kustomization completo y se escanea ese output.
- readOnlyRootFilesystem pasa de false a true en el contenedor del
frontend: revisando next.config.ts (optimización de imágenes) y
app/api/revalidate/route.ts (revalidateTag sin cache handler custom),
la imagen sí escribe a ./.next/cache en runtime. Se agregan volúmenes
emptyDir para .next/cache y /tmp.
El default de Trivy (5m) dejó de alcanzar para escanear la imagen del
frontend, igual que ya le había pasado a commerce-backend el
2026-08-16 ("context deadline exceeded" ~4m45s, justo tras terminar
el docker build). Se aplica el mismo fix ya validado en
build-medusa.yaml: --timeout 15m0s en ambos scans de imagen (CRITICAL
y HIGH), y se sube timeout-minutes del job de 20 a 30 para que quepan.
Con el runner corriendo 1 job a la vez (capacity: 1), cuando 2+
pipelines comparten el mismo commit disparador, el primero en terminar
deja su propio commit de GitOps en main -- los siguientes veian 'main
ya no es igual a mi commit' y se saltaban su propia promocion, aunque
era seguro promocionar. Visto en vivo: Frontend construyo, escaneo y
firmo v1.0.119 pero el manifiesto seguia en v1.0.104 (Promocion GitOps:
false). Fix en los 3 workflows: git merge-base --is-ancestor en vez de
comparacion exacta de SHA. Bump manual de frontend a v1.0.119 (la
version que ya estaba lista, sin desplegar). Documentado el limite
conocido de este fix en el playbook de la migracion.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_011FqYP3Wf1W63Qmh7qgXAAT
Los 3 pipelines (build.yaml, build-medusa.yaml, deploy-docs.yaml)
todavia apuntaban a las rutas viejas de deployment.yaml (borradas al
migrar cada app a un overlay de platform-templates) para el paso de
auto-actualizacion GitOps. Se rompio en vivo en el primer build real
post-migracion (docs-portal v1.0.117): la imagen se construyo, escaneo
y firmo bien, pero el ultimo paso (sed sobre el manifest) fallo con
'No such file or directory'. Se corrigen las 3 rutas a
patches/deployment.yaml, y se bumpea a mano el tag de docs-portal a
v1.0.117 (la imagen ya existe en el registry, firmada y verificada,
no hace falta reconstruirla).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_011FqYP3Wf1W63Qmh7qgXAAT
Los 3 pipelines (frontend, commerce-backend, docs-portal) ahora capturan
el digest real del docker push y lo usan como referencia para cosign
sign/verify, en vez del tag mutable :VERSION. Documenta ademas la
decision de mantener Rekor deshabilitado (registry privado, evita
dependencia de red saliente hacia rekor.sigstore.dev via el tunel).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_011FqYP3Wf1W63Qmh7qgXAAT
El runner de Gitea ejecuta cada job dentro de un contenedor propio que
habla con el daemon Docker del host (sibling containers) -- un
`docker run -v "\${{ github.workspace }}:/src"` desde ahí intenta
montar una ruta que solo existe DENTRO del contenedor del job, no en
el host real: "mkdir /workspace: read-only file system". Confirmado en
el run real (job 128, task_id 128) tras el fix del anchor.
Se valida localmente contra docker.gitea.com/runner-images:ubuntu-latest
(la misma imagen del runner real) que python3/pip3 están disponibles.
pip3 install directo falla por paquetes de apt sin metadata compatible
(PyJWT, "RECORD file not found") -- se usa un venv aislado en su lugar,
validado end-to-end con los dos steps extraídos del YAML real.
Gitea descartaba el workflow completo en TODOS los eventos (push y
pull_request), desde el primer commit de gitleaks: "unknown on type:
&yaml.Node{...Value:"frontend_paths"...}". El YAML era válido (pyyaml
lo parsea sin problema, resolviendo el alias como cualquier parser
estándar) pero el parser propio de Gitea Actions para el bloque "on:"
no resuelve &anchor/*alias antes de inspeccionar el tipo de nodo.
Confirmado en vivo: tras mergear #19 a main, deploy-docs.yaml corrió
normal (sin anchors) pero build.yaml no generó ningún action_run.
Fix: paths duplicados literalmente entre push: y pull_request:, sin
anchor. Válido con parser YAML + bash -n en los 20 steps.
El python3 -c "..." embebido dentro del run: | tenía el código pegado
a columna 0, por debajo de la indentación del bloque YAML -- eso corta
el block scalar ahí mismo y Gitea terminaba ignorando el workflow
completo ("could not find expected ':'"), silenciosamente, desde el
commit de Semgrep.
Validado con un parser YAML real (no solo con builds de Docker) y
bash -n sobre los 20 steps del archivo.
Firma la imagen (solo el tag versionado, no :latest) después del push
exitoso, usando la llave privada desde secrets de Gitea Actions
(COSIGN_PRIVATE_KEY/COSIGN_PASSWORD, nunca en el repo ni en disco).
Verifica la firma como smoke test en el mismo pipeline contra
workloads/ecommerce/cosign.pub (pública, commiteada a propósito).
Firma solo con el par de llaves propio, sin publicar en el
transparency log público de Sigstore (--use-signing-config=false
--tlog-upload=false / --insecure-ignore-tlog=true) — registry privado,
no tiene sentido esa fuga de metadata.
Par de llaves generado y validado end-to-end (firma + verificación,
incluyendo que verificar con la llave incorrecta falla como se espera)
contra un registry local descartable antes de tocar nada real. Docs en
docs/devsecops/cosign.md, incluyendo qué falta para que un admission
controller verifique esto en el cluster (no implementado todavía).
Corre después del gate de CRITICAL de Trivy, sobre la imagen ya
construida. Genera CycloneDX y SPDX, publicados como artifact
sbom-v1.0.X en cada build.
Validado contra la imagen real: 3528 componentes CycloneDX / 228
paquetes SPDX. Documenta en docs/devsecops/sbom.md el propósito
(trazabilidad tipo "log4shell"), diferencia entre formatos, y un
hallazgo real (yarn empaquetado sin usarse, mismo patrón que el npm
sacado en el fix de Trivy).
Escanea workloads/ecommerce con rulesets públicos del registro de
Semgrep (p/typescript, p/react, p/nextjs, p/security-audit) vía la
imagen oficial semgrep/semgrep:1.173.0. Sin --error a propósito: siempre
termina en exit 0, solo reporta — primera vuelta para revisar juntos qué
reglas deberían pasar a bloquear más adelante.
Validado contra el código real: 0 hallazgos en 91 reglas / 72 archivos.
Documenta la herramienta en docs/devsecops/sast.md, incluyendo la
diferencia con gitleaks/trivy y qué significa (y qué no) un scan limpio.
trivy config sobre frontend.yaml (CRITICAL/HIGH/MEDIUM, informativo) y
trivy image sobre la imagen recién construida (CRITICAL bloquea con
--ignore-unfixed, HIGH solo informa), entre build (push:false, load:true)
y el push real al registry.
Fix real encontrado al validar contra la imagen real: el stage runner
heredaba npm/npx/corepack completos de la imagen base de Node sin
necesitarlos en runtime, trayendo CVE-2026-59873 (CRITICAL, node-tar
empaquetado en npm). Sacarlos del stage final baja CRITICAL de 1 a 0 y
HIGH fixable de 21 a 15 (las que quedan son de la propia app, ej. next
desactualizado, documentadas como pendiente sin bloquear).
Documenta ambos scans en docs/devsecops/trivy.md con los hallazgos
reales de este repo.
Corre en push y pull_request, antes del job build (needs: gitleaks).
Si detecta un secreto, exit-code=1 detiene el pipeline antes de
construir la imagen. Scan histórico completo del repo (249 commits)
confirmado limpio, corrido aparte de forma manual.
Documenta el step en docs/devsecops/gitleaks.md: qué es secret
scanning, por qué corre antes del build, cómo leer un hallazgo y
cómo manejar falsos positivos con allowlist.
Conservé:
actions/checkout@v3
docker/login-action@v2
docker/build-push-action@v4
Secretos REGISTRY_USER y REGISTRY_PASSWORD
Versionamiento v1.0.${{ github.run_number }}
Imagen versionada y latest
Actualización automática de frontend.yaml
Commit [skip ci]
Timeout de 20 minutos
Las mejoras agregadas son:
Ya no construye imágenes por cambios exclusivos en frontend.yaml, ingress.yaml o patches/.
Elimina integration/ y archivos *.example.tsx únicamente dentro del runner, evitando el error de compilación anterior.
Comprueba que CategoryMenu.tsx, cuando exista:
lea los parámetros actuales de la URL;
contenga collection=Marvel;
contenga category=Mochilas;
esté realmente importado por otro componente, Header o Layout.
Evita que un pipeline antiguo actualice el manifiesto si ya existe un commit más nuevo.
devopsandClaude Opus 5.5