violin/skills/pentest/references/standards.md

Violin Operational Standards

Purpose: Single source of truth for guardrail rules, evidence handling policy, and severity scoring methodology. Applies to every Violin engagement. Cross-referenced from SOUL.md, SKILL.md, and individual playbooks.

---

1. Guardrails

1.1 Cloud Metadata Protection

Cloud metadata endpoints are off-limits by default unless SSRF-to-metadata is an explicit engagement goal:

Provider	Endpoint	Protocol
AWS	169.254.169.254/latest/meta-data/	IPv4 link-local
GCP	metadata.google.internal/computeMetadata/v1/	DNS + magic header
Azure	169.254.169.254/metadata/instance?api-version=2021-02-01	IPv4 + Metadata:true
OpenStack	169.254.169.254/latest/meta-data/	IPv4
DigitalOcean	169.254.169.254/metadata/v1/	IPv4
Oracle Cloud	169.254.169.254/opc/v1/	IPv4
Alibaba Cloud	100.100.100.200/latest/meta-data/	IPv4
AWS IPv6	[fd00:ec2::254]/latest/meta-data/	IPv6 ECS link-local

Default rule: Treat metadata endpoints as out-of-scope unless the scope document says otherwise. If in scope: Document target provider, retrieve minimal metadata for impact demonstration, store evidence in $ENG_DIR/evidence/exploitation/ssrf-metadata.md. Never use retrieved credentials outside the engagement.

1.2 Aux-Client Leakage Mitigation

Discovered credentials, tokens, session cookies, and API keys must be handled differently depending on where they appear:

Context	Treatment
Chat messages (clarify, assistant responses)	Redact to last 6 characters only — e.g. ghp_...aBcDeF
Evidence files ($ENG_DIR/evidence/)	Full values OK — this is the permanent record
Secrets vault ($ENG_DIR/findings/secrets-vault.md)	Full values — must be in .gitignore
Screenshots	Blur or crop sensitive data before saving as evidence
PII (names, emails of non-target users)	Redact everywhere — chat, evidence, report
Test credentials provided in scope	Keep unchanged — they're test data

If you accidentally log a full credential to a chat channel (not an evidence file), immediately note the incident in the retrospective.

1.3 Rate Limit Enforcement

• Default inter-request delay: 200ms minimum between active requests against any single host.
• Burst handling: If a response returns 429 (Too Many Requests), back off exponentially: 1s, 2s, 4s, 8s, max 30s.
• Authorised rate limits: Respect any rate limit specified in the Rules of Engagement. Defaults apply when RoE is silent.
• Scope: Active scanning only (nmap, ffuf, gobuster, nuclei, sqlmap). Passive recon (DNS lookups, certificate transparency, web searches) is not rate-limited.

1.4 Bypass Exhaustion Principle

Before marking a finding as false negative (vulnerability not present), you must attempt the full bypass set for that vulnerability class:

Class	Bypass Types to Attempt
WAF/Filter	Case variation, encoding (URL/Unicode/UTF-8), comment injection, parameter pollution, header splitting, null byte
SQLi	Error-based, UNION, blind (boolean/time), second-order, NoSQL variants
XSS	Reflected, stored, DOM, blind, SVG/XML, HTTP header, mXSS
SSRF	Basic, blind, semi-blind, DNS rebinding, protocol smuggling
Path Traversal	URL encoding, double encoding, UTF-8 overlong, path truncation, null byte

Only after attempting the full bypass set can you record "not vulnerable" with confidence.

1.5 Authorization Gate

Written authorization must be obtained:

1. Before any active scanning — Signed Rules of Engagement or pentest agreement on file.
2. Before exploitation — Phase-specific approval confirming the scope and risk tolerance.
3. Before credential attacks — Explicit written carve-out in the RoE.

Record authorization in $ENG_DIR/scope/authorization.md:

engagement_id: <target>-<YYYY-MM-DD>
authorizer: <name>
authorization_date: <YYYY-MM-DD>
approved_modes:
  - passive_recon
  - active_recon
  - exploitation
  - credential_attacks  # only if explicitly carved out
scope_document: $ENG_DIR/scope/scope.yaml

1.6 Scope Allowlist

Every outgoing request must be checked against the engagement scope:

