[AZapata27]

Problema

• CodeQL (job security de ci.yml) sólo corría con push o PR: si el repo no tiene actividad, las nuevas consultas y avisos de CodeQL no se aplican.
• No había una medición pública de la postura de seguridad de la cadena de suministro (OpenSSF Scorecard).
• No había releases versionadas: ni tags, ni GitHub Releases, ni CHANGELOG.md.

Qué cambia

1. CodeQL semanal: ci.yml suma un trigger schedule (23 6 * * 1, lunes 06:23 UTC). El resto del workflow no cambia.
2. OpenSSF Scorecard (.github/workflows/scorecard.yml), con las restricciones de ossf/scorecard-action para publish_results: true:
   • triggers branch_protection_rule, schedule semanal (41 6 * * 1) y push a master;
   • permissions: {} arriba; el job tiene contents: read, actions: read, security-events: write e id-token: write;
   • sin env/defaults ni pasos run:; sólo harden-runner, checkout (persist-credentials: false), scorecard-action, upload-artifact y codeql-action/upload-sarif;
   • acciones fijadas a SHA completo con # vX.Y.Z: las compartidas reutilizan los SHA de reusable-workflows v1.0.0 y ossf/scorecard-action queda en fa7117db83c52d787ae5a89f350999701505d78e # v2.5.0 (tag anotado ya resuelto a su commit).
   • Badge de Scorecard en el README, al lado del de CI.
3. Releases con release-please usando el workflow central release.yml de AZapata27/reusable-workflows (mismo SHA dd1bf38…, v1.0.0):
   • .github/workflows/release.yml corre con push a master. Pide los permisos que exige el reusable (contents, issues, pull-requests de escritura, más id-token y attestations como techo del job de provenance, que queda omitido porque no se pasa artifact-name).
   • release-please-config.json + .release-please-manifest.json en modo manifest, release-type: simple, tags vX.Y.Z y las mismas secciones de changelog que reusable-workflows.
   • version.txt (0.0.0) es el archivo que release-please actualiza en el tipo simple. La primera release se fija en 0.1.0 con release-as.
   • No se publica ningún artefacto.

Cómo se usa

• Commits con Conventional Commits (feat:, fix:, …) a master → release-please abre o actualiza un PR de release → al hacer merge crea el tag vX.Y.Z, la GitHub Release y CHANGELOG.md.
• El score queda en https://scorecard.dev/viewer/?uri=github.com/AZapata27/SyncroBoard-Tasks-System y los hallazgos en Security → Code scanning.

Casos borde

• Quitar release-as de release-please-config.json después de publicar 0.1.0. Si queda, release-please vuelve a proponer 0.1.0.
• Con bump-minor-pre-major: true, mientras la versión sea 0.x un cambio incompatible sube la minor, no la major.
• El PR de release lo abre GITHUB_TOKEN, así que no dispara CI sobre ese PR. Con los checks requeridos del ruleset no se puede hacer merge hasta que corran: hay que relanzarlos (por ejemplo, cerrando y reabriendo el PR o con un push vacío) o configurar el secreto release-token (PAT o GitHub App) en el caller. Hay que hacer un cambio antes del merge: en este repo el ajuste Settings → Actions → General → Allow GitHub Actions to create and approve pull requests está desactivado (can_approve_pull_request_reviews: false). Mientras siga así, release-please no puede abrir el PR de release. En reusable-workflows ya está activo. Este PR no lo cambia.
• version.txt es la versión del repositorio. Las versiones de los archivos de build (-SNAPSHOT) no se tocan.
• La ejecución programada de ci.yml también corre build y workflow-lint, no sólo CodeQL. Es un costo semanal aceptable.
• Scorecard publica resultados sólo desde la rama por defecto. En este PR el workflow no corre (no tiene trigger pull_request) y el badge mostrará datos después del primer push a master.

Validación

• actionlint v1.7.12 sin errores.
• zizmor v1.30.1 sin hallazgos de ninguna severidad (con auditorías online).
• JSON de release-please validado. No se tocaron archivos de build, así que no hacía falta compilar.
• Commit firmado (SSH).

🤖 Generated with Claude Code