Repository navigation
Conversation
This workflow triggers Datadog Synthetic tests on push and pull request events to the main branch.
📝 WalkthroughWalkthroughA new GitHub Actions workflow file is introduced to automate the execution of Datadog Synthetic tests. The workflow is triggered on pushes and pull requests to the main branch and executes synthetic tests via the Datadog CI GitHub Action using API credentials stored as secrets. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Tip CodeRabbit can enforce grammar and style rules using `languagetool`.Configure the |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/datadog-synthetics.yml:
- Around line 22-24: The workflow is missing explicit GITHUB_TOKEN permissions;
add a permissions block to the job (jobs.build) to restrict access to least
privilege by granting only repository contents read access required by
actions/checkout. Concretely, add a permissions: contents: read entry under the
build job (or at top-level workflow) so the GITHUB_TOKEN is constrained for the
build job.
- Line 27: Replace the mutable checkout tag "uses: actions/checkout@v4" with the
corresponding full commit SHA to pin the action (matching the approach used for
the Datadog action on line 32); locate the "uses: actions/checkout@v4" entry in
the datadog-synthetics.yml workflow and update it to the specific commit SHA for
actions/checkout so the workflow is immutable and supply-chain secure.
- Around line 19-20: The Datadog Synthetics step fails for forked PRs because
repository secrets (DD_API_KEY, DD_APP_KEY) are unavailable; modify the workflow
step named "Datadog Synthetics" to guard execution by adding a conditional that
only runs the step when both secrets are present (e.g., use an if expression
that checks secrets.DD_API_KEY and secrets.DD_APP_KEY are non-empty), so the
step is skipped for fork-origin pull requests where those secrets are not
exposed.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 17355409-bd73-4c71-b4d0-2130faf50d4d
📒 Files selected for processing (1)
.github/workflows/datadog-synthetics.yml
| pull_request: | ||
| branches: [ "main" ] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/datadog-synthetics.ymlRepository: PaddyCH96/Personal-ATS-checker
Length of output: 1769
🌐 Web query:
GitHub secrets not available forked pull request security
💡 Result:
GitHub Actions does not expose repository secrets to workflows triggered by pull requests from forks because the workflow may execute untrusted, attacker-controlled code, and any available secret could be exfiltrated (for pull_request from forks, the GITHUB_TOKEN is also read-only). [1]
What to do instead (common safe patterns)
-
Run CI on fork PRs without secrets (recommended): use
on: pull_requestfor tests/lint that don’t need credentials. GitHub explicitly treats this as the “minimal privileges” path. [1] -
If you need to comment/label the PR (needs elevated perms):
- Use
pull_request_target, but do not check out or run the fork’s code in that workflow, becausepull_request_targetruns in the base repo context and can have access to secrets/greater permissions—this is a known exfiltration foot-gun. [2][3]
- Use
-
Two-stage workflow (separate untrusted + privileged steps):
- Stage A (
pull_request): build/test untrusted code, upload artifacts. - Stage B (
workflow_runor manual trigger): only after review/approval, run privileged steps that require secrets; treat artifacts cautiously. [2]
- Stage A (
-
Use GitHub settings/controls for forks (especially private repos):
- There are repo/org/enterprise controls for fork PR workflows (including whether to send secrets/variables, whether to send write tokens, and whether approval is required). These exist because enabling secrets for fork PRs materially changes the risk profile. [4][5]
If you share your exact goal (e.g., “run integration tests against AWS” vs “just post a comment”), I can suggest the safest workflow/event + permissions layout for it.
Sources:
[1] GitHub Blog – security guarantee for pull_request from forks: no secrets + read-only token: (github.blog)
[2] GitHub Docs – secure use reference; warns about pull_request_target/workflow_run + untrusted checkout and secret exposure: (docs.github.com)
[3] Example real-world pull_request_target secret-exfil advisory: (github.com)
[4] GitHub Docs – repository Actions settings & fork workflow approval policies: (docs.github.com)
[5] GitHub Docs – API fields like send_secrets_and_variables / fork PR workflow permissions: (docs.github.com)
Citations:
- 1: https://github.blog/security/supply-chain-security/four-tips-to-keep-your-github-actions-workflows-secure/
- 2: https://docs.github.com/en/enterprise-cloud%40latest/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions?learn=getting_started&learnProduct=actions
- 3: https://github.com/timescale/pgai/security/advisories/GHSA-89qq-hgvp-x37m?utm_source=openai
- 4: https://docs.github.com/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository?utm_source=openai
- 5: https://docs.github.com/en/rest/actions/permissions?utm_source=openai
Guard secret-dependent step for forked PRs.
The Datadog Synthetics step at lines 34–35 requires repository secrets (DD_API_KEY, DD_APP_KEY), which are unavailable in pull requests from forked repositories. This causes the workflow to fail on fork-origin PRs.
Add a conditional to skip the step when secrets are empty:
Suggested change
- name: Run Datadog Synthetic tests
+ if: ${{ secrets.DD_API_KEY != '' && secrets.DD_APP_KEY != '' }}
uses: DataDog/synthetics-ci-github-action@87b505388a22005bb8013481e3f73a367b9a53eb # v1.4.0
with:
api_key: ${{secrets.DD_API_KEY}}
app_key: ${{secrets.DD_APP_KEY}}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| pull_request: | |
| branches: [ "main" ] | |
| - name: Run Datadog Synthetic tests | |
| if: ${{ secrets.DD_API_KEY != '' && secrets.DD_APP_KEY != '' }} | |
| uses: DataDog/synthetics-ci-github-action@87b505388a22005bb8013481e3f73a367b9a53eb # v1.4.0 | |
| with: | |
| api_key: ${{secrets.DD_API_KEY}} | |
| app_key: ${{secrets.DD_APP_KEY}} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/datadog-synthetics.yml around lines 19 - 20, The Datadog
Synthetics step fails for forked PRs because repository secrets (DD_API_KEY,
DD_APP_KEY) are unavailable; modify the workflow step named "Datadog Synthetics"
to guard execution by adding a conditional that only runs the step when both
secrets are present (e.g., use an if expression that checks secrets.DD_API_KEY
and secrets.DD_APP_KEY are non-empty), so the step is skipped for fork-origin
pull requests where those secrets are not exposed.
| jobs: | ||
| build: | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -path "./.github/workflows/datadog-synthetics.yml" -type fRepository: PaddyCH96/Personal-ATS-checker
Length of output: 116
🏁 Script executed:
cat -n .github/workflows/datadog-synthetics.yml | head -40Repository: PaddyCH96/Personal-ATS-checker
Length of output: 1769
Set explicit workflow/job token permissions (least privilege).
No permissions block is declared at the workflow or job level. Explicitly constraining GITHUB_TOKEN to the minimum required permissions follows the principle of least privilege. This job only needs read access to repository contents for the actions/checkout action.
Suggested change
jobs:
build:
+ permissions:
+ contents: read
runs-on: ubuntu-latest📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| jobs: | |
| build: | |
| runs-on: ubuntu-latest | |
| jobs: | |
| build: | |
| permissions: | |
| contents: read | |
| runs-on: ubuntu-latest |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/datadog-synthetics.yml around lines 22 - 24, The workflow
is missing explicit GITHUB_TOKEN permissions; add a permissions block to the job
(jobs.build) to restrict access to least privilege by granting only repository
contents read access required by actions/checkout. Concretely, add a
permissions: contents: read entry under the build job (or at top-level workflow)
so the GITHUB_TOKEN is constrained for the build job.
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check if the file exists and read its content
if [ -f ".github/workflows/datadog-synthetics.yml" ]; then
cat -n .github/workflows/datadog-synthetics.yml | head -40
else
echo "File not found"
fiRepository: PaddyCH96/Personal-ATS-checker
Length of output: 1769
🌐 Web query:
GitHub Actions best practices pin commit SHA mutable tags security
💡 Result:
Why pin to a full commit SHA (vs tags/branches)
- Tags like
v1and branches likemainare mutable: the maintainer (or an attacker who compromises the maintainer) can move them to point at different code, and your workflow will silently start running it. Pinning to a full-length commit SHA makes the referenced code content-addressed and immutable in practice. [1] - GitHub explicitly recommends SHA pinning, and GitHub Actions policy can now enforce “must be pinned to full SHA” so unpinned workflows fail. [2]
Recommended pattern
Pin the action to a SHA, and keep the human-friendly version as a comment:
- uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.2.1This is the approach GitHub and common tooling encourage (pin SHA; optionally annotate the intended release/tag). [1]
Keep pins updated (without going back to mutable refs)
- Enable Dependabot version updates for GitHub Actions so it opens PRs to bump your pinned SHAs safely and routinely. [3]
Example dependabot.yml:
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"(Dependabot supports GitHub Actions updates directly.) [3]
Enforce org/enterprise guardrails
- Use “Allowed actions and reusable workflows” policy to restrict what can run (e.g., only GitHub-owned, verified creators, or an allowlist), and use the option to require references like
owner/repo@<full_sha>. [4] - With the newer GitHub Actions policy controls, you can block unpinned uses and require SHA pinning across your org/enterprise. [2]
Operational hardening (commonly paired with SHA pinning)
- Automate pinning/hardening across repos (e.g., Step Security’s tooling aligns with GitHub guidance to pin third-party actions to full SHAs). [5]
Sources: GitHub Well-Architected guidance on Actions security and SHA pinning [1]; GitHub Changelog on SHA-pinning enforcement in Actions policy [2]; GitHub Docs on Dependabot updates for GitHub Actions [3]; GitHub Docs on allowed actions/reusable workflows policies and SHA references [4]; Step Security secure-repo guidance referencing GitHub’s recommendation to pin to full SHAs [5].
Pin actions/checkout to a full commit SHA.
Line 27 uses a mutable tag (@v4), which weakens workflow supply-chain integrity and is inconsistent with the Datadog action pinned to SHA on line 32.
Suggested change
- - uses: actions/checkout@v4
+ - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: actions/checkout@v4 | |
| - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4 |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/datadog-synthetics.yml at line 27, Replace the mutable
checkout tag "uses: actions/checkout@v4" with the corresponding full commit SHA
to pin the action (matching the approach used for the Datadog action on line
32); locate the "uses: actions/checkout@v4" entry in the datadog-synthetics.yml
workflow and update it to the specific commit SHA for actions/checkout so the
workflow is immutable and supply-chain secure.
1 participant
This workflow triggers Datadog Synthetic tests on push and pull request events to the main branch.
Summary by CodeRabbit