# Security and Compliance Verification Model

Sphinixx treats security and compliance as continuously verified controls, not a one-time badge. Automated checks can prove that selected controls are present; they cannot certify the absence of vulnerabilities or provide legal certification.

## Three-pass security review

`tools/security/run_security_review.py` performs three independent checks:

1. static security baseline scanning for high-risk source/config patterns;
2. compliance-control verification for production defaults and architectural boundaries;
3. endpoint exposure/risk registration for every OpenAPI HTTP operation.

A change is not considered security-clean if any pass fails.

## Endpoint register

`docs/security/endpoint_security_register.md` and `.json` rate each HTTP operation from 0-10 and classify it LOW, MODERATE, HIGH or CRITICAL.

The score represents exposure and impact, not proof that an exploit exists. High-impact destructive operations may remain CRITICAL even when authenticated because compromise or authorization failure would still have severe consequences.

The register records the expected control boundary, such as:

- privileged internal principal/capability;
- user session and ownership checks;
- signed provider webhook;
- restricted observability network/token;
- intentionally public sanitized response.

A CRITICAL endpoint with no machine-recognised control fails the endpoint audit.

## Controls strengthened by this pass

- public health responses are coarse by default;
- detailed diagnostics remain on privileged admin surfaces;
- `/metrics` is restricted to configured source networks or a bearer credential;
- Redis and NATS require internal authentication in the container stack;
- the unused NATS monitoring port is not enabled;
- PostgreSQL production runtime credentials are separated from the database owner role;
- PostgreSQL exporter uses a dedicated `pg_monitor` role rather than application or owner credentials;
- privileged content review/publish actions require `content.publish.review`;
- direct settlement-record writes require `payments.settlement.write`;
- HTTP rate-limit identities are keyed digests, so bearer tokens do not become Redis/cache keys;
- routine auth anomaly telemetry stores a pseudonymous source identifier instead of raw IP;
- raw security evidence remains in the restricted evidence plane with retention controls;
- public transparency output remains a one-way sanitized projection.

## Personal data and evidence

Source IP addresses and internal contact details are security evidence and may be personal data. Routine diagnostics use pseudonymous source identifiers. Raw source IP is reserved for the restricted blue-team evidence path, with explicit retention and access policy.

Do not add keystroke logging, screen capture, arbitrary message-content monitoring or broad employee surveillance to the routine security plane. Any materially more intrusive monitoring requires a separate purpose, necessity/proportionality review, transparency assessment and legal review.

## Payments

The application does not intentionally process raw card data. Provider webhook signatures and idempotency remain mandatory. Payment and refund endpoints are rated highly because financial actions are inherently sensitive even when correctly authenticated.

Crypto remains disabled by default and must not be enabled solely because a provider adapter exists.

## Database roles

Production separates:

- PostgreSQL owner/admin role for database lifecycle and migrations;
- application role for runtime DML and sequence use;
- monitoring role granted `pg_monitor` for exporter telemetry.

The application role is not intended to own schema migrations in production. Schema changes should be applied as an explicit controlled deployment operation and verified before application traffic is shifted.

## Legal/compliance caveat

These controls support a defensible security and data-protection posture. They are not a substitute for deployment-specific PCI scope review, UK GDPR documentation, processor/controller agreements, retention justification, incident procedures, penetration testing, or legal advice.