Git Team Ops

• Outcome: Review
• Latest audit: Sep 11, 2026 · 4:25 AM UTC
• Version: 0.1.5

Overview

The skill is coherent for GitOps automation, but its release workflow template grants repository write permissions before it implements release behavior, so users should review it before installing.

Install only after reviewing the copied workflow templates. In particular, reduce the senior release workflow permissions to read-only until real release logic needs write access, consider pinning actions/checkout and the clawhub installer to reviewed versions, and prefer short-lived GitHub App installation tokens over PATs.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (4)

T08 · Insecure Dependencies

Warning

• Location: README.md:35
• Finding: Mutable Package Version Is Downloaded and Executed During Installation## Vulnerability Details **File Location**: `README.md`, lines 35-39 **Vulnerability Type**: Mutable third-party package execution **Risk Level**: Medium ### Vulnerable Code ```markdown ## Install ```bash npx clawhub@latest install launchthatbot-git-team-ops ``` ``` ### Technical Analysis The documented installation command uses `npx` to retrieve and execute `clawhub@latest`. The `latest` distribution tag is mutable and does not identify the exact package artifact that was reviewed. Consequently, the effective installer code can change after this Skill has been audited. Because `npx` executes the downloaded package with the invoking user's privileges, compromise of the package publisher, npm account, registry response, or a future release could result in arbitrary local code execution. The external installer is not included in this repository, so its behavior cannot be verified by this audit. ### Attack Path 1. An attacker compromises the `clawhub` package publisher, registry account, or release pipeline. 2. The attacker publishes a malicious release and assigns it the `latest` tag. 3. A user follows the README and executes the documented command. 4. `npx` downloads and runs the attacker-controlled package. 5. The malicious installer executes with the user's permissions and can access files, credentials, environment variables, and repositories available to that account. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the installing user's account. The accessible scope may include local source repositories, Git credentials, agent configuration, environment secrets, and any services available to that user. The command does not itself request elevated operating-system privileges, so the direct privilege boundary is the invoking account.
• Remediation: ## Remediation Suggestions - Replace `@latest` with an exact, reviewed package version. - Where supported, verify the package archive against a documented integrity hash or trusted signature. - Document the expected registry and package publisher. - Recommend downloading and inspecting the package before execution in security-sensitive environments. - Use a controlled internal registry or approved artifact mirror for production deployments. - Establish an explicit update process so new installer versions are reviewed before the documented pin is changed.

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: templates/github/workflows/senior-release-control.yml:13
• Finding: Placeholder Release Workflow Receives Unnecessary Repository Write Permissions## Vulnerability Details **File Location**: `templates/github/workflows/senior-release-control.yml`, lines 13-30 **Vulnerability Type**: Excessive GitHub Actions token permissions **Risk Level**: Medium ### Vulnerable Code ```yaml permissions: contents: write pull-requests: write jobs: release-control: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v4 - name: Release control placeholder run: | echo "Senior release workflow triggered." echo "Implement semantic release or custom release logic here." echo "Requested release type: ${{ inputs.release_type }}" ``` ### Technical Analysis The workflow grants `contents: write` and `pull-requests: write` to its `GITHUB_TOKEN`, but its current implementation only checks out the repository and prints informational messages. It does not create commits, tags, releases, or pull requests. These write permissions therefore exceed the minimum privileges required for the declared placeholder behavior. GitHub Actions token permissions apply to every step in the job. A compromised action dependency or an unsafe step added later could use the token to modify repository contents or pull requests. This risk is amplified by the workflow's use of a mutable action tag. ### Attack Path 1. A repository maintainer installs the supplied release workflow template. 2. The workflow is manually triggered and GitHub issues a job token with content and pull-request write access. 3. A referenced action is compromised, or a later workflow modification introduces malicious command execution. 4. Malicious code reads or implicitly uses the job's `GITHUB_TOKEN`. 5. The token is used through the GitHub API to alter repository content or pull-request state within the permissions GitHub grants to the workflow. ### Impact Assessment Exploitation could permit modification of repository contents ...[truncated 388 chars]
• Remediation: ## Remediation Suggestions - Change the placeholder workflow to `contents: read` and remove `pull-requests: write`. - Grant write permissions only after release functionality that needs them has been implemented and reviewed. - Place privileged release operations in a separate, narrowly scoped job. - Use protected environments with required human approval for jobs that receive write permissions. - Preserve branch protection and release rules rather than relying solely on workflow role conventions. - Pin every third-party action to a reviewed full commit SHA.

