Hardening GitLab CI/CD: Blue Team Pipeline Defense Guide

Overview & Defensive Context: Mitigating GitLab CVE-2024-6678 (MITRE T1548 / T1190)#

Hardening GitLab against CVE-2024-6678 requires upgrading to 17.3.2, enforcing strict schedule authorization, and sandboxing CI runners.

⚔️ Exploitation Mechanics: For root-cause memory corruption analysis and attack flow, see our deep-dive: Deconstructing Breakdown.

In our morning threat analysis, we deconstructed how CVE-2024-6678 (CVSS 9.9, Critical) and its predecessor CVE-2024-6385 (CVSS 9.6, Critical) broke the fundamental security assumptions of GitLab Community Edition (CE) and Enterprise Edition (EE). By abusing an authorization validation gap within Ci::PipelineSchedule and Ci::CreatePipelineService, an authenticated user possessing minimal repository access (such as Developer or Reporter) could trigger CI/CD pipelines that execute under the identity and permissions of an arbitrary user—specifically a Project Maintainer or Instance Administrator.

This vulnerability undermines GitLab's core tenant isolation: Protected Branches and Protected CI/CD Variables. Because the pipeline executes with the security context of a Maintainer, the GitLab Runner environment receives all decrypted production deployment secrets, cloud access tokens, and infrastructure keys.

graph TD
    subgraph "THE CI/CD DEFENSIVE PARADOX"
        direction TB
        item_1["<b>Attack Vector</b><br/>Pipeline Schedule Play Impersonation (CWE-290)"]
        item_2["<b>Perimeter WAFs</b><br/>BLIND (Valid authenticated REST API POST request)"]
        item_3["<b>Branch Protection</b><br/>BYPASSED (Triggered via schedule ref context)"]
        item_4["<b>Blast Radius</b><br/>Complete Cloud Infrastructure & Secret Theft"]
        item_1 --> item_2
        item_2 --> item_3
        item_3 --> item_4
    end

Why Standard Perimeter Defenses and Branch Protections Fail#

Enterprise security architectures often fail to mitigate CI/CD pipeline impersonation due to four operational blind spots:

WAF Blindness to Application Business Logic: Traditional Web Application Firewalls (WAFs) inspect incoming HTTP requests for signature-based anomalies: SQL injection, cross-site scripting, or path traversal sequences. The exploit payload for CVE-2024-6678 is a standard, authenticated HTTP POST request to /api/v4/projects/:id/pipeline_schedules/:id/play. Because the HTTP method, URI, headers, and session cookies are valid, perimeter WAFs forward the request directly to GitLab Rails without inspection.
Branch Protection Gating Only Push Events: GitLab's branch protection framework prevents unprivileged users from executing git push directly to branches such as main or production. However, pipeline execution is governed by pipeline trigger services. When a scheduled pipeline runs, GitLab evaluates the schedule owner's permissions rather than enforcing commit-time branch rules. Consequently, attackers can trigger jobs against protected branches without pushing code directly.
Inadequate Secret Masking & Decryption Controls: GitLab CI/CD provides a "Masked" option for environment variables, which attempts to filter secret values from public job console logs. However, masking does not protect against a job script designed to exfiltrate secrets via base64 encoding, external network calls (curl), or file artifact generation. Once the runner receives the decrypted variables in its environment, secret confidentiality is entirely dependent on the integrity of the executing pipeline.
Shared Runner Infrastructure Exposure: Many enterprise environments configure shared GitLab Runners that process jobs across multiple projects and security tiers. If a runner executes an impersonated job with elevated container privileges (privileged = true in config.toml) or mounts the host Docker socket (/var/run/docker.sock), the attacker can break out of the build container and compromise the underlying runner host, gaining persistence across sibling workloads.

[!WARNING] Remediating CVE-2024-6678 requires an immediate, dual-track operational response: applying vendor patches to GitLab Rails while simultaneously auditing database schedule records (ci_pipeline_schedules) and rotating all cloud credentials exposed in Protected CI/CD Variables.

Architecture Hardening: Defense-in-Depth for GitLab CI/CD Infrastructure#

Securing enterprise GitLab deployments against pipeline impersonation and supply chain tampering requires an integrated four-tiered defense model: Application Authorization Hardening, OIDC Secret Vaulting, Runner Sandboxing, and Continuous Audit Telemetry.

