Skip to content
This repository was archived by the owner on Nov 3, 2025. It is now read-only.
This repository was archived by the owner on Nov 3, 2025. It is now read-only.

[fix]: Code scanning alert: Implementation of Explicit Permissions in validate-infra.yml Workflow #54

@glaucia86

Description

@glaucia86

Tracking issue for:


Implementation of Explicit Permissions in validate-infra.yml Workflow

Executive Summary

CodeQL has detected an actions/missing-workflow-permissions security violation in the infrastructure validation workflow. The workflow lacks explicitly defined permissions, resulting in the inheritance of default repository permissions, which violates the principle of least privilege and potentially exposes the repository to security risks.

Technical Context

Identified Vulnerability

The CodeQL static code analyzer identified that the .github/workflows/validate-infra.yml file does not explicitly define the permission scope for the GITHUB_TOKEN used during action execution.

Security Implications

When permissions are not explicitly defined in a workflow:

  • The workflow inherits default permissions configured at the repository level
  • Repositories created before February 2023 or repositories within organizations may have default permissions set to read-write for all scopes
  • This configuration violates the principle of least privilege, granting excessive access to the token used during workflow execution
  • It compromises the Zero Trust security posture by failing to restrict the token's privilege perimeter

Current Workflow

The validate-infra.yml workflow performs the following operations:

  1. Code checkout
  2. Bicep file building for linting
  3. Microsoft Security DevOps analysis execution
  4. SARIF results upload to GitHub Security tab

Required Permissions

Following analysis of the workflow, the only required permissions are:

  • contents: read - For code checkout execution
  • security-events: write - For security results upload

Solution

Implementation Steps

  1. Open the .github/workflows/validate-infra.yml file
  2. Add explicit permissions declaration at the workflow level (immediately after the on: section)
  3. Define only the minimum permissions necessary for workflow execution
  4. Save and commit the changes

Detailed Implementation

Add the following code block to the .github/workflows/validate-infra.yml file after the event declaration:

permissions:
  contents: read        # Minimum permission for code checkout
  security-events: write # Permission to submit security results

Complete Workflow With Changes

name: Validate Infrastructure

on:
  push:
    paths:
      - 'infra/**'

# Added explicit permissions
permissions:
  contents: read
  security-events: write

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build Bicep for linting
        uses: azure/CLI@v2
        with:
          inlineScript: az config set bicep.use_binary_from_path=false && az bicep build -f infra/main.bicep --stdout

      - name: Run Microsoft Security DevOps Analysis
        uses: microsoft/security-devops-action@v1
        id: msdo
        continue-on-error: true
        with:
          tools: templateanalyzer

      - name: Upload alerts to Security tab
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: ${{ steps.msdo.outputs.sarifFile }}

Alternative: Job-Level Permissions

If the workflow contains multiple jobs with distinct permission requirements, permissions can be defined at the job level:

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      security-events: write
    steps:
      # job steps

Technical Justification

The implementation of explicit and granular permissions:

  1. Principle of Least Privilege: Limits the scope of the GITHUB_TOKEN to strictly necessary permissions
  2. Defense in Depth: Creates an additional protection layer, mitigating potential impact in case of pipeline compromise
  3. Reduced Attack Surface: Decreases the available attack vector in case of vulnerabilities in third-party actions
  4. Security Governance: Aligns the workflow with security best practices recommended by GitHub and NIST
  5. Traceability: Makes required permissions explicit, facilitating security audits

References

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions