Add recommendation regarding runner groups and labels

Signed-off-by: Thomas Sjögren <konstruktoid@users.noreply.github.com>

Author: konstruktoid

content/library/application-security/recommendations/actions-security/index.md

@@ -1,11 +1,11 @@
 ---
 # SPDX-FileCopyrightText: GitHub and The Project Authors
 # SPDX-License-Identifier: MIT
-draft: false # Set to false when ready to publish
+draft: true # Set to false when ready to publish
 title: 'Securing GitHub Actions Workflows'
 publishDate: 2024-08-16
 params:
-  authors: [{ name: 'Greg Mohler', handle: 'callmegreg' }, { name: 'Kitty Chiu', handle: 'kittychiu' }]
+  authors: [{ name: 'Greg Mohler', handle: 'callmegreg' }, { name: 'Kitty Chiu', handle: 'kittychiu' }, { name: 'Thomas Sjögren', handle: 'konstruktoid' }]
 
 # Classifications of the framework to drive key concepts, design principles, and architectural best practices
 pillars:
@@ -90,6 +90,7 @@ To secure GitHub Actions workflows, consider the following strategies:
 10. **Use `head.sha` instead of `head.ref`**: Where possible, reference by commit SHA instead of a user-provided branch name or tag (ref), especially in sensitive contexts (such as `run` steps). If require, use environment variable to store `head.ref` and reference it to prevent injection attack.
 11. **Use caution with public repositories**: Anyone can suggest changes to public repositories. Review workflow triggers, and never use self-hosted runners with public repositories.
 12. **Restrict allowed actions**: Use the [*Allow enterprise, and select non-enterprise, actions and reusable workflows*](https://docs.github.com/en/enterprise-cloud@latest/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#controlling-access-to-public-actions-and-reusable-workflows) setting  to control which actions can run.
+13. **Segregate runners**: Use organizational runner groups and labels to separate high-privilege runners (with access to secrets, sensitive resources or host access) from low-privilege runners.
 
 ## Assumptions and preconditions
 
@@ -126,6 +127,7 @@ Repository rulesets provide a strong defensive layer that complements workflow-l
 - [Require status checks to pass before merging](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-status-checks-to-pass-before-merging): Ensure automated validation checks pass before merging.
 - [Require code scanning results](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-code-scanning-results): Identify security vulnerabilities before merge.
 - [Require signed commits](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-signed-commits): Ensure all commits are signed to prove who authored them and that they haven't been modified.
+- [Require workflows to pass before merging](https://docs.github.com/en/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging): Ensure organizational or enterprise-level requirements for workflows are met before merging. This could be a workflow that checks for required labels, validates commit messages, or performs other organizational policy checks.
 - Restrict bypass permissions: Limit bypass capabilities to emergencies and monitor via audit logs.
 
 ### Implement least privilege for workflow permissions
@@ -257,6 +259,10 @@ The [allowed actions and reusable workflows setting](https://docs.github.com/en/
 
 Consider defining the list of allowed actions using policy as code (e.g., via Terraform or the REST API) to establish a request/approval process, track changes for audit purposes, and improve visibility into which actions are allowed.
 
+### Segregate runners
+
+Use [runner groups](https://docs.github.com/en/actions/concepts/runners/runner-groups) and [labels](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/apply-labels) to separate high-privilege runners (with access to sensitive resources or direct host access) from low-privilege runners. This segregation allows for more granular control over [which repositories can access different runners](https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/manage-access#changing-which-repositories-can-access-a-runner-group) and which [jobs can access specific runners](https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/choose-the-runner-for-a-job), reducing the risk of a compromised or misconfigured workflow gaining access to sensitive resources. For example, create a runner group for container image build runners or a runner group with runners having access to restricted networks and restrict its members to only the repositories that require those privileges, place unprivileged tasks such as linting and static analysis in a separate runner group with no access to secrets or sensitive resources.
+
 ## Additional solution detail and trade-offs to consider
 
 ### Pinning actions based on a version tag