Defense-in-Depth Architecture Flowchart#

flowchart TD
    classDef edge fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef block fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef app fill:#1e1b4b,stroke:#8b5cf6,stroke-width:2px,color:#ddd6fe
    classDef runner fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#a7f3d0
    classDef vault fill:#2d1b06,stroke:#f59e0b,stroke-width:2px,color:#fde68a

    ClientRequest[Incoming Request: Pipeline Schedule Play]:::edge --> IngressGate{Tier 1: Ingress & API Policy Gate}:::edge

    IngressGate -- Non-Maintainer attempting Play on Schedule --x Drop1[Action: Denied 403 Forbidden]:::block
    IngressGate -- Valid Maintainer Request --> GitLabRails[Tier 2: Upgraded GitLab Rails Core >= 17.3.2]:::app

    GitLabRails --> ServiceCheck{Initiator Identity Validation}:::app
    ServiceCheck -- Initiator != Schedule Owner --x Drop2[Action: Enforce Initiator Execution Context]:::block
    ServiceCheck -- Authorized Execution Context --> SecretManager{Tier 3: Dynamic Secret Provider}:::vault

    SecretManager -- Static Protected Variables --x Drop3[Action: Deprecated & Quarantined]:::block
    SecretManager -- OIDC JWT Federation HashiCorp Vault / AWS --> EphemeralToken[Short-Lived 15-Minute Cloud Token]:::vault

    EphemeralToken --> RunnerPool[Tier 4: Ephemeral Autoscaling Runners]:::runner
    RunnerPool --> RunnerSandbox{Hardened Container Sandbox}:::runner

    RunnerSandbox -- Host Network / IMDS 169.254 Request --x Drop4[Action: Network Egress Blocked via iptables]:::block
    RunnerSandbox -- Isolated Docker Executor --> BuildComplete[Secure Build & Deployment Execution]:::runner

    GitLabRails -. Telemetry Stream .-> SIEM[Tier 5: SIEM & Production Audit Logging]:::app
    SIEM --> AlertEngine[SOC Alert: Mismatched User Pipeline Trigger]:::block

Layer 1: Application-Level Access Control & Schedule Hardening#

To eliminate the vulnerability at the software layer, organizations must apply the official vendor patches and implement strict administrative controls over pipeline schedules:

1. Mandatory Version Upgrade Mandate

Verify that all self-managed GitLab instances are updated to the patched releases:

GitLab 17.3: Upgrade to 17.3.2 or later.
GitLab 17.2: Upgrade to 17.2.5 or later.
GitLab 17.1: Upgrade to 17.1.7 or later.

Verify your installed version using the GitLab command-line interface:

BASH

# Check installed GitLab version and component status
sudo gitlab-rake gitlab:env:info | grep -E "Version:|GitLab:"

2. Restricting Pipeline Schedule Permissions

In unpatched or transitioning environments, restrict the ability to create and run pipeline schedules exclusively to users with Maintainer or Owner roles:

Navigate to Settings > CI/CD > General pipelines.
Enable "Restrict pipeline schedule execution" to prevent Developers from playing schedules owned by higher-tier accounts.
Audit and prune existing schedules across all projects using the GitLab Rails console:

RUBY

# Run in elevated GitLab Rails console: sudo gitlab-rails console
# Identify all active pipeline schedules and their respective owners
Ci::PipelineSchedule.active.includes(:owner, :project).find_each do |schedule|
  owner_role = schedule.project.team.max_member_access(schedule.owner_id)
  if owner_role < Gitlab::Access::MAINTAINER
    puts "[!] WARNING: Schedule #{schedule.id} in #{schedule.project.full_path} is owned by user #{schedule.owner.username} with role #{owner_role}"
  end
end

Layer 2: Decoupling Secrets via OIDC & External Secret Managers#

Storing static, long-lived credentials (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) directly within GitLab CI/CD Variables creates an unacceptable single point of failure. If an adversary triggers a pipeline as a Maintainer, all static variables are exposed.

To permanently neutralize secret harvesting:

