diff --git a/.github/CUSTOM-AGENTS.md b/.github/CUSTOM-AGENTS.md index c39903af3..683ad7414 100644 --- a/.github/CUSTOM-AGENTS.md +++ b/.github/CUSTOM-AGENTS.md @@ -355,7 +355,7 @@ Users are responsible for verifying their repository's `.gitignore` configuratio **Subagents:** Codebase Profiler, Skill Assessor, Finding Deep Verifier, Report Generator -**Critical:** Orchestrator-only pattern. Delegates codebase profiling, skill assessment, adversarial finding verification, and report generation to specialized subagents. Uses OWASP skills (`owasp-agentic`, `owasp-llm`, `owasp-top-10`) for vulnerability references. Supports incremental comparison with prior scan reports. +**Critical:** Orchestrator-only pattern. Delegates codebase profiling, skill assessment, adversarial finding verification, and report generation to specialized subagents. Uses OWASP skills (`owasp-agentic`, `owasp-llm`, `owasp-top-10`, `owasp-cicd`) for vulnerability references. Supports incremental comparison with prior scan reports. ### code-review-functional diff --git a/.github/agents/security/security-reviewer.agent.md b/.github/agents/security/security-reviewer.agent.md index b4487e708..40a4970ff 100644 --- a/.github/agents/security/security-reviewer.agent.md +++ b/.github/agents/security/security-reviewer.agent.md @@ -96,7 +96,7 @@ Report path pattern (plan): `.copilot-tracking/security/{{YYYY-MM-DD}}/plan-risk Sequence number resolution: Determine `{{NNN}}` by listing existing reports in the date directory, extracting the highest sequence number, incrementing by one, and zero-padding to three digits. Start at `001` when no reports exist. -Skill resolution: Read the applicable OWASP skill (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`) to access vulnerability references. Follow the skill's normative reference links to load vulnerability reference documents. +Skill resolution: Read the applicable OWASP skill (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`, `owasp-cicd`) to access vulnerability references. Follow the skill's normative reference links to load vulnerability reference documents. ### Subagents @@ -112,6 +112,7 @@ Skill resolution: Read the applicable OWASP skill (e.g., `owasp-top-10`, `owasp- * owasp-agentic * owasp-llm * owasp-top-10 +* owasp-cicd ## Subagent Prompt Templates diff --git a/.github/agents/security/subagents/codebase-profiler.agent.md b/.github/agents/security/subagents/codebase-profiler.agent.md index 9b0075578..742e9bdfb 100644 --- a/.github/agents/security/subagents/codebase-profiler.agent.md +++ b/.github/agents/security/subagents/codebase-profiler.agent.md @@ -31,7 +31,7 @@ Scan the repository to identify its technology stack and determine which OWASP s ## Constants -Skill resolution: Read the applicable OWASP skill by name (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`). +Skill resolution: Read the applicable OWASP skill by name (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`, `owasp-cicd`). ### Technology Signals @@ -51,6 +51,14 @@ owasp-top-10: - "REST API endpoints" - "Server-side templates" - "Web framework config (Express, Django, Flask, Rails, Spring)" +owasp-cicd: + - "CI/CD pipeline definitions" + - "Build scripts" + - "Deployment configurations" + - ".github/workflows/" + - "Jenkinsfile" + - ".gitlab-ci.yml" + - "azure-pipelines.yml" ``` ## Codebase Profile Format diff --git a/.github/agents/security/subagents/finding-deep-verifier.agent.md b/.github/agents/security/subagents/finding-deep-verifier.agent.md index 7a87afbd8..a9b2e44c4 100644 --- a/.github/agents/security/subagents/finding-deep-verifier.agent.md +++ b/.github/agents/security/subagents/finding-deep-verifier.agent.md @@ -31,7 +31,7 @@ Perform deep adversarial verification of all FAIL and PARTIAL findings for a sin ## Constants -Skill resolution: Read the applicable OWASP skill by name (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`). Follow the skill's normative reference links to access vulnerability references. +Skill resolution: Read the applicable OWASP skill by name (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`, `owasp-cicd`). Follow the skill's normative reference links to access vulnerability references. Verdict values: CONFIRMED, DISPROVED, DOWNGRADED. diff --git a/.github/agents/security/subagents/skill-assessor.agent.md b/.github/agents/security/subagents/skill-assessor.agent.md index 1005b7ab7..4dc7eed56 100644 --- a/.github/agents/security/subagents/skill-assessor.agent.md +++ b/.github/agents/security/subagents/skill-assessor.agent.md @@ -30,7 +30,7 @@ Assess exactly one OWASP skill per invocation. Read all vulnerability references ## Constants -Skill resolution: Read the applicable OWASP skill by name (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`). Follow the skill's normative reference links to access the vulnerability index and individual vulnerability references. +Skill resolution: Read the applicable OWASP skill by name (e.g., `owasp-top-10`, `owasp-llm`, `owasp-agentic`, `owasp-cicd`). Follow the skill's normative reference links to access the vulnerability index and individual vulnerability references. ### Status Values diff --git a/.github/prompts/security/security-review.prompt.md b/.github/prompts/security/security-review.prompt.md index 94d8201cc..476876adf 100644 --- a/.github/prompts/security/security-review.prompt.md +++ b/.github/prompts/security/security-review.prompt.md @@ -2,7 +2,7 @@ name: security-review agent: Security Reviewer description: "Runs an OWASP vulnerability assessment against the current codebase - Brought to you by microsoft/hve-core" -argument-hint: "[scope=path/to/dir] [mode={audit|diff|plan}] [targetSkill={owasp-top-10|owasp-llm|owasp-agentic}]" +argument-hint: "[scope=path/to/dir] [mode={audit|diff|plan}] [targetSkill={owasp-top-10|owasp-llm|owasp-agentic|owasp-cicd}]" --- # Vulnerability Scan @@ -13,7 +13,7 @@ argument-hint: "[scope=path/to/dir] [mode={audit|diff|plan}] [targetSkill={owasp ## Inputs * ${input:mode:audit}: (Optional, defaults to audit) Scanning mode: `audit`, `diff`, or `plan`. -* ${input:targetSkill}: (Optional) Single OWASP skill to assess. Bypasses codebase profiling when provided. Available skills: `owasp-agentic`, `owasp-llm`, `owasp-top-10`. +* ${input:targetSkill}: (Optional) Single OWASP skill to assess. Bypasses codebase profiling when provided. Available skills: `owasp-agentic`, `owasp-llm`, `owasp-top-10`, `owasp-cicd`. * ${input:scope}: (Optional) Specific directories or paths to focus on. When omitted, assesses the full codebase. * ${input:plan}: (Optional) Implementation plan document path. Inferred from attached files or conversation context when not provided. diff --git a/.github/skills/security/owasp-cicd/SKILL.md b/.github/skills/security/owasp-cicd/SKILL.md new file mode 100644 index 000000000..763a090e8 --- /dev/null +++ b/.github/skills/security/owasp-cicd/SKILL.md @@ -0,0 +1,45 @@ +--- +name: owasp-cicd +description: OWASP CI/CD Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in continuous integration and continuous delivery environments - Brought to you by microsoft/hve-core. +license: CC-BY-SA-4.0 +user-invocable: false +metadata: + authors: "OWASP CI/CD Security Project" + spec_version: "1.0" + framework_revision: "1.0.0" + last_updated: "2026-02-16" + skill_based_on: "https://github.com/chris-buckley/agnostic-prompt-standard" + content_based_on: "https://owasp.org/www-project-top-10-ci-cd-security-risks/" +--- + +# OWASP CI/CD Top 10 — Skill Entry + +This `SKILL.md` is the **entrypoint** for the OWASP CI/CD Top 10 skill. + +The skill encodes the **OWASP Top 10 CI/CD Security Risks** as structured, machine-readable references +that an agent can query to identify, assess, and remediate CI/CD pipeline security risks. + +## Normative references (CI/CD Top 10) + +1. [00 Vulnerability Index](references/00-vulnerability-index.md) +2. [01 Insufficient Flow Control Mechanisms](references/01-insufficient-flow-control-mechanisms.md) +3. [02 Inadequate Identity and Access Management](references/02-inadequate-identity-access-management.md) +4. [03 Dependency Chain Abuse](references/03-dependency-chain-abuse.md) +5. [04 Poisoned Pipeline Execution](references/04-poisoned-pipeline-execution.md) +6. [05 Insufficient PBAC](references/05-insufficient-pbac.md) +7. [06 Insufficient Credential Hygiene](references/06-insufficient-credential-hygiene.md) +8. [07 Insecure System Configuration](references/07-insecure-system-configuration.md) +9. [08 Ungoverned Usage of 3rd Party Services](references/08-ungoverned-usage-of-3rd-party-services.md) +10. [09 Improper Artifact Integrity Validation](references/09-improper-artifact-integrity-validation.md) +11. [10 Insufficient Logging and Visibility](references/10-insufficient-logging-visibility.md) + +## Skill layout + +* `SKILL.md` — this file (skill entrypoint). +* `references/` — the CI/CD Top 10 normative documents. + * `00-vulnerability-index.md` — index of all vulnerability identifiers, categories, and cross-references. + * `01` through `10` — one document per vulnerability aligned with OWASP CI/CD Security numbering. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/00-vulnerability-index.md b/.github/skills/security/owasp-cicd/references/00-vulnerability-index.md new file mode 100644 index 000000000..5801da8f9 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/00-vulnerability-index.md @@ -0,0 +1,82 @@ +--- +title: 'OWASP CI/CD Top 10 Vulnerability Index' +description: Index of OWASP Top 10 CI/CD Security Risks (2025) vulnerability identifiers, categories, and cross-references +--- + +# 00 Vulnerability Index + +This document provides the index for the OWASP CI/CD Security Top 10 vulnerabilities. +Each entry includes its identifier, title, and primary category. + +## Vulnerability catalog + +| ID | Title | Category | +|---|---|---| +| CICD-SEC-1:2025 | Insufficient Flow Control Mechanisms | Flow Control | +| CICD-SEC-2:2025 | Inadequate Identity and Access Management | Identity Management | +| CICD-SEC-3:2025 | Dependency Chain Abuse | Supply Chain | +| CICD-SEC-4:2025 | Poisoned Pipeline Execution | Pipeline Security | +| CICD-SEC-5:2025 | Insufficient PBAC | Access Controls | +| CICD-SEC-6:2025 | Insufficient Credential Hygiene | Credential Management | +| CICD-SEC-7:2025 | Insecure System Configuration | Configuration Management | +| CICD-SEC-8:2025 | Ungoverned Usage of 3rd Party Services | Third-Party Governance | +| CICD-SEC-9:2025 | Improper Artifact Integrity Validation | Artifact Integrity | +| CICD-SEC-10:2025 | Insufficient Logging and Visibility | Logging and Visibility | + +## Cross-reference matrix + +Each vulnerability document follows a consistent structure: + +1. Description — what the vulnerability is and how it manifests in CI/CD environments. +2. Risk — concrete consequences of exploitation and business impact. +3. Vulnerability checklist — indicators that the environment is exposed. +4. Prevention controls — defensive measures and rectification steps. +5. Example attack scenarios — realistic exploitation narratives. +6. Detection guidance — signals and methods to identify exposure. +7. Remediation — immediate and long-term actions to contain and resolve. + +## Category groupings + +### Flow Control + +* CICD-SEC-1:2025 Insufficient Flow Control Mechanisms + +### Identity Management + +* CICD-SEC-2:2025 Inadequate Identity and Access Management + +### Supply Chain + +* CICD-SEC-3:2025 Dependency Chain Abuse + +### Pipeline Security + +* CICD-SEC-4:2025 Poisoned Pipeline Execution + +### Access Controls + +* CICD-SEC-5:2025 Insufficient PBAC + +### Credential Management + +* CICD-SEC-6:2025 Insufficient Credential Hygiene + +### Configuration Management + +* CICD-SEC-7:2025 Insecure System Configuration + +### Third-Party Governance + +* CICD-SEC-8:2025 Ungoverned Usage of 3rd Party Services + +### Artifact Integrity + +* CICD-SEC-9:2025 Improper Artifact Integrity Validation + +### Logging and Visibility + +* CICD-SEC-10:2025 Insufficient Logging and Visibility + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/01-insufficient-flow-control-mechanisms.md b/.github/skills/security/owasp-cicd/references/01-insufficient-flow-control-mechanisms.md new file mode 100644 index 000000000..56901a319 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/01-insufficient-flow-control-mechanisms.md @@ -0,0 +1,103 @@ +--- +title: 'CICD-SEC-1: Insufficient Flow Control Mechanisms' +description: OWASP CI/CD Top 10 reference for insufficient flow control vulnerabilities including unauthorized code changes and deployment bypass +--- + +# 01 Insufficient Flow Control Mechanisms + +Identifier: CICD-SEC-1:2025 +Category: Flow Control + +## Description + +Insufficient flow control mechanisms refer to the ability of an attacker that has obtained permissions +to a system within the CI/CD process (SCM, CI, artifact repository) to single-handedly push malicious +code or artifacts down the pipeline, due to a lack of mechanisms that enforce additional approval or +review. + +CI/CD flows are designed for speed. New code can be created on a developer's machine and reach +production within minutes, often with full reliance on automation and minimal human involvement. +Since CI/CD processes are the highway to highly gated and secured production environments, +organizations must introduce measures and controls to ensure that no single entity (human or +application) can push code or artifacts through the pipeline without undergoing a strict set of +reviews and approvals. + +## Risk + +* An attacker with access to the SCM, CI, or downstream systems can deploy malicious artifacts + potentially all the way to production without any approval or review. +* Pushing code to a repository branch that is automatically deployed through the pipeline to + production. +* Abusing auto-merge rules that automatically merge pull requests meeting a predefined set of + requirements, pushing malicious unreviewed code. +* Abusing insufficient branch protection rules, such as excluding specific users or branches, to + bypass protections and push malicious unreviewed code. +* Uploading artifacts to a repository in the guise of a legitimate artifact created by the build + environment, which may be picked up by a deploy pipeline and deployed to production. +* Directly changing application code or infrastructure in production without additional verification. + +## Vulnerability checklist + +* Repository branches hosting production code lack branch protection rules. +* Users or branches are excluded from branch protection rules. +* Auto-merge rules exist that can be bypassed or manipulated. +* Pipeline triggers do not require additional approval for production deployments. +* Artifacts uploaded by non-CI service accounts are not blocked or reviewed before flowing through + the pipeline. +* No drift detection exists between code running in production and its CI/CD origin. +* Single accounts have both push-to-repository and trigger-deployment permissions. + +## Prevention controls + +1. Configure branch protection rules on branches hosting code used in production and other + sensitive systems. +2. Avoid excluding user accounts or branches from branch protection rules. +3. Ensure accounts with permission to push unreviewed code do not also have permission to trigger + deployment pipelines connected to the repository. +4. Limit auto-merge rule usage and ensure they apply to the minimal number of contexts. +5. Review auto-merge rule code thoroughly to prevent bypass and avoid importing third-party code + in the auto-merge process. +6. Prevent accounts from triggering production build and deployment pipelines without additional + approval or review. +7. Allow artifacts to flow through the pipeline only when created by a pre-approved CI service + account. +8. Detect and prevent drifts between code running in production and its CI/CD origin, and modify + any resource that contains a drift. + +## Example attack scenarios + +### Scenario A — Unprotected branch deployment + +An attacker gains access to a developer account on the SCM. The main branch lacks branch protection +rules. The attacker pushes malicious code directly to the main branch, triggering an automated +pipeline that deploys the code to production without any review or approval gate. + +### Scenario B — Auto-merge rule bypass + +An organization uses auto-merge rules to merge pull requests that pass automated checks. An attacker +crafts a pull request that satisfies the auto-merge criteria while containing a malicious payload +hidden in an overlooked file type. The PR is automatically merged and deployed to production without +human review. + +## Detection guidance + +* Audit branch protection rule configurations across all repositories hosting production code. +* Review auto-merge rule logic and history of auto-merged pull requests for anomalies. +* Monitor pipeline triggers and correlate them with code review and approval records. +* Detect configuration drifts between deployed resources and their CI/CD source definitions. +* Alert on artifacts flowing through deployment pipelines that were not produced by approved CI + service accounts. + +## Remediation + +* Enable and enforce branch protection rules on all branches linked to production deployments. +* Remove all user and branch exclusions from branch protection rules. +* Separate push-to-repository and trigger-deployment permissions across distinct accounts. +* Audit and harden all auto-merge rules, removing those that are overly permissive. +* Implement artifact provenance validation to ensure only CI-produced artifacts enter deploy + pipelines. +* Deploy drift detection tooling to identify and alert on unauthorized production changes. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/02-inadequate-identity-access-management.md b/.github/skills/security/owasp-cicd/references/02-inadequate-identity-access-management.md new file mode 100644 index 000000000..f42a51e9a --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/02-inadequate-identity-access-management.md @@ -0,0 +1,108 @@ +--- +title: 'CICD-SEC-2: Inadequate Identity and Access Management' +description: OWASP CI/CD Top 10 reference for identity and access management vulnerabilities including overprivileged accounts and stale permissions +--- + +# 02 Inadequate Identity and Access Management + +Identifier: CICD-SEC-2:2025 +Category: Identity Management + +## Description + +Inadequate identity and access management risks stem from the difficulties in managing the vast +amount of identities spread across the different systems in the engineering ecosystem, from source +control to deployment. The existence of poorly managed identities, both human and programmatic +accounts, increases the potential and the extent of damage of their compromise. + +Software delivery processes consist of multiple systems connected together with the aim of moving +code and artifacts from development to production. Each system provides multiple methods of access +and integration (username and password, personal access tokens, marketplace applications, OAuth +applications, plugins, SSH keys). The different types of accounts and methods of access can +potentially have their own unique provisioning method, set of security policies, and authorization +model. This complexity creates challenges in managing identities throughout the entire identity +lifecycle and ensuring their permissions are aligned with the principle of least privilege. + +Major concerns include overly permissive identities, stale identities that are no longer active, +local identities not federated with a centralized identity provider, external identities registered +with unmanaged email domains or belonging to external collaborators, self-registered identities +with overly broad default permissions, and shared identities used across multiple humans or +applications. + +## Risk + +* Compromising nearly any user account on any CI/CD system could grant powerful capabilities to + the environment and serve as a path into the production environment. +* Hundreds or thousands of identities across the ecosystem, paired with a lack of strong IAM + practices and overly permissive accounts, drastically expand the attack surface. +* Stale accounts remain valid entry points for attackers long after the original user has departed. +* Local accounts bypass centralized security policies including MFA enforcement and lockout rules. +* External collaborator accounts reduce overall security to the level of the external party's + environment. +* Shared identities eliminate accountability and expand credential exposure footprint. + +## Vulnerability checklist + +* Human or programmatic accounts have permissions beyond what is required for their role. +* Inactive accounts exist that have not been disabled or removed within the acceptable period. +* Local user accounts exist on CI/CD systems that are not federated with a centralized IdP. +* Employees use personal email addresses or domains not owned by the organization. +* External collaborators have access without predetermined expiry dates. +* Self-registration is enabled on CI/CD systems with non-zero default permissions. +* Shared accounts are in use across multiple humans or applications. +* No periodic review process exists for identity permissions across the ecosystem. + +## Prevention controls + +1. Conduct continuous analysis and mapping of all identities across all systems within the + engineering ecosystem, covering all methods of programmatic access. +2. Remove permissions not necessary for the ongoing work of each identity across all systems. +3. Determine an acceptable period for disabling or removing stale accounts and enforce it. +4. Avoid creating local user accounts; manage identities using a centralized identity provider. +5. Continuously map all external collaborators and ensure their identities follow least privilege, + with predetermined expiry dates for both human and programmatic accounts. +6. Prevent employees from using personal email addresses or non-organization-owned domains on + CI/CD platforms. +7. Disable self-registration on CI/CD systems and grant permissions on an as-needed basis. +8. Avoid granting base permissions to all users or large automatically-assigned groups. +9. Avoid using shared accounts; create dedicated accounts for each specific context with exact + required permissions. + +## Example attack scenarios + +### Scenario A — Stale account compromise + +An engineer leaves the organization but their accounts on the SCM and CI system are not +deprovisioned. An attacker compromises the former engineer's credentials through a credential +stuffing attack. The stale account still has write access to production repositories, allowing +the attacker to push malicious code through the pipeline. + +### Scenario B — Overly permissive self-registration + +A self-managed CI system allows self-registration. New accounts are assigned a base set of +permissions that includes access to pipeline configurations and build logs. An attacker +self-registers, gains access to the system, and discovers secrets exposed in build logs, which +they use to access production cloud environments. + +## Detection guidance + +* Periodically enumerate all identities across SCM, CI, artifact repositories, and deployment + systems, checking for stale, overly permissive, or shared accounts. +* Monitor for logins from non-organization-owned email domains. +* Audit self-registration settings and default permission assignments. +* Alert on identity creation events and permission escalation events across CI/CD systems. +* Review external collaborator access lists and expiration dates. + +## Remediation + +* Deprovision all stale accounts across every CI/CD system. +* Federate all local accounts to the centralized identity provider. +* Enforce MFA on all human accounts across all CI/CD systems. +* Remove base permissions from self-registered or automatically-assigned groups. +* Replace all shared accounts with dedicated, individually-scoped accounts. +* Establish automated workflows to disable external collaborator access upon contract expiry. +* Implement periodic access reviews with mandatory re-certification of identity permissions. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/03-dependency-chain-abuse.md b/.github/skills/security/owasp-cicd/references/03-dependency-chain-abuse.md new file mode 100644 index 000000000..018f848e6 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/03-dependency-chain-abuse.md @@ -0,0 +1,111 @@ +--- +title: 'CICD-SEC-3: Dependency Chain Abuse' +description: OWASP CI/CD Top 10 reference for dependency chain abuse vulnerabilities including dependency confusion and typosquatting attacks +--- + +# 03 Dependency Chain Abuse + +Identifier: CICD-SEC-3:2025 +Category: Supply Chain + +## Description + +Dependency chain abuse risks refer to an attacker's ability to abuse flaws relating to how +engineering workstations and build environments fetch code dependencies. Dependency chain abuse +results in a malicious package inadvertently being fetched and executed locally when pulled. + +Managing dependencies and external packages is increasingly complex given the total number of +systems involved across all development contexts. Packages are fetched using dedicated clients +per programming language, typically from a combination of self-managed package repositories and +language-specific SaaS repositories. Inadequate configurations may cause an engineer or the build +system to download a malicious package instead of the intended one, and in many cases the package +is immediately executed after download due to pre-install scripts. + +The main attack vectors are dependency confusion (publishing malicious packages in public +repositories with the same name as internal packages), dependency hijacking (compromising a +package maintainer's account to upload malicious versions), typosquatting (publishing packages +with names similar to popular packages), and brandjacking (publishing packages that mimic a +trusted brand's naming conventions). + +## Risk + +* Malicious code executes on developer workstations or build servers when a poisoned package is + pulled. +* Credential theft and lateral movement within the environment where the malicious code executes. +* Malicious code can make its way to production from the build server, potentially maintaining + the original safe functionality to reduce probability of discovery. +* Internal package names leaked to public repositories enable dependency confusion attacks. +* Build environments fetching packages directly from the internet without proxy controls are + exposed to all dependency chain attack vectors. + +## Vulnerability checklist + +* Clients fetch packages directly from external repositories without routing through an internal + proxy. +* Internal package names are not registered under the organization's scope. +* No checksum or signature verification is configured for pulled packages. +* Clients are configured to pull the latest version of a package rather than a pinned version. +* Package manager configuration files (such as .npmrc) are absent from project repositories. +* Pre-install scripts execute in a context with access to secrets and sensitive resources. +* Names of internal projects are published or discoverable in public repositories. +* No controls exist to prevent dependency confusion between internal and external registries. + +## Prevention controls + +1. Route all package fetches through an internal proxy rather than directly from the internet. +2. Where applicable, configure all clients to pull packages only from internal repositories + containing pre-vetted packages, and enforce this client configuration. +3. Enable checksum verification and signature verification for all pulled packages. +4. Pin package versions to pre-vetted versions or ranges and use framework-specific lock files. +5. Register all private packages under the organization's scope. +6. Ensure all code referencing a private package uses the package's scope. +7. Force clients to fetch scoped packages solely from the internal registry. +8. Run pre-install scripts in a separate context without access to secrets or other sensitive + resources. +9. Include package manager configuration files in every project repository to override insecure + default client configurations. +10. Avoid publishing names of internal projects in public repositories. + +## Example attack scenarios + +### Scenario A — Dependency confusion + +An attacker discovers the name of an internal NPM package used by the organization by finding +references in a public repository. The attacker publishes a package with the same name on the +public NPM registry with a higher version number. The build system, configured to check both +internal and public registries, pulls the higher-versioned malicious package. The pre-install +script executes, exfiltrating environment variables containing cloud credentials. + +### Scenario B — Dependency hijacking + +An attacker compromises the account of a maintainer of a widely-used Python package on PyPI. +They upload a new version containing a backdoor that executes during installation. Organizations +configured to pull the latest version of the package automatically fetch and execute the +compromised version on their build servers, granting the attacker access to build secrets and +deployment credentials. + +## Detection guidance + +* Monitor package manager audit logs for unexpected package sources or version changes. +* Compare checksums of fetched packages against known-good values. +* Alert on packages pulled from public registries that share names with internal packages. +* Audit package manager client configurations across build environments and developer + workstations. +* Scan dependency lock files for unexpected version changes or new dependencies. +* Monitor outbound network connections from build nodes during dependency installation. + +## Remediation + +* Configure internal proxies as the sole package source for all build environments and developer + workstations. +* Register all internal package names under the organization's scope on relevant public + registries to prevent namespace squatting. +* Pin all dependency versions and enforce lock file usage. +* Enable checksum and signature verification across all package manager configurations. +* Isolate pre-install script execution from secrets and sensitive build resources. +* Remove any references to internal package names from public repositories. +* Harden all build environments according to the guidelines under CICD-SEC-7. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/04-poisoned-pipeline-execution.md b/.github/skills/security/owasp-cicd/references/04-poisoned-pipeline-execution.md new file mode 100644 index 000000000..c3c9835a7 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/04-poisoned-pipeline-execution.md @@ -0,0 +1,126 @@ +--- +title: 'CICD-SEC-4: Poisoned Pipeline Execution' +description: OWASP CI/CD Top 10 reference for poisoned pipeline execution vulnerabilities including malicious code injection into CI/CD pipelines +--- + +# 04 Poisoned Pipeline Execution + +Identifier: CICD-SEC-4:2025 +Category: Pipeline Security + +## Description + +Poisoned Pipeline Execution (PPE) risks refer to the ability of an attacker with access to source +control systems, and without access to the build environment, to manipulate the build process by +injecting malicious code or commands into the build pipeline configuration, essentially poisoning the +pipeline and running malicious code as part of the build process. + +The PPE vector abuses permissions against an SCM repository in a way that causes a CI pipeline to +execute malicious commands. Users that have permissions to manipulate CI configuration files, or +other files which the CI pipeline job relies on, can modify them to contain malicious commands. +Pipelines executing unreviewed code, such as those triggered directly from pull requests or commits +to arbitrary repository branches, are more susceptible to PPE. + +There are three types of PPE: + +Direct PPE (D-PPE) occurs when the attacker modifies the CI configuration file in a repository they +have access to, either by pushing directly to an unprotected branch or by submitting a pull request. +The pipeline execution is defined by the commands in the modified configuration file. + +Indirect PPE (I-PPE) occurs when the pipeline configuration file is protected but the attacker +injects malicious code into files referenced by the configuration, such as Makefiles, test +frameworks, linter configurations, or scripts called from the pipeline. + +Public PPE (3PE) targets public repositories that allow contributions from anonymous users. If the +CI pipeline of a public repository runs unreviewed code suggested by anonymous users, it is +susceptible to this attack, potentially exposing internal assets including secrets from private +projects sharing the same CI instance. + +## Risk + +* Access to any secret available to the CI job, including secrets injected as environment variables + and credentials for cloud providers, artifact registries, and the SCM itself. +* Access to external assets the job node has permissions to, such as files on the node's filesystem + or credentials to cloud environments accessible through the underlying host. +* Ability to ship malicious code and artifacts further down the pipeline in the guise of legitimate + build output. +* Ability to access additional hosts and assets in the network or environment of the job node. +* Lateral movement from the CI environment to production systems using stolen credentials. + +## Vulnerability checklist + +* Pipelines execute code from unreviewed pull requests or commits to arbitrary branches. +* CI configuration files can be modified by contributors without review. +* Pipeline configuration files are stored in the same repository as source code without protection. +* Files referenced by the pipeline configuration (Makefiles, scripts, test files, linter configs) + can be modified without triggering a separate review process. +* Public repositories run CI pipelines on code submitted by anonymous contributors. +* Pipeline execution nodes have access to secrets beyond what is needed for the specific job. +* No isolation exists between pipeline nodes handling public and private repositories. +* Branch protection rules do not have correlating CI trigger restrictions. + +## Prevention controls + +1. Ensure pipelines running unreviewed code execute on isolated nodes not exposed to secrets and + sensitive environments. +2. Evaluate the need for triggering pipelines on public repositories from external contributors. + Where possible, refrain from running pipelines originating from forks and consider requiring + manual approval for pipeline execution. +3. For sensitive pipelines exposed to secrets, ensure each branch configured to trigger a pipeline + has a correlating branch protection rule in the SCM. +4. Require review of CI configuration file changes before the pipeline runs, or manage the CI + configuration file in a separate protected branch. +5. Remove unnecessary SCM repository permissions from users. +6. Scope each pipeline to only the credentials it needs with minimum required privileges. +7. Review and restrict which files referenced by the pipeline configuration can be modified + without additional approval. + +## Example attack scenarios + +### Scenario A — Direct PPE credential theft + +A GitHub Actions workflow is configured to trigger on push events. An attacker creates a new remote +branch and modifies the workflow file to exfiltrate AWS credentials stored as repository secrets. +The modified workflow loads the secrets into environment variables and sends them to an +attacker-controlled server. The push triggers the pipeline, which executes the poisoned +configuration and leaks the credentials. + +### Scenario B — Indirect PPE via Makefile + +A Jenkins pipeline fetches its Jenkinsfile from a protected main branch, but the build stage runs +a Makefile stored in the repository. An attacker creates a pull request modifying the Makefile to +replace the build target with a command that exfiltrates all environment variables. Since the +pipeline triggers on pull requests, the malicious Makefile content executes during the build stage +where AWS credentials are loaded, sending them to the attacker. + +### Scenario C — Public PPE on open source project + +An open source project runs CI on all pull requests. An attacker submits a pull request modifying +the test suite to include malicious code. The CI pipeline executes the tests, running the +attacker's code on the build node. Because the same CI instance services private repositories, the +attacker accesses secrets belonging to private projects. + +## Detection guidance + +* Monitor for modifications to CI configuration files in pull requests and pushes. +* Alert on pipeline executions triggered by unreviewed code from forks or external contributors. +* Audit which files referenced by pipeline configurations have been modified in recent commits. +* Monitor outbound network connections from build nodes for unexpected destinations. +* Review pipeline logs for unusual secret access patterns or commands. +* Compare pipeline configuration files against their protected branch versions before execution. + +## Remediation + +* Isolate pipeline execution nodes that process unreviewed code from those handling sensitive + workloads. +* Move CI configuration files to protected branches and require review for all changes. +* Implement manual approval gates for pipelines triggered by external contributors. +* Restrict pipeline credentials using fine-grained scoping aligned with each job's requirements. +* Separate CI infrastructure for public and private repositories. +* Audit and lock down all files referenced by pipeline configurations (Makefiles, scripts, test + configurations, linter configurations). +* Enable and enforce branch protection rules with correlating pipeline trigger restrictions. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/05-insufficient-pbac.md b/.github/skills/security/owasp-cicd/references/05-insufficient-pbac.md new file mode 100644 index 000000000..1c65bdcfa --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/05-insufficient-pbac.md @@ -0,0 +1,109 @@ +--- +title: 'CICD-SEC-5: Insufficient PBAC' +description: OWASP CI/CD Top 10 reference for insufficient pipeline-based access controls including overprivileged execution nodes and shared environments +--- + +# 05 Insufficient PBAC + +Identifier: CICD-SEC-5:2025 +Category: Access Controls + +## Description + +Pipeline-Based Access Controls (PBAC) refer to the context in which each pipeline, and each step +within that pipeline, is running. Given the highly sensitive and critical nature of each pipeline, +it is imperative to limit each pipeline to the exact set of data and resources it needs access to. + +Pipeline execution nodes carry out commands specified in the pipeline configuration, performing +sensitive activities including accessing source code, obtaining secrets from vaults and cloud +identity services, creating and deploying artifacts, and connecting to production systems. When +running malicious code within a pipeline, adversaries leverage insufficient PBAC to abuse the +permissions granted to the pipeline for lateral movement within or outside the CI/CD system. + +PBAC includes controls relating to access within the pipeline execution environment (code, secrets, +environment variables, other pipelines), permissions to the underlying host and other pipeline +nodes, and ingress and egress network filters. + +## Risk + +* Malicious code running in the context of a pipeline execution node has the full permissions of + the pipeline stage, including access to all available secrets. +* Access to the underlying host and ability to connect to any system the pipeline has access to. +* Exposure of confidential data through overly broad secret scoping. +* Lateral movement within the CI environment and to servers and systems outside the CI + environment. +* Deployment of malicious artifacts down the pipeline, including to production. +* The extent of potential damage from a compromise is directly determined by the granularity of + PBAC in the environment. + +## Vulnerability checklist + +* Shared pipeline nodes are used for pipelines with different levels of sensitivity or access + requirements. +* Secrets are not scoped to individual pipelines and steps, allowing broader access than required. +* Pipeline execution nodes are not reverted to a pristine state after each execution. +* The OS user running pipeline jobs has excessive permissions on the execution node. +* Pipeline jobs run on the controller node rather than separate dedicated nodes. +* Execution nodes are not regularly patched. +* Network segmentation does not restrict execution node access to only required resources. +* Build nodes have unrestricted internet access. +* Installation scripts execute with access to secrets and sensitive resources from other build + stages. + +## Prevention controls + +1. Do not use shared nodes for pipelines with different levels of sensitivity. Use shared nodes + only for pipelines with identical levels of confidentiality. +2. Scope secrets so that each pipeline and step has access to only the secrets it requires. +3. Revert the execution node to its pristine state after each pipeline execution. +4. Ensure the OS user running the pipeline job has permissions granted according to the principle + of least privilege. +5. Run CI and CD pipeline jobs on separate, dedicated nodes rather than the controller node. +6. Keep execution nodes appropriately patched. +7. Configure network segmentation so execution nodes can access only the resources they require. + Refrain from granting unlimited internet access to build nodes. +8. Ensure installation scripts execute in a separate context without access to secrets or + sensitive resources from other build stages. + +## Example attack scenarios + +### Scenario A — Shared node secret leakage + +An organization runs all pipeline jobs on a shared pool of nodes. A low-sensitivity open source +project pipeline and a high-sensitivity production deployment pipeline share the same nodes. +An attacker poisons the open source project's pipeline to enumerate environment variables and +filesystem contents on the shared node. Because secrets from the production pipeline persist in +memory and on disk from prior executions, the attacker exfiltrates production deployment +credentials. + +### Scenario B — Unrestricted network lateral movement + +A build node has unrestricted network access within the corporate environment. An attacker gains +code execution on the build node through a compromised dependency. Using the node's network +access, the attacker scans internal systems, discovers an unprotected internal service, and pivots +to access production databases containing customer data. + +## Detection guidance + +* Audit pipeline configurations to identify shared nodes servicing pipelines with differing + sensitivity levels. +* Review secret scoping across CI/CD systems to detect overly broad access grants. +* Monitor execution node state to verify pristine-state restoration after each pipeline run. +* Inspect OS user permissions on execution nodes. +* Monitor network traffic from execution nodes for connections to unexpected destinations. +* Alert on pipeline jobs executing on controller nodes. + +## Remediation + +* Segregate pipeline execution nodes by sensitivity level, dedicating node pools to pipelines + with matching confidentiality requirements. +* Re-scope all secrets to the minimum set of pipelines and steps that require them. +* Implement ephemeral pipeline execution nodes that are destroyed and recreated for each job. +* Reduce OS user privileges on execution nodes to the minimum required for job execution. +* Move all pipeline jobs off the controller node to dedicated worker nodes. +* Establish a patch management cadence for all execution nodes. +* Implement network segmentation and egress filtering on all build node networks. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/06-insufficient-credential-hygiene.md b/.github/skills/security/owasp-cicd/references/06-insufficient-credential-hygiene.md new file mode 100644 index 000000000..ab341a1aa --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/06-insufficient-credential-hygiene.md @@ -0,0 +1,116 @@ +--- +title: 'CICD-SEC-6: Insufficient Credential Hygiene' +description: OWASP CI/CD Top 10 reference for credential hygiene vulnerabilities including hardcoded secrets and unrotated credentials in pipelines +--- + +# 06 Insufficient Credential Hygiene + +Identifier: CICD-SEC-6:2025 +Category: Credential Management + +## Description + +Insufficient credential hygiene risks deal with an attacker's ability to obtain and use various +secrets and tokens spread throughout the pipeline due to flaws having to do with access controls +around credentials, insecure secret management, and overly permissive credentials. + +CI/CD environments are built of multiple systems communicating and authenticating against each +other, creating challenges around protecting credentials due to the large variety of contexts in +which credentials can exist. Application credentials are used at runtime, credentials to production +systems are used by pipelines to deploy infrastructure, and engineers use credentials in testing +environments and within their code and artifacts. + +Major flaws affecting credential hygiene include credentials committed to SCM repositories (remaining +visible in commit history even after deletion), credentials used insecurely inside build and +deployment processes, credentials left in container image layers, credentials printed to console +output and log management systems, and unrotated credentials that accumulate exposure over time. + +## Risk + +* Credentials are the most sought-after object by adversaries seeking access to high-value + resources or to deploy malicious code and artifacts. +* Engineering environments provide attackers with multiple avenues to obtain credentials. +* Credentials committed to code repositories persist in commit history indefinitely. +* Secrets printed to build console output are exposed to anyone with access to build results and + may flow to centralized log management systems. +* Credentials embedded in container image layers are accessible to anyone who can download the + image. +* Unrotated credentials allow a constantly growing number of people and artifacts to hold valid + credentials. +* Shared credentials increase exposure footprint and reduce accountability. + +## Vulnerability checklist + +* Credentials are present in code committed to SCM repository branches, including in commit + history. +* Secrets are used in CI/CD builds without scoping to specific pipelines and steps. +* Pipeline credentials can be accessed by unreviewed code flowing through the pipeline. +* Credentials are injected into the build in a manner that makes them accessible outside runtime. +* Secrets exist in container image layers. +* Credentials are printed to pipeline console output in cleartext. +* Static credentials exist that have not been rotated within the defined rotation period. +* The same set of credentials is shared across multiple contexts. +* Credentials lack usage conditions such as source IP restrictions or identity binding. +* No automated scanning exists for secrets in code repositories. + +## Prevention controls + +1. Establish procedures to continuously map credentials across the engineering ecosystem and + ensure each set follows the principle of least privilege. +2. Avoid sharing the same credentials across multiple contexts. +3. Prefer temporary credentials over static credentials. For static credentials, establish + periodic rotation procedures and detect stale credentials. +4. Configure credential usage conditions such as scoping to specific source IPs or identities. +5. Detect secrets pushed to code repositories using IDE plugins, push-time scanning, and + periodic repository scans covering past commits. +6. Scope secrets in CI/CD systems so each pipeline and step accesses only the secrets it + requires. +7. Use built-in vendor options or third-party tools to prevent secrets from being printed to + pipeline console outputs and audit existing outputs for secret exposure. +8. Verify that secrets are removed from all artifact types including container image layers, + binaries, and Helm charts. + +## Example attack scenarios + +### Scenario A — Credentials in commit history + +A developer accidentally commits AWS access keys to a repository. The keys are removed in a +subsequent commit, but remain visible in the commit history. An attacker with read access to the +repository browses the commit history, extracts the keys, and uses them to access the organization's +cloud infrastructure and exfiltrate data from production S3 buckets. + +### Scenario B — Secrets exposed in build logs + +A CI pipeline prints environment variables to the console output during a debugging step that was +never removed. The build logs, including plaintext credentials for the production database, flow +to the centralized log management system. An attacker who gains access to the logging platform +discovers the credentials and uses them to access the production database. + +## Detection guidance + +* Scan all repositories for secrets in current branches and historical commits using automated + secret detection tools. +* Audit CI/CD pipeline configurations for secrets injected as environment variables and assess + their scope. +* Review pipeline console outputs for exposed credentials. +* Inspect container images layer by layer to detect embedded secrets. +* Monitor credential usage patterns and alert on access from unexpected sources or contexts. +* Track credential rotation dates and alert on credentials that exceed the defined rotation + period. + +## Remediation + +* Rotate all credentials known or suspected to have been exposed. +* Remove secrets from repository commit history using history-rewriting tools and invalidate the + exposed credentials. +* Implement automated secret scanning in pre-commit hooks, CI pipelines, and periodic repository + scans. +* Re-scope all pipeline secrets to the minimum set of pipelines and steps that require them. +* Mask or redact all secrets in pipeline console outputs. +* Rebuild container images to eliminate secrets from intermediate layers using multi-stage builds. +* Establish and enforce a credential rotation policy with automated tracking and alerting. +* Replace shared credentials with dedicated, individually-scoped credentials. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/07-insecure-system-configuration.md b/.github/skills/security/owasp-cicd/references/07-insecure-system-configuration.md new file mode 100644 index 000000000..d5d292606 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/07-insecure-system-configuration.md @@ -0,0 +1,116 @@ +--- +title: 'CICD-SEC-7: Insecure System Configuration' +description: OWASP CI/CD Top 10 reference for insecure system configuration vulnerabilities including unpatched CI/CD infrastructure and debug exposure +--- + +# 07 Insecure System Configuration + +Identifier: CICD-SEC-7:2025 +Category: Configuration Management + +## Description + +Insecure system configuration risks stem from flaws in the security settings, configuration, and +hardening of the different systems across the pipeline (SCM, CI, artifact repository), often +resulting in low-effort attack vectors for adversaries looking to expand their foothold in the +environment. + +CI/CD environments are comprised of multiple systems provided by a variety of vendors. These +systems involve various security settings and configurations at the application, network, and +infrastructure levels that have a major influence on security posture and susceptibility to +compromise. + +Examples of potential hardening flaws include self-managed systems running outdated versions or +lacking security patches, systems with overly permissive network access controls, self-hosted +systems that have administrative permissions on the underlying OS, systems with insecure default +configurations around authorization, access controls, and logging, and systems with inadequate +credential hygiene such as default credentials that are not disabled. + +While SaaS CI/CD solutions eliminate some risks associated with system hardening and lateral +movement, organizations remain responsible for securely configuring their SaaS solutions, each +of which has unique security configurations and best practices. + +## Risk + +* Security flaws in CI/CD systems may be leveraged to obtain unauthorized access or compromise + the system and access the underlying OS. +* Flaws may be abused to manipulate legitimate CI/CD flows, obtain sensitive tokens, and + potentially access production environments. +* Lateral movement within the environment and outside the context of CI/CD systems becomes + possible through compromised nodes. +* Self-managed systems left accessible from the internet with default credentials expose source + code and secrets. +* Debug permissions on execution nodes may allow engineers to access all secrets loaded into + memory and use the node's identity. + +## Vulnerability checklist + +* Self-managed CI/CD systems run outdated versions or lack security patches. +* CI/CD systems have overly permissive network access controls, including internet-facing + instances without access restrictions. +* Self-hosted systems have administrative permissions on the underlying OS. +* Default system configurations have not been reviewed and hardened for security. +* Default credentials exist that are not disabled or changed. +* Overly permissive programmatic tokens are in use. +* Engineers have debug permissions on execution nodes, granting access to secrets in memory. +* No inventory exists of CI/CD systems, versions, and designated owners. +* No periodic review process exists for system security configurations. + +## Prevention controls + +1. Maintain an inventory of all CI/CD systems and versions in use, with a designated owner for + each system. +2. Continuously check for known vulnerabilities and apply security patches when available. If a + patch is not available, consider removing the component or restricting access. +3. Ensure network access to CI/CD systems is aligned with the principle of least access. +4. Establish a process to periodically review all system configurations that affect security + posture, ensuring all settings are optimal. +5. Ensure permissions to pipeline execution nodes follow the principle of least privilege. +6. Restrict debug permissions on execution nodes, recognizing that users with debug access can + expose secrets loaded in memory and use the node's identity. +7. Disable default credentials and replace them with properly managed credentials. +8. Ensure all SaaS CI/CD solution configurations are reviewed against vendor-specific security + best practices. + +## Example attack scenarios + +### Scenario A — Internet-exposed SCM with default credentials + +A self-managed Bitbucket instance is left accessible from the internet with default credentials +enabled. An attacker discovers the instance through an internet scan, logs in with default +credentials, and gains access to all hosted source code repositories including those containing +secrets and production deployment configurations. + +### Scenario B — Unpatched build server compromise + + +A self-managed Jenkins instance runs an outdated version with a known remote code execution +vulnerability. The system is accessible from the internet. An attacker exploits the vulnerability +to gain shell access on the Jenkins server, accesses stored pipeline credentials, and uses them +to deploy malicious code to production through legitimate deployment pipelines. + +## Detection guidance + +* Scan all CI/CD system instances for known vulnerabilities and outdated versions. +* Audit network access controls to identify internet-facing or overly permissive CI/CD systems. +* Check for the presence of default credentials across all CI/CD systems. +* Review system configurations against hardening baselines and vendor security best practices. +* Monitor for debug sessions on pipeline execution nodes. +* Enumerate and audit all programmatic tokens for excessive permissions. + +## Remediation + +* Patch or upgrade all CI/CD systems to current, supported versions. +* Restrict network access to CI/CD systems, removing internet exposure where not required and + implementing IP allowlisting. +* Disable all default credentials and replace with properly managed alternatives. +* Conduct a comprehensive security configuration review of all CI/CD systems against hardening + baselines. +* Remove administrative OS permissions from self-hosted CI/CD systems. +* Restrict debug permissions on execution nodes to only those who require them, with appropriate + monitoring. +* Establish a vulnerability management cadence for all CI/CD infrastructure components. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/08-ungoverned-usage-of-3rd-party-services.md b/.github/skills/security/owasp-cicd/references/08-ungoverned-usage-of-3rd-party-services.md new file mode 100644 index 000000000..d25819736 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/08-ungoverned-usage-of-3rd-party-services.md @@ -0,0 +1,119 @@ +--- +title: 'CICD-SEC-8: Ungoverned Usage of 3rd Party Services' +description: OWASP CI/CD Top 10 reference for ungoverned third-party service usage including excessive permissions and unaudited integrations +--- + +# 08 Ungoverned Usage of 3rd Party Services + +Identifier: CICD-SEC-8:2025 +Category: Third-Party Governance + +## Description + +The CI/CD attack surface consists of an organization's organic assets, such as the SCM or CI, and +the third-party services which are granted access to those organic assets. Risks having to do with +ungoverned usage of third-party services rely on the extreme ease with which a third-party service +can be granted access to resources in CI/CD systems, effectively expanding the attack surface of the +organization. + +Third-party applications can be connected through many methods depending on the platform, including +marketplace applications, OAuth applications, provisioned access tokens, provisioned SSH keys, and +webhook events. Each method takes seconds to minutes to implement and can grant third parties +numerous capabilities, ranging from reading code in a single repository to fully administering the +organization. In many cases no special permissions or approvals are required by the organization +prior to implementation. + +Build systems also allow easy integration of third parties by adding one or two lines of code to +the pipeline configuration file or installing a plugin from a marketplace. The third-party +functionality is imported and executed as part of the build process with full access to whatever +resources are available from the pipeline stage. + +Organizations face significant challenges in obtaining full visibility around which third parties +have access to different systems, what methods of access they have, what level of permissions they +have been granted, and what level of permissions they actually use. + +## Risk + +* Organizations are only as secure as the third parties they implement. +* Insufficient RBAC and least privilege around third parties, coupled with minimal governance and + diligence, significantly increase the organization's attack surface. +* Compromise of a single third party can cause damage far outside the scope of the system the + third party is connected to. +* Third parties with write permissions on a repository can be leveraged to push code that + triggers a build and runs malicious code on the build system. +* Third parties integrated into build processes execute with full access to pipeline stage + resources including secrets. +* Lack of visibility over the actual permissions used by third parties versus permissions granted + prevents effective access control. + +## Vulnerability checklist + +* Third-party services are granted access to CI/CD systems without a formal approval or vetting + process. +* Third-party permissions exceed the minimum required for their function. +* No comprehensive inventory exists of all third parties integrated with CI/CD systems. +* Third-party integrations are not reviewed for all methods of access (marketplace apps, OAuth, + tokens, SSH keys, webhooks). +* Third parties integrated into build processes run without scoped access to secrets and code. +* No ingress or egress filters exist for third-party components executing within pipelines. +* Unused or redundant third-party integrations are not periodically removed. +* Third-party integrations lack predetermined expiry or review dates. + +## Prevention controls + +1. Establish vetting procedures to ensure third parties are approved prior to being granted + access and that their permissions align with the principle of least privilege. +2. Introduce controls and procedures to maintain continuous visibility over all third parties + integrated to CI/CD systems, including method of integration, permissions granted, and + permissions actually used. +3. Limit and scope each third party to the specific resources it requires access to. +4. Ensure third parties executing as part of the build process run inside a scoped context with + limited access to secrets and code, and with strict ingress and egress filters. +5. Remove unused and redundant third-party permissions. +6. Periodically review all third-party integrations and deprovision those no longer in use. +7. Require predetermined expiry dates for third-party access grants. + +## Example attack scenarios + +### Scenario A — Compromised code coverage tool + +A popular code coverage tool is integrated into the CI pipeline through a marketplace application. +The tool's infrastructure is compromised by an attacker, who modifies the tool's script to +exfiltrate environment variables from builds. Since the tool executes within the build context with +access to all pipeline secrets, the attacker steals credentials for cloud providers, artifact +registries, and the SCM from every organization using the compromised tool. + +### Scenario B — OAuth token theft from analytics platform + + +A git analytics platform is granted OAuth access to the organization's GitHub repositories for +code analysis. An attacker gains access to the analytics platform's database and steals the stored +OAuth tokens for all customers. The attacker uses the tokens to access and modify source code in +production repositories, inject backdoors, and trigger deployment pipelines. + +## Detection guidance + +* Enumerate all third-party integrations across CI/CD systems, covering all methods of access + (marketplace apps, OAuth applications, access tokens, SSH keys, webhooks). +* Compare permissions granted to each third party against permissions actually used. +* Monitor third-party activity logs for unexpected access patterns. +* Alert on new third-party integrations being added without going through the approval process. +* Audit pipeline configurations for third-party components that execute with pipeline-level + credentials. +* Review webhook configurations for endpoints that are no longer maintained or recognized. + +## Remediation + +* Conduct a comprehensive inventory of all third-party integrations across every CI/CD system. +* Remove all third-party integrations that are unused, redundant, or unrecognized. +* Reduce permissions of remaining third-party integrations to the minimum required. +* Implement an approval workflow for new third-party integrations with mandatory security review. +* Scope third-party components in build pipelines to isolated contexts with restricted secret + access and network filtering. +* Establish expiry dates on all third-party access grants and implement periodic re-certification. +* Rotate all credentials that third-party services have had access to after removing unnecessary + integrations. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/09-improper-artifact-integrity-validation.md b/.github/skills/security/owasp-cicd/references/09-improper-artifact-integrity-validation.md new file mode 100644 index 000000000..665b25849 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/09-improper-artifact-integrity-validation.md @@ -0,0 +1,108 @@ +--- +title: 'CICD-SEC-9: Improper Artifact Integrity Validation' +description: OWASP CI/CD Top 10 reference for artifact integrity validation vulnerabilities including unsigned artifacts and missing provenance +--- + +# 09 Improper Artifact Integrity Validation + +Identifier: CICD-SEC-9:2025 +Category: Artifact Integrity + +## Description + +Improper artifact integrity validation risks allow an attacker with access to one of the systems in +the CI/CD process to push malicious (although seemingly benign) code or artifacts down the pipeline, +due to insufficient mechanisms for ensuring the validation of code and artifacts. + +CI/CD processes consist of multiple steps, ultimately responsible for taking code all the way from +an engineer's workstation to production. There are multiple resources being fed into each step, +combining internal resources and artifacts with third-party packages and artifacts fetched from +remote locations. The fact that the ultimate resource is reliant upon multiple sources spread across +different steps, provided by multiple contributors, creates multiple entry points through which this +ultimate resource can be tampered with. + +If a tampered resource is able to infiltrate the delivery process without raising suspicion or +encountering security gates, it will most likely continue flowing through the pipeline, all the +way to production, in the guise of a legitimate resource. + +## Risk + +* A malicious artifact shipped through the pipeline can result in the execution of malicious code + on systems within the CI/CD process or in production. +* Unsigned or unverified code commits can introduce tampered code without attribution. +* Tampered artifacts persisting across pipeline stages can compromise downstream systems. +* Third-party resources fetched without hash verification can be substituted with malicious + versions. +* Configuration drifts between deployed resources and CI/CD-managed templates may indicate + unauthorized changes deployed by untrusted sources. + +## Vulnerability checklist + +* Code commits are not signed and the pipeline does not enforce commit signature verification. +* No artifact signing infrastructure exists to sign resources generated during the pipeline. +* Artifacts are not verified against a signing authority before being consumed in subsequent + pipeline stages. +* Third-party resources fetched during build or deploy are not verified against published hashes. +* No configuration drift detection exists for production resources versus their CI/CD source + definitions. +* Pipeline stages accept artifacts from untrusted sources without integrity checks. +* Container images used in production are not signed or verified before deployment. +* No software bill of materials (SBOM) is generated or tracked for pipeline-produced artifacts. + +## Prevention controls + +1. Implement code signing and enforce signature verification on all commits before they enter the + pipeline. +2. Sign all artifacts generated during the pipeline using an external resource signing + infrastructure. +3. Verify artifact integrity against the signing authority before consuming resources in + subsequent pipeline stages. +4. Calculate and cross-reference hashes of third-party resources against the official published + hashes of the resource provider before use in build or deploy pipelines. +5. Implement configuration drift detection for production resources, alerting on resources that + are not managed through a signed infrastructure-as-code template. +6. Generate and track software bills of materials for all pipeline-produced artifacts. +7. Enforce container image signing and verification before deployment to any environment. + +## Example attack scenarios + +### Scenario A — Tampered build artifact + +An attacker gains access to the build server and modifies the application binary after it is +compiled but before it is uploaded to the artifact repository. No signing or integrity validation +exists between the build and deploy stages. The tampered binary is picked up by the deployment +pipeline and deployed to production, executing the attacker's backdoor code on production servers. + +### Scenario B — Compromised third-party script + +A CI pipeline fetches a third-party script from an external URL during the build process to perform +a specific build task. An attacker gains access to the hosting environment of the third-party script +and replaces it with a malicious version. Because the pipeline does not verify the script's hash +against a known-good value, the compromised script is executed during the next build, stealing +credentials and injecting a backdoor into the build output. + +## Detection guidance + +* Audit pipeline configurations for stages that consume artifacts without integrity verification. +* Monitor for unsigned commits entering protected branches. +* Detect configuration drifts between production resources and their CI/CD source definitions. +* Compare hashes of fetched third-party resources against known-good reference values. +* Track artifact provenance across pipeline stages and alert on artifacts without valid + signatures. +* Monitor for container images deployed without valid signatures. + +## Remediation + +* Deploy an artifact signing infrastructure and integrate signing into all pipeline stages. +* Enforce commit signature verification on all branches feeding into CI/CD pipelines. +* Implement hash verification for all third-party resources fetched during pipeline execution. +* Deploy configuration drift detection tooling for all production environments. +* Establish a policy requiring all artifacts to be signed before entering subsequent pipeline + stages. +* Implement container image signing and enforce verification before deployment. +* Generate and maintain SBOMs for all artifacts produced by CI/CD pipelines. +* Audit and remediate all existing pipeline stages that currently lack integrity validation. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/.github/skills/security/owasp-cicd/references/10-insufficient-logging-visibility.md b/.github/skills/security/owasp-cicd/references/10-insufficient-logging-visibility.md new file mode 100644 index 000000000..b86371135 --- /dev/null +++ b/.github/skills/security/owasp-cicd/references/10-insufficient-logging-visibility.md @@ -0,0 +1,124 @@ +--- +title: 'CICD-SEC-10: Insufficient Logging and Visibility' +description: OWASP CI/CD Top 10 reference for insufficient logging and visibility vulnerabilities including blind spots and inadequate audit trails +--- + +# 10 Insufficient Logging and Visibility + +Identifier: CICD-SEC-10:2025 +Category: Logging and Visibility + +## Description + +Insufficient logging and visibility risks allow an adversary to carry out malicious activities +within the CI/CD environment without being detected during any phase of the attack kill chain, +including identifying the attacker's TTPs (Techniques, Tactics, and Procedures) as part of any +post-incident investigation. + +The existence of strong logging and visibility capabilities is essential for an organization's +ability to prepare for, detect, and investigate a security-related incident. While workstations, +servers, network devices, and key IT and business applications are typically covered in depth within +an organization's logging and visibility programs, it is often not the case with systems and +processes in engineering environments. + +Given the amount of potential attack vectors leveraging engineering environments and processes, it is +imperative that security teams build the appropriate capabilities to detect these attacks as soon as +they happen. As many of these vectors involve leveraging programmatic access against the different +systems, a key aspect is to create strong levels of visibility around both human and programmatic +access. + +Both audit logs (user access, user creation, permission modification) and applicative logs (push +events, build executions, artifact uploads) are equally important for maintaining sufficient +visibility. + +## Risk + +* Organizations that do not ensure appropriate logging and visibility around engineering + environments may fail to detect a breach entirely. +* Minimal investigative capabilities create great difficulties in mitigation and remediation after + a breach. +* Time and data are the most valuable commodities during incident response, and the absence of + all relevant data sources in a centralized location can be the difference between a successful + and devastating outcome. +* Attackers can operate undetected for extended periods within CI/CD systems. +* Post-incident analysis is severely hampered without comprehensive audit trails across all + CI/CD systems. +* Inability to correlate events across SCM, CI, artifact repositories, and deployment systems + prevents detection of multi-stage attacks. + +## Vulnerability checklist + +* No complete inventory exists of all CI/CD systems, including all instances of self-managed + systems. +* Audit logs are not enabled on all CI/CD systems, or are not enabled to their full extent. +* Applicative logs (pipeline execution, artifact operations, code operations) are not captured. +* Logs from CI/CD systems are not shipped to a centralized location such as a SIEM. +* No alerts exist to detect anomalies or potential malicious activity in CI/CD systems. +* Programmatic access to CI/CD systems is not logged or monitored to the same degree as human + access. +* No correlation rules exist to detect anomalies across the code shipping process involving + multiple systems. +* Log retention periods are insufficient for investigation of incidents discovered with a delay. + +## Prevention controls + +1. Build and maintain a comprehensive inventory of all CI/CD systems in use, including every + instance of self-managed systems. +2. Identify and enable all relevant log sources across every CI/CD system, covering both human + and programmatic access through all available methods. +3. Enable both audit log sources (user access, user creation, permission changes) and applicative + log sources (push events, build executions, artifact operations). +4. Ship all CI/CD logs to a centralized location such as a SIEM to support aggregation and + correlation across systems. +5. Create alerts to detect anomalies and potential malicious activity within each system as well + as across the code shipping process spanning multiple systems. +6. Ensure log retention periods are sufficient for post-incident investigation requirements. +7. Monitor programmatic access with the same rigor as human access. + +## Example attack scenarios + +### Scenario A — Undetected credential exfiltration + +An attacker compromises a CI pipeline through a poisoned dependency and exfiltrates credentials +stored as environment variables. Because no logging exists for outbound network connections from +build nodes and pipeline execution events are not shipped to a centralized monitoring system, the +credential theft goes undetected. The attacker uses the stolen credentials for months, laterally +moving across production environments, before the breach is discovered through an unrelated +investigation. + +### Scenario B — Delayed incident response due to missing logs + +A build server is compromised and used to inject a backdoor into production artifacts. When the +compromise is eventually discovered, the incident response team attempts to reconstruct the attack +timeline. However, audit logs were not enabled on the CI system, and execution logs were retained +for only seven days. The team cannot determine when the compromise began, what credentials were +accessed, or which artifacts were affected, leading to a full rebuild of all production +infrastructure. + +## Detection guidance + +* Verify that all CI/CD systems have audit and applicative logging enabled and configured. +* Confirm that logs from all CI/CD systems are being shipped to and received by the centralized + SIEM. +* Test alert rules by simulating anomalous activities across CI/CD systems. +* Periodically review log coverage to identify CI/CD systems or event types that are not being + captured. +* Validate that programmatic access events (API calls, token usage, webhook invocations) are + logged. +* Confirm log retention periods meet investigation requirements. + +## Remediation + +* Conduct a comprehensive inventory of all CI/CD systems and instances, identifying gaps in log + coverage. +* Enable all audit and applicative log sources on every CI/CD system. +* Configure log shipping from all CI/CD systems to the centralized SIEM or logging platform. +* Develop and deploy detection rules and alerts for anomalous activity across CI/CD systems, + including multi-system correlation rules. +* Extend log retention periods to meet organizational incident investigation requirements. +* Ensure programmatic access is logged and monitored at parity with human access. +* Conduct periodic log coverage reviews to catch newly-added systems or configuration drifts. + +--- + +*🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.* diff --git a/collections/hve-core-all.collection.yml b/collections/hve-core-all.collection.yml index 4378cebd7..55a46dd78 100644 --- a/collections/hve-core-all.collection.yml +++ b/collections/hve-core-all.collection.yml @@ -555,6 +555,9 @@ items: - path: .github/skills/security/owasp-agentic kind: skill maturity: experimental +- path: .github/skills/security/owasp-cicd + kind: skill + maturity: experimental - path: .github/skills/security/owasp-llm kind: skill maturity: experimental diff --git a/collections/security.collection.md b/collections/security.collection.md index d6dc90d9b..47ff80673 100644 --- a/collections/security.collection.md +++ b/collections/security.collection.md @@ -27,4 +27,5 @@ Skills included: - **OWASP Top 10** — OWASP Top 10 for Web Applications (2025) vulnerability knowledge base - **OWASP LLM Top 10** — OWASP Top 10 for LLM Applications (2025) vulnerability knowledge base - **OWASP Agentic Top 10** — OWASP Agentic Security Top 10 vulnerability knowledge base for AI agent systems +- **OWASP CI/CD Top 10** - OWASP CI/CD Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in continuous integration and continuous delivery environments - **Security Reviewer Formats** — Format specifications and data contracts for the security reviewer orchestrator and its subagents diff --git a/collections/security.collection.yml b/collections/security.collection.yml index 4a5f6e688..c57576529 100644 --- a/collections/security.collection.yml +++ b/collections/security.collection.yml @@ -53,6 +53,9 @@ items: - path: .github/skills/security/owasp-agentic kind: skill maturity: experimental + - path: .github/skills/security/owasp-cicd + kind: skill + maturity: experimental - path: .github/skills/security/security-reviewer-formats kind: skill maturity: experimental diff --git a/docs/docusaurus/src/data/collectionCards.ts b/docs/docusaurus/src/data/collectionCards.ts index c58929331..efa6c6f01 100644 --- a/docs/docusaurus/src/data/collectionCards.ts +++ b/docs/docusaurus/src/data/collectionCards.ts @@ -87,7 +87,7 @@ export const collectionCards: CollectionCardData[] = [ { name: 'security', description: 'Security review, planning, incident response, and risk assessment', - artifacts: 46, + artifacts: 47, maturity: 'Experimental', href: '/docs/getting-started/collections', }, @@ -98,5 +98,5 @@ export interface MetaCollections { } export const metaCollections: MetaCollections = { - 'hve-core-all': 227, + 'hve-core-all': 228, }; diff --git a/plugins/hve-core-all/README.md b/plugins/hve-core-all/README.md index d7157613b..f2b675146 100644 --- a/plugins/hve-core-all/README.md +++ b/plugins/hve-core-all/README.md @@ -289,6 +289,7 @@ copilot plugin install hve-core-all@hve-core | hve-core-installer | Decision-driven installer for HVE-Core with 6 clone-based installation methods, extension quick-install, environment detection, and agent customization workflows - Brought to you by microsoft/hve-core | | jira | Jira issue workflows for search, issue updates, transitions, comments, and field discovery via the Jira REST API. Use when you need to search with JQL, inspect an issue, create or update work items, move an issue between statuses, post comments, or discover required fields for issue creation. - Brought to you by microsoft/hve-core | | owasp-agentic | OWASP Agentic Security Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in AI agent systems - Brought to you by microsoft/hve-core. | +| owasp-cicd | OWASP CI/CD Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in continuous integration and continuous delivery environments - Brought to you by microsoft/hve-core. | | owasp-llm | OWASP Top 10 for LLM Applications (2025) vulnerability knowledge base for identifying, assessing, and remediating security risks in large language model systems - Brought to you by microsoft/hve-core. | | owasp-top-10 | OWASP Top 10 for Web Applications (2025) vulnerability knowledge base for identifying, assessing, and remediating security risks in web application environments - Brought to you by microsoft/hve-core. | | security-reviewer-formats | Format specifications and data contracts for the security reviewer orchestrator and its subagents - Brought to you by microsoft/hve-core. | diff --git a/plugins/hve-core-all/skills/security/owasp-cicd b/plugins/hve-core-all/skills/security/owasp-cicd new file mode 120000 index 000000000..094e2dfd4 --- /dev/null +++ b/plugins/hve-core-all/skills/security/owasp-cicd @@ -0,0 +1 @@ +../../../../.github/skills/security/owasp-cicd \ No newline at end of file diff --git a/plugins/security/README.md b/plugins/security/README.md index 8014a4141..7f868d978 100644 --- a/plugins/security/README.md +++ b/plugins/security/README.md @@ -37,6 +37,7 @@ Skills included: - **OWASP Top 10** — OWASP Top 10 for Web Applications (2025) vulnerability knowledge base - **OWASP LLM Top 10** — OWASP Top 10 for LLM Applications (2025) vulnerability knowledge base - **OWASP Agentic Top 10** — OWASP Agentic Security Top 10 vulnerability knowledge base for AI agent systems +- **OWASP CI/CD Top 10** - OWASP CI/CD Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in continuous integration and continuous delivery environments - **Security Reviewer Formats** — Format specifications and data contracts for the security reviewer orchestrator and its subagents ## Install @@ -108,6 +109,7 @@ copilot plugin install security@hve-core | owasp-top-10 | OWASP Top 10 for Web Applications (2025) vulnerability knowledge base for identifying, assessing, and remediating security risks in web application environments - Brought to you by microsoft/hve-core. | | owasp-llm | OWASP Top 10 for LLM Applications (2025) vulnerability knowledge base for identifying, assessing, and remediating security risks in large language model systems - Brought to you by microsoft/hve-core. | | owasp-agentic | OWASP Agentic Security Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in AI agent systems - Brought to you by microsoft/hve-core. | +| owasp-cicd | OWASP CI/CD Top 10 vulnerability knowledge base for identifying, assessing, and remediating security risks in continuous integration and continuous delivery environments - Brought to you by microsoft/hve-core. | | security-reviewer-formats | Format specifications and data contracts for the security reviewer orchestrator and its subagents - Brought to you by microsoft/hve-core. | | pr-reference | Generates PR reference XML containing commit history and unified diffs between branches with extension and path filtering. Includes utilities to list changed files by type and read diff chunks. Use when creating pull request descriptions, preparing code reviews, analyzing branch changes, discovering work items from diffs, or generating structured diff summaries. - Brought to you by microsoft/hve-core | diff --git a/plugins/security/skills/security/owasp-cicd b/plugins/security/skills/security/owasp-cicd new file mode 120000 index 000000000..094e2dfd4 --- /dev/null +++ b/plugins/security/skills/security/owasp-cicd @@ -0,0 +1 @@ +../../../../.github/skills/security/owasp-cicd \ No newline at end of file