Harden CI: Artifactory OIDC, fork-aware workflows, composer.lock

[MichaelGHSeg]

Summary

• Add Artifactory OIDC composite action — exchanges GitHub OIDC token for short-lived Artifactory access token, configures Composer to resolve through `virtual-php-thirdparty`
• Add `ci.yml` — replaces `tests.yml`, fork-aware runner selection, PHP 8.1–8.4 matrix, `composer install --no-scripts`, SHA-pinned actions
• Update `e2e-tests.yml` — remove `E2E_TESTS_TOKEN` (sdk-e2e-tests going public), fork-aware
• Commit `composer.lock` (removed from `.gitignore`)

Notes

• No deploy workflow needed — Packagist publishes automatically from git tags
• Old `tests.yml` can be deleted once `ci.yml` is validated

Test plan

• CI runs on this PR
• Artifactory OIDC exchange succeeds on same-repo CI
• Before merging: set `ARTIFACTORY_URL` repository variable

[semgrep-code-segmentio-2]

Semgrep identified an issue in your code:

The codecov-action is pinned to a mutable semantic version tag instead of a full commit SHA, allowing attackers who compromise the codecov repository to inject malicious code into your workflow.

More details about this

The codecov/codecov-action@v5 action is pinned to a semantic version tag (@v5) instead of a full commit SHA. This creates a security risk because the maintainers of the codecov-action repository could push a malicious update to the v5 tag, and your workflow would automatically pull and execute the compromised code without warning.

Exploit scenario:

1. A attacker gains write access to the codecov/codecov-action repository (or the account of a maintainer)
2. They force-push a malicious commit to the existing v5 tag, overwriting the legitimate code with a backdoor
3. On your next workflow run, the step Upload coverage to Codecov checks out and executes the malicious version of codecov-action
4. The backdoor could steal your CODECOV_TOKEN secret (which is already exposed to this action) or inject code into your build artifacts
5. Unlike actions pinned to a commit SHA like actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683, GitHub cannot detect this tampering because the tag points to whatever the attacker pushed

Other actions in this workflow like actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 and shivammathur/setup-php@cf4cade2721270509d5b1c766dad417c269cbb11 correctly use full commit SHAs, making them immutable against this attack.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: codecov/codecov-action@v5
	uses: codecov/codecov-action@e851fdd58d965fa1d6a5b0db7cb65a4d42b992fc # v5

View step-by-step instructions

1. Replace uses: codecov/codecov-action@v5 with a full 40-character commit SHA from the codecov/codecov-action repository, for example uses: codecov/codecov-action@<full-commit-sha>.
2. Add the version as a comment after the SHA, such as # v5, so it stays readable while still being immutable.
3. Choose the SHA from the exact v5 release or tag you intend to use, instead of a moving tag reference. This prevents the workflow from silently picking up different action code later.

Alternatively, if you do not want to depend on the third-party action at all, replace the uses: step with a run: step that uploads coverage through a trusted tool already installed in the 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 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 identified an issue in your code:

Mutable tag @v5 on codecov-action allows silent code changes by action maintainer, enabling supply-chain attacks against your CI/CD pipeline and secrets.

More details about this

The codecov/codecov-action@v5 step uses a mutable tag (v5) instead of pinning to a specific commit SHA. This allows the action maintainer to silently update what code runs when your workflow executes.

Attack scenario: An attacker compromises the codecov organization and updates the v5 tag to point to malicious code. When your CI/CD pipeline runs, it automatically uses the compromised version without any notification. The malicious action has access to your repository contents and secrets (including CODECOV_TOKEN), allowing the attacker to exfiltrate your source code, steal credentials, or manipulate your build artifacts.

This type of attack has real precedent—the trivy-action and kics-github-action were both compromised in similar supply-chain attacks that affected thousands of repositories.

Other steps in your workflow like actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 and shivammathur/setup-php@cf4cade2721270509d5b1c766dad417c269cbb11 are correctly pinned to specific commit SHAs and are safe from this risk.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: codecov/codecov-action@v5
	uses: codecov/codecov-action@0d3f4b1b85f4a1d8c2e7b6f9a4c3d2e1f0a9b8c7 # v5 - replace with the exact 40-character commit SHA for the intended v5 release from codecov/codecov-action

View step-by-step instructions

1. Replace the mutable action tag with a full 40-character commit SHA in the workflow step.
   Change uses: codecov/codecov-action@v5 to uses: codecov/codecov-action@<full-commit-sha>, and keep the version as a comment such as # v5.x.x.

2. Pin the SHA to the exact release you intend to use from the codecov/codecov-action repository, for example by taking the commit behind the current v5 release instead of using the tag name directly.
   This prevents the action reference from changing if the tag is later moved.

3. Keep the rest of the step unchanged, including the existing with: inputs and CODECOV_TOKEN handling, so only the action reference becomes immutable.

Alternatively, if you need a newer Codecov release, update to that release first and then pin uses: to that release’s full commit SHA instead of a branch or tag.

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

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