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

Content

View full analysis

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

text

### 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

View 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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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
• Confidence: 70% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · SKILL.md (reported line 97)May include surrounding context.

md

- 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

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.

Content

No source excerpt is available for this finding.