Declare explicit secrets inputs instead of relying on callers' secrets: inherit

[prymax10]

Context

Every caller of go-pr-validation.yml across the org passes secrets: inherit — br-slc, br-sta, br-sisbajud, br-consignado-gw. A review of LerianStudio/br-sisbajud#229 flagged this as CWE-732 (incorrect permission assignment): inherit forwards all of the caller repository's secrets into the reusable workflow and onward to every nested workflow, far beyond what any of them consume.

The finding is legitimate. It was declined in that PR because fixing it caller-by-caller is unsafe and would fragment the convention — this is the right place to fix it once.

Why callers cannot fix it themselves

The suggested replacement in that review was MANAGE_TOKEN, SLACK_WEBHOOK_URL and LERIAN_LIB_READ_TOKEN. Enumerating what the chain actually consumes at v1.47.4 shows that list is incomplete — it would have broken the security scan silently:

Nested workflow	Secrets actually referenced
pr-validation.yml	MANAGE_TOKEN, SLACK_WEBHOOK_URL
go-pr-analysis.yml	MANAGE_TOKEN, SLACK_WEBHOOK_URL
pr-security-scan.yml	MANAGE_TOKEN, SLACK_WEBHOOK_URL, GITHUB_TOKEN, DOCKER_USERNAME, DOCKERHUB_IMAGE_PULL_TOKEN, NPMRC_TOKEN
lerian-lib-version-check.yml	MANAGE_TOKEN, LERIAN_LIB_READ_TOKEN

Union across the chain: MANAGE_TOKEN, SLACK_WEBHOOK_URL, LERIAN_LIB_READ_TOKEN, GITHUB_TOKEN, DOCKER_USERNAME, DOCKERHUB_IMAGE_PULL_TOKEN, NPMRC_TOKEN.

Three of the seven were missing from the suggested list. A caller adopting it would lose Docker Hub pull credentials and the npm token in pr-security-scan.yml, and the Slack notification path fails quietly rather than loudly.

Proposed change

Declare an explicit secrets: block on go-pr-validation.yml's workflow_call, marking each as required: false where the corresponding job is optional, and forward them explicitly to the nested workflows instead of relying on inheritance. Callers then move from secrets: inherit to a named mapping, and the contract becomes visible and auditable at the boundary.

Suggested rollout: land the explicit inputs while still accepting inherit (no breaking change), migrate callers one repo at a time, then tighten.

Notes

• Verified against tag v1.47.4 (commit 419fe86a8a8aa70c1b4b796a2f2bed895456e54d).
• Raised from MAP-3954 (controlled repository sharing); recorded as separate technical debt so it is not mixed into that work.

[prymax10]

Related: MANAGE_TOKEN is exposed to repository-controlled commands

A second finding from the same review, in the same area — recording it here rather than opening a parallel issue, since both stem from how credentials reach the reusable workflows.

The problem

When a caller sets go_private_modules, go-pr-analysis.yml writes MANAGE_TOKEN into global git configuration to resolve private modules:

git config --global url."https://${{ secrets.MANAGE_TOKEN }}@github.com/".insteadOf "https://github.com/"

The same jobs then run repository-controlled targets — make lint, make sec, and the test targets. Those commands come from the pull request's own tree, so a same-repository PR can read the token out of the global git config, or simply use it, during steps that are supposed to be untrusted.

The rewrite persists for the whole job rather than being scoped to module resolution.

Suggested direction

Either:

1. use a temporary credential helper active only while modules are fetched, and remove it before any repository-controlled command runs; or
2. resolve private modules in a separate trusted job and pass only the module cache forward.

Scope

This is not introduced by any single caller — every repo that sets go_private_modules inherits it, including the develop branches of br-sfn, br-sta, br-slc and br-sisbajud. Verified against 419fe86 (v1.47.4).

Raised from MAP-3954 (LerianStudio/br-sisbajud#229) and recorded as debt so it is not mixed into that work.

[prymax10]

Related: nested action references are unpinned

Third finding from the same review series, same root area — callers cannot fix it, so recording it here.

go-pr-validation.yml can be pinned by callers to a full commit SHA (and now is, in LerianStudio/br-sisbajud#229). But the workflow itself invokes its own shared actions at a mutable major ref:

uses: LerianStudio/github-actions-shared-workflows/src/config/non-doc-changes@v1
uses: LerianStudio/github-actions-shared-workflows/src/validate/result-gate@v1

So pinning at the caller boundary is only skin deep: whatever @v1 points to today can change tomorrow, and every caller inherits that silently — including the ones that believe they are pinned.

Suggested direction

Pin the nested uses: inside the reusable workflows to full commit SHAs with a trailing # vX.Y.Z comment, and let the release process bump them. That makes a caller's SHA pin actually mean "this exact behaviour".

Verified against 419fe86 (v1.47.4). Raised from MAP-3954 (LerianStudio/br-sisbajud#229).