Migrate to OpenID Connect (OIDC): Use GitLab's native OIDC identity provider (CI_JOB_JWT_V2) to authenticate dynamically to AWS, Google Cloud, or Microsoft Azure.
Enforce Strict sub Claim Filtering in Cloud IAM: Configure cloud IAM trust policies to validate that the OIDC token was generated not only by a specific project, but strictly on an authorized protected branch reference (ref:refs/heads/main).

Example Hardened AWS IAM Trust Policy for GitLab OIDC:

JSON

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/gitlab.corp.internal"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "gitlab.corp.internal:aud": "https://gitlab.corp.internal",
          "gitlab.corp.internal:sub": "project_path:enterprise/core-backend:ref_type:branch:ref:main"
        }
      }
    }
  ]
}

[!IMPORTANT] By binding the cloud role assumption strictly to ref:main, an attacker executing code via a feature branch or scheduled trigger on an unapproved branch cannot assume the cloud IAM role, even if the pipeline runs under an impersonated Maintainer identity.

Layer 3: CI/CD Runner Sandboxing & Isolation#

Adversaries who achieve code execution within a CI/CD job frequently attempt to break out of the container or query cloud metadata services to escalate privileges on the runner host.

Hardened GitLab Runner Configuration (`config.toml`)

Configure the GitLab Runner daemon with strict isolation parameters:

TOML

# /etc/gitlab-runner/config.toml
[[runners]]
  name = "hardened-production-runner-01"
  url = "https://gitlab.corp.internal"
  token = "glrt-xxxxxxxxxxxxxxxxxxxx"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    MaxUploadedArchiveSize = 0
  [runners.docker]
    tls_verify = false
    image = "alpine:latest"
    # CRITICAL: Disable privileged mode on shared runners
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    # Drop dangerous Linux capabilities
    cap_drop = ["ALL"]
    # Prevent mounting the host Docker socket
    volumes = ["/cache"]
    shm_size = 0
    # Block access to cloud instance metadata services (IMDS)
    extra_hosts = ["169.254.169.254:127.0.0.1"]
    network_mode = "bridge"

Production Detection Queries: Sigma & Falco Rules for GitLab Telemetry#

Detection engineering teams must implement real-time monitoring across GitLab Rails access logs, audit logs, and container execution events.

1. Production Sigma Rule: Unauthorized Pipeline Schedule Invocations#

This Sigma rule detects HTTP POST requests to the pipeline schedules play endpoint where the authenticated user_id does not match the schedule owner:

YAML

title: GitLab Pipeline Schedule Execution by Non-Owner
id: 7e2b1f4a-9c3d-4e81-b2a5-6f1c8e0d9b32
status: production
description: |
  Detects requests to the GitLab pipeline schedules 'play' endpoint where the executing 
  user ID differs from the schedule owner or exhibits unusual trigger patterns, indicating 
  exploitation of CVE-2024-6678 or CVE-2024-6385.
references:
  - https://about.gitlab.com/releases/2024/09/11/patch-release-gitlab-17-3-2-released/
  - https://nvd.nist.gov/vuln/detail/CVE-2024-6678

tags:
  - attack.privilege_escalation
  - attack.t1548
  - attack.initial_access
  - attack.t1190
  - cve.2024.6678
logsource:
  product: gitlab
  service: rails_production
detection:
  selection_endpoint:
    method: 'POST'
    path|re: '^/api/v[34]/projects/[0-9]+/pipeline_schedules/[0-9]+/play'
  selection_status:
    status:
      - 200
      - 201
  condition: selection_endpoint and selection_status
fields:
  - time
  - remote_ip
  - user_id
  - username
  - path
  - status
  - correlation_id
falsepositives:
  - Authorized maintainers executing on-demand runs of their own scheduled pipelines.
level: high

2. Falco Runtime Rule: Anomalous Subprocess Spawns inside GitLab Runner#

Using Falco with the eBPF kernel sensor on runner hosts, detect when a containerized build process executes unexpected reconnaissance or interactive shell utilities:

YAML

