[sec-check] refresh-community-people.yml commits third-party profile data without running validate:community-people

Abre .github/workflows/refresh-community-people.yml e inspecciona los pasos del job refresh junto con los comandos del validador y de las pruebas unitarias indicados en el issue. Añade los dos pasos de npm especificados sin cambiar las demás líneas del workflow y, después, verifica que el workflow ejecute test:unit y validate:community-people antes de build.

Security Finding

Severity: medium
Type: unsafe-pattern (missing validation gate in an unattended automation path)
File: .github/workflows/refresh-community-people.yml

refresh-community-people.yml runs weekly with contents: write and
pull-requests: write. Its job body is:

      - run: npm ci
      - run: npm run fetch:community-people
      - run: npm run build
      - uses: peter-evans/create-pull-request@...

It never runs npm run validate:community-people.

The other two workflows that regenerate data from a source this repository does
not control both gate their output before committing it:

refresh-community-people.yml is also the only one of the three that does not
run npm run test:unit.

Impact

scripts/fetch-community-people.mjs writes data/community-people.json from
https://raw.githubusercontent.com/cncf/people/main/people.json — a repository
this project does not control, whose records are themselves derived from
free-text fields on third-party GitHub profiles.

That script fails open on the image field. resolveImage() calls
firstAllowedImageUrl(upstream, previous.image, fallbackImages[name], derivedAvatar)
(scripts/lib/profile-image.mjs:63-70), which returns the empty string when
every candidate fails the host gate. It logs a warning and exits 0. The empty
value is written to disk, and src/components/CommunityPeople/index.js:52 and
:108 render it with no guard, shipping <img src=""> — which browsers resolve
against the current document URL and re-request the page.

scripts/validate-community-people.mjs:65-70 is the gate that catches this, and
it is the only gate that does. Confirmed at b54cf81:

$ node scripts/validate-community-people.mjs
Validated 16 community profiles                       # exit 0

# after setting one person's image to '' — exactly what
# firstAllowedImageUrl() writes when every candidate fails the host gate
$ node scripts/validate-community-people.mjs
1 error(s) in community people:
  [error] people.tab: Ricardo Rocha missing image     # exit 1

npm run build does not fail on that value, so today the workflow reports
success and opens a PR carrying data the repository's own gate rejects. The
same validator is also the only thing that catches a person present in the
generated file but absent from data/community-roster.json
(validate-community-people.mjs:56-63) — an injected profile row.

The PR's own ci.yml run does execute validate:community-people, so this is
defence in depth rather than a path straight to production: the exposure is that
the unattended producer reports green on output its consumer rejects, and the
only thing standing between that and main is a maintainer not merging a red
automation PR. The two sibling workflows already close this gap for their own
data; this one does not.

Recommendation

Add the validator step, and npm run test:unit for parity with the other two
refresh workflows. Replace the steps: block of the refresh job in
.github/workflows/refresh-community-people.yml with exactly:

    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: npm
      - run: npm ci
      - run: npm run test:unit
      - run: npm run fetch:community-people
      - run: npm run validate:community-people
      - run: npm run build
      - uses: peter-evans/create-pull-request@5f6978faf089d4d20b00c7766989d076bb2fc7f1 # v8.1.1
        with:
          branch: automation/refresh-community-people
          delete-branch: true
          commit-message: 'chore: refresh community profiles'
          title: 'chore: refresh community profiles'
          body: |
            Automated refresh of the public GitHub profile data used by the End User Community lightboxes.
          labels: automated
          signoff: true

The only additions are the npm run test:unit and
npm run validate:community-people steps; every other line, including all four
action SHA pins, is unchanged from the current file.

Note that validate-community-people.mjs:88-96 currently emits the staleness
check as a warning rather than an error, pending #122. reportAndExit()
exits 0 on warnings, so adding this step does not make the workflow red on the
frozen fetchedAt that #122 causes — it fails only on the real errors above.

Scope

• Claims .github/workflows/refresh-community-people.yml only.
• Disjoint from #725 (scripts/validate-community-people.mjs + its test — the
  validator's contents, not who runs it), #674 (package.json), #704
  (.devcontainer/, docs, tests/dev-environment.test.mjs) and every other
  open PR; none of them touch this workflow.

This needs a human or an ISSUES_PRS_MERGE agent to land

The fix is entirely inside .github/workflows/. This agent's GitHub App token
is minted at the contributor tier, which does not carry the Workflows
permission, so GitHub rejects any push whose diff touches that directory. No PR
can accompany this issue; the replacement text above is given verbatim so
applying it is mechanical.

Filed by sec-check agent (ACMM L4/L5 — hold-gated mode)

🐝 Hive Agent: security | Instance: hosted-available-lke648397-260827-5n31 | SHA: b54cf81

— hive: agent=sec-check backend=copilot model=claude-opus-5 copilot=1.0.88