• Domains, IPs, CIDRs, and URLs listed in $ENG_DIR/scope/scope.yaml
• Requests to targets outside the scope must stop immediately
• Unexpected targets encountered during testing follow the Scope Violations procedure in scoping.md

1.7 Command Guard

Every target-touching terminal command must be checked before execution:

python $HOME/.hermes/profiles/violin/scripts/violin_guard.py check-command --scope "$ENG_DIR/scope/scope.yaml" --eng-dir "$ENG_DIR" --session-id "<session-id>" --phase RECON --target "example.com" --command "nmap -sV example.com"

Guard outcomes:

Exit code	Meaning	Required action
0	Allowed	The command may run after the normal phase approval.
1	Blocked	Do not run the command. Rewrite it or re-scope first.
2	Review required	Ask for explicit approval or clarification before running.

Hard blocks (always exit 1, never bypassed by yolo):

• Destructive patterns — rm -rf, mkfs, dd of=/dev/..., wipefs, shred /dev/..., fork bombs, chmod -R 0, chown -R, curl|sh/wget|sh.
• Out-of-scope targets — any IPv4/CIDR literal in the command absent from scope.yaml (targets.ip_addresses / in_scope_urls / roles / hostnames). Unknown hostnames return exit 2 (verify authorization).

If the guard cannot classify the target, tool, or phase, treat the command as review-required. Do not use agent judgment to override a blocked result.

---

2. Evidence Handling

2.1 Evidence Types

Type	Storage Location	Format
Raw tool output	$ENG_DIR/evidence/<phase>/<tool>-<target>.txt	Plain text
Screenshots	$ENG_DIR/evidence/<phase>/screenshots/	PNG
Request/response pairs	$ENG_DIR/evidence/<phase>/http/	.req / .resp or markdown
Findings	$ENG_DIR/evidence/reporting/findings.yaml	YAML (structured)
Secrets / tokens	$ENG_DIR/findings/secrets-vault.md	Markdown (must be gitignored)

2.2 Evidence Integrity Rules

• Do not modify raw tool output after saving.
• Do not fabricate evidence. Every finding must be reproducible.
• Timestamp every evidence file with the engagement date.
• Cite evidence in reports using relative paths from $ENG_DIR.

2.3 Chat vs File vs Vault Policy

Content	Chat	Evidence File	Secrets Vault
Target URL/Domain	✅ Full	✅ Full	❌ N/A
Open port / service	✅ Full	✅ Full	❌ N/A
SQLi PoC (1 row)	✅ Parameter used	✅ Full output	❌ N/A
Auth token / JWT	❌ Last 6 only	✅ Full	✅ Full
Cracked password	❌ Last 6 only	✅ Full	✅ Full
API key / secret	❌ Last 6 only	✅ Full	✅ Full
Database dump (sample)	❌ Summary only	✅ Full	✅ Full
User PII (non-target)	❌ Not in chat	❌ Not in evidence	❌ Not anywhere
Screenshot	✅ With sensitive data blurred	✅ High resolution	❌ N/A

2.4 Atomic Finding Rule

Use one finding per atomic security issue. An atomic finding has one root cause, one affected asset or asset class, one reproducible proof, and one remediation owner. Do not bundle several vulnerabilities, assets, or proof paths into one finding just because they share a theme.

Split into separate findings when any of these differ: root cause, affected asset, verification receipt, proof command, remediation owner, CVSS vector, severity, or exploit preconditions.

Use a roll-up only for repeated instances with a shared root cause, shared remediation, and comparable impact. The roll-up must link to each atomic finding and must not replace the individual evidence trail.

2.5 Attack-Chain Correlation

Attack-chain correlation connects individually validated atomic findings into a multi-step narrative without merging their evidence. Each chain record uses:

chain_id: CHAIN-001
step_id: STEP-001
finding_id: FIND-001
prerequisite_findings: []
resulting_access: "unauthenticated SSRF reaches internal admin panel"
chain_impact: "enables the next approved validation step"

The chain impact may raise business priority, but it must not replace the CVSS or receipt for any atomic finding. Every step keeps its own approval, evidence, verification receipt, and remediation owner.

---

3. Severity Scoring

3.1 L1–L4 Finding Levels

