Compliance mapping

Secronyx appears in a compliance programme in two roles. As a component, its authentication, authorization, redaction and audit log are controls that your assessor will want to see evidence for. As a collector, its compliance and security scope tools produce dated statements about the hosts it runs on. This page covers both, and it is careful about what it claims: the project holds no certification, the only framework mapping the repository documents is for the audit log, and the compliance-check tools implement a subset of each benchmark rather than the whole. Where the older documentation and the code disagree, this page follows the code.

What is and is not claimed

• No certification. Nothing in the repository asserts that the software, or a host running it, is SOC 2, ISO 27001, PCI DSS or HIPAA compliant. Compliance is a property of your programme, of which this software is one part.
• The audit subsystem's documentation (docs/security/audit.md) states that it supports the audit trail requirements of SOC 2 Type II, ISO 27001, HIPAA, PCI-DSS and GDPR. That is the mapping reproduced below, and it is a statement about what the log records, not an attestation.
• get_compliance_check labels its checks with CIS, PCI-DSS, HIPAA and STIG identifiers. The set of checks is small and fixed; treat the output as evidence for the controls it names, not as a benchmark scan.

The server as a control

The controls an assessor typically asks about, with the mechanism and the evidence to hand them:

Audit log mapping

The audit documentation maps the log to the following requirements. The wording is the project's own:

The same document lists minimum retention periods to configure --audit-max-files against: one year for SOC 2 and PCI-DSS, six years for HIPAA, and the duration of processing plus three years for GDPR. Confirm these with your assessor; they are the project's reading of the frameworks, not a legal position. Rotation deletes files beyond --audit-max-files, so for long retention ship the files off-host before that happens, as described under Audit logging.

Two properties of the chain matter to an assessor. First, it is unkeyed: each hash is a SHA-256 of the event fields and prev_hash, so it detects modification, insertion or deletion by anyone who cannot rewrite the whole file, but a party with write access to the file and knowledge of the format could regenerate a consistent chain. Shipping events to a separate system as they are written is what turns tamper-evident into tamper-resistant. Second, the chain continues across rotation, so --audit-verify run against a file whose first event already carries a prev_hash — any live file that has been rotated at least once — reports hash chain broken at event 1 (seq=N); verify the concatenation of the rotated files followed by the live file instead, as the audit page shows.

The server as a collector

Five tools in the compliance scope produce the host-side evidence. All are registered by default; none need --enable-sensitive.

Frameworks by platform

The framework argument is matched case-insensitively in the platform collector. The tool description advertises cis, pci, hipaa, stig; the sets actually implemented are:

An earlier phase document described soc2 and nist frameworks; the code has no such sets and those values fall through to Basic Security. Each check carries status of pass, fail, skip or manual; score_percent is passed divided by the checks that are neither skip nor manual, so a result with only manual checks scores 100. The identifiers are the project's own labels for the benchmark items they approximate; they are not a licensed reproduction of a benchmark and should be cited as "checked by secronyx get_compliance_check", with the check's title, actual and expected fields as the evidence.

Most get_security_scan findings on macOS reference the CIS macOS Benchmark section they correspond to (for example SEC-003, "FileVault not enabled", references CIS macOS Benchmark 2.5.1); the SIP and Gatekeeper findings reference the Apple Security Guide instead. Every finding carries a remediation. The score starts at 100 and deducts 25 per critical, 15 per high, 8 per medium, 3 per low and 1 per info finding, floored at 0; the grade is A at 90 or above, then B, C and D per ten points, and F below 60.

Supporting tools in other scopes

Assessors usually want the underlying configuration alongside the check result. The security scope covers get_linux_auditd_status, get_linux_kernel_lockdown, get_linux_sysctl_security, get_linux_mac_detailed, get_linux_auto_updates, get_windows_audit_policy, get_windows_local_security_policy, get_windows_gpo_applied, get_windows_defender_status, get_bitlocker_status, get_windows_credential_guard, get_macos_filevault_status, get_macos_sip_status, get_macos_gatekeeper_status and get_macos_mdm_profiles. get_password_policy is in state; get_admin_account_summary and get_ssh_security_summary in triage. Software inventory for a supply-chain control comes from get_sbom_cyclonedx (CycloneDX 1.4), get_sbom_spdx and the package tools in software. Of the tools named here, only get_certificates, get_user_accounts, get_sudo_config and get_ssh_config require the sensitive scope.

Assembling an evidence pack

A repeatable collection has four parts, and each is verifiable independently of the person who ran it.

1. The collection identity. Issue a dedicated API key (secronyx apikey create --file /etc/secronyx/keys.json --name compliance-runner --scopes compliance,security,software,triage,state --expires 30d --cidr <scheduler>/32; --file is required, and the key is printed once). Its name becomes the identity on that caller's audit events, so the pack is attributable to the job rather than to whoever holds a shared token.
2. The results. Call the tools over JSON-RPC and store the raw responses. Each carries a timestamp; get_forensic_snapshot also carries a snapshot_id. For a host with no HTTP listener, secronyx --query get_compliance_check --framework cis --json runs the same collector directly, with the caveat that direct queries are not audited as tools/call events.
3. The audit record. Run the collection listener with --audit-buffer-size 0 --audit-sync-write so the events are on disk before the response is returned; --audit-sync-write on its own still leaves the write to the async buffer. After the run, secronyx --audit-verify --audit-output <file> prints Audit verification OK: N events verified, and the exit status is 0.
4. The configuration statement. Capture the server's start-up log: the Auth: line, Scope policy: N tools not registered (sensitive=false, scopes="..."), and the absence of WARNING: output redaction is DISABLED and WARNING: audit logging is DISABLED. Together with tools/list, this shows the assessor what the collection could and could not have read.

# Verify the pack's audit trail
secronyx --audit-verify --audit-output /var/log/secronyx/audit.jsonl
# Audit verification OK: 1523 events verified

Limits to state in your own documentation

• The compliance checks are a small fixed subset per framework; a full benchmark assessment needs a dedicated scanner. The tool is useful for continuous evidence on the items it covers and for feeding a model the current state.
• Checks marked manual are reported, not evaluated.
• Redaction is pattern-based and has documented limits; an assessor reviewing the audit log should know that params may contain what the caller sent, which is why redaction stays on.
• Forecasts and trends from the analytics scope are extrapolated from in-process samples and say so; they are not a capacity record.
• Nothing here substitutes for host hardening, network segmentation or a secrets manager; see the "What the server is not" list under Security model.

Related pages: Audit logging, Redaction, Scopes and authorization, Use cases, Tutorial: verify the audit chain, and the Secronyx homepage.