Container Compliance Audit Engine. Continuous, Not Point-in-Time.
HarborGuard collects compliance evidence continuously from every scan and generates framework-mapped reports on demand. SOC 2, CIS Docker Benchmark, NIST 800-53, PCI-DSS, FedRAMP, ISO 27001, HIPAA, and CMMC — backed by a self-auditing audit log.
CC7.1
Detection & Monitoring
CC7.2
Incident Response
CC7.4
Vulnerability Remediation
CC6.1
Logical Access Controls
CC2.2
Risk Assessment
10
Built-in compliance frameworks
Continuous
Evidence collection model
Continuous
SLA breach monitoring
Self-auditing
Audit log (reads + exports logged)
What it does
Compliance evidence that accumulates every time you scan.
Most compliance processes for container security work like this: a few weeks before an audit, someone runs a scanner, exports the results, and hands a CSV to an auditor. The auditor gets a snapshot of what the environment looked like on one day. This is point-in-time compliance — and SOC 2 Type II, FedRAMP Moderate, and NIST 800-53 are not point-in-time standards. They require evidence of continuous operation.
HarborGuard collects evidence as a side effect of every scan. Scan execution timestamps, scanner database freshness, vulnerability counts by severity, SBOM artifacts, CIS Docker hardening findings, SLA adherence records, and audit events all accumulate in the evidence store as you operate. When you trigger a compliance report, the engine queries the evidence that was collected over the selected period — not a one-time export.
Every control in every framework is evaluated against live data: is your scan coverage above the threshold? Have CRITICAL findings been remediated within the SLA? Are SBOM artifacts present for in-scope images? Control outcomes are stored per framework report and compared to the prior period so regressions generate immediate notifications — not surprises at the next audit.
How it works
Container compliance audit engine, step by step.
Configure the compliance policy
The compliance policy is the single source of truth for all compliance behavior. Set it in the Compliance Policy modal in the dashboard. The policy defines severity thresholds, SLA windows per severity, notification routing, SBOM requirements, and which frameworks are in scope. Every change is captured in the audit log.
Evidence is collected continuously from every scan
Every scan that completes adds evidence to the compliance data store: scan execution timestamps, scanner database freshness, vulnerability counts per severity, SBOM artifacts, and hardening findings from Dockle. This evidence accumulates continuously — not just when you request a report.
Select a framework and trigger report generation
From the compliance dashboard, select a framework (SOC 2, CIS Docker, NIST 800-53, etc.) and a reporting period. The report worker picks up the job from the platform's job queue and runs the report engine against the continuously collected evidence.
The report engine evaluates each control
The report engine iterates through the framework's control definitions. Each control specifies which data queries to run, which metrics to evaluate, and what pass/fail thresholds apply. Controls can have full, partial, or out-of-scope coverage depending on what HarborGuard can observe from container layer data alone.
Control outcomes are compared to the prior report
After generation, the control-failure notification hook compares the new report's control outcomes to the most recent prior report for the same framework. Controls that regressed from PASS to WARNING or from WARNING to FAILED trigger control-failed notifications routed through your configured channels.
SLA breach monitoring runs continuously
The SLA breach worker runs on a continuous schedule. It evaluates all open vulnerabilities against the current time and fires SLA-warning notifications for findings approaching breach and SLA-breach notifications for findings past their deadline. Breach events are recorded in the audit log as evidence of SLA-driven remediation process.
The audit log exports as signed evidence
Every policy change, report generation, attestation, and scan is captured in the audit log. The audit log is itself audited — reads and exports are logged. Compliance packs for several frameworks (SOC 2 CC7.1, FedRAMP CA-7) include the audit log as an evidence artifact, providing auditors with a tamper-evident record of the compliance process.
Ten built-in compliance frameworks
SOC 2 Type II
CC7.1 detection, CC7.2 response, CC7.4 remediation
CIS Docker Benchmark v1.6.0
§4 image layer hardening, Dockle findings mapped
NIST 800-53 Rev 5
SI-2 flaw remediation, RA-5 vulnerability scanning
NIST 800-190
Container-specific security guide
NIST 800-171
CUI protection for defense contractors
PCI-DSS v4.0
Req 6 software security, Req 11 testing
FedRAMP Moderate
Control mapping only; platform is not FedRAMP-authorized. CA-7, SI-2 templates
ISO 27001:2022
Control mapping only; HarborGuard is not ISO 27001 certified. A.12.6 templates
HIPAA Security Rule
HIPAA Security Rule control mapping (HarborGuard does not process PHI and does not act as a Business Associate)
CMMC Level 2
RM.2.142 vulnerability remediation
HIPAA control mapping
HarborGuard maps your container security posture (image scanning, vulnerability remediation, audit evidence) to the HIPAA Security Rule's technical safeguards. HarborGuard processes only technical metadata — SBOMs, vulnerability data, image manifests, compliance mappings — and does not receive, store, or transmit Protected Health Information (PHI). HarborGuard is not a Business Associate as defined in 45 CFR 160.103 and does not require a BAA. Your team remains responsible for the PHI side of your HIPAA program; we provide the container-security evidence.
FedRAMP, ISO 27001, and SOC 2 scope
HarborGuard provides control mapping aligned to FedRAMP Moderate, ISO 27001:2022, and SOC 2 Type II. The platform itself is not FedRAMP-authorized and is not ISO 27001 certified. SOC 2 Type II controls are implemented internally; a formal third-party audit is planned for 2026. These framework templates are designed for customers operating their own compliance boundaries.
Policy as code: the compliance policy modal
The Compliance Policy modal is the single source of truth for all compliance-affecting settings. Admins and owners can read and write the policy; auditors have read-only access. Every write to the policy is recorded in the audit log with a before/after diff.
The policy controls: minimum severity threshold for triage entry, SLA windows per severity, notification routing (Slack, PagerDuty, email per event type), SLA breach lead time (notification advance), required SBOM format, and framework scope selections. A preview API computes SLA delta impact and section-level regression warnings before you commit a policy change.
When you update SLA windows, you can trigger an SLA backfill that recomputes deadlines for all currently open findings. This ensures new policy commitments apply retroactively to existing risk, not just new findings from the next scan cycle.
The self-auditing audit log
Every policy-visible action in HarborGuard is captured in the audit log: policy changes, report generations, scan starts and completions, false-positive attestations, patch operations, triage run state transitions, and user access events. The audit log itself is audited — reads and exports of audit data are logged as events, providing a chain of custody.
The audit log is an evidence artifact included in compliance packs for SOC 2 (CC7.1, CC7.2), FedRAMP (CA-7), and ISO 27001 (A.12.4) controls. Auditors receive a signed export covering the reporting period. The export format includes event ID, timestamp, actor, action, target, and IP address — enough for an auditor to reconstruct the operational timeline.
The audit log has no purge mechanism exposed to users. Records accumulate indefinitely and can only be exported, not deleted — ensuring the evidence base is immutable.
Control regression notifications: preventing compliance drift
Compliance drift is the gap that opens between your last audit report and the current state of your systems. Most container security platforms do nothing to close that gap until the next report is run. HarborGuard runs the control-failure notification hook after every report generation. If any control regressed from the prior period — PASS to WARNING, or WARNING to FAILED — a notification fires immediately through your configured channels.
Behind every compliance report is a short, well-defined lifecycle. Each step has a clear input and a clear output, and the regression-detection step at the end is what turns a static report into continuous compliance.
Report requested
An admin or owner selects a framework and reporting period from the dashboard, or a scheduled job fires on its cadence. The request is scoped to the organization and queued on the platform's job queue.
Evidence assembled
The report engine assembles the evidence the framework requires: scan execution history, image coverage, SBOM artifacts, severity distribution, SLA adherence, audit events, scanner database freshness, and per-image hardening findings.
Controls evaluated
Each control in the framework's definition is evaluated against the assembled evidence. The engine emits a PASS, WARNING, or FAILED status per control, with a finding message and a recommendation.
Report rendered and exported
The bundle is rendered as a PDF, CSV, or JSON export ready for an auditor. The report itself is recorded in the audit log, creating a closed evidence loop.
Regressions trigger notifications
The new control outcomes are diffed against the most recent prior report for the same framework. Any control that regressed from PASS to WARNING or WARNING to FAILED fires a control-failed notification through your configured channels.
SLA monitoring runs continuously
On a continuous schedule, the SLA breach worker evaluates every open vulnerability against its deadline. Findings approaching breach fire warning notifications; findings past their deadline fire breach notifications. Every event is recorded as evidence.
Evidence artifacts per framework
Each compliance framework specifies which evidence categories supply data for each control. The evidence base is the same across frameworks — the mapping from category to control varies. Here are the key evidence categories and what they supply:
Scan execution history
Timestamps, scanner IDs, and status for every scan in the period. Satisfies 'continuous monitoring' controls (SOC 2 CC7.1, FedRAMP CA-7, NIST RA-5).
Scan coverage
Percentage of the in-scope image inventory that was scanned at least once in the period. Low coverage triggers WARNING on detection controls across all frameworks.
SBOM artifacts
SPDX and CycloneDX SBOM artifacts per scan. Required evidence for FedRAMP SI-2, CMMC RM.2.142, and NIST 800-53 SA-17. Syft generates these on every scan.
Vulnerability summary
Severity distribution of findings (critical/high/medium/low counts, fixable vs unfixable). Powers the main vulnerability posture metrics across all frameworks.
SLA compliance
Percentage of findings remediated within their SLA deadline. The primary evidence for remediation process controls (SOC 2 CC7.4, NIST SI-2, FedRAMP SI-2).
MTTR report
Mean time to remediation (MTTR) by severity, derived from remediation timestamps set when patches land or findings are closed. Shows remediation velocity over the period.
Raw scan results
Per-image finding detail including CVE IDs, packages, fixed versions, and Dockle hardening results. CIS Docker Benchmark controls consume this for per-image pass/fail determination.
Audit log entries
Policy changes, attestations, and admin actions. SOC 2 CC2.2 (risk assessment communication) and FedRAMP CA-7 (continuous monitoring) controls require evidence of ongoing management activity.
Explore related capabilities
Questions about the container compliance audit engine
What compliance frameworks does HarborGuard support?
HarborGuard ships with ten built-in compliance framework definitions: SOC 2 Type II, CIS Docker Benchmark v1.6.0, NIST 800-53 Rev 5, NIST 800-190 (container security guide), NIST 800-171 (CUI protection), PCI-DSS v4.0, FedRAMP Moderate, ISO 27001:2022, HIPAA Security Rule, and CMMC Level 2. Each framework definition specifies the required controls, which data queries supply the evidence, what metrics determine pass/fail, and the narrative text that explains each control's relevance to container security. The framework registry is extensible — enterprise customers can request custom framework templates.
What is the compliance policy modal and why is it the single source of truth?
The Compliance Policy modal is the authoritative location for all policy settings that affect compliance behavior. It stores severity thresholds (which CVEs enter the triage queue), SLA windows per severity (how many days before a breach notification fires), notification routing (which channels receive which event types), SBOM requirements, and which frameworks are in scope. All policy reads throughout the system — the triage pipeline, the SLA breach worker, CVE Watch scoping, and report generation — read from a single organization-level policy record, which is what the policy modal writes to. There is no other place where these settings live.
How is HarborGuard's compliance evidence different from a point-in-time audit?
Traditional compliance evidence for container security is collected at audit time: someone runs a scanner, exports results, and hands a spreadsheet to the auditor. HarborGuard collects evidence continuously as scans run. When you generate a report, the engine queries evidence accumulated over the selected period — scan execution logs, SBOM artifacts, vulnerability timelines, SLA compliance records, and audit events. The report reflects what actually happened over the period, not what the environment looked like at one moment. For SOC 2 Type II, this is the distinction between a Type I (point-in-time) and Type II (over a period) opinion — HarborGuard is built for Type II.
What is the CIS Docker Benchmark and how does HarborGuard cover it?
The CIS Docker Benchmark v1.6.0 is a set of prescriptive recommendations for securing Docker containers and images, published by the Center for Internet Security. Section 4 (Container Images and Build Files) covers the requirements HarborGuard can evaluate from image layer data: running as non-root (4.1), removing unnecessary packages (4.3), using trusted base images (4.2), and scanning for vulnerabilities (4.5). HarborGuard maps Dockle findings directly into CIS Docker Benchmark controls in compliance reports. Dockle is the only open-source tool purpose-built to check CIS Docker §4 requirements from image layer inspection, and HarborGuard runs it as part of every scan.
How does the SLA breach worker relate to compliance evidence?
Compliance frameworks like SOC 2 (CC7.4) and NIST 800-53 (SI-2) require evidence that vulnerabilities are remediated within a defined timeframe. HarborGuard's SLA breach worker enforces those timeframes by firing notifications when deadlines approach or pass. More importantly, the breach worker's actions are recorded in the audit log — every SLA-breach and SLA-warning event includes the CVE ID, severity, deadline, and the image it affects. Compliance reports include SLA compliance metrics: what percentage of findings were remediated within their SLA, how many are currently breached, and the distribution of mean-time-to-remediation (MTTR). These metrics directly populate evidence for SI-2 and CC7.4 controls.
What is the control-failure notification and how does it prevent compliance drift?
After every report is generated, the control-failure notification hook compares the new control outcomes to the most recent prior report for the same framework. If a control regressed — from PASS to WARNING, or from WARNING to FAILED — a control-failed notification fires immediately. The notification includes the control ID, control name, the old status, the new status, and the finding message. This prevents compliance drift: instead of discovering at the next quarterly audit that three controls failed three months ago, you get an immediate alert the day the regression happens. The notifications route through the same channels as triage and SLA alerts: Slack, PagerDuty, email, or webhooks.
Stop scrambling before every audit
Start your 14-day trial. Continuous compliance evidence from your first scan.
Connect a registry, run your first scan, and your compliance evidence base starts accumulating immediately. Generate a SOC 2 or CIS Docker report the same day.