T08 · Insecure Dependencies

Warning

• Location: templates/github/workflows/junior-pr-validate.yml:12
• Finding: Junior Validation Workflow Uses a Mutable GitHub Action Reference## Vulnerability Details **File Location**: `templates/github/workflows/junior-pr-validate.yml`, lines 12-14 **Vulnerability Type**: Unpinned CI dependency **Risk Level**: Medium ### Vulnerable Code ```yaml steps: - name: Checkout uses: actions/checkout@v4 ``` ### Technical Analysis The workflow references `actions/checkout` through the mutable `v4` tag rather than a full commit SHA. The code executed by downstream repositories can therefore differ from the action revision originally reviewed with this Skill. The workflow correctly limits its token to `contents: read`, reducing the potential for repository modification. Nevertheless, a compromised action revision would execute on the GitHub-hosted runner and could access the checked-out source, workflow environment, and any credentials exposed to that job. ### Attack Path 1. The template is copied into a target repository. 2. The `v4` action tag is compromised, moved, or resolves to an unsafe upstream revision. 3. A pull request triggers the validation workflow. 4. GitHub downloads and executes the compromised checkout action. 5. The malicious action reads available source code, job metadata, or credentials and may transmit them externally or tamper with subsequent job state. ### Impact Assessment The immediate GitHub token is limited to read-only repository contents, so direct repository modification is constrained. However, successful exploitation could expose private repository source, workflow metadata, and any additional secrets later made available to the job. It could also falsify validation behavior or alter files within the ephemeral runner workspace.
• Remediation: ## Remediation Suggestions - Pin `actions/checkout` to a reviewed full commit SHA instead of `@v4`. - Retain the action version as a comment for maintainability. - Use controlled dependency-update automation to propose SHA updates for review. - Continue limiting the workflow token to `contents: read`. - Avoid adding secrets to pull-request workflows unless they are strictly required and protected from untrusted contributions.

T08 · Insecure Dependencies

Warning

• Location: templates/github/workflows/senior-release-control.yml:20
• Finding: Privileged Release Workflow Uses a Mutable GitHub Action Reference## Vulnerability Details **File Location**: `templates/github/workflows/senior-release-control.yml`, lines 20-22 **Vulnerability Type**: Unpinned privileged CI dependency **Risk Level**: Medium ### Vulnerable Code ```yaml steps: - name: Checkout uses: actions/checkout@v4 ``` ### Technical Analysis The release workflow executes `actions/checkout` through the mutable `v4` tag. A tag does not provide the immutable provenance of a full commit SHA, so the action code used by installed copies of the template can change independently of this package. This occurrence is particularly sensitive because the same job is granted `contents: write` and `pull-requests: write`. A compromised checkout action would execute within a job holding a write-capable `GITHUB_TOKEN`. ### Attack Path 1. A senior agent or maintainer installs the release workflow template. 2. The upstream action tag is compromised, moved, or made to resolve to malicious code. 3. An authorized user manually triggers the release workflow. 4. The runner executes the compromised action in the write-enabled job. 5. The malicious action abuses the workflow token to call GitHub APIs and modify content or pull requests, subject to repository and branch-protection controls. ### Impact Assessment Successful exploitation could provide write access to repository contents and pull-request operations through the workflow identity. This could support source tampering, malicious release preparation, pull-request manipulation, or broader downstream supply-chain compromise. The exact ability to modify protected branches depends on the target repository's branch-protection and GitHub Actions policies.
• Remediation: ## Remediation Suggestions - Pin `actions/checkout` to a reviewed full commit SHA. - Remove the job's write permissions until implemented release logic demonstrates a specific need for them. - Review and approve action SHA updates through pull requests. - Use protected environments and required approvals before executing privileged release jobs. - Restrict workflow modification through CODEOWNERS and branch-protection rules. - Audit every action introduced into a write-enabled job and minimize credential persistence during checkout.

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (2)

Credential Access

High

• Category: Privilege Escalation

Content

- Installation ID
- App private key (PEM)

Use only installation access tokens for repo operations.
Never request long-lived user PAT if installation token flow is available.

### pat mode

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 90% confidence
• Finding: The install command uses `npx clawhub@latest`, which fetches and executes the most recent published package version at runtime rather than a reviewed, fixed version. In a security-sensitive GitOps skill that manages repository workflows and automation, this increases supply-chain risk because a compromised or breaking upstream release could be executed by users during installation.

Static analysis

No suspicious patterns detected.