Project name must match PyPi

[richdawe-cio]

Following on from customerio#8 , we need to update the project name in pyproject.toml to match the name in PyPi for trusted publishing workflows. Otherwise they will fail.

[richdawe-cio]

Sorry meant to open this against our fork.

[semgrep-code-segmentio-2]

Semgrep identified an issue in your code:

GitHub Actions workflow uses a mutable version tag instead of a pinned commit SHA, allowing action maintainers (or attackers who compromise them) to inject malicious code that runs with your credentials.

More details about this

The workflow uses pypa/gh-action-pypi-publish@release/v1, which pins the action to a version tag rather than a full commit SHA. This means the actual code executed can change without warning every time the workflow runs—if the maintainer updates the release/v1 tag to point to a different commit, your workflow will silently pull that new version.

Here's how an attacker could exploit this:

1. Compromise the pypa/gh-action-pypi-publish repository by gaining access to the maintainer's account or through a supply-chain attack.
2. Update the release/v1 tag to point to a malicious commit containing backdoor code that exfiltrates your PyPI credentials stored in the PYPI_API_TOKEN environment variable.
3. Your next workflow run automatically executes this malicious version without any code review, since your workflow is configured to use a mutable tag reference.
4. The attacker gains your PyPI token and publishes a compromised package to PyPI under your project's name, affecting all downstream users.

By pinning to a specific commit SHA (e.g., @a1d2e3f...), you ensure that no matter what happens to the tag or repository, only that exact version of the action executes.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: pypa/gh-action-pypi-publish@release/v1
	uses: pypa/gh-action-pypi-publish@9b7d5b2c6f4e8a1d3c0f7e6b5a4d3c2b1a0f9e8d # release/v1

View step-by-step instructions

1. Replace the third-party action reference with a full 40-character commit SHA instead of the mutable tag @release/v1.
2. Keep the intended version in a trailing comment so it is still easy to understand which release you pinned, for example: uses: pypa/gh-action-pypi-publish@<full-commit-sha> # release/v1.
3. Resolve the SHA from the action's repository release or tag page and use the exact commit that release/v1 currently points to. Pinning to a commit makes the workflow use an immutable action revision.
4. Leave the rest of the step unchanged unless the pinned revision's documentation requires different inputs.

💬 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.

Need help with this issue? Consult our appsec team or ask in #help-appsec on Slack.

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

[semgrep-code-segmentio-2]

Semgrep found 9 github-actions-mutable-action-tag findings:

• .github/workflows/test.yml
  • L25 - Triage
  • L29 - Triage
• .github/workflows/publish.yml
  • L17 - Triage
  • L22 - Triage
  • L37 - Triage
• .github/workflows/lint.yml
  • L20 - Triage
  • L24 - Triage
• .github/workflows/build.yml
  • L18 - Triage
  • L22 - Triage

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608.

Need help with this issue? Consult our appsec team or ask in #help-appsec on Slack.