Define and apply best practice for secrets in CI on PRs (security)

[AlexanderLanin]

Currently we have some understanding of security problems when running code from pull requests, and some solutions. However, we lack a common practice. Within this issue we want to identify/understand common practices, identify gaps and apply the fixes.

Resources to consider:

• https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
• ...

Note: best understanding of the topic so far by @dcalavrezo-qorix

[AlexanderLanin]

@sameer6989 can you help out with this one?

[sameer6989]

Best practices for handling secrets in github actions for PR workflows

1. Avoid using pull_request_target for running untrusted PR code

Why?

• "pull_request_target" runs in the context of the base repository, granting write permissions and access to secrets, even for PRs from forks.
• If an attacker submits a malicious PR, they could gain access to repository secrets and write to the repository.

Solution:

• Use pull_request instead, if write access and secrets are not required.
• If pull_request_target is required (e.g., for PR labeling), ensure the workflow does not check out or execute untrusted code.

---

2. Use workflow_run to isolate privileged actions

Why?

• Workflows triggered by pull_request have limited permissions (read-only, no secrets), but sometimes you need to process untrusted PR code securely.

Solution:

1. Use a pull_request workflow (no access to secrets) to process untrusted code.
2. Trigger a workflow_run workflow (with access to secrets) to perform privileged actions.

---

3. Restrict GITHUB_TOKEN permissions

Why?

• By default, GITHUB_TOKEN has write permissions, which increases the risk of an attacker modifying the repository.

Solution:

• Reduce permissions to read-only unless explicitly required :

  permissions:
    contents: read

• If a job requires write access, grant only the necessary permissions :

  permissions:
    pull-requests: write
    contents: none

---

4. Use environment variables instead of inline secrets

Why?

• Directly using ${{ secrets.YOUR_SECRET }} in commands can expose secrets in logs.

Solution:

• Store secrets in environment variables securely:

  env:
    MY_SECRET: ${{ secrets.YOUR_SECRET }}

• Always quote variables when using them in scripts to prevent unintended command injection:

  echo "$MY_SECRET"

---

5. Do not store secrets in artifacts

Why?

• Artifacts generated by unprivileged workflows are untrusted.

Solution:

• Never include secrets in artifacts.
• If artifacts need to be processed by a privileged workflow, validate their contents before use.

---

6. Validate all untrusted input

Why?

• PR titles, issue comments, and branch names can be attacker-controlled.

Solution:

• Store untrusted input in environment variables instead of using them directly in scripts:

  - name: Set Title Variable
    env:
      TITLE: ${{ github.event.issue.title }}
    run: echo "$TITLE"

---

7. Securely reference third-party actions

Why?

• Referencing actions by @main or @vX.Y.Z can lead to supply chain attacks if an action is compromised.

Solution:

• Use a full commit SHA:

  uses: actions/checkout@26968a09c0ea4f3e233fdddbafd1166051a095f6

---

8. Implement repository and actor checks

Why?

• PRs can come from untrusted forks.

Solution:

• Restrict execution to trusted repositories:

  if: github.event.pull_request.head.repo.full_name == 'your-org/repo'

• Use GitHub Teams (github.actor) to allow only trusted users:

  if: github.actor == 'trusted-user'

---

9. Prevent cache poisoning attacks

Why?

• Untrusted PRs can modify cached dependencies.

Solution:

• Ensure cache keys do not use attacker-controlled input.
• Use a secure cache restore mechanism with immutable cache keys.

---

10. Keep security vulnerabilities in check

Why?

• Having a well-documented security policy ensures consistency across the project.

Solution:

• Enable CodeQL scanning to detect security vulnerabilities in workflows.
• Regularly audit GitHub Actions permissions and access levels.

---

References :
Preventing pwn requests

Untrusted inputs

How to trust your building blocks

New vulnerability patterns and mitigation strategies