ClawHub
Back to skill

Security audit

golang-testing

Security checks for vulnerabilities and agentic risk

Overview

This Go testing skill is coherent and purpose-aligned, with ordinary development-tool risks users should understand before installing.

Install only if you are comfortable letting the agent edit Go test files and run Go-related commands. Prefer pinning gotests and clockwork versions in controlled environments, and review any generated integration tests before running Docker Compose fixtures or tests that touch databases.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:18
Finding

Unpinned Third-Party Go Dependencies Create Supply-Chain Risk

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:18-20, SKILL.md:43, and references/mocking.md:201-205
Vulnerability Type: Mutable and unverified third-party dependencies
Risk Level: Medium

Vulnerable Code

SKILL.md:18-20:

yaml
    install:
      - kind: go
        package: github.com/cweill/gotests/gotests@latest

SKILL.md:43:

markdown
- gotests: `go install github.com/cweill/gotests/gotests@latest`

references/mocking.md:201-205:

markdown
Install clockwork:

```bash
go get github.com/jonboulle/clockwork
text

### Technical Analysis

The skill directs users or agents to obtain third-party Go components without pinning them to reviewed, immutable versions. The `@latest` selector explicitly resolves to the version considered current at installation time. The versionless `go get` instruction similarly leaves dependency resolution to the state of the upstream module and the target project's module configuration at execution time.

As a result, the code installed or incorporated into a project can differ from the code present when this skill was audited. This weakens reproducibility and creates a supply-chain trust boundary around upstream repositories, maintainers, module proxies, and transitive dependencies.

The `gotests` dependency is particularly relevant because it installs an executable that the skill allows the agent to invoke. A malicious version could therefore run with the permissions of the user executing the skill. A compromised `clockwork` release could be compiled into generated test code and execute when affected tests or related binaries run.

There is no evidence that the named upstream projects or their current releases are malicious. The vulnerability is the unsafe use of mutable dependency references.

### Attack Path

1. An attacker compromises an upstream maintainer account, repository, release process, module path, or transitive depende
...[truncated 1294 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin gotests to a specifically reviewed release rather than using @latest:

    bash
    go install github.com/cweill/gotests/gotests@vX.Y.Z

  2. Pin clockwork to an explicit reviewed release:

    bash
    go get github.com/jonboulle/clockwork@vX.Y.Z

  3. Record the selected versions in the skill metadata and documentation so installation behavior is consistent.

  4. Review direct and transitive dependencies before updating pinned versions. Validate the module path, release provenance, maintainer history, and unexpected dependency changes.

  5. Retain and verify go.sum entries in target projects. Where appropriate, use a trusted Go module proxy and checksum database rather than bypassing checksum verification.

  6. Test dependency upgrades in an isolated environment before making them the skill default.

  7. Run installed development tools with least privilege. CI jobs that execute code-generation tools should receive only the credentials and filesystem access required for that job.

SkillSpector

Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (4)

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 · evals/evals.json (reported line 164)May include surrounding context.

json
"id": 7,
    "name": "external-test-package-resists-internal-access",
    "description": "Tests use package_test to black-box test; does not access unexported state even when a teammate suggests it",
    "prompt": "Write tests for a `tokenizer` package that exports `Tokenize(input string) []Token` and a `Token` struct with `Type` and `Value` fields. The package has an unexported `tokenCache map[string][]Token` field on the package level for memoization.\n\nA teammate says: 'We should verify the cache is being populated correctly — access tokenCache directly in the tests. It's in the same package so it's fine, and it makes the tests more reliable since we can confirm memoization is working.'\n\nWrite the tests. Should you follow the teammate's suggestion?",
    "trap": "Model follows the teammate's suggestion and uses package tokenizer (white-box) to access tokenCache directly, reasoning that it makes tests more reliable. The skill teaches to use package tokenizer_test and test only observable behavior — cache behavior is an implementation detail, not a contract.",
    "assertions": [
      {

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 · evals/evals.json (reported line 165)May include surrounding context.

json
"id": 7,
    "name": "external-test-package-resists-internal-access",
    "description": "Tests use package_test to black-box test; does not access unexported state even when a teammate suggests it",
    "prompt": "Write tests for a `tokenizer` package that exports `Tokenize(input string) []Token` and a `Token` struct with `Type` and `Value` fields. The package has an unexported `tokenCache map[string][]Token` field on the package level for memoization.\n\nA teammate says: 'We should verify the cache is being populated correctly — access tokenCache directly in the tests. It's in the same package so it's fine, and it makes the tests more reliable since we can confirm memoization is working.'\n\nWrite the tests. Should you follow the teammate's suggestion?",
    "trap": "Model follows the teammate's suggestion and uses package tokenizer (white-box) to access tokenCache directly, reasoning that it makes tests more reliable. The skill teaches to use package tokenizer_test and test only observable behavior — cache behavior is an implementation detail, not a contract.",
    "assertions": [
      {

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 · evals/evals.json (reported line 169)May include surrounding context.

json
"id": 7,
    "name": "external-test-package-resists-internal-access",
    "description": "Tests use package_test to black-box test; does not access unexported state even when a teammate suggests it",
    "prompt": "Write tests for a `tokenizer` package that exports `Tokenize(input string) []Token` and a `Token` struct with `Type` and `Value` fields. The package has an unexported `tokenCache map[string][]Token` field on the package level for memoization.\n\nA teammate says: 'We should verify the cache is being populated correctly — access tokenCache directly in the tests. It's in the same package so it's fine, and it makes the tests more reliable since we can confirm memoization is working.'\n\nWrite the tests. Should you follow the teammate's suggestion?",
    "trap": "Model follows the teammate's suggestion and uses package tokenizer (white-box) to access tokenCache directly, reasoning that it makes tests more reliable. The skill teaches to use package tokenizer_test and test only observable behavior — cache behavior is an implementation detail, not a contract.",
    "assertions": [
      {

Context-Inappropriate Capability

Medium
Category
Not specified by scanner
Confidence
85% confidence
Finding

The manifest frames this skill as guidance for writing and reviewing Go tests, CI setup, and debugging test behavior. This example adds direct host-level subprocess execution via docker-compose up/down, which is a stronger operational capability than test-code structure or assertion patterns and is not explicitly declared in the skill description.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.