Skip to main content

vulkro compliance

Pro

vulkro compliance is part of Pro: Compliance evaluator (compliance), findings mapped to the control they break. On Free it stops before doing any work, prints what it needs and where to get it, and exits 1. See Pricing.

Run a compliance evaluation against a profile. Each finding the security engine produced is mapped to the relevant control(s); unmet controls are listed with the citation that flags them, ready for an audit handoff.

Usage​

vulkro compliance . --profile soc2
vulkro compliance . --profile pci --format json

Flags​

FlagDescriptionDefault
--profile <NAME>One of owasp-asvs, pci, soc2, hipaa, nist-ssdf, iso27001, cis, cwe-top25.owasp-asvs
--format <FMT>Output format.table

What's mapped​

Every finding category emits a compliance_controls list. The same finding typically satisfies multiple frameworks - e.g. a CSRF detection maps to ASVS V13, OWASP A05:2021, PCI 6.5.9, and CIS 16.10 simultaneously.

The desktop console's Compliance tab renders pass/fail per control with direct links to the underlying findings, so an auditor can ask "show me how you meet PCI 6.5.7" and you can answer in one click.

Profiles​

ProfileCoverage
owasp-asvsASVS L1 + L2 chapters V1-V14
owasp-top10OWASP Top 10:2021 categories A01-A10
pciPCI-DSS 4.0 requirements 6, 11
soc2Trust Services Criteria CC6 (Logical Access), CC7 (System Operations)
hipaaSecurity Rule Sec.164.312
nist-ssdfSP 800-218 PS, PW, RV practices
iso27001Annex A.5, A.8, A.14
cisCIS Critical Security Controls v8
cwe-top25CWE Top 25 Most Dangerous

Command reference​

Generated from vulkro help compliance on vulkro 0.26.0. This block is the authoritative flag, usage, and exit-code reference for this command; the prose above is the friendly explanation. Do not edit this block by hand; run npm run docs:cli after a release.

[Pro] Check findings against a compliance framework such as SOC 2 or PCI DSS.

[Pro] Run a compliance evaluation against a profile.

Controls are evaluated over the same finding set `vulkro scan` shows: the default confidence floor and unreachable-code suppression are applied. `--all-confidence` evaluates the raw pool instead and says so on the count line.

Exit code: 0 report rendered, 2 on an unknown profile or a scan / IO error. It reports control coverage rather than failing on findings, so it never returns 1.

Usage: vulkro compliance [OPTIONS] [PATH]

Arguments:
  [PATH]
          [default: .]

Options:
      --offline
          Hard-disable every outbound network call for this run (sets VULKRO_OFFLINE=1). Blocks the CVE feed, the license heartbeat, the update check, webhooks, and any cloud AI endpoint; a loopback model (http://127.0.0.1, http://localhost) is still allowed. Equivalent to exporting VULKRO_OFFLINE=1, and the flag wins when both are set

      --profile <PROFILE>
          owasp-asvs | owasp-web | pci | soc2 | hipaa | nist-ssdf | nist-800-53 | stateramp | iso27001 | cis | cwe-top25 | gdpr
          
          [default: owasp-asvs]

      --all-confidence
          Evaluate every finding instead of the set `vulkro scan` shows by default. The count line says which pool it used

  -f, --format <FORMAT>
          Possible values:
          - table
          - json
          - sarif
          - gh-pr
          - gh-pr-inline-comments: GitHub PR per-finding **inline review comments**. NDJSON, one `{path, line, side, severity, rule_id, fingerprint, body}` object per line. Designed to be piped straight to a `gh api` loop so `vulkro gate` can drop comments next to the offending line on the Files Changed tab without going through a GitHub App. See the GitHub CLI integration guide at vulkro.com/docs
          - github-annotations:    GitHub Actions / GitLab CI **PR annotations**. One workflow-command line per finding (`::error file=...,line=...,endLine=...,title=<rule id>::<message> (<helpUri>)`). Printed straight to a CI job's stdout, GitHub turns each line into an inline annotation pinned to `file:line` on the Files Changed tab; GitLab CI's annotation parser reads the same grammar. When run against a baseline (`--gate-vs` / a `gate` flow) only NEW findings are annotated so a first run does not paper the PR
          - gitlab-mr:             GitLab Merge-Request comment: GitLab-flavored Markdown with collapsible blocks
          - bitbucket-pr:          Bitbucket Pull-Request comment: flat Markdown (Bitbucket does not render `<details>`)
          - azure-pr:              Azure DevOps Pull-Request comment: flat Markdown (shared with Bitbucket)
          - junit
          - csv
          - cyclonedx:             CycloneDX 1.6 JSON SBOM (uses `ScanResult.packages`)
          - cyclonedx-1.7:         CycloneDX 1.7 JSON SBOM. Same component shape as `cyclonedx`; emits the newer `specVersion`. Offered alongside 1.6 (which stays default)
          - spdx:                  SPDX 2.3 JSON SBOM
          - spdx3:                 SPDX 3.0.1 JSON-LD SBOM (`@context` + `@graph` of typed elements). Offered alongside SPDX 2.3, which stays the default for `--format spdx`
          - cbom:                  CycloneDX 1.6 CBOM (Cryptographic Bill of Materials): one `cryptographic-asset` component per detected weak algorithm (MD5, SHA-1, ECB, RC4, DES, static IV, insecure RNG), with file:line occurrences inlined under `evidence.occurrences`. Compliance buyers (FedRAMP, post-quantum readiness reviews) ask for this as a distinct artefact from the library SBOM
          - openvex:               OpenVEX 0.2.0 exploitability statements for each dependency CVE (`affected` / `not_affected` / `under_investigation`), with `not_affected` backed by reachability analysis. Pairs with an SBOM
          - cyclonedx-vex:         CycloneDX 1.6 VEX: the same exploitability verdicts as `openvex`, in a CycloneDX `vulnerabilities[].analysis` document
          - cbom-1.7:              CycloneDX 1.7 CBOM. Same crypto-asset grouping as `cbom` plus a richer post-quantum descriptor. Offered alongside 1.6 (default)
          - pdf:                   PDF render of the executive HTML report (requires `wkhtmltopdf` on PATH)
          - ropa-md:               GDPR Article 30 Records-of-Processing template - Markdown
          - ropa-html:             GDPR Article 30 Records-of-Processing template - HTML
          - ndjson:                Newline-delimited JSON: one finding per line plus a trailing summary line. Designed for SIEM ingestion and `jq` filter pipelines
          - evidence-graph:        Evidence-graph JSON (`evidence-graph/1.0`): a stable, versioned, AI-consumable document that composes endpoints, taint source -> sink flows, reachability verdicts, findings, and the dependency SBOM into one graph. Meant to be handed to an external AI agent as deterministic ground truth (Vulkro embeds no model; the agent brings its own). Pairs with `vulkro aggregate` for cross-repo linking. See `docs/ai-tool/`
          
          [default: table]

  -h, --help
          Print help (see a summary with '-h')
Last updated on