ci: integrate SafeDep PMG on all workflow jobs

[vanshika-verma-rzp]

Summary

Integrates SafeDep PMG (Package Manager Guard) into every job across both GitHub Actions workflows. PMG runs as a persistent proxy in CI, intercepts installs from supported package managers via standard proxy env vars, and auto-blocks any package flagged as malicious.

Reference: PMG in GitHub Actions

What changed

Each job received two steps, per the SafeDep docs:

1. Start PMG — safedep/pmg@v1 in server-mode, placed after checkout and before any package setup.
2. Enforce PMG policy — pmg proxy stop --fail-on-violation with if: always(), which fails the job on a block and flushes final events to the cloud (runs even if an earlier step fails).

Coverage

File	Job	Installs intercepted	Notes
ci.yml	build	bundle install	Start placed before ruby/setup-ruby
ci.yml	test	bundle install	Start placed before ruby/setup-ruby
ci.yml	publish	apt-get / gem push	Added for full coverage; harmless guard (PMG only intercepts supported package managers)
ruby.yml	test	bundle install (via bundler-cache: true)	Start placed before ruby/setup-ruby so PMG intercepts the bundler install run inside the action

Why placement matters (ruby.yml)

ruby.yml's test job uses bundler-cache: true, which runs bundle install inside the ruby/setup-ruby action. The PMG start step is therefore placed before setup-ruby so the proxy env vars are active when that install runs.

Secrets

The steps reference secrets.SAFEDEP_API_KEY and secrets.SAFEDEP_TENANT_ID. These are optional — PMG blocks malicious packages using SafeDep's free community intelligence with or without credentials. If the secrets are unset, they resolve empty and PMG still enforces; only cloud event sync to Endpoint Hub is skipped. No job breaks either way.

Follow-up (optional): add SAFEDEP_API_KEY and SAFEDEP_TENANT_ID as repo secrets to enable SafeDep Cloud event sync.

Verification

• ✅ Both workflow files validated as parseable YAML.
• ✅ No existing steps modified, removed, or reordered — all original steps intact.
• ✅ Diff is purely additive: +36 lines, 0 deletions. Nothing extra beyond the PMG integration.

Diff stat

.github/workflows/ci.yml   | 27 +++++++++++++++++++++++++++
.github/workflows/ruby.yml |  9 +++++++++
2 files changed, 36 insertions(+)

---

Discussion thread: Slack

[semgrep-code-razorpay]

Semgrep identified an issue in your code:

The safedep/pmg@v1 step can silently change when the upstream tag is repointed. A compromised action could run in CI and expose the provided SafeDep API credentials.

More details about this

The Start PMG step runs safedep/pmg@v1, a mutable version tag rather than an immutable commit. The action owner—or an attacker who compromises that repository—can repoint v1 to a malicious commit; the next push or pull request would execute that code on ubuntu-latest before the Ruby tests run. Because the step receives secrets.SAFEDEP_API_KEY and secrets.SAFEDEP_TENANT_ID, the malicious action could read or exfiltrate those credentials and use them to access the SafeDep tenant. It could also alter the workspace or workflow outputs before bundle exec rake and the PMG policy check execute.

A plausible attack sequence:

1. An attacker gains control of the safedep/pmg repository or its release process and moves the v1 tag to a malicious revision.
2. A developer opens a pull request or pushes to master, triggering this workflow.
3. GitHub resolves uses: safedep/pmg@v1 to the attacker-controlled revision and runs its code in the Start PMG step.
4. That code accesses the step's api-key and tenant-id inputs, which contain ${{ secrets.SAFEDEP_API_KEY }} and ${{ secrets.SAFEDEP_TENANT_ID }}, then sends them to an attacker-controlled endpoint or uses them against the SafeDep service.

The risk is specific to the mutable v1 reference; the other-party action can change without any change to this workflow.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: safedep/pmg@v1
	# Replace with the verified 40-character commit SHA for the trusted safedep/pmg v1 release.
	uses: safedep/pmg@<VERIFIED_VALUE_REQUIRED> # v1

View step-by-step instructions

