ci: add workflow to build accountant

[0xThemis]

Note

Low Risk
CI-only changes following an established OPRF node release pattern; no application runtime or auth logic is modified.

Overview
Adds tag-driven release automation for oprf-accountant, aligned with the existing OPRF node release pattern.

Pushing a world-id-oprf-accountant-v* tag runs a new workflow that resolves stable vs prerelease versions, calls the reusable Build Docker workflow for oprf-accountant, and creates a GitHub release with notes generated by git-cliff from services/oprf-accountant/cliff.toml (scoped to accountant tags and services/oprf-accountant/** commits).

Build Docker is updated so the post-build staging deploy dispatch is skipped for oprf-accountant as well as oprf-node, so accountant images are built and released without auto-deploying to staging.

^{Reviewed by Cursor Bugbot for commit 1aeeefd. Bugbot is set up for automated code reviews on this repo. Configure here.}

[semgrep-code-worldcoin]

Semgrep identified an issue in your code:

GitHub Action orhun/git-cliff-action@v4 is pinned to a mutable version tag instead of a commit SHA, allowing attackers who compromise the repository to inject malicious code into your workflow.

More details about this

The GitHub Action orhun/git-cliff-action is pinned to a version tag (@v4) instead of a full-length commit SHA. This means the action can be modified retroactively if the maintainer updates the v4 tag, potentially introducing malicious code without your awareness.

Exploit scenario:

1. An attacker compromises the orhun/git-cliff-action repository and gains the ability to force-push to the v4 tag.
2. They inject malicious code into the action that exfiltrates secrets available in the GitHub Actions environment—such as secrets.GITHUB_TOKEN (which has contents: write permissions in this workflow).
3. When your workflow runs, it executes the compromised action code. The attacker can then use the stolen GITHUB_TOKEN to push malicious commits to your repository, create unauthorized releases, or modify your source code.
4. The compromised version runs seamlessly because your workflow still references @v4, making the attack invisible until discovered.

Pinning to a full commit SHA (e.g., @a1b2c3d4e5f6...) ensures the action code is immutable—even if the repository is compromised, the specific commit you pinned cannot be modified.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the third-party action reference with a full 40-character commit SHA instead of the mutable tag.
   Change uses: orhun/git-cliff-action@v4 to uses: orhun/git-cliff-action@<full-commit-sha>.

2. Keep the readable version as a comment next to the SHA so future updates are easier.
   For example: uses: orhun/git-cliff-action@<full-commit-sha> # v4.x.y.

3. Resolve the correct SHA from the action release you intend to keep using.
   Look up the v4 release in the orhun/git-cliff-action repository, find the exact commit behind that release, and pin to that commit instead of the tag. This makes the workflow use an immutable action revision.

4. If you want to avoid unplanned behavior changes, pin to the commit for the current release version rather than jumping to a newer tag during this fix.

Alternatively, if you are intentionally upgrading the action now, pin to the full commit SHA for the newer released version and keep the version comment updated to match.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by third-party-action-not-pinned-to-commit-sha.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-worldcoin]

Semgrep identified an issue in your code:

GitHub Actions step uses mutable version tag v4 instead of a pinned commit SHA, allowing the action owner to silently inject malicious code into your workflow.

More details about this

The orhun/git-cliff-action@v4 reference uses a mutable version tag instead of a pinned commit SHA. This allows the action owner to silently update what code runs in your workflow—including potentially malicious changes—without any notification or review.

Exploit scenario:

1. An attacker compromises the orhun/git-cliff-action repository
2. They push malicious code and re-tag it as v4 (overwriting the existing tag)
3. Your workflow runs the "Generate release notes" step, which pulls orhun/git-cliff-action@v4
4. Instead of the legitimate git-cliff tool, the malicious version executes, gaining access to your secrets like GITHUB_TOKEN and potentially id-token
5. The attacker uses these credentials to modify your GitHub release, inject malware into your repository, or steal sensitive data

This is a real attack vector—similar compromises have affected trivy-action and kics-github-action. The actions/checkout@v7 reference above also has the same vulnerability.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the mutable action tag in the Generate release notes step with the full 40-character commit SHA for the exact orhun/git-cliff-action version you want to keep.
   Change uses: orhun/git-cliff-action@v4 to uses: orhun/git-cliff-action@<40-character-commit-sha> and add a comment with the version for readability, such as # v4.x.y.

2. Look up the commit SHA from the release or tag you intend to trust on the action's repository, then pin to that commit instead of the major tag.
   The final line should look like uses: orhun/git-cliff-action@<40-character-commit-sha> # v4.x.y.

3. Keep the existing with: arguments unchanged unless the pinned version's release notes require a configuration change.
   Pinning to a commit prevents the action owner from silently moving v4 to different code later.

4. Alternatively, if you need to stay on a newer release of the same action, update the reference to the new release's commit SHA instead of using a tag like @v4 again.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-worldcoin]

Semgrep identified an issue in your code:

The actions/checkout@v7 uses a mutable version tag that could be silently updated by the action owner to contain malicious code, enabling a supply-chain attack against your workflow.

More details about this

The actions/checkout@v7 reference uses a mutable version tag instead of a pinned commit SHA. An attacker who maintains the actions/checkout action could update the v7 tag to point to malicious code without your knowledge.

Here's how an exploit could work:

1. An attacker gains control of the actions/checkout repository (or a dependency within it)
2. The attacker updates the v7 tag to point to a new commit containing malicious code—for example, code that exfiltrates secrets from the workflow environment
3. Your next workflow run checks out code using actions/checkout@v7, which now resolves to the attacker's malicious version
4. The malicious code runs with access to secrets.GITHUB_TOKEN and other sensitive environment variables, allowing the attacker to steal credentials, modify your repository, or compromise your releases

This is a supply-chain attack vector that has been exploited in real-world incidents like the trivy-action and kics-github-action compromises.

To resolve this comment:

✨ Commit fix suggestion

1. Replace the mutable action reference actions/checkout@v7 with a full 40-character commit SHA for the exact action version you want to keep using.
2. Keep the version as an inline comment so the workflow stays readable, for example: uses: actions/checkout@<full-40-char-sha> # v7.x.x.
3. Make sure the pinned SHA comes from the official actions/checkout release you intend to use, not from a branch or shortened hash. This prevents the referenced code from changing without an explicit workflow update.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by github-actions-mutable-action-tag.

_{You can view more details about this finding in the Semgrep AppSec Platform.}

[semgrep-code-worldcoin]

Semgrep identified an issue in your code:

secrets: inherit in the build-docker job grants the reusable workflow access to all repository secrets, violating least privilege and exposing them if the workflow is compromised.

More details about this

The build-docker job calls a reusable workflow using secrets: inherit, which grants the called workflow access to all secrets in the repository instead of just the ones it needs.

Here's how an attacker could exploit this:

1. Compromise the reusable workflow: An attacker modifies ./.github/workflows/build-docker.yml (or tricks a maintainer into merging a malicious change).

2. Exfiltrate all secrets: The compromised workflow now has access to every secret defined in the repository through secrets.GITHUB_TOKEN, secrets.MY_API_KEY, secrets.DATABASE_PASSWORD, etc.—anything stored in the repo's secrets.

3. Extract the secrets in the malicious workflow: The attacker adds a step like run: echo ${{ toJson(secrets) }} to dump all secrets, or sends them to an attacker-controlled server.

4. Use stolen secrets: With access to all repository secrets, the attacker can authenticate as the repository, access databases, deploy malicious code, or access third-party services.

Because the build-docker job only actually needs specific secrets (if any), using secrets: inherit unnecessarily exposes the entire secret store to that workflow.

To resolve this comment:

✨ Commit fix suggestion

1. Replace secrets: inherit with an explicit secrets: mapping on the build-docker job.
2. Pass only the secrets that ./.github/workflows/build-docker.yml actually uses, for example:
   secrets: { GIT_HUB_TOKEN: ${{ secrets.GIT_HUB_TOKEN }}, AWS_ROLE: ${{ secrets.AWS_ROLE }} }
3. Add each required secret as a separate entry instead of forwarding everything. This limits the reusable workflow to only the credentials it needs.
4. If build-docker.yml expects specific secret names under on: workflow_call: secrets:, match those names exactly in the caller, for example REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}.
5. Remove any secret from the mapping that is not required by the reusable workflow.

Alternatively, if the reusable workflow currently depends on many inherited secrets, define the minimum required secrets in ./.github/workflows/build-docker.yml under on.workflow_call.secrets first, then pass only that small set from this job.

💬 Ignore this finding

Reply with Semgrep commands to ignore this finding.

• /fp <comment> for false positive
• /ar <comment> for acceptable risk
• /other <comment> for all other reasons

Alternatively, triage in Semgrep AppSec Platform to ignore the finding created by secrets-inherit.

_{You can view more details about this finding in the Semgrep AppSec Platform.}