torusguard 1.3.4 → 1.3.5

package/skills/torusguard/payload/rules/secrets/TG-SEC-005-secret-in-git-history.md

@@ -1,37 +1,42 @@
-# TG-SEC-005: Secret in Git History
+# TG-SEC-005: Secret or Private Key in Git History
 
 ## Severity
-High by default. Raise to Critical when applicable.
+Critical. Committing private API keys, credentials, or private certificates into git history persists them permanently across all cloned repositories, even if deleted in subsequent commits.
 
 ## Applies To
-- Relevant endpoints and services
+- Git Repositories, Public and Private Remotes
+- All Languages & Frameworks
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+Deleting a secret file in a follow-up commit (`git rm .env`) does NOT remove it from git history. Attackers clone public repositories and run scanners (`git log -p`) to extract historical secrets within seconds.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- Git commit objects or patch diffs containing private keys, AWS access keys, or JWT secret strings.
 
 ## Unsafe Example
-```javascript
-// Unsafe code example
+```bash
+# UNSAFE: Adding .env with live credentials directly to git tracking
+git add .env
+git commit -m "Add production database credentials"
 ```
 
 ## Safe Example
-```javascript
-// Safe code example
+```bash
+# SAFE: Keeping .env in .gitignore; using .env.example with placeholder tokens
+echo ".env" >> .gitignore
+git add .gitignore .env.example
+git commit -m "Add environment configuration baseline"
 ```
 
-## Remediation
-1. Step one
-2. Step two
-
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 2 lines
+- Deletions: <= 2 lines
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Immediately rotate any secret that was committed to git history.
+2. Use tools like `git-filter-repo` or BFG Repo-Cleaner to purge the commit blob from repository history.
+3. Add `.env` and `*.pem` to `.gitignore`.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SEC-001`: Hardcoded Secret or API Key in Tracked Source
+- `TG-SEC-003`: Unencrypted Secret in Tracked Config File

package/skills/torusguard/payload/rules/secrets/TG-SEC-006-secret-in-build-artifact.md

@@ -1,37 +1,54 @@
-# TG-SEC-006: Secret in Build Artifact
+# TG-SEC-006: Secret in Build Artifact or Container Image
 
 ## Severity
-High by default. Raise to Critical when applicable.
+Critical. Copying `.env` files, build-time secrets, or SSH keys into Docker build layers persists secrets in image layers, allowing anyone with pull access to extract credentials via `docker history` or container inspection.
 
 ## Applies To
-- Relevant endpoints and services
+- Dockerfiles, Container Builds, Serverless Bundle Artifacts
+- Docker, Containerd, Podman, Webpack, Vite
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+Docker image layers are cached and stored individually. Running `COPY .env .` followed by `RUN rm .env` still retains the `.env` file in the preceding layer blob, allowing trivial credential recovery.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- Dockerfile instructions containing `COPY .env` or `ARG SECRET_KEY` without BuildKit secret mount protection.
 
 ## Unsafe Example
-```javascript
-// Unsafe code example
+```dockerfile
+# UNSAFE: Copying local .env into container layer
+FROM node:20-alpine
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci
+COPY .env .
+COPY . .
+RUN npm run build
 ```
 
 ## Safe Example
-```javascript
-// Safe code example
+```dockerfile
+# SAFE: Using BuildKit secret mounts or multi-stage build without persisting secrets
+# syntax=docker/dockerfile:1.4
+FROM node:20-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci
+COPY . .
+RUN --mount=type=secret,id=build_secrets npm run build
+
+FROM node:20-alpine
+WORKDIR /app
+COPY --from=builder /app/dist ./dist
 ```
 
-## Remediation
-1. Step one
-2. Step two
-
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 5 lines
+- Deletions: <= 2 lines
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Use Docker BuildKit secret mounts (`--mount=type=secret`) for credentials needed during build.
+2. Use multi-stage Docker builds to ensure final runtime images only contain compiled frontend assets.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SUPPLY-006`: Container Build Secret Persistence
+- `TG-SEC-001`: Hardcoded Secret or API Key in Tracked Source