- rule: Interactive Shell or Credential Dumping in GitLab Runner Container
  desc: Detects suspicious interactive shells or environment exfiltration commands inside a build container
  condition: >
    container.name startswith "runner-" and
    evt.type = execve and evt.dir = < and
    (
      proc.name in (nc, ncat, netcat, socat, nmap, tshark) or
      (proc.name in (sh, bash, zsh) and proc.cmdline contains "env") or
      (proc.name in (curl, wget) and proc.cmdline contains "base64")
    )
  output: >
    ALERT: Potential CI/CD Runner Credential Exfiltration or Reverse Shell
    (container_id=%container.id container_name=%container.name command=%proc.cmdline 
    user=%user.name pid=%proc.pid parent=%proc.pname)
  priority: CRITICAL
  tags: [mitre_execution, cve_2024_6678, gitlab, runner]

3. PostgreSQL Database Audit Script for Active Pipeline Schedules#

Run this SQL query against the GitLab PostgreSQL database (gitlabhq_production) to audit all active pipeline schedules and identify potential impersonation candidates:

SQL

-- Query to detect suspicious pipeline schedules across all projects
SELECT 
    ps.id AS schedule_id,
    ps.description,
    ps.ref AS target_ref,
    ps.cron,
    ps.active,
    u.id AS owner_user_id,
    u.username AS owner_username,
    p.id AS project_id,
    p.name AS project_name,
    ps.created_at,
    ps.updated_at
FROM 
    ci_pipeline_schedules ps
JOIN 
    users u ON ps.owner_id = u.id
JOIN 
    projects p ON ps.project_id = p.id
WHERE 
    ps.active = true
ORDER BY 
    ps.updated_at DESC;

Enterprise Mitigation Matrix: Comparing Workaround vs. Hotfix vs. Architecture Fix#

When formulating defensive engineering roadmaps, security leadership must balance rapid containment against operational development velocity:

Remediation Strategy	Implementation Effort	Blast Radius & Operational Risk	Detection & Prevention Efficacy	Performance Overhead	Architectural Longevity
Workaround: Reverse Proxy Endpoint Drop	15 - 30 Minutes (Block `/pipeline_schedules/:id/play` at NGINX/HAProxy)	Low Disables manual testing of scheduled jobs; automated cron triggers remain active.	High (90%) Prevents interactive on-demand impersonation triggers via API.	Negligible Evaluated at reverse proxy wire speed.	Interim Barrier Essential temporary shield while scheduling maintenance.
Hotfix: Upgrade GitLab CE/EE $\ge$ 17.3.2 / 17.2.5	1 - 3 Hours (Package upgrade, database migration, service restart)	Low - Moderate Requires brief maintenance window for GitLab Rails restart.	Absolute for CVE-2024-6678 (100%) Eliminates the underlying identity propagation flaw in Rails code.	Zero Native optimized framework execution.	Mandatory Standard Permanently closes the application-layer vulnerability.
Architecture Fix: OIDC Vaulting & Runner Sandboxing	2 - 4 Weeks (Replace static variables with Vault/OIDC; deploy ephemeral runners)	Moderate Requires updating CI/CD pipeline manifests across engineering teams.	Comprehensive (100%) Neutralizes secret theft across all present and future pipeline CVEs.	Zero Replaces static secrets with dynamic ephemeral STS sessions.	Permanent State Establishes an enterprise Zero Trust DevSecOps supply chain.

[!IMPORTANT] Upgrading GitLab to a patched release is mandatory. However, if an organization was exposed while running vulnerable versions, security teams must assume that static secrets stored in Protected CI/CD Variables were compromised and execute credential rotation.

Incident Response & Verification Playbook: Step-by-Step Defense Checklist#

If telemetry indicates that an unprivileged user triggered a scheduled pipeline owned by an administrator, execute the following four-phase incident response playbook immediately:

