Skip to main content

vulkro compliance-pack

Produce a self-contained audit-evidence directory mapping findings to specific SOC 2, ISO 27001, or HIPAA control IDs. Distinct from vulkro compliance, which is the in-process profile-evaluation flag: compliance-pack writes a packaged bundle on disk for handoff to auditors.

Usage​

vulkro compliance-pack .                           # default: SOC 2
vulkro compliance-pack . --framework iso27001
vulkro compliance-pack . --framework hipaa --output ./audit-2026-q1

Arguments​

ArgumentDescriptionDefault
PATHProject root..

Flags​

FlagDescriptionDefault
--framework <NAME>soc2, iso27001, or hipaa.soc2
--output <DIR>, -oOutput directory../vulkro-compliance-pack

What the pack contains​

vulkro-compliance-pack/
+-- manifest.json         <- framework, generated_at, scan_id,
|                            control_summary{ control_id: { status,
|                            finding_count, evidence_files } }
+-- summary.md            <- human-readable markdown table of controls
+-- findings.csv          <- flat: control_id, severity, owasp_category,
|                            file, line, message, remediation
+-- README.md             <- what's in this bundle + auditor's read-me
+-- controls/
    +-- CC.6.1.json       <- per-control evidence with file:line refs
    +-- CC.7.1.json
    +-- ...

Control IDs and filenames are framework-specific:

  • SOC 2 - CC.6.1.json, CC.7.2.json, P.1.0.json, etc.
  • ISO 27001 - A.5.15.json, A.8.24.json, etc.
  • HIPAA - 164.312_a__1_.json ((/) sanitised for filesystems).

Mapping table​

Categorisation runs over each finding's OwaspCategory plus message-keyword cues, bucketing into eight classes that map to framework controls:

BucketSOC 2ISO 27001HIPAA
AuthCC.6.1A.5.15, A.8.2164.312(a)(1)
MisconfigCC.6.6, CC.7.1A.5.23, A.8.28164.312(a)(1)
SecretsCC.6.1, CC.6.7A.5.15, A.8.2, A.8.24164.312(a)(1), 164.308(a)(1)(ii)(D)
DependenciesCC.7.1, CC.7.2A.8.28164.308(a)(1)(ii)(D)
PIICC.6.1, P.1.0A.5.15164.312(c)(1), 164.312(e)(1)
PHICC.6.1, P.1.0A.5.15164.312(c)(1), 164.312(e)(1)
CryptoCC.6.7A.8.24164.312(e)(1)
LoggingCC.7.3, CC.4.1A.8.28164.308(a)(1)(ii)(D)

Status per control:

  • Pass - no findings tagged to the control.
  • Partial - only Medium/Low findings.
  • Fail - at least one High/Critical finding.

ScanResult.credentials and ScanResult.git_secrets (which live outside the unified findings array) are promoted into synthetic Secrets-bucket findings so they show up against the right controls.

What an auditor sees​

The summary.md is the auditor's entry point. Example excerpt:

| Control | Status | Findings | Evidence |
|---|---|---:|---|
| CC.6.1 (Logical Access) | Fail | 12 | controls/CC.6.1.json |
| CC.6.6 (Network Filtering) | Partial | 3 | controls/CC.6.6.json |
| CC.7.1 (Detection) | Fail | 41 | controls/CC.7.1.json |
| CC.7.2 (Monitoring) | Pass | 0 | - |
...

Each controls/<id>.json is the structured deep-dive: list of findings tagged to that control, file:line references, severity, and the verbatim remediation guidance. Auditors who want to verify a control independently can jump from summary.md straight to the file:line in source.

Reproducibility​

The pack is reproducible from a tagged commit + the same vulkro version. Pin both in your audit narrative so a re-run produces byte-identical evidence (mod the generated_at timestamp).

Disclaimer​

The pack is one input to an audit, not a complete audit. It captures what the security engine sees in code; it doesn't replace process controls, training records, or vendor risk assessments. The generated README.md says exactly this so an auditor doesn't mistake the scope.

Last updated on