Merge pull request #19892 from owen-mc/fix-markdown-query-help-formatting

Fix markdown query help formatting

actions/ql/src/Security/CWE-077/EnvPathInjectionCritical.md

@@ -1,6 +1,4 @@
-# Environment Path Injection
-
-## Description
+## Overview
 
 GitHub Actions allow to define the system PATH variable by writing to a file pointed to by the `GITHUB_PATH` environment variable. Writing to this file appends a directory to the system PATH variable and automatically makes it available to all subsequent actions in the current job.
 
@@ -12,11 +10,11 @@ echo "$HOME/.local/bin" >> $GITHUB_PATH
 
 If an attacker can control the contents of the system PATH, they are able to influence what commands are run in subsequent steps of the same job.
 
-## Recommendations
+## Recommendation
 
 Do not allow untrusted data to influence the system PATH: Avoid using untrusted data sources (e.g., artifact content) to define the system PATH.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -36,4 +34,4 @@ If an attacker can manipulate the value being set, such as through artifact down
 
 ## References
 
-- [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions)
+- GitHub Docs: [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions).

actions/ql/src/Security/CWE-077/EnvPathInjectionMedium.md

@@ -1,6 +1,4 @@
-# Environment Path Injection
-
-## Description
+## Overview
 
 GitHub Actions allow to define the system PATH variable by writing to a file pointed to by the `GITHUB_PATH` environment variable. Writing to this file appends a directory to the system PATH variable and automatically makes it available to all subsequent actions in the current job.
 
@@ -12,11 +10,11 @@ echo "$HOME/.local/bin" >> $GITHUB_PATH
 
 If an attacker can control the contents of the system PATH, they are able to influence what commands are run in subsequent steps of the same job.
 
-## Recommendations
+## Recommendation
 
 Do not allow untrusted data to influence the system PATH: Avoid using untrusted data sources (e.g., artifact content) to define the system PATH.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -36,4 +34,4 @@ If an attacker can manipulate the value being set, such as through artifact down
 
 ## References
 
-- [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions)
+- GitHub Docs: [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions).

actions/ql/src/Security/CWE-077/EnvVarInjectionCritical.md

@@ -1,6 +1,4 @@
-# Environment Variable Injection
-
-## Description
+## Overview
 
 GitHub Actions allow to define environment variables by writing to a file pointed to by the `GITHUB_ENV` environment variable:
 
@@ -37,7 +35,7 @@ steps:
 
 If an attacker can control the values assigned to environment variables and there is no sanitization in place, the attacker will be able to inject additional variables by injecting new lines or `{delimiters}`.
 
-## Recommendations
+## Recommendation
 
 1. **Do not allow untrusted data to influence environment variables**:
 
@@ -64,7 +62,7 @@ If an attacker can control the values assigned to environment variables and ther
           } >> "$GITHUB_ENV"
     ```
 
-## Examples
+## Example
 
 ### Example of Vulnerability
 
@@ -113,5 +111,5 @@ An attacker is be able to run arbitrary code by injecting environment variables
 
 ## References
 
-- [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions)
-- [GitHub Actions Exploitation: Repo Jacking and Environment Manipulation](https://www.synacktiv.com/publications/github-actions-exploitation-repo-jacking-and-environment-manipulation)
+- GitHub Docs: [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions).
+- Synacktiv: [GitHub Actions Exploitation: Repo Jacking and Environment Manipulation](https://www.synacktiv.com/publications/github-actions-exploitation-repo-jacking-and-environment-manipulation).

actions/ql/src/Security/CWE-077/EnvVarInjectionMedium.md

@@ -1,6 +1,4 @@
-# Environment Variable Injection
-
-## Description
+## Overview
 
 GitHub Actions allow to define environment variables by writing to a file pointed to by the `GITHUB_ENV` environment variable:
 
@@ -37,7 +35,7 @@ steps:
 
 If an attacker can control the values assigned to environment variables and there is no sanitization in place, the attacker will be able to inject additional variables by injecting new lines or `{delimiters}`.
 
-## Recommendations
+## Recommendation
 
 1. **Do not allow untrusted data to influence environment variables**:
 
@@ -64,7 +62,7 @@ If an attacker can control the values assigned to environment variables and ther
           } >> "$GITHUB_ENV"
     ```
 
-## Examples
+## Example
 
 ### Example of Vulnerability
 
@@ -113,5 +111,5 @@ An attacker would be able to run arbitrary code by injecting environment variabl
 
 ## References
 