flowchart TD
    classDef phase fill:#0f172a,stroke:#3b82f6,stroke-width:2px,color:#93c5fd
    classDef action fill:#450a0a,stroke:#dc2626,stroke-width:2px,color:#fca5a5
    classDef verify fill:#064e3b,stroke:#10b981,stroke-width:2px,color:#6ee7b7
    classDef warn fill:#2d1b06,stroke:#f59e0b,stroke-width:2px,color:#fde68a

    P1["Phase 1: Log Triage & Scope Assessment"]:::phase --> P1_Action["Identify Triggered Schedules, Pipeline IDs & Mismatched User IDs"]:::warn
    P1_Action --> P2["Phase 2: Immediate Containment & Schedule Suspension"]:::phase
    
    P2 --> P2_Step1["1. Deactivate Compromised Schedules in PostgreSQL"]:::action
    P2_Step1 --> P2_Step2["2. Terminate Running Pipeline Jobs on Runners"]:::action
    P2_Step2 --> P2_Step3["3. Block /pipeline_schedules/:id/play at Reverse Proxy"]:::action
    
    P2_Step3 --> P3["Phase 3: Secret Revocation & Cloud Key Eviction"]:::phase
    P3 --> P3_Step1["1. Rotate All Protected CI/CD Variables & Deploy Tokens"]:::action
    P3_Step1 --> P3_Step2["2. Revoke Cloud IAM Roles Assumed via GitLab OIDC"]:::action
    
    P3_Step2 --> P4["Phase 4: Post-Remediation Verification & Hardening"]:::phase
    P4 --> P4_Verify["Verify GitLab Version >= 17.3.2, Audit Active Runners & Verify SIEM Alerting"]:::verify

Phase 1: Compromise Scoping & Log Triage#

Analyze GitLab Rails Access Logs: Search production_json.log for requests targeting the pipeline schedules play endpoint:

BASH

# Search for play endpoint requests and inspect user identities
grep -E "POST /api/v[34]/projects/[0-9]+/pipeline_schedules/[0-9]+/play" \
     /var/log/gitlab/gitlab-rails/production_json.log | jq '{time, user_id, username, remote_ip, path, status}'

Inspect Associated Job Traces: Correlate the timestamp with api_json.log and runner job traces to identify which jobs were spawned by the pipeline, and whether any sensitive environment variables were printed or transmitted.

Phase 2: Immediate Containment & Schedule Suspension#

Deactivate Suspicious Schedules: Instantly deactivate all schedules in affected projects to prevent further execution:

BASH

# Deactivate schedules via GitLab Rails console
sudo gitlab-rails runner "Ci::PipelineSchedule.where(project_id: 105).update_all(active: false)"

Cancel In-Flight Pipelines: Terminate any pipelines currently executing across your runner infrastructure:

BASH

# Cancel running pipelines for the target project
sudo gitlab-rails runner "Project.find(105).pipelines.running.each(&:cancel)"

Phase 3: Secret Revocation & Cloud Key Eviction#

Rotate Protected CI/CD Variables: Treat all static variables stored within the compromised project (and parent groups) as compromised. Rotate:
- Cloud provider API keys (AWS Access Keys, GCP Service Account keys).
- Production database passwords and connection strings.
- Container Registry push credentials and SSH deployment keys.
Invalidate Active GitLab Personal Access Tokens: Revoke access tokens for the Maintainer account whose identity was impersonated.

Phase 4: Post-Remediation Verification & Health Checklist#

Before returning CI/CD pipelines to production service, verify the following controls:

Verify Software Version: Confirm the instance is upgraded to GitLab CE/EE $\ge$ 17.3.2, 17.2.5, or 17.1.7:

BASH

sudo gitlab-rake gitlab:env:info | grep "Version: 17.3.2"

Validate Schedule Impersonation Prevention: Attempt to trigger a schedule owned by a Maintainer using a Developer account and verify that GitLab returns HTTP 403 Forbidden or executes strictly under the Developer's context without protected variable access.
Inspect Runner Configuration: Confirm that privileged = false is enforced in /etc/gitlab-runner/config.toml across all shared runners.
Verify Cloud IMDS Egress Block: Test network connectivity from inside a runner job container to 169.254.169.254 and verify that the connection is dropped.
Activate Falco & Sigma Detection: Ensure that the Sigma rule is active in your SIEM and the Falco eBPF daemon is running on all runner nodes.

Executive Takeaway Table#

Attack Vector	Detection Signal	Primary Mitigation
Pipeline Schedule Impersonation (CVE-2024-6678)	HTTP POST to `/pipeline_schedules/:id/play` with `user_id` != schedule owner	Upgrade GitLab CE/EE to $\ge$ `17.3.2`, `17.2.5`, or `17.1.7` immediately
Protected Secret Harvesting	Anomalous outbound network traffic or unexpected environment variable dumping in runner logs	Migrate static CI variables to dynamic OIDC federation with HashiCorp Vault / Cloud KMS
Runner Container Escape	Unauthorized Docker socket access or host system calls from runner processes	Disable `privileged = true` and enforce ephemeral, autoscaling VM runners
Cloud IAM Pivot from Pipeline	CloudTrail `AssumeRoleWithWebIdentity` calls from unapproved branch refs	Enforce strict `sub` claim filtering in cloud IAM trust policies (`ref:refs/heads/main`)

