Awesome/awesome-copilot
1
0
Fork 0
mirror of https://github.com/github/awesome-copilot.git synced 2026-03-23 09:35:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: pin GitHub Actions to immutable SHA hashes to prevent supply chain attacks (#1088)

Browse Source 
* chore: publish from staged

* fix: pin GitHub Actions to immutable SHA hashes to prevent supply chain attacks

Co-authored-by: simonkurtz-MSFT <84809797+simonkurtz-MSFT@users.noreply.github.com>

* chore: publish from staged

* Clean plugins

* Clean plugins

* Clean plugins

* Fix gem-team plugin

* Reset README.plugins.md

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
This commit is contained in:
Simon Kurtz
2026-03-22 18:37:40 -05:00
committed by GitHub
parent 10e717202f
commit 919fdb3f8e
13 changed files with 52 additions and 50 deletions
Download Patch File Download Diff File Expand all files Collapse all files

32
instructions/github-actions-ci-cd-best-practices.instructions.md
View File

@@ -47,9 +47,9 @@ jobs:
artifact_path: ${{ steps.package_app.outputs.path }}
steps:
- name: Checkout code
uses: actions/checkout@v4
uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
- name: Setup Node.js
uses: actions/setup-node@v3
uses: actions/setup-node@3235b876344d2a9aa001b8d1453c930bba69e610 # v3.9.1
with:
node-version: 18
- name: Install dependencies and build
@@ -62,7 +62,7 @@ jobs:
zip -r dist.zip dist
echo "path=dist.zip" >> "$GITHUB_OUTPUT"
- name: Upload build artifact
uses: actions/upload-artifact@v3
uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
with:
name: my-app-build
path: dist.zip
@@ -74,7 +74,7 @@ jobs:
environment: staging
steps:
- name: Download build artifact
uses: actions/download-artifact@v3
uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
with:
name: my-app-build
- name: Deploy to Staging
@@ -87,17 +87,17 @@ jobs:
### **3. Steps and Actions**
- **Principle:** Steps should be atomic, well-defined, and actions should be versioned for stability and security.
- **Deeper Dive:**
- **`uses`:** Referencing marketplace actions (e.g., `actions/checkout@v4`, `actions/setup-node@v3`) or custom actions. Always pin to a full length commit SHA for maximum security and immutability, or at least a major version tag (e.g., `@v4`). Avoid pinning to `main` or `latest`.
- **`uses`:** Referencing marketplace actions (e.g., `actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2`) or custom actions. Always pin to a full-length commit SHA for maximum security and immutability. Tags and branches are mutable references — a malicious actor who gains write access to an action's repository can silently move a tag (e.g., `@v4`) to a compromised commit, executing arbitrary code in your workflow (a supply chain attack). A commit SHA is immutable and cannot be redirected. Add the version as a comment (e.g., `# v4.3.1`) for human readability. Avoid mutable references like `@main`, `@latest`, or major version tags (e.g., `@v4`).
- **`name`:** Essential for clear logging and debugging. Make step names descriptive.
- **`run`:** For executing shell commands. Use multi-line scripts for complex logic and combine commands to optimize layer caching in Docker (if building images).
- **`env`:** Define environment variables at the step or job level. Do not hardcode sensitive data here.
- **`with`:** Provide inputs to actions. Ensure all required inputs are present.
- **Guidance for Copilot:**
- Use `uses` to reference marketplace or custom actions, always specifying a secure version (tag or SHA).
- Use `uses` to reference marketplace or custom actions, always pinning to an immutable commit SHA with a human-readable version comment (e.g., `uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2`). This is especially critical for third-party actions where you have no control over whether a tag gets moved.
- Use `name` for each step for readability in logs and easier debugging.
- Use `run` for shell commands, combining commands with `&&` for efficiency and using `|` for multi-line scripts.
- Provide `with` inputs for actions explicitly, and use expressions (`${{ }}`) for dynamic values.
- **Security Note:** Audit marketplace actions before use. Prefer actions from trusted sources (e.g., `actions/` organization) and review their source code if possible. Use `dependabot` for action version updates.
- **Security Note:** Audit marketplace actions before use. Prefer actions from trusted sources (e.g., `actions/` organization) and review their source code if possible. Use `dependabot` for action version updates. **Never use mutable tag or branch references** (`@v4`, `@main`, `@latest`) — these are vulnerable to supply chain attacks where a compromised tag can execute malicious code in your CI/CD pipeline.
## Security Best Practices in GitHub Actions
@@ -136,7 +136,7 @@ jobs:
- **Federated Identity:** This is a key pattern for modern, secure cloud deployments.
- **Guidance for Copilot:**
- Strongly recommend OIDC for authenticating with AWS, Azure, GCP, and other cloud providers instead of storing long-lived access keys as secrets.
- Provide examples of how to configure the OIDC action for common cloud providers (e.g., `aws-actions/configure-aws-credentials@v4`).
- Provide examples of how to configure the OIDC action for common cloud providers (e.g., `aws-actions/configure-aws-credentials@<SHA> # v4.x.x`). Always pin to a full commit SHA.
- Explain the concept of trust policies and how they relate to OIDC setup.
- **Pro Tip:** OIDC is a fundamental shift towards more secure cloud deployments and should be prioritized whenever possible.
@@ -162,7 +162,7 @@ jobs:
permissions:
contents: read # This job only needs to read code, override workflow default
steps:
- uses: actions/checkout@v4
- uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
- run: npm run lint
```
@@ -219,13 +219,13 @@ jobs:
- **Restore Keys:** Use `restore-keys` for fallbacks to older, compatible caches.
- **Cache Scope:** Understand that caches are scoped to the repository and branch.
- **Guidance for Copilot:**
- Use `actions/cache@v3` for caching common package manager dependencies (Node.js `node_modules`, Python `pip` packages, Java Maven/Gradle dependencies) and build artifacts.
- Use `actions/cache` (pinned to a full commit SHA) for caching common package manager dependencies (Node.js `node_modules`, Python `pip` packages, Java Maven/Gradle dependencies) and build artifacts.
- Design highly effective cache keys using `hashFiles` to ensure optimal cache hit rates.
- Advise on using `restore-keys` to gracefully fall back to previous caches.
- **Example (Advanced Caching for Monorepo):**
```yaml
- name: Cache Node.js modules
uses: actions/cache@v3
uses: actions/cache@668228422ae6a00e4ad889ee87cd7109ec5666a7 # v5.0.4
with:
path: |
~/.npm
@@ -259,8 +259,8 @@ jobs:
node-version: [16.x, 18.x, 20.x]
browser: [chromium, firefox]
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v3
- uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1
- uses: actions/setup-node@3235b876344d2a9aa001b8d1453c930bba69e610 # v3.9.1
with:
node-version: ${{ matrix.node-version }}
- name: Install Playwright browsers
@@ -289,7 +289,7 @@ jobs:
- **`lfs`:** Manage Git LFS (Large File Storage) files efficiently. If not needed, set `lfs: false`.
- **Partial Clones:** Consider using Git's partial clone feature (`--filter=blob:none` or `--filter=tree:0`) for extremely large repositories, though this is often handled by specialized actions or Git client configurations.
- **Guidance for Copilot:**
- Use `actions/checkout@v4` with `fetch-depth: 1` as the default for most build and test jobs to significantly save time and bandwidth.
- Use `actions/checkout` (pinned to a full commit SHA, e.g., `actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1`) with `fetch-depth: 1` as the default for most build and test jobs to significantly save time and bandwidth.
- Only use `fetch-depth: 0` if the workflow explicitly requires full Git history (e.g., for release tagging, deep commit analysis, or `git blame` operations).
- Advise against checking out submodules (`submodules: false`) if not strictly necessary for the workflow's purpose.
- Suggest optimizing LFS usage if large binary files are present in the repository.
@@ -303,7 +303,7 @@ jobs:
- **Use Cases:** Build outputs (executables, compiled code, Docker images), test reports (JUnit XML, HTML reports), code coverage reports, security scan results, generated documentation, static website builds.
- **Limitations:** Artifacts are immutable once uploaded. Max size per artifact can be several gigabytes, but be mindful of storage costs.
- **Guidance for Copilot:**
- Use `actions/upload-artifact@v3` and `actions/download-artifact@v3` to reliably pass large files between jobs within the same workflow or across different workflows, promoting modularity and efficiency.
- Use `actions/upload-artifact` and `actions/download-artifact` (both pinned to full commit SHAs) to reliably pass large files between jobs within the same workflow or across different workflows, promoting modularity and efficiency.
- Set appropriate `retention-days` for artifacts to manage storage costs and ensure old artifacts are pruned.
- Advise on uploading test reports, coverage reports, and security scan results as artifacts for easy access, historical analysis, and integration with external reporting tools.
- Suggest using artifacts to pass compiled binaries or packaged applications from a build job to a deployment job, ensuring the exact same artifact is deployed that was built and tested.
@@ -452,7 +452,7 @@ This checklist provides a granular set of criteria for reviewing GitHub Actions
- Are `needs` dependencies correctly defined between jobs to ensure proper execution order?
- Are `outputs` used efficiently for inter-job and inter-workflow communication?
- Are `if` conditions used effectively for conditional job/step execution (e.g., environment-specific deployments, branch-specific actions)?
- Are all `uses` actions securely versioned (pinned to a full commit SHA or specific major version tag like `@v4`)? Avoid `main` or `latest` tags.
- Are all `uses` actions pinned to a full commit SHA with a human-readable version comment (e.g., `actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4.3.1`)? Tags (e.g., `@v4`) and branches (e.g., `@main`) are mutable and can be silently redirected to malicious commits — always use immutable SHA references, especially for third-party actions.
- Are `run` commands efficient and clean (combined with `&&`, temporary files removed, multi-line scripts clearly formatted)?
- Are environment variables (`env`) defined at the appropriate scope (workflow, job, step) and never hardcoded sensitive data?
- Is `timeout-minutes` set for long-running jobs to prevent hung workflows?