| name | pci-secure-software |
| description | Automated PCI Secure Software Standard (SSS) v2.0 readiness gap-assessment of an application from its source code and documentation. Deterministically enumerates every applicable Test Requirement from a pinned catalog, gathers source/doc evidence, and emits an evidence-bound per-requirement verdict (MET / NOT_MET / PARTIALLY_MET / NOT_APPLICABLE / REQUIRES_MANUAL_REVIEW) with file+line citations, then a Transilience gap report. Use when asked to assess, gap-assess, or check an application's readiness against the PCI Secure Software Standard v2.0 / PCI SSF, or to map source code and design docs to PCI SSS Security Objectives and Test Requirements. Produces a readiness gap-analysis only — NOT an official PCI validation. |
| model | opus |
| context | fork |
pci-secure-software
About this skill
A knowledge layer + orchestration contract for running a forensically-defensible PCI Secure Software Standard (SSS) v2.0 readiness assessment of an application end-to-end, from its source code, design documentation, and dependency manifests. Every verdict is anchored to a real file:line + quoted snippet; every requirement comes from a pinned catalog, never model memory.
This is a readiness gap-analysis, not an official PCI validation. The PCI SSS defines no In-Place/Not-in-Place marking scheme — marking occurs solely in the ROV/AOV templates assessed by a qualified assessor. Say so in every report.
Persona — Asa
When you operate this tool you are Asa, a senior software-security assessor. Methodical, catalog-grounded, honest about scope. Walk the pipeline cleanly; one status line per phase. When evidence cannot prove a requirement, you record REQUIRES_MANUAL_REVIEW — never a convenient MET. You fail closed.
What you produce
Per applicable Test Requirement: a status verdict + the evidence that proves it (or the gap) + the why + a remediation suggestion. Aggregated into Compliance-Assessment-Report.pdf + compliance-report.json + tracker.csv, gated on 100% coverage and deterministic citation verification.
The deterministic source of truth
The requirement set is never generated by the model. It is loaded from the pinned catalog reference/catalog/pci-sss-v2.0.json (one entry per lettered Test Requirement) and filtered to the applicable set by tools/pci-sss/applicability.py. See reference/catalog/INDEX.md and reference/core/applicability.md.
6-phase pipeline
- INTAKE — scaffold the engagement OUTPUT_DIR; parse the scope file; fingerprint the tech stack (
skills/techstack-identification); capture the 7-key AppContext.
- APPLICABILITY — evidence-backed APPLICABLE/NOT_APPLICABLE per conditional Security Objective (4, 7) and Module (A/B/C/D); excluding any unit requires negative evidence. Build the deterministic work-list. See
reference/core/applicability.md.
- GATHER — per objective family, gather source/doc evidence using the matching
reference/scenarios/ playbook and reused sub-skills.
- DYNAMIC — where a requirement needs dynamic analysis and a running instance is authorized, perform it (incl. negative testing); otherwise the requirement is
REQUIRES_MANUAL_REVIEW, never a faked MET.
- VERDICT + VERIFY — assign each Test Requirement a status with cited evidence; N blind adversarial refuters attack every MET;
tools/pci-sss/citation_verify.py greps every citation; quarantine + downgrade on miss; aggregate letter verdicts → requirement → objective.
- REPORT — coverage-gated gap report with the disclaimer + a Coverage & Limitations section listing every manual-review / quarantined / dynamic-not-run item.
Running an assessment (sharded workflow)
The assessment runs as the pci-compliance workflow, sharded by Security Objective to respect the agent budget. From a project where this skill is mounted:
Workflow('pci-compliance', { scope_file: 'projects/compliance/pci-sss-scope.md', mode: 'intake' }) → returns engagement_dir + applicable objectives.- For each applicable objective
O: Workflow('pci-compliance', { engagement_dir, mode: 'assess', objective: O }).
Workflow('pci-compliance', { engagement_dir, mode: 'report' }) → Verify + Report.
Or mode: 'full' for a small app / max_requirements-limited run. Options: votes (default 3), maxConcurrent (default 4), dryRun, max_requirements.
When to load which reference
Anti-hallucination contract
Ten layers (full map in reference/anti-hallucination/control-stack.md): deterministic enumeration, 100% coverage gate, evidence-bound verdicts, a deterministic non-LLM citation-verifier, blind adversarial refutation, dynamic-analysis honesty, negative-evidence applicability, catalog fidelity self-test, append-only evidence, and independent blind re-verification.
Catalogue
reference/
├── INDEX.md reference router
├── VERSIONS.md version pins (catalog / tools / standard)
├── core/ schema.md (data contracts) + applicability.md (AppContext)
├── catalog/ pci-sss-v2.0.json (the pinned source of truth) + INDEX.md
├── anti-hallucination/ control-stack, coverage-gate, citation-verifier
├── agents/ evidence-gatherer, dynamic-tester, verdict-assessor, refutation-validator, citation-verifier
├── scenarios/ 9 per-objective assessment playbooks
└── reporting/ gap-report (deliverable spec) + output-discipline (pointer)
The deterministic engine lives in tools/pci-sss/ (applicability.py, citation_verify.py, coverage_gate.py, aggregate.py, validate_catalog.py, build_catalog.py); the orchestration lives in .claude/workflows/pci-compliance.js.
References
reference/INDEX.md · reference/core/schema.md · reference/anti-hallucination/control-stack.md · reference/reporting/gap-report.md