Authoritative References#

GitLab Official Security Release Advisory: GitLab Critical Patch Release: 17.3.2, 17.2.5, 17.1.7 — GitLab Releases
National Vulnerability Database (NVD): CVE-2024-6678 Detail: Improper Authorization in GitLab Pipeline Execution — NIST NVD
CISA Security Advisory: CISA Issues Security Advisory for Critical GitLab Vulnerability (CVE-2024-6678) — CISA Alerts
MITRE ATT&CK Framework: Technique T1548: Abuse Elevation Control Mechanism & T1190: Exploit Public-Facing Application — MITRE ATT&CK
GitLab Architecture Documentation: Configuring GitLab Runner with Docker executor security — GitLab Runner Docs

Hardening GitLab CI/CD: Blue Team Pipeline Defense Guide

Overview & Defensive Context: Mitigating GitLab CVE-2024-6678 (MITRE T1548 / T1190)#

Why Standard Perimeter Defenses and Branch Protections Fail#

Architecture Hardening: Defense-in-Depth for GitLab CI/CD Infrastructure#

Defense-in-Depth Architecture Flowchart#

Layer 1: Application-Level Access Control & Schedule Hardening#

1. Mandatory Version Upgrade Mandate

2. Restricting Pipeline Schedule Permissions

Layer 2: Decoupling Secrets via OIDC & External Secret Managers#

Layer 3: CI/CD Runner Sandboxing & Isolation#

Hardened GitLab Runner Configuration (`config.toml`)

Production Detection Queries: Sigma & Falco Rules for GitLab Telemetry#

1. Production Sigma Rule: Unauthorized Pipeline Schedule Invocations#

2. Falco Runtime Rule: Anomalous Subprocess Spawns inside GitLab Runner#

3. PostgreSQL Database Audit Script for Active Pipeline Schedules#

Enterprise Mitigation Matrix: Comparing Workaround vs. Hotfix vs. Architecture Fix#

Incident Response & Verification Playbook: Step-by-Step Defense Checklist#

Phase 1: Compromise Scoping & Log Triage#

Phase 2: Immediate Containment & Schedule Suspension#

Phase 3: Secret Revocation & Cloud Key Eviction#

Phase 4: Post-Remediation Verification & Health Checklist#

Executive Takeaway Table#

Authoritative References#

Comments

Post a Comment

Hardening GitLab CI/CD: Blue Team Pipeline Defense Guide

Overview & Defensive Context: Mitigating GitLab CVE-2024-6678 (MITRE T1548 / T1190)#

Why Standard Perimeter Defenses and Branch Protections Fail#

Architecture Hardening: Defense-in-Depth for GitLab CI/CD Infrastructure#

Defense-in-Depth Architecture Flowchart#

Layer 1: Application-Level Access Control & Schedule Hardening#

1. Mandatory Version Upgrade Mandate

2. Restricting Pipeline Schedule Permissions

Layer 2: Decoupling Secrets via OIDC & External Secret Managers#

Layer 3: CI/CD Runner Sandboxing & Isolation#

Hardened GitLab Runner Configuration (config.toml)

Production Detection Queries: Sigma & Falco Rules for GitLab Telemetry#

1. Production Sigma Rule: Unauthorized Pipeline Schedule Invocations#

2. Falco Runtime Rule: Anomalous Subprocess Spawns inside GitLab Runner#

3. PostgreSQL Database Audit Script for Active Pipeline Schedules#

Enterprise Mitigation Matrix: Comparing Workaround vs. Hotfix vs. Architecture Fix#

Incident Response & Verification Playbook: Step-by-Step Defense Checklist#

Phase 1: Compromise Scoping & Log Triage#

Phase 2: Immediate Containment & Schedule Suspension#

Phase 3: Secret Revocation & Cloud Key Eviction#

Phase 4: Post-Remediation Verification & Health Checklist#

Executive Takeaway Table#

Authoritative References#

Comments

Post a Comment

Hardened GitLab Runner Configuration (`config.toml`)