Our auditors

Every finding Pencheff produces is automatically mapped to up to ten compliance frameworks so that a single scan becomes a single piece of audit evidence across your entire security programme.

Web / cloud / data frameworks

Framework	Scope	Controls covered
OWASP Top 10 (2021)	Web / API	A01–A10
PCI-DSS 4.0	Card data environments	2.2, 4.1, 6.2, 6.5.x, 7.x, 8.x
NIST 800-53 Rev 5	US federal / FedRAMP	AC, AU, CM, IA, SC, SI
SOC 2	Service orgs	CC6.x, CC7.x, A1.x
ISO 27001:2022	International ISMS	Annex A.5.x, A.8.x
HIPAA	Healthcare (US)	164.308, 164.312
OWASP Mobile Top 10 (2024)	Mobile apps	M1–M10

AI / LLM frameworks

LLM red-team findings automatically attach mappings for the AI-specific governance frameworks. Each finding's compliance.MITRE ATLAS / NIST AI RMF / EU AI Act keys map the underlying OWASP LLM category onto the relevant controls.

Framework	Scope	Mapping
OWASP LLM Top 10 (2025)	LLM applications	LLM01–LLM10
MITRE ATLAS	Adversarial ML threat model	AML.T0010–AML.T0058
NIST AI Risk Management Framework	US guidance	MAP / MEASURE / MANAGE functions
EU AI Act	EU regulation	Articles 10, 13, 14, 15, 17, 50, 55

Example LLM01 finding (prompt injection) maps to:

{
  "owasp": "LLM01: Prompt Injection",
  "compliance": {
    "OWASP":      ["LLM01: Prompt Injection"],
    "MITRE ATLAS": ["AML.T0051", "AML.T0054"],
    "NIST AI RMF": ["MAP 1.5", "MEASURE 2.7", "MANAGE 2.3"],
    "EU AI Act":   ["Article 15", "Article 55"]
  }
}

How the mapping works

Each finding carries a category (e.g. injection, auth, crypto, components) and an owasp_category. The reporting layer in reporting/compliance.py maps those onto control identifiers for every framework.

Example (a SQL injection finding):

{
  "owasp": "A03: Injection",
  "compliance": {
    "OWASP":      ["A03: Injection"],
    "PCI-DSS":    ["6.5.1"],
    "NIST-800-53": ["SI-10", "SI-16"],
    "SOC2":       ["CC6.1", "CC6.6"],
    "ISO27001":   ["A.8.24", "A.8.28"],
    "HIPAA":      ["164.312(a)(2)(iv)", "164.312(c)(1)"]
  }
}

Focused profiles

Use targeted profiles when an audit asks for a specific framework:

• compliance — 5-framework breadth, OWASP-first
• compliance-full — every module + SCA + IaC, all six frameworks
• pci-dss / soc2 — single-framework policy YAML

Report exports

Compliance mappings appear in:

• DOCX reports — per-finding table + framework summary appendices
• JSON exports — compliance: { FRAMEWORK: [controls] } on every finding
• CSV exports — one column per framework, comma-separated controls
• SBOMs — declared license + PURL for A06 (Vulnerable Components) support

Custom mappings

Add additional frameworks (e.g. CIS Controls, NERC-CIP) by extending the maps in plugins/pencheff/pencheff/config.py — PRs welcome.

Pencheff maps findings to SOC 2 Trust Services Criteria (primarily Security / Common Criteria CC6–CC7 and Availability A1).

TSC	Example controls	Coverage
CC6.1 — Logical access controls	CC6.1, CC6.2, CC6.3	scan_auth, scan_authz, scan_oauth, scan_mfa_bypass
CC6.6 — Boundary protection	CC6.6	CORS, SSRF, clickjacking, WebSocket security
CC6.7 — Encryption	CC6.7	scan_infrastructure (TLS)
CC7.1 — Detection / monitoring	CC7.1	Passive scanner, change detection via ASM
CC7.2 / CC7.3 — Anomaly handling	CC7.2, CC7.3	Continuous profile + retest automation
CC8.1 — Change management	CC8.1	SBOM + dep scan in CI/CD gate
A1.1 — Availability / capacity	A1.1	scan_business_logic (rate limiting, race), cloud misconfig

Policy example

apiVersion: pencheff/v1
kind: ScanPolicy
metadata: { name: soc2 }
spec:
  targets: [{ url: "${TARGET_URL}" }]
  modules:
    - { name: scan_infrastructure, depth: standard }
    - { name: scan_auth,           depth: standard }
    - { name: scan_authz,          depth: standard }
    - { name: scan_cloud,          depth: standard }
    - { name: scan_dependencies,   params: { path: "./" } }
    - { name: generate_sbom,       params: { path: "./", format: spdx } }
  thresholds: { fail_on: high }
  reports:
    - { format: docx, path: "./reports/soc2/" }

Evidence packet

The DOCX report has a SOC 2 Control Mapping appendix with one row per CC control, showing findings and remediation status — suitable for submission to your auditor as Type II evidence.

Pencheff covers the PCI-DSS v4.0 technical requirements most commonly exercised by external auditors. Use the pci-dss or compliance-full profile.

Requirements covered

Requirement	Meaning	Pencheff module
2.2	Secure configuration	scan_infrastructure, scan_dockerfile, scan_kubernetes
4.1	Strong cryptography	scan_infrastructure (SSL/TLS)
6.2	Bespoke / custom software secure development	SCA + IaC + DAST
6.5.1	Injection flaws	scan_injection
6.5.7	Cross-site scripting	scan_client_side, scan_dom_xss
6.5.8	Broken access control	scan_authz
6.5.10	Broken authentication / session mgmt	scan_auth, scan_oauth, scan_advanced
6.6	Web application firewall or code review	scan_waf
7.1 / 7.2	Access control	scan_authz
8.1 / 8.2 / 8.3	Strong authentication + MFA	scan_auth, scan_mfa_bypass
11.3	Internal + external vuln scans	scan_host_vulns, scan_network_misconfig

Report

pencheff run-policy policies/examples/pci_dss.yaml

The resulting DOCX includes a PCI-DSS 4.0 mapping table listing every requirement touched by the scan, and the findings that hit each.