package/skills/torusguard/payload/rules/secrets/TG-SEC-007-secret-in-test-or-example-fixture.md

@@ -1,37 +1,42 @@
 # TG-SEC-007: Secret in Test or Example Fixture
 
 ## Severity
-High by default. Raise to Critical when applicable.
+Medium. Committing real production or staging credentials into test fixtures, mocks, or example configuration files leaks secrets under the assumption that test directories are unmonitored.
 
 ## Applies To
-- Relevant endpoints and services
+- Test Suites, Mock Fixtures, Example Configs
+- All Languages & Frameworks
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+Developers often copy live payload captures from production to create integration tests or seed fixtures. If these fixtures contain real API keys or customer JWT tokens, they are exposed in source control.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- High-entropy tokens, Stripe live keys (`sk_live_`), or valid JWT signatures present in `tests/`, `fixtures/`, or `examples/` directories.
 
 ## Unsafe Example
 ```javascript
-// Unsafe code example
+// UNSAFE: Real active production API key used in test fixture
+const mockAuth = {
+  apiKey: "sk_live_51M0...REAL_STRIPE_LIVE_KEY_12345"
+};
 ```
 
 ## Safe Example
 ```javascript
-// Safe code example
+// SAFE: Explicit synthetic mock sentinel string
+const mockAuth = {
+  apiKey: "sk_test_fake_mock_token_for_unit_tests_only"
+};
 ```
 
-## Remediation
-1. Step one
-2. Step two
-
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 2 lines
+- Deletions: <= 2 lines
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Replace all real credentials in test directories with synthetic, inert mock sentinels (`test_token_dummy`).
+2. Rotate any credentials that were copied from production to test files.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SEC-001`: Hardcoded Secret or API Key in Tracked Source
+- `TG-SEC-004`: Sensitive Information in Logs

package/skills/torusguard/payload/rules/ssrf/TG-SSRF-002-missing-internal-network-protection.md

@@ -1,37 +1,64 @@
 # TG-SSRF-002: Missing Internal Network Protection
 
 ## Severity
-High by default. Raise to Critical when applicable.
+Critical. Allowing server-side HTTP clients to dispatch requests to internal network interfaces (127.0.0.1, private RFC 1918 subnets, or cloud metadata services like 169.254.169.254) allows external attackers to extract cloud credentials and interact with internal microservices.
 
 ## Applies To
-- Relevant endpoints and services
+- Webhook dispatchers, URL preview fetchers, PDF generators, image proxies
+- Node.js (fetch, axios), Python (requests, httpx, urllib), Go (net/http), Java
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+If a server accepts a destination URL from a user (e.g. `/api/fetch-avatar?url=...`) without blocking private network spaces, an attacker can supply `http://169.254.169.254/latest/meta-data/iam/security-credentials/` to steal AWS IAM role tokens, or `http://127.0.0.1:6379` to inject Redis commands.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- Server-side request calls dispatching requests to unvalidated URLs that could resolve to loopback (`127.0.0.0/8`), link-local (`169.254.0.0/16`), or private IP ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`).
 
 ## Unsafe Example
-```javascript
-// Unsafe code example
+```python
+# UNSAFE: Outbound fetch without private IP filtering
+import requests
+from fastapi import FastAPI
+
+app = FastAPI()
+
+@app.get("/fetch")
+def fetch_url(url: str):
+    return requests.get(url).text # Attacker passes http://169.254.169.254/...
 ```
 
 ## Safe Example
-```javascript
-// Safe code example
-```
+```python
+# SAFE: Resolving IP and validating against private subnet ranges before fetching
+import socket
+import ipaddress
+import requests
+from fastapi import FastAPI, HTTPException
 
-## Remediation
-1. Step one
-2. Step two
+app = FastAPI()
 
