Back to skill

Security audit

python-testing

Security checks for vulnerabilities and agentic risk

Overview

This is a coherent Python testing guidance skill with ordinary pytest setup examples and no hidden execution behavior.

Install only if you want pytest-focused guidance. Use an isolated virtual environment, pin testing dependencies where practical, and review any copied CI or pre-commit workflow before committing it to a repository.

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 (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:34
Finding
Unpinned Python Testing Dependencies## Vulnerability Details **File Location**: `SKILL.md`, line 34 **Vulnerability Type**: Unpinned third-party dependency installation **Risk Level**: Medium ### Vulnerable Code ```markdown 1. **Dependencies**: `pip install pytest pytest-cov pytest-asyncio pytest-mock` ``` ### Technical Analysis The installation command does not specify reviewed package versions, a lock file, or integrity hashes. Consequently, package resolution may produce different dependency sets over time. If a future package release or one of its transitive dependencies is compromised, following this instruction could install attacker-controlled code into the user's Python environment. Python packages may execute code during build or installation, and installed pytest plugins may also load automatically when tests run. This is a supply-chain hardening issue. The reviewed package names appear legitimate, and the audit found no evidence that the Skill intentionally directs users to typosquatted or malicious packages. ### Attack Path 1. An attacker compromises a listed package, one of its transitive dependencies, or the associated publishing account. 2. The attacker publishes a malicious release that remains compatible with unconstrained dependency resolution. 3. A user follows the Skill's Quick Start command. 4. `pip` resolves and downloads the compromised release. 5. Malicious code executes during package build, installation, import, or pytest plugin loading. 6. The code gains the permissions of the user or CI account running the command. ### Impact Assessment Successful exploitation could permit arbitrary code execution with the privileges of the account performing installation or running pytest. On a developer workstation, this could expose source code, accessible credentials, environment variables, and writable files. In CI, it could affect checked-out repository content, build artifacts, and secrets made available to the job. The scope i ...[truncated 96 chars]
Remediation
## Remediation Suggestions - Replace unconstrained installation instructions with a reviewed requirements or lock file. - Pin direct and transitive dependencies to exact versions. - Generate and verify package hashes where practical, such as with `pip install --require-hashes`. - Use an isolated virtual environment rather than installing into a system Python environment. - Enable automated dependency vulnerability scanning and controlled update review. - Document a reproducible workflow, for example: ```bash python -m venv .venv . .venv/bin/activate python -m pip install --require-hashes -r requirements-test.txt ``` - Regenerate pins and hashes through a trusted update process rather than accepting arbitrary latest releases.

T08 · Insecure Dependencies

Warning
Location
modules/testing-workflows.md:85
Finding
GitHub Actions Referenced by Mutable Version Tags## Vulnerability Details **File Location**: `modules/testing-workflows.md`, lines 85-101 **Vulnerability Type**: Mutable third-party CI dependencies **Risk Level**: Medium ### Vulnerable Code ```yaml steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: ${{ matrix.python-version }} - name: Install dependencies run: | pip install -e ".[dev]" - name: Run tests run: pytest --cov --cov-report=xml - name: Upload coverage uses: codecov/codecov-action@v4 if: matrix.python-version == '3.12' ``` ### Technical Analysis The workflow references GitHub Actions using major-version tags rather than immutable full commit SHAs. Tags such as `v4` and `v5` can resolve to different code after the workflow has been reviewed or copied into another project. If an upstream action repository, maintainer account, or mutable tag is compromised, the workflow runner could execute altered action code automatically. The Codecov action additionally processes and uploads coverage output, making strict provenance and permission controls important. The actions shown are well-known components, and no malicious action reference was identified. The vulnerability is the lack of immutable dependency pinning. ### Attack Path 1. A user copies the documented workflow into a repository. 2. An attacker compromises an upstream action publisher, repository, release process, or mutable version tag. 3. The attacker changes the code resolved by one of the referenced major-version tags. 4. A push or pull request starts the workflow. 5. GitHub downloads and executes the modified action on the CI runner. 6. The action accesses resources available to that job, potentially including checked-out source, generated coverage data, workflow tokens, environment variables, and writable artifacts. 7. Depending on job permiss ...[truncated 700 chars]
Remediation
## Remediation Suggestions - Pin every action to a reviewed full commit SHA instead of a mutable major-version tag. - Preserve the human-readable release in a comment, for example: ```yaml - uses: actions/checkout@REVIEWED_FULL_COMMIT_SHA # v4 ``` - Apply explicit least-privilege workflow permissions, such as: ```yaml permissions: contents: read ``` - Grant additional permissions only to the specific job or step that requires them. - Avoid exposing secrets to workflows triggered by untrusted pull requests. - Pin third-party actions, including coverage-upload actions, with particular care. - Use dependency-update tooling that proposes reviewed SHA updates rather than silently following mutable tags. - Add artifact and network restrictions where supported, and review what coverage information is uploaded externally.
Vulnerability Patterns
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (2)

Vague Triggers

Medium
Confidence
93% confidence
Finding
The manifest trigger list contains generic terms such as "python", "testing", and "pytest", plus the broad phrase "writing or auditing a Python test suite". These are common request terms and the file does not provide narrowing conditions or negative examples, increasing the chance of unintended invocation.

Unbounded Resource Access

Medium
Category
Excessive Agency
Content
@pytest.mark.asyncio
async def test_operation_timeout():
    with pytest.raises(asyncio.TimeoutError):
        await asyncio.wait_for(slow_operation(), timeout=0.1)
```

## Testing Exception Handling
Confidence
75% confidence
Finding
Skill allows unbounded resource consumption (API calls, storage, compute). Without rate limits or quotas, a compromised or misbehaving agent can cause denial-of-service or cost overruns.

Static analysis

No suspicious patterns detected.