-- [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions)
-- [GitHub Actions Exploitation: Repo Jacking and Environment Manipulation](https://www.synacktiv.com/publications/github-actions-exploitation-repo-jacking-and-environment-manipulation)
+- GitHub Docs: [Workflow commands for GitHub Actions](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions).
+- Synacktiv: [GitHub Actions Exploitation: Repo Jacking and Environment Manipulation](https://www.synacktiv.com/publications/github-actions-exploitation-repo-jacking-and-environment-manipulation).

actions/ql/src/Security/CWE-094/CodeInjectionCritical.md

@@ -1,18 +1,16 @@
-# Code Injection in GitHub Actions
-
-## Description
+## Overview
 
 Using user-controlled input in GitHub Actions may lead to code injection in contexts like _run:_ or _script:_.
 
 Code injection in GitHub Actions may allow an attacker to exfiltrate any secrets used in the workflow and the temporary GitHub repository authorization token. The token may have write access to the repository, allowing an attacker to make changes to the repository.
 
-## Recommendations
+## Recommendation
 
 The best practice to avoid code injection vulnerabilities in GitHub workflows is to set the untrusted input value of the expression to an intermediate environment variable and then use the environment variable using the native syntax of the shell/script interpreter (that is, not _${{ env.VAR }}_).
 
 It is also recommended to limit the permissions of any tokens used by a workflow such as the GITHUB_TOKEN.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 

actions/ql/src/Security/CWE-094/CodeInjectionMedium.md

@@ -1,18 +1,16 @@
-# Code Injection in GitHub Actions
-
-## Description
+## Overview
 
 Using user-controlled input in GitHub Actions may lead to code injection in contexts like _run:_ or _script:_.
 
 Code injection in GitHub Actions may allow an attacker to exfiltrate any secrets used in the workflow and the temporary GitHub repository authorization token. The token may have write access to the repository, allowing an attacker to make changes to the repository.
 
-## Recommendations
+## Recommendation
 
 The best practice to avoid code injection vulnerabilities in GitHub workflows is to set the untrusted input value of the expression to an intermediate environment variable and then use the environment variable using the native syntax of the shell/script interpreter (that is, not _${{ env.VAR }}_).
 
 It is also recommended to limit the permissions of any tokens used by a workflow such as the GITHUB_TOKEN.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 

actions/ql/src/Security/CWE-1395/UseOfKnownVulnerableAction.md

@@ -1,13 +1,11 @@
-# Use of Actions with known vulnerabilities
-
-## Description
+## Overview
 
 The security of the workflow and the repository could be compromised by GitHub Actions workflows that utilize GitHub Actions with known vulnerabilities.
 
-## Recommendations
+## Recommendation
 
 Either remove the component from the workflow or upgrade it to a version that is not vulnerable.
 
 ## References
 
-- [GitHub Docs: Keeping your actions up to date with Dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot)
+- GitHub Docs: [Keeping your actions up to date with Dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot).

actions/ql/src/Security/CWE-275/MissingActionsPermissions.md

@@ -1,12 +1,21 @@
-# Actions Job and Workflow Permissions are not set
-
-## Description
+## Overview
 
 If a GitHub Actions job or workflow has no explicit permissions set, then the repository permissions are used. Repositories created under organizations inherit the organization permissions. The organizations or repositories created before February 2023 have the default permissions set to read-write. Often these permissions do not adhere to the principle of least privilege and can be reduced to read-only, leaving the `write` permission only to a specific types as `issues: write` or `pull-requests: write`.
 
-## Recommendations
+## Recommendation
 
-Add the `permissions` key to the job or the root of workflow (in this case it is applied to all jobs in the workflow that do not have their own `permissions` key) and assign the least privileges required to complete the task:
+Add the `permissions` key to the job or the root of workflow (in this case it is applied to all jobs in the workflow that do not have their own `permissions` key) and assign the least privileges required to complete the task.
+
+## Example
+
+### Incorrect Usage
+
+```yaml
+name: "My workflow"
+# No permissions block
+```
+
+### Correct Usage
 
 ```yaml
 name: "My workflow"
@@ -27,4 +36,4 @@ jobs:
 
 ## References
 
-- [Assigning permissions to jobs](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/assigning-permissions-to-jobs)
+- GitHub Docs: [Assigning permissions to jobs](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/assigning-permissions-to-jobs).

actions/ql/src/Security/CWE-285/ImproperAccessControl.md

@@ -1,14 +1,12 @@
-# Improper Access Control
-
-## Description
+## Overview
 
 Sometimes labels are used to approve GitHub Actions. An authorization check may not be properly implemented, allowing an attacker to mutate the code after it has been reviewed and approved by label.
 
-## Recommendations
+## Recommendation
 
 When using labels, make sure that the code cannot be modified after it has been reviewed and the label has been set.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -57,4 +55,4 @@ jobs:
 
 ## References
 
-- [Events that trigger workflows](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target)
+- GitHub Docs: [Events that trigger workflows](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target).

actions/ql/src/Security/CWE-312/ExcessiveSecretsExposure.md

@@ -1,14 +1,12 @@
-# Excessive Secrets Exposure
-
-## Description
+## Overview
 
 When the workflow runner cannot determine what secrets are needed to run the workflow, it will pass all the available secrets to the runner including organization and repository secrets. This violates the least privileged principle and increases the impact of a potential vulnerability affecting the workflow.
 
-## Recommendations
+## Recommendation
 
 Only pass those secrets that are needed by the workflow. Avoid using expressions such as `toJSON(secrets)` or dynamically accessed secrets such as `secrets[format('GH_PAT_%s', matrix.env)]` since the workflow will need to receive all secrets to decide at runtime which one needs to be used.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -48,5 +46,5 @@ env:
 
 ## References
 
-- [Using secrets in GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-encrypted-secrets-in-a-workflow)
-- [Job uses all secrets](https://github.com/boostsecurityio/poutine/blob/main/docs/content/en/rules/job_all_secrets.md)
+- GitHub Docs: [Using secrets in GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-encrypted-secrets-in-a-workflow).
+- poutine: [Job uses all secrets](https://github.com/boostsecurityio/poutine/blob/main/docs/content/en/rules/job_all_secrets.md).

actions/ql/src/Security/CWE-312/SecretsInArtifacts.md

@@ -1,6 +1,4 @@
-# Storage of sensitive information in GitHub Actions artifact
-
-## Description
+## Overview
 
 Sensitive information included in a GitHub Actions artifact can allow an attacker to access the sensitive information if the artifact is published.
 
@@ -10,6 +8,8 @@ Only store information that is meant to be publicly available in a GitHub Action
 
 ## Example
 
+### Incorrect Usage
+
 The following example uses `actions/checkout` to checkout code which stores the GITHUB_TOKEN in the \`.git/config\` file and then stores the contents of the \`.git\` repository into the artifact:
 
 ```yaml
@@ -28,6 +28,8 @@ jobs:
           path: .
 ```
 
+### Correct Usage
+
 The issue has been fixed below, where the `actions/upload-artifact` uses a version (v4+) which does not include hidden files or directories into the artifact.
 
 ```yaml

actions/ql/src/Security/CWE-312/UnmaskedSecretExposure.md

@@ -1,14 +1,12 @@
-# Unmasked Secret Exposure
-
-## Description
+## Overview
 
 Secrets derived from other secrets are not known to the workflow runner, and therefore are not masked unless explicitly registered.
 
-## Recommendations
+## Recommendation
 
 Avoid defining non-plain secrets. For example, do not define a new secret containing a JSON object and then read properties out of it from the workflow, since these read values will not be masked by the workflow runner.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -34,4 +32,4 @@ Avoid defining non-plain secrets. For example, do not define a new secret contai
 
 ## References
 
-- [Using secrets in GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-encrypted-secrets-in-a-workflow)
+- GitHub Docs: [Using secrets in GitHub Actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-encrypted-secrets-in-a-workflow).

actions/ql/src/Security/CWE-349/CachePoisoningViaCodeInjection.md

@@ -1,6 +1,4 @@
-# Cache Poisoning in GitHub Actions
-
-## Description
+## Overview
 
 GitHub Actions cache poisoning is a technique that allows an attacker to inject malicious content into the Action's cache from unprivileged workflow, potentially leading to code execution in privileged workflows.
 
@@ -23,7 +21,7 @@ In GitHub Actions, cache scopes are primarily determined by the branch structure
 
 Due to the above design, if something is cached in the context of the default branch (e.g., `main`), it becomes accessible to any feature branch derived from `main`.
 
-## Recommendations
+## Recommendation
 
 1. Avoid using caching in workflows that handle sensitive operations like releases.
 2. If caching must be used:
@@ -34,7 +32,7 @@ Due to the above design, if something is cached in the context of the default br
 4. Never run untrusted code in the context of the default branch.
 5. Sign the cache value cryptographically and verify the signature before usage.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -78,6 +76,6 @@ jobs:
 
 ## References
 
-- [The Monsters in Your Build Cache – GitHub Actions Cache Poisoning](https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/)
-- [GitHub Actions Caching Documentation](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows)
-- [Cache Poisoning in GitHub Actions](https://scribesecurity.com/blog/github-cache-poisoning/)
+- Adnan Khan's Blog: [The Monsters in Your Build Cache – GitHub Actions Cache Poisoning](https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/).
+- GitHub Docs: [GitHub Actions Caching Documentation](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows).
+- Scribe Security Blog: [Cache Poisoning in GitHub Actions](https://scribesecurity.com/blog/github-cache-poisoning/).

actions/ql/src/Security/CWE-349/CachePoisoningViaDirectCache.md

@@ -1,6 +1,4 @@
-# Cache Poisoning in GitHub Actions
-
-## Description
+## Overview
 
 GitHub Actions cache poisoning is a technique that allows an attacker to inject malicious content into the Action's cache from unprivileged workflow, potentially leading to code execution in privileged workflows.
 
@@ -23,7 +21,7 @@ In GitHub Actions, cache scopes are primarily determined by the branch structure
 
 Due to the above design, if something is cached in the context of the default branch (e.g., `main`), it becomes accessible to any feature branch derived from `main`.
 
-## Recommendations
+## Recommendation
 
 1. Avoid using caching in workflows that handle sensitive operations like releases.
 2. If caching must be used:
@@ -34,7 +32,7 @@ Due to the above design, if something is cached in the context of the default br
 4. Never run untrusted code in the context of the default branch.
 5. Sign the cache value cryptographically and verify the signature before usage.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -123,6 +121,6 @@ jobs:
 
 ## References
 
-- [The Monsters in Your Build Cache – GitHub Actions Cache Poisoning](https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/)
-- [GitHub Actions Caching Documentation](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows)
-- [Cache Poisoning in GitHub Actions](https://scribesecurity.com/blog/github-cache-poisoning/)
+- Adnan Khan's Blog: [The Monsters in Your Build Cache – GitHub Actions Cache Poisoning](https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/).
+- GitHub Docs: [GitHub Actions Caching Documentation](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows).
+- Scribe Security Blog: [Cache Poisoning in GitHub Actions](https://scribesecurity.com/blog/github-cache-poisoning/).

actions/ql/src/Security/CWE-349/CachePoisoningViaPoisonableStep.md

@@ -1,6 +1,4 @@
-# Cache Poisoning in GitHub Actions
-
-## Description
+## Overview
 
 GitHub Actions cache poisoning is a technique that allows an attacker to inject malicious content into the Action's cache from unprivileged workflow, potentially leading to code execution in privileged workflows.
 
@@ -23,7 +21,7 @@ In GitHub Actions, cache scopes are primarily determined by the branch structure
 
 Due to the above design, if something is cached in the context of the default branch (e.g., `main`), it becomes accessible to any feature branch derived from `main`.
 
-## Recommendations
+## Recommendation
 
 1. Avoid using caching in workflows that handle sensitive operations like releases.
 2. If caching must be used:
@@ -34,7 +32,7 @@ Due to the above design, if something is cached in the context of the default br
 4. Never run untrusted code in the context of the default branch.
 5. Sign the cache value cryptographically and verify the signature before usage.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -80,6 +78,6 @@ jobs:
 
 ## References
 
-- [The Monsters in Your Build Cache – GitHub Actions Cache Poisoning](https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/)
-- [GitHub Actions Caching Documentation](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows)
-- [Cache Poisoning in GitHub Actions](https://scribesecurity.com/blog/github-cache-poisoning/)
+- Adnan Khan's Blog: [The Monsters in Your Build Cache – GitHub Actions Cache Poisoning](https://adnanthekhan.com/2024/05/06/the-monsters-in-your-build-cache-github-actions-cache-poisoning/).
+- GitHub Docs: [GitHub Actions Caching Documentation](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows).
+- Scribe Security Blog: [Cache Poisoning in GitHub Actions](https://scribesecurity.com/blog/github-cache-poisoning/).

actions/ql/src/Security/CWE-367/UntrustedCheckoutTOCTOUCritical.md

@@ -1,17 +1,15 @@
-# Untrusted Checkout TOCTOU (Time-of-check to time-of-use)
-
-## Description
+## Overview
 
 Untrusted Checkout is protected by a security check but the checked-out branch can be changed after the check.
 
-## Recommendations
+## Recommendation
 
 Verify that the code has not been modified after the security check. This may be achieved differently depending on the type of check:
 
 - Deployment Environment Approval: Make sure to use a non-mutable reference to the code to be executed. For example use a `sha` instead of a `ref`.
 - Label Gates: Make sure to use a non-mutable reference to the code to be executed. For example use a `sha` instead of a `ref`.
 
-## Examples
+## Example
 
 ### Incorrect Usage (Deployment Environment Approval)
 
@@ -99,4 +97,4 @@ jobs:
 
 ## References
 
-- [ActionsTOCTOU](https://github.com/AdnaneKhan/ActionsTOCTOU)
+- [ActionsTOCTOU](https://github.com/AdnaneKhan/ActionsTOCTOU).

actions/ql/src/Security/CWE-367/UntrustedCheckoutTOCTOUHigh.md

@@ -1,17 +1,15 @@
-# Untrusted Checkout TOCTOU (Time-of-check to time-of-use)
-
-## Description
+## Overview
 
 Untrusted Checkout is protected by a security check but the checked-out branch can be changed after the check.
 
-## Recommendations
+## Recommendation
 
 Verify that the code has not been modified after the security check. This may be achieved differently depending on the type of check:
 
 - Deployment Environment Approval: Make sure to use a non-mutable reference to the code to be executed. For example use a `sha` instead of a `ref`.
 - Label Gates: Make sure to use a non-mutable reference to the code to be executed. For example use a `sha` instead of a `ref`.
 
-## Examples
+## Example
 
 ### Incorrect Usage (Deployment Environment Approval)
 
@@ -99,4 +97,4 @@ jobs:
 
 ## References
 
-- [ActionsTOCTOU](https://github.com/AdnaneKhan/ActionsTOCTOU)
+- [ActionsTOCTOU](https://github.com/AdnaneKhan/ActionsTOCTOU).

actions/ql/src/Security/CWE-571/ExpressionIsAlwaysTrueCritical.md

@@ -1,6 +1,4 @@
-# If Condition Always Evaluates to True
-
-## Description
+## Overview
 
 GitHub Workflow Expressions (`${{ ... }}`) used in the `if` condition of jobs or steps must not contain extra characters or spaces. Otherwise, the condition is invariably evaluated to `true`.
 
@@ -14,7 +12,7 @@ To avoid the vulnerability where an `if` condition always evaluates to `true`, i
 2. Avoid multiline or spaced-out conditional expressions that might inadvertently introduce unwanted characters or formatting.
 3. Test the workflow to ensure the `if` conditions behave as expected under different scenarios.
 
-## Examples
+## Example
 
 ### Correct Usage
 
@@ -60,4 +58,4 @@ To avoid the vulnerability where an `if` condition always evaluates to `true`, i
 
 ## References
 
-- [Expression Always True Github Issue](https://github.com/actions/runner/issues/1173)
+- GitHub actions/runner Issues: [Expression Always True](https://github.com/actions/runner/issues/1173).

actions/ql/src/Security/CWE-571/ExpressionIsAlwaysTrueHigh.md

@@ -1,6 +1,4 @@
-# If Condition Always Evaluates to True
-
-## Description
+## Overview
 
 GitHub Workflow Expressions (`${{ ... }}`) used in the `if` condition of jobs or steps must not contain extra characters or spaces. Otherwise, the condition is invariably evaluated to `true`.
 
@@ -14,7 +12,7 @@ To avoid the vulnerability where an `if` condition always evaluates to `true`, i
 2. Avoid multiline or spaced-out conditional expressions that might inadvertently introduce unwanted characters or formatting.
 3. Test the workflow to ensure the `if` conditions behave as expected under different scenarios.
 
-## Examples
+## Example
 
 ### Correct Usage
 
@@ -60,4 +58,4 @@ To avoid the vulnerability where an `if` condition always evaluates to `true`, i
 
 ## References
 
-- [Expression Always True Github Issue](https://github.com/actions/runner/issues/1173)
+- GitHub actions/runner Issues: [Expression Always True](https://github.com/actions/runner/issues/1173).

actions/ql/src/Security/CWE-829/ArtifactPoisoningCritical.md

@@ -1,16 +1,14 @@
-# Artifact poisoning
-
-## Description
+## Overview
 
 The workflow downloads artifacts that may be poisoned by an attacker in previously triggered workflows. If the contents of these artifacts are not correctly extracted, stored and verified, they may lead to repository compromise if untrusted code gets executed in a privileged job.
 
-## Recommendations
+## Recommendation
 
 - Always consider artifacts content as untrusted.
 - Extract the contents of artifacts to a temporary folder so they cannot override existing files.
 - Verify the contents of the artifacts downloaded. If an artifact is expected to contain a numeric value, verify it before using it.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -69,4 +67,4 @@ jobs:
 
 ## References
 
-- [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
+- GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

actions/ql/src/Security/CWE-829/ArtifactPoisoningMedium.md

@@ -1,16 +1,14 @@
-# Artifact poisoning
-
-## Description
+## Overview
 
 The workflow downloads artifacts that may be poisoned by an attacker in previously triggered workflows. If the contents of these artifacts are not correctly extracted, stored and verified, they may lead to repository compromise if untrusted code gets executed in a privileged job.
 
-## Recommendations
+## Recommendation
 
 - Always consider artifacts content as untrusted.
 - Extract the contents of artifacts to a temporary folder so they cannot override existing files.
 - Verify the contents of the artifacts downloaded. If an artifact is expected to contain a numeric value, verify it before using it.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -69,4 +67,4 @@ jobs:
 
 ## References
 
-- [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
+- GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

actions/ql/src/Security/CWE-829/UnpinnedActionsTag.md

@@ -1,14 +1,12 @@
-# Unpinned tag for 3rd party Action in workflow
-
-## Description
+## Overview
 
 Using a tag for a 3rd party Action that is not pinned to a commit can lead to executing an untrusted Action through a supply chain attack.
 
-## Recommendations
+## Recommendation
 
 Pinning an action to a full length commit SHA is currently the only way to use a non-immutable action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. When selecting a SHA, you should verify it is from the action's repository and not a repository fork.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -24,4 +22,4 @@ Pinning an action to a full length commit SHA is currently the only way to use a
 
 ## References
 
-- [Using third-party actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)
+- GitHub Docs: [Using third-party actions](https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions).

actions/ql/src/Security/CWE-829/UntrustedCheckoutCritical.md

@@ -1,10 +1,8 @@
-# Execution of Untrusted Checked-out Code
-
-## Description
+## Overview
 
 GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A potentially dangerous misuse of the triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted code (Pull Request HEAD) may lead to repository compromise if untrusted code gets executed in a privileged job.
 
-## Recommendations
+## Recommendation
 
 - Avoid using `pull_request_target` unless necessary.
 - Employ unprivileged `pull_request` workflows followed by `workflow_run` for privileged operations.
@@ -14,7 +12,7 @@ The best practice is to handle the potentially untrusted pull request via the **
 
 The artifacts downloaded from the first workflow should be considered untrusted and must be verified.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -134,4 +132,4 @@ jobs:
 
 ## References
 
-- [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
+- GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

actions/ql/src/Security/CWE-829/UntrustedCheckoutHigh.md

@@ -1,10 +1,8 @@
-# Execution of Untrusted Checked-out Code
-
-## Description
+## Overview
 
 GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A potentially dangerous misuse of the triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted code (Pull Request HEAD) may lead to repository compromise if untrusted code gets executed in a privileged job.
 
-## Recommendations
+## Recommendation
 
 - Avoid using `pull_request_target` unless necessary.
 - Employ unprivileged `pull_request` workflows followed by `workflow_run` for privileged operations.
@@ -14,7 +12,7 @@ The best practice is to handle the potentially untrusted pull request via the **
 
 The artifacts downloaded from the first workflow should be considered untrusted and must be verified.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -134,4 +132,4 @@ jobs:
 
 ## References
 
-- [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
+- GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

actions/ql/src/Security/CWE-829/UntrustedCheckoutMedium.md

@@ -1,10 +1,8 @@
-# Execution of Untrusted Checked-out Code
-
-## Description
+## Overview
 
 GitHub workflows can be triggered through various repository events, including incoming pull requests (PRs) or comments on Issues/PRs. A potentially dangerous misuse of the triggers such as `pull_request_target` or `issue_comment` followed by an explicit checkout of untrusted code (Pull Request HEAD) may lead to repository compromise if untrusted code gets executed in a privileged job.
 
-## Recommendations
+## Recommendation
 
 - Avoid using `pull_request_target` unless necessary.
 - Employ unprivileged `pull_request` workflows followed by `workflow_run` for privileged operations.
@@ -14,7 +12,7 @@ The best practice is to handle the potentially untrusted pull request via the **
 
 The artifacts downloaded from the first workflow should be considered untrusted and must be verified.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -134,4 +132,4 @@ jobs:
 
 ## References
 
-- [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/)
+- GitHub Security Lab Research: [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/).

actions/ql/src/Violations Of Best Practice/CodeQL/UnnecessaryUseOfAdvancedConfig.md

@@ -1,13 +1,11 @@
-# Unneccesary use of advanced configuration
-
-## Description
+## Overview
 
 The CodeQL workflow does not use any custom settings and could be simplified by switching to the CodeQL default setup.
 
-## Recommendations
+## Recommendation
 
 If there is no reason to have a custom configuration switch to the CodeQL default setup.
 
 ## References
 
-- [GitHub Docs: Configuring Default Setup for a repository](https://docs.github.com/en/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning#configuring-default-setup-for-a-repository)
+- GitHub Docs: [Configuring Default Setup for a repository](https://docs.github.com/en/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning#configuring-default-setup-for-a-repository).

actions/ql/src/experimental/Security/CWE-088/ArgumentInjectionCritical.md

@@ -1,18 +1,16 @@
-# Argument Injection in GitHub Actions
-
-## Description
+## Overview
 
 Passing user-controlled arguments to certain commands in the context of `Run` steps may lead to arbitrary code execution.
 
 Argument injection in GitHub Actions may allow an attacker to exfiltrate any secrets used in the workflow and the temporary GitHub repository authorization token. The token may have write access to the repository, allowing the attacker to make changes to the repository.
 
-## Recommendations
+## Recommendation
 
 When possible avoid passing user-controlled data to commands which may spawn new processes using some of their arguments.
 
 It is also recommended to limit the permissions of any tokens used by a workflow such as the GITHUB_TOKEN.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -35,7 +33,7 @@ An attacker may set the body of an Issue comment to `BAR/g;1e whoami;#` and the
 
 ## References
 
-- [Common Weakness Enumeration: CWE-88](https://cwe.mitre.org/data/definitions/88.html).
-- [Argument Injection Explained](https://sonarsource.github.io/argument-injection-vectors/explained/)
-- [Argument Injection Vectors](https://sonarsource.github.io/argument-injection-vectors/)
-- [GTFOBins](https://gtfobins.github.io/)
+- Common Weakness Enumeration: [CWE-88](https://cwe.mitre.org/data/definitions/88.html).
+- [Argument Injection Vectors](https://sonarsource.github.io/argument-injection-vectors/).
+- Argument Injection Vectors: [Argument Injection Explained](https://sonarsource.github.io/argument-injection-vectors/explained/).
+- [GTFOBins](https://gtfobins.github.io/).

actions/ql/src/experimental/Security/CWE-088/ArgumentInjectionMedium.md

@@ -1,18 +1,16 @@
-# Argument Injection in GitHub Actions
-
-## Description
+## Overview
 
 Passing user-controlled arguments to certain commands in the context of `Run` steps may lead to arbitrary code execution.
 
 Argument injection in GitHub Actions may allow an attacker to exfiltrate any secrets used in the workflow and the temporary GitHub repository authorization token. The token may have write access to the repository, allowing the attacker to make changes to the repository.
 
-## Recommendations
+## Recommendation
 
 When possible avoid passing user-controlled data to commands which may spawn new processes using some of their arguments.
 
 It is also recommended to limit the permissions of any tokens used by a workflow such as the GITHUB_TOKEN.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -35,7 +33,7 @@ An attacker may set the body of an Issue comment to `BAR|g;1e whoami;#` and the
 
 ## References
 
-- [Common Weakness Enumeration: CWE-88](https://cwe.mitre.org/data/definitions/88.html).
-- [Argument Injection Explained](https://sonarsource.github.io/argument-injection-vectors/explained/)
-- [Argument Injection Vectors](https://sonarsource.github.io/argument-injection-vectors/)
-- [GTFOBins](https://gtfobins.github.io/)
+- Common Weakness Enumeration: [CWE-88](https://cwe.mitre.org/data/definitions/88.html).
+- [Argument Injection Vectors](https://sonarsource.github.io/argument-injection-vectors/).
+- Argument Injection Vectors: [Argument Injection Explained](https://sonarsource.github.io/argument-injection-vectors/explained/).
+- [GTFOBins](https://gtfobins.github.io/).

actions/ql/src/experimental/Security/CWE-829/UnversionedImmutableAction.md

@@ -1,14 +1,12 @@
-# Unversioned Immutable Action
-
-## Description
+## Overview
 
 This action is eligible for Immutable Actions, a new GitHub feature that is currently only available for internal users. Immutable Actions are released as packages in the GitHub package registry instead of resolved from a pinned SHA at the repository. The Immutable Action provides the same immutability as pinning the version to a SHA but with improved readability and additional security guarantees.
 
-## Recommendations
+## Recommendation
 
 For internal users: when using [immutable actions](https://github.com/github/package-registry-team/blob/main/docs/immutable-actions/immutable-actions-howto.md) use the full semantic version of the action. This will ensure that the action is resolved to the exact version stored in the GitHub package registry.
 
-## Examples
+## Example
 
 ### Incorrect Usage
 
@@ -25,4 +23,4 @@ For internal users: when using [immutable actions](https://github.com/github/pac
 
 ## References
 
-- [Consuming immutable actions]()
+- [Consuming immutable actions]().

docs/query-help-style-guide.md

@@ -100,7 +100,7 @@ Note, if any code words are included in the `overview` and `recommendation` sect
 
 ## Including references
 
-You should include one or more references, formatted as an unordered list (`- ...` or `* ...`) in Markdown or with `<li> ... </li>` for each item in XML, to provide further information about the problem that your query is designed to find. References can be of the following types:
+You should include one or more references, formatted as an unordered list (`- ...` or `* ...`) in Markdown or with `<li> ... </li>` for each item in XML, to provide further information about the problem that your query is designed to find. Each reference should end in a full stop. References can be of the following types:
 
 ### Books
 
@@ -124,7 +124,7 @@ If you are citing an academic paper, we recommend adopting the reference style o
 
 If you are citing a website, please use the following format, without breadcrumb trails:
 
->\<Name of website>: \<Name of page or anchor>
+>\<Name of website>: \<Name of page or anchor>.
 
 For example:
 
@@ -242,8 +242,8 @@ tab width settings cannot be taken into account.
 
 ## References
 
-* Java SE Documentation: [Compound Statements](https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#15395)
-* Wikipedia: [Indentation style](https://en.wikipedia.org/wiki/Indentation_style)
+* Java SE Documentation: [Compound Statements](https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#15395).
+* Wikipedia: [Indentation style](https://en.wikipedia.org/wiki/Indentation_style).
 ````
 
 ### XML example

java/ql/src/Performance/StringReplaceAllWithNonRegex.md

@@ -1,7 +1,3 @@
-# Use of `String#replaceAll` with a first argument which is not a regular expression
-
-Using `String#replaceAll` is less performant than `String#replace` when the first argument is not a regular expression.
-
 ## Overview
 
 The `String#replaceAll` method is designed to work with regular expressions as its first parameter. When you use a simple string without any regex patterns (like special characters or syntax), it's more efficient to use `String#replace` instead. This is because `replaceAll` has to compile the input as a regular expression first, which adds unnecessary overhead when you are just replacing literal text.

java/ql/src/Violations of Best Practice/Undesirable Calls/DoNotCallFinalize.md

@@ -8,6 +8,8 @@ Avoid calling `finalize()` in application code. Allow the JVM to determine a gar
 
 ## Example
 
+### Incorrect Usage
+
 ```java
 class LocalCache {
     private Collection<File> cacheFiles = ...;
@@ -19,9 +21,10 @@ void main() {
     // ...
     cache.finalize(); // NON_COMPLIANT
 }
-
 ```
 
+### Correct Usage
+
 ```java
 import java.lang.AutoCloseable;
 import java.lang.Override;
@@ -43,10 +46,9 @@ void main() {
         // ...
     }
 }
-
 ```
 
-# Implementation Notes
+## Implementation Notes
 
 This rule ignores `super.finalize()` calls that occur within `finalize()` overrides since calling the superclass finalizer is required when overriding `finalize()`. Also, although overriding `finalize()` is not recommended, this rule only alerts on direct calls to `finalize()` and does not alert on method declarations overriding `finalize()`.
 

ruby/ql/src/queries/variables/UninitializedLocal.md

@@ -1,6 +1,4 @@
-# Method call on `nil`
-
-## Description
+## Overview
 In Ruby, it is not necessary to explicitly initialize variables.
 If a local variable has not been explicitly initialized, it will have the value `nil`. If this happens unintentionally, though, the variable will not represent an object with the expected methods, and a method call on the variable will raise a `NoMethodError`.
 
@@ -11,7 +9,9 @@ This can be achieved by using a safe navigation or adding a check for `nil`.
 
 Note: You do not need to explicitly initialize the variable, if you can make the program deal with the possible `nil` value. In particular, initializing the variable to `nil` will have no effect, as this is already the value of the variable. If `nil` is the only possible default value, you need to handle the `nil` value instead of initializing the variable.
 
-## Examples
+## Example
+
+### Incorrect Usage
 
 In the following code, the call to `create_file` may fail and then the call `f.close` will raise a `NoMethodError` since `f` will be `nil` at that point.
 
@@ -24,6 +24,8 @@ ensure
 end
 ```
 
+### Correct Usage
+
 We can fix this by using safe navigation:
 ```ruby
 def dump(x)
@@ -36,6 +38,5 @@ end
 
 ## References
 
-- https://www.rubyguides.com/: [Nil](https://www.rubyguides.com/2018/01/ruby-nil/)
-- https://ruby-doc.org/: [NoMethodError](https://ruby-doc.org/core-2.6.5/NoMethodError.html)
-
+- RubyGuides: [Everything You Need To Know About Nil](https://www.rubyguides.com/2018/01/ruby-nil/).
+- Ruby-Doc.org: [NoMethodError](https://ruby-doc.org/core-2.6.5/NoMethodError.html).