-## Verification
-- Test case 1
-- Test case 2
+def is_safe_url(url: str) -> bool:
+    from urllib.parse import urlparse
+    hostname = urlparse(url).hostname
+    if not hostname: return False
+    ip = ipaddress.ip_address(socket.gethostbyname(hostname))
+    return not (ip.is_private or ip.is_loopback or ip.is_link_local)
 
-## False Positives and Exceptions
-An exception requires documented review.
+@app.get("/fetch")
+def fetch_url(url: str):
+    if not is_safe_url(url):
+        raise HTTPException(status_code=400, detail="Invalid destination IP")
+    return requests.get(url, timeout=5.0).text
+```
+
+## Ponytail Remediation Budget
+- Additions: <= 14 lines
+- Deletions: <= 2 lines
+
+## Remediation
+1. Parse the destination hostname and resolve DNS.
+2. Assert that resolved IP addresses are neither loopback (`127.0.0.0/8`), link-local (`169.254.0.0/16`), nor RFC 1918 private subnets.
+3. Pin DNS resolution to prevent time-of-check to time-of-use (TOCTOU) DNS rebinding attacks.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SSRF-001`: User-Controlled Server-Side URL Fetch
+- `TG-SSRF-004`: Unbounded Outbound Request

package/skills/torusguard/payload/rules/ssrf/TG-SSRF-003-unsafe-redirect-following.md

@@ -1,37 +1,41 @@
 # TG-SSRF-003: Unsafe Redirect Following
 
 ## Severity
-High by default. Raise to Critical when applicable.
+High. Configuring server-side HTTP clients to automatically follow redirects allows attackers to bypass initial URL allowlists by supplying a public URL that redirects (301/302) to an internal loopback or cloud metadata service.
 
 ## Applies To
-- Relevant endpoints and services
+- HTTP Clients (Axios, Requests, Fetch, urllib, cURL)
+- Node.js, Python, Go, Java
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+An application might validate that `https://example.com/image.png` is safe. However, if `example.com` returns a redirect header `Location: http://169.254.169.254/latest/meta-data/` and the client follows redirects automatically, the internal metadata service is fetched.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- HTTP client configurations with `maxRedirects > 0`, `follow_redirects=True`, or `allow_redirects=True` on user-controlled fetches.
 
 ## Unsafe Example
 ```javascript
-// Unsafe code example
+// UNSAFE: Axios configured with default automatic redirect following
+const response = await axios.get(userSuppliedUrl, { maxRedirects: 5 });
 ```
 
 ## Safe Example
 ```javascript
-// Safe code example
+// SAFE: Disabling automatic redirect following or revalidating redirect target
+const response = await axios.get(userSuppliedUrl, {
+  maxRedirects: 0,
+  validateStatus: status => status >= 200 && status < 300
+});
 ```
 
-## Remediation
-1. Step one
-2. Step two
-
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 4 lines
+- Deletions: <= 2 lines
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Disable automatic HTTP redirect following (`maxRedirects: 0` or `allow_redirects=False`).
+2. If redirects must be supported, intercept `Location` headers and re-run IP safety checks before dispatching secondary requests.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SSRF-001`: User-Controlled Server-Side URL Fetch
+- `TG-SSRF-002`: Missing Internal Network Protection

package/skills/torusguard/payload/rules/ssrf/TG-SSRF-004-unbounded-outbound-request.md

@@ -1,37 +1,46 @@
-# TG-SSRF-004: Unbounded Outbound Request
+# TG-SSRF-004: Unbounded Outbound Request Without Timeout
 
 ## Severity
-High by default. Raise to Critical when applicable.
+Critical. Dispatching server-side HTTP requests without strict socket and read timeouts allows malicious endpoints or slowloris servers to hang server worker threads indefinitely, leading to resource exhaustion and DoS.
 
 ## Applies To
-- Relevant endpoints and services
+- Outbound HTTP Clients (Python `requests`, Node `axios`, Go `http.Client`)
+- Python, Node.js, Go, Java
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+In Python `requests`, the default timeout is `None` (it waits forever). If an attacker provides a URL pointing to a server that accepts the connection and trickles 1 byte every 10 minutes, your server worker threads become permanently exhausted.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- Outbound HTTP calls (`requests.get`, `requests.post`, `axios.get`, `fetch`) lacking explicit `timeout` parameters.
 
 ## Unsafe Example
-```javascript
-// Unsafe code example
+```python
+# UNSAFE: Python requests call without timeout hangs indefinitely
+import requests
+
+def fetch_avatar(url: str):
+    response = requests.get(url) # Can hang indefinitely
+    return response.content
 ```
 
 ## Safe Example