1. Identify the full 40-character commit SHA that corresponds to the trusted v1 release of safedep/pmg.

2. Replace the mutable tag with that commit SHA and retain the version comment for maintainability:
   uses: safedep/pmg@<40-character-commit-sha> # v1

3. Confirm that the pinned commit is the intended safedep/pmg release before allowing the action to access SAFEDEP_API_KEY and SAFEDEP_TENANT_ID. A commit SHA cannot be silently repointed like a tag or branch.

💬 Ignore this finding

Leave a nosemgrep comment directly above or at the end of line 30 like so // nosemgrep: yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag

Take care to validate that this is not a true positive finding before ignoring it.
Learn more about ignoring code, files and folders here.

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

[semgrep-code-razorpay]

Semgrep identified an issue in your code:

The workflow runs safedep/pmg from the mutable v1 tag, allowing a repointed action to execute in CI. A compromised action could steal PMG credentials and the publish job’s GEM_API_KEY, then publish malicious Ruby gems.

More details about this

uses: safedep/pmg@v1 follows the mutable v1 tag rather than an immutable commit. The owner of safedep/pmg (or an attacker who compromises that repository) can move v1 to a different commit without changing this workflow, causing future runs to execute attacker-controlled code.

A plausible attack is:

1. An attacker gains control of the safedep/pmg repository and repoints the v1 tag to a malicious action.
2. A subsequent build or publish run starts the Start PMG step and executes that malicious action before the Ruby tests or gem publication.
3. The action reads the job's SAFEDEP_API_KEY, SAFEDEP_TENANT_ID, and—especially in publish—GEM_API_KEY from the runner environment or process context.
4. Using GEM_API_KEY, the attacker can publish unauthorized Ruby gems or tampered versions; they can also alter files or artifacts used by later steps. The same mutable safedep/pmg@v1 reference appears in both jobs, so both execution paths are exposed.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: safedep/pmg@v1
	uses: safedep/pmg@<VERIFIED_VALUE_REQUIRED> # v1
	uses: safedep/pmg@<VERIFIED_VALUE_REQUIRED> # v1

View step-by-step instructions

1. Identify the trusted 40-character commit SHA for the safedep/pmg release corresponding to v1 from the action’s official repository or release metadata.

2. Replace both occurrences of safedep/pmg@v1 with the full commit SHA, retaining the version as a comment. For example: uses: safedep/pmg@<40-character-commit-sha> # v1

3. Confirm that the uses: values in both the build/test job and the publish job use the same immutable SHA and do not use a branch or version tag.

💬 Ignore this finding

Leave a nosemgrep comment directly above or at the end of line 80 like so // nosemgrep: yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag

Take care to validate that this is not a true positive finding before ignoring it.
Learn more about ignoring code, files and folders here.

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

[semgrep-code-razorpay]

Semgrep identified an issue in your code:

The workflow executes safedep/pmg@v1, a mutable action reference that can silently be repointed to attacker-controlled code. A compromised action could access PMG secrets and tamper with or exfiltrate Ruby build and release artifacts.

More details about this

The Start PMG step runs safedep/pmg@v1, where v1 is a mutable branch or tag rather than an immutable commit. The action owner—or someone who compromises that repository—can move v1 to a malicious commit without changing this workflow, causing future build, test, or publish jobs to execute attacker-controlled code.

A plausible attack is:

1. An attacker gains control of the safedep/pmg repository and repoints v1 to a malicious release.
2. The next workflow run downloads that release when it reaches uses: safedep/pmg@v1.
3. The malicious action executes with the job's permissions and can read ${{ secrets.SAFEDEP_API_KEY }} and ${{ secrets.SAFEDEP_TENANT_ID }} supplied to the PMG step.
4. It can exfiltrate those credentials, inspect the checked-out Ruby source and built gems, or tamper with artifacts before actions/upload-artifact@v3 uploads them. In publish, the same action runs in the tag-triggered release path, so a compromised v1 can affect released packages without a workflow-file change.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: safedep/pmg@v1
	uses: safedep/pmg@<VERIFIED_VALUE_REQUIRED> # v1; replace with the verified 40-character commit SHA for the trusted v1 release

