Source aware whitebox testing

Source Aware Whitebox Testing

penkit51 AI — professional penetration testing skill pack. Authorized testing only.

Deep Exploitation Guide

Source-Aware White-Box Coordination

Use this coordination playbook when repository source code is available.

Objective

Increase white-box coverage by combining source-aware triage with dynamic validation. Source-aware tooling is expected by default when source is available.

Recommended Workflow

1. Build a quick source map before deep exploitation, including at least one AST-structural pass (sg or tree-sitter) scoped to relevant paths.
   • For sg baseline, derive sg-targets.txt from semgrep.json scope first (paths.scanned, fallback to unique results[].path) and run xargs ... sg run on that list.
   • Only fall back to path heuristics when semgrep scope is unavailable.
2. Run first-pass static triage to rank high-risk paths.
3. Use triage outputs to prioritize dynamic PoC validation.
4. Keep findings evidence-driven: no report without validation.

Source-Aware Triage Stack

• semgrep: fast security-first triage and custom pattern scans
• ast-grep (sg): structural pattern hunting and targeted repo mapping
• tree-sitter: syntax-aware parsing support for symbol and route extraction
• gitleaks + trufflehog: complementary secret detection (working tree and history coverage)
• trivy fs: dependency, misconfiguration, license, and secret checks

Coverage target per repository:

• one semgrep pass
• one AST structural pass (sg and/or tree-sitter)
• one secrets pass (gitleaks and/or trufflehog)
• one trivy fs pass

Agent Delegation Guidance

• Keep child agents specialized by vulnerability/component as usual.
• For source-heavy subtasks, prefer creating child agents with source_aware_sast skill.
• Use source findings to shape payloads and endpoint selection for dynamic testing.

Validation Guardrails

• Static findings are hypotheses until validated.
• Dynamic exploitation evidence is still required before vulnerability reporting.
• Keep scanner output concise, deduplicated, and mapped to concrete code locations.

Platform Methodology

Source Aware Whitebox Testing

penkit51 AI — professional penetration testing skill pack. Authorized testing only.

Deep Exploitation Guide

Source-Aware White-Box Coordination

Use this coordination playbook when repository source code is available.

Objective

Increase white-box coverage by combining source-aware triage with dynamic validation. Source-aware tooling is expected by default when source is available.

Recommended Workflow

1. Build a quick source map before deep exploitation, including at least one AST-structural pass (sg or tree-sitter) scoped to relevant paths.
   • For sg baseline, derive sg-targets.txt from semgrep.json scope first (paths.scanned, fallback to unique results[].path) and run xargs ... sg run on that list.
   • Only fall back to path heuristics when semgrep scope is unavailable.
2. Run first-pass static triage to rank high-risk paths.
3. Use triage outputs to prioritize dynamic PoC validation.
4. Keep findings evidence-driven: no report without validation.

Source-Aware Triage Stack

• semgrep: fast security-first triage and custom pattern scans
• ast-grep (sg): structural pattern hunting and targeted repo mapping
• tree-sitter: syntax-aware parsing support for symbol and route extraction
• gitleaks + trufflehog: complementary secret detection (working tree and history coverage)
• trivy fs: dependency, misconfiguration, license, and secret checks

Coverage target per repository:

• one semgrep pass
• one AST structural pass (sg and/or tree-sitter)
• one secrets pass (gitleaks and/or trufflehog)
• one trivy fs pass

Agent Delegation Guidance

• Keep child agents specialized by vulnerability/component as usual.
• For source-heavy subtasks, prefer creating child agents with source_aware_sast skill.
• Use source findings to shape payloads and endpoint selection for dynamic testing.

Validation Guardrails

• Static findings are hypotheses until validated.
• Dynamic exploitation evidence is still required before vulnerability reporting.
• Keep scanner output concise, deduplicated, and mapped to concrete code locations.

Validation & Reporting

• Confirm every finding with reproducible PoC before reporting
• Document: severity (CVSS), affected asset, steps, evidence, remediation
• Use record_vulnerability when running inside the penkit51 platform
• Chain low-severity findings into higher-impact attack paths
• Never report without evidence — distinguish hypothesis from confirmed vuln

Validation & Reporting

• Confirm every finding with reproducible PoC before reporting
• Document: severity (CVSS), affected asset, steps, evidence, remediation
• Use record_vulnerability when running inside the penkit51 platform
• Chain low-severity findings into higher-impact attack paths
• Never report without evidence — distinguish hypothesis from confirmed vuln