-```javascript
-// Safe code example
-```
+```python
+# SAFE: Explicit timeout prevents hanging worker threads
+import requests
 
-## Remediation
-1. Step one
-2. Step two
+def fetch_avatar(url: str):
+    response = requests.get(url, timeout=5.0) # 5-second socket timeout
+    return response.content
+```
 
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 2 lines
+- Deletions: <= 1 line
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Always specify an explicit `timeout` on all network calls (typically 3.0 to 10.0 seconds).
+2. Configure custom client sessions with default timeouts applied globally.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SSRF-001`: User-Controlled Server-Side URL Fetch
+- `TG-RATE-003`: Unbounded Resource Consumption

package/skills/torusguard/payload/rules/supply-chain/TG-SUPPLY-001-missing-or-ignored-dependency-lockfile.md

@@ -1,37 +1,44 @@
 # TG-SUPPLY-001: Missing or Ignored Dependency Lockfile
 
 ## Severity
-High by default. Raise to Critical when applicable.
+High. Omitting or `.gitignore`-ing dependency lockfiles (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `Poetry.lock`, `Cargo.lock`, `go.sum`) allows non-deterministic builds and exposes installations to malicious sub-dependency updates.
 
 ## Applies To
-- Relevant endpoints and services
+- npm, pnpm, yarn, pip, poetry, cargo, go
+- All polyglot projects
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+Without a committed lockfile, running `npm install` or `pip install` resolves the latest compatible semantic version (`^1.0.0`). If a third-party dependency author account is compromised and publishes a malicious patch version, your CI/CD pipeline installs it automatically.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- `.gitignore` files containing `package-lock.json`, `yarn.lock`, or `pnpm-lock.yaml`.
+- Repositories with manifest files (`package.json`) lacking corresponding lockfiles.
 
 ## Unsafe Example
-```javascript
-// Unsafe code example
+```gitignore
+# UNSAFE: Ignoring dependency lockfiles in version control
+node_modules/
+package-lock.json
+yarn.lock
 ```
 
 ## Safe Example
-```javascript
-// Safe code example
+```gitignore
+# SAFE: Tracking lockfiles in version control; ignoring only node_modules
+node_modules/
+dist/
+build/
 ```
 
-## Remediation
-1. Step one
-2. Step two
-
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 1 line
+- Deletions: <= 2 lines
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Remove lockfile references from `.gitignore`.
+2. Run `npm install` to generate `package-lock.json` and commit it to git.
+3. In CI/CD pipelines, use `npm ci` or `pnpm install --frozen-lockfile` instead of `npm install`.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SUPPLY-002`: Vulnerable Dependency Review Missing
+- `TG-SUPPLY-004`: Unpinned CI Action

package/skills/torusguard/payload/rules/supply-chain/TG-SUPPLY-003-unsafe-ci-cd-secret-exposure.md

@@ -1,37 +1,47 @@
-# TG-SUPPLY-003: Unsafe CI/CD Secret Exposure
+# TG-SUPPLY-003: Unsafe CI/CD Secret Exposure in Workflow Logs
 
 ## Severity
-High by default. Raise to Critical when applicable.
+Critical. Echoing or printing pipeline secrets in CI/CD step commands (`echo ${{ secrets.API_KEY }}`) or passing secrets directly in command line arguments persists plaintext credentials in build logs.
 
 ## Applies To