View step-by-step instructions

1. Replace the mutable tag in the PMG step with the full 40-character commit SHA for the intended safedep/pmg v1 release: uses: safedep/pmg@<40-character-commit-sha>.
2. Confirm that the SHA belongs to the trusted safedep/pmg repository and corresponds to the v1 release, then optionally retain the version as a comment: uses: safedep/pmg@<40-character-commit-sha> # v1.
3. Apply the same pin to each safedep/pmg@v1 reference in this workflow. A commit SHA prevents the action owner from silently repointing the tag to different code.

💬 Ignore this finding

Leave a nosemgrep comment directly above or at the end of line 51 like so // nosemgrep: yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag

Take care to validate that this is not a true positive finding before ignoring it.
Learn more about ignoring code, files and folders here.

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

[semgrep-code-razorpay]

Semgrep identified an issue in your code:

The workflow runs safedep/pmg@v1, so the action can change silently when its tag is repointed. A compromised release could execute with SafeDep secrets and exfiltrate credentials or alter the build.

More details about this

The Start PMG step runs safedep/pmg@v1, where v1 is a mutable tag rather than an immutable commit. The action owner—or an attacker who compromises that repository—can repoint v1 to a malicious commit without changing this workflow.

A plausible attack is:

1. An attacker gains control of the safedep/pmg repository and moves the v1 tag to a malicious release.
2. A push to master or a matching version tag starts this CI workflow and downloads the newly tagged code for safedep/pmg.
3. The malicious action executes during Start PMG with server-mode: true and access to secrets.SAFEDEP_API_KEY and secrets.SAFEDEP_TENANT_ID.
4. It can send those credentials, repository contents, or build data to an attacker-controlled server before the later bundle install and gem build steps run, potentially allowing unauthorized access to the SafeDep tenant or tampering with the build.

Because the workflow text remains unchanged, ordinary code review may not reveal when the action's behavior changes.

To resolve this comment:

✨ Commit fix suggestion

Suggested change

	uses: safedep/pmg@v1
	uses: safedep/pmg@<VERIFIED_VALUE_REQUIRED> # v1
	# Human intervention required: replace the placeholder with the verified 40-character commit SHA for the trusted v1 release.

View step-by-step instructions

1. Resolve the trusted commit SHA for the safedep/pmg v1 release from the action’s official repository or release metadata.
2. Replace the mutable tag with the full 40-character commit SHA, keeping the version comment for readability: uses: safedep/pmg@<40-character-commit-sha> # v1
3. Verify that the selected commit belongs to the intended v1 release and is not a branch or abbreviated SHA.

💬 Ignore this finding

Leave a nosemgrep comment directly above or at the end of line 19 like so // nosemgrep: yaml.github-actions.security.github-actions-mutable-action-tag.github-actions-mutable-action-tag

Take care to validate that this is not a true positive finding before ignoring it.
Learn more about ignoring code, files and folders here.

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

[semgrep-code-razorpay]

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.

🥳 Fixed in commit 67bea21 🥳

[semgrep-code-razorpay]

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.

⭐ Removed in commit 0c6e9ea ⭐

[semgrep-code-razorpay]

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.

🧼 Fixed in commit 67bea21 🧼

[semgrep-code-razorpay]

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.

🎈 Removed in commit 0c6e9ea 🎈

[semgrep-code-razorpay]

A run: step pipes the output of curl or wget directly into a shell interpreter. This is the "curl | bash" install pattern — if the remote server is compromised or the URL is hijacked, an attacker can execute arbitrary code in your CI runner. Consider downloading the file first, verifying its checksum or signature, and then executing it.

🧼 Removed in commit 0c6e9ea 🧼

[semgrep-code-razorpay]

A run: step pipes the output of curl or wget directly into a shell interpreter. This is the "curl | bash" install pattern — if the remote server is compromised or the URL is hijacked, an attacker can execute arbitrary code in your CI runner. Consider downloading the file first, verifying its checksum or signature, and then executing it.

⭐ Removed in commit 0c6e9ea ⭐