Security & compliance

What this covers

pgAgroal Enterprise is a closed-source control layer built on standard, unmodified upstream pgagroal. This posture covers the Enterprise layer — the operator, the control plane, and the managed image packaging. Vulnerabilities in pgagroalitself are reported and fixed upstream first, on the community's timeline. The value Elevarq adds is operational delivery: patched, signed images applied to your fleet, not earlier access to security information.

Controls-to-evidence map

Each shipped capability is mapped to the SOC 2 Trust Services Criteria (TSC) and the ISO/IEC 27001:2022 Annex A control it supports, with where the evidence lives in the product repository. The map links concrete, already-implemented controls to the criteria — it is audit and sales evidence, not a compliance assertion.

Some capabilities support readiness but are still in progress and are not claimed as complete — for example, control-plane backup, restore, and DR tooling, health-gated upgrade and rollback automation, and policy-as-code enforcement of the controls above. The policy guardrails how-to shows how the hardening controls become enforced at admission.

Signed images and attested SBOMs

Every published image is reproducible, pinned to the upstream pgagroal version, and verifiable independently of Elevarq:

• Signed images — cosign keyless signatures. Verify a pulled image before you run it.
• SBOM — an SPDX SBOM is generated and attested to the image digest, so the bill of materials is bound to the exact artifact.

# Verify the cosign signature
cosign verify <image>@<digest>

# Verify the SPDX SBOM attestation bound to the digest
cosign verify-attestation --type spdxjson <image>@<digest>

CVE-response and patching commitments

The CVE-response SLA describes how the managed distribution responds to security issues in its pgagroal base. The promise is operational delivery speed after a fix exists: when a coordinated fix is public, your managed image is rebuilt, signed, SBOM'd, tested, and rolled to your fleet — you do not track pgagroal CVEs or rebuild images yourself.

Response targets are measured from when a coordinated fix or CVE is public:

• Critical — patched image published (signed + SBOM) within 24 hours; immediate customer notification.
• High — patched image within 72 hours; customer notification within 24 hours.
• Medium and Low — next scheduled image; noted in release notes.

A hard rule underpins this: Elevarq never races disclosure. We do not publish a fix or CVE ahead of the upstream coordinated release, and never ship an embargoed code fix into a publicly pullable image before that release — doing so would arm attackers against everyone still on upstream. During an embargo we protect customers without revealing the bug through deployment mitigations (network isolation, hardened defaults, monitoring) and by doing the upstream legwork so the coordinated release lands sooner for everyone. CI runs Trivy (vuln, secret, config) and govulncheck on every change, plus a nightly scan; the managed image ships Trivy-clean for fixable HIGH and CRITICAL findings.

VEX policy

A Vulnerability Exploitability eXchange (VEX) document states, per vulnerability, whether the product is actually affected — so consumers do not chase findings that are present in a dependency but not exploitable in our context. Elevarq publishes a VEX alongside each Enterprise image release for any non-applicable or accepted findings, using the OpenVEX format with each statement referencing the image by digest and a CVE.

• The managed image ships Trivy-clean for fixable HIGH and CRITICAL findings (--ignore-unfixed).
• For findings that remain — unfixed upstream, or present but not exploitable — a per-release OpenVEX document records the status and a machine-readable justification.
• Statuses used are not_affected, affected, fixed, and under_investigation; not_affected carries a justification from the OpenVEX controlled vocabulary (for example vulnerable_code_not_in_execute_path).

Consumers can apply the release VEX to suppress non-applicable findings in their own scanners:

# Filter a Trivy scan against the release VEX (suppresses not_affected findings)
trivy image --vex pgagroal-enterprise-<version>.vex.json <image>@<digest>

Today this is the process and template — there are no standing not_affected or affected statements to publish, because the released image is clean for fixable HIGH and CRITICAL. Live VEX documents are produced per release when a finding warrants a statement, and are signed and attached like the SBOM.

Reporting a vulnerability

Report security issues privately to security@elevarq.com. Please do not open a public GitHub issue for a suspected vulnerability. Where possible, include the affected component and version or image digest, a description and impact, and reproduction steps. Elevarq acknowledges reports and coordinates a fix and disclosure timeline with you.

Coordinated disclosure applies: for issues in upstream pgagroal we work with the maintainers and do not disclose ahead of them. Security fixes are delivered for the latest released minor of the Enterprise image, operator, and chart; older versions are supported per the customer agreement. In scope: the Enterprise operator, control plane, managed-image packaging, Helm chart, and CI/supply-chain tooling. Out of scope: upstream pgagroalinternals (report upstream) and the customer's own infrastructure and configuration.

Related

• Enforce policy guardrails — make the hardening controls enforced at admission, not just documented.
• Run preflight checks — validate posture before a change reaches the cluster.
• Collect a support bundle — gather evidence and diagnostics for an incident or audit.