-- Relevant endpoints and services
+- GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines
+- YAML Workflows
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+CI/CD logs are often accessible to broad team members, external contributors, or public viewers on open-source repositories. Even when CI providers attempt log masking, modified or base64-encoded strings bypass masking and remain permanently visible in build logs.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- CI steps running `echo` or `print` on `${{ secrets.* }}` or `$SECRET_*`.
+- Passing secrets as command-line arguments instead of masked environment variables.
 
 ## Unsafe Example
-```javascript
-// Unsafe code example
+```yaml
+# UNSAFE: Echoing secrets directly into execution step logs
+- name: Deploy to Cloud
+  run: |
+    echo "Using token ${{ secrets.DEPLOY_TOKEN }}"
+    deploy-tool --token ${{ secrets.DEPLOY_TOKEN }}
 ```
 
 ## Safe Example
-```javascript
-// Safe code example
+```yaml
+# SAFE: Injecting secrets strictly via environment variables without logging
+- name: Deploy to Cloud
+  env:
+    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
+  run: |
+    deploy-tool
 ```
 
-## Remediation
-1. Step one
-2. Step two
-
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 5 lines
+- Deletions: <= 3 lines
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Never print or echo secret variables in workflow step commands.
+2. Pass secrets into steps strictly via the `env:` block.
+3. Avoid command-line arguments for secrets; configure tools to read credentials from environment variables or secure files.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SEC-001`: Hardcoded Secret or API Key in Tracked Source
+- `TG-SUPPLY-004`: Unpinned CI Action

package/skills/torusguard/payload/rules/supply-chain/TG-SUPPLY-004-unpinned-ci-action.md

@@ -1,37 +1,42 @@
 # TG-SUPPLY-004: Unpinned CI Action
 
 ## Severity
-High by default. Raise to Critical when applicable.
+Critical. Referencing third-party GitHub Actions using mutable branch or version tags (e.g. `uses: actions/checkout@v4`) allows attackers who compromise the action's repository to push malicious code that runs with your workflow's permissions.
 
 ## Applies To
-- Relevant endpoints and services
+- GitHub Actions Workflows (`.github/workflows/*.yml`)
+- CI/CD Configurations
 
 ## Why It Matters
-Explaining the risk of this vulnerability.
+Git tags in third-party repositories are mutable pointers. An attacker who compromises a popular action maintainer's account can force-push a malicious commit to `@v3` or `@v4`, granting them immediate execution inside your CI environment with access to your repository secrets.
 
 ## What TorusGuard Looks For
-- Specific code patterns or configurations
+- GitHub Actions `uses:` declarations referencing version tags (`@v4`, `@main`) instead of 40-character immutable commit SHA hashes.
 
 ## Unsafe Example
-```javascript
-// Unsafe code example
+```yaml
+# UNSAFE: Mutable tag vulnerable to tag spoofing
+steps:
+  - uses: actions/checkout@v4
+  - uses: some-vendor/setup-tool@v1
 ```
 
 ## Safe Example
-```javascript
-// Safe code example
+```yaml
+# SAFE: Immutable commit SHA pinning with version comment
+steps:
+  - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
+  - uses: some-vendor/setup-tool@c2e8c2f1f8b172a5a54db5e6b12a818c1b2c3d4e # v1.2.0
 ```
 
-## Remediation
-1. Step one
-2. Step two
-
-## Verification
-- Test case 1
-- Test case 2
+## Ponytail Remediation Budget
+- Additions: <= 2 lines
+- Deletions: <= 2 lines
 
-## False Positives and Exceptions
-An exception requires documented review.
+## Remediation
+1. Pin all external GitHub Actions to full 40-character commit SHAs.
+2. Use tools like Dependabot or Renovate to automate SHA updates with release verification.
 
 ## Related Rules
-- TG-OTHER-001
+- `TG-SUPPLY-003`: Unsafe CI/CD Secret Exposure
+- `TG-SUPPLY-005`: Unsafe Dependency Install Script