Level	Label	Description	CVSS Required?
L1	Identified	Pattern matched — the vulnerability class is present in the code/surface, but no behaviour change was observed. No payload was sent, or the payload was blocked.	No
L2	Partial	Sink reached — the vulnerable code path was exercised, but a defence (WAF, filter, CSP) prevented full exploitation.	No
L3	Confirmed	Payload changed application behaviour — evidence of impact: modified response, altered state, reflected input.	Yes — CVSS 3.1 Base Score required
L4	Critical	Data extracted, code executed, or privilege escalated — direct evidence of compromise with measurable impact.	Yes — CVSS 3.1 Vector + Score required

3.2 CVSS 3.1 Scoring Methodology

For L3 and L4 findings, compute the CVSS 3.1 Base Score:

1. Attack Vector (AV): Network (N) / Adjacent (A) / Local (L) / Physical (P)
2. Attack Complexity (AC): Low (L) / High (H)
3. Privileges Required (PR): None (N) / Low (L) / High (H)
4. User Interaction (UI): None (N) / Required (R)
5. Scope (S): Unchanged (U) / Changed (C)
6. Confidentiality (C): None (N) / Low (L) / High (H)
7. Integrity (I): None (N) / Low (L) / High (H)
8. Availability (A): None (N) / Low (L) / High (H)

Example vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N → Score: 9.1 (Critical)

Use the NVD CVSS Calculator or compute inline with a script.

3.3 CVSS 4.0 Scoring Methodology

For L3 and L4 findings, calculate CVSS 4.0 alongside CVSS 3.1 when feasible. Use the CVSS 4.0 vector as the preferred current scoring record while retaining CVSS 3.1 for historical comparability.

Core CVSS 4.0 metrics to review:

1. Attack Vector (AV) and Attack Complexity (AC)
2. Attack Requirements (AT) — whether exploitation depends on pre-existing deployment conditions
3. Privileges Required (PR) and User Interaction (UI)
4. Vulnerable System Confidentiality (VC), Vulnerable System Integrity (VI), and Vulnerable System Availability (VA)
5. Subsequent System Confidentiality (SC), Subsequent System Integrity (SI), and Subsequent System Availability (SA)

Example vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N → Critical when calculator output is 9.0–10.0.

3.4 Severity Crosswalk

Use templates/cvss4-crosswalk.md for every report-ready L3/L4 finding. The crosswalk records CVSS 3.1, CVSS 4.0, selected report severity, and an anti-under-rating ratify pass.

Severity	CVSS 3.1 Base Score	CVSS 4.0 Base Score
Low	0.1–3.9	0.1–3.9
Medium	4.0–6.9	4.0–6.9
High	7.0–8.9	7.0–8.9
Critical	9.0–10.0	9.0–10.0

The anti-under-rating ratify pass is mandatory before delivery: compare calculator output to the demonstrated evidence and confirm the final severity is not lower than proven confidentiality, integrity, availability, privilege, or data exposure impact.

3.5 Finding Record Format

Every L3/L4 finding in the report should include:

finding:
  id: FIND-001
  title: SQL Injection in /api/products
  severity_level: L3  # L1–L4
  cvss_vector: "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N"
  cvss_score: 7.5
  cvss_severity: HIGH
  cwe: CWE-89
  owasp: A03:2021
  evidence:
    - $ENG_DIR/evidence/exploitation/sqli-products.req.txt
    - $ENG_DIR/evidence/exploitation/sqli-products.resp.txt
  remediation: Use parameterized queries. Sanitize user input.

---

4. Verification

Verification-discipline rules (independent re-check, corroborate ≥2 evidence angles before Validated, "no result ≠ absence", blocker taxonomy) are in references/evidence-and-verification-discipline.md. Flag-capture (FLAGS) mode rules are in references/flags-mode.md.

When checking that this document is being followed, verify:

grep -c '169.254.169.254\|aux-client\|bypass exhaustion\|rate limit\|200ms' skills/pentest/references/standards.md >= 5  ✓
grep -c 'redact\|gitignored\|last 6\|PII\|secrets.vault' skills/pentest/references/standards.md >= 4  ✓
grep -c 'L1 Identified\|L2 Partial\|L3 Confirmed\|L4 Critical\|CVSS 3.1\|CVSS vector' skills/pentest/references/standards.md >= 4  ✓