Security, what is true today

We publish what we ship. Audits land here only after they are signed.

SignalOps is pre-launch. This page lists the controls we can point to in code right now, plus the work that stays clearly labeled as roadmap work until it is earned.

Tech facts

The parts we can verify in the repo today.

This grid extends the existing trust-strip language, but every line here maps back to runtime config, schema, auth code, or the current published landing facts.

Cloudflare D1 boundThe Pages runtime binds DB as the application database today.
R2 bucket boundR2_BUCKET is configured beside D1 for asset storage.
TLS 1.3 in transitCloudflare-managed certificates back the current landing stack.
AES-256 at restD1 and R2 follow the current default encryption posture.
Audit writes are insert-onlySensitive app paths create new audit_log rows with timestamps and before/after JSON.
security_events is liveA dedicated table stores severity-tagged security events with indexed lookups.
24-hour session windowSession expiry and cookie max-age are both set to 24 hours.
Edge expiry enforcementExpired alliance_session cookies are rejected and cleared before protected routes continue.

Data lifecycle

Ingest, store, audit, delete.

We are keeping the lifecycle section narrow on purpose. This is the current path we can point to in middleware, storage bindings, and logging code.

Ingest

Ingest is handled in code today.

Protected requests pass through edge middleware before the route handler. The middleware decodes the alliance_session cookie inline and treats malformed or expired payloads as invalid.

Store

Store is handled in code today.

Operational records are wired through the DB binding to Cloudflare D1. Asset storage is wired through R2_BUCKET in the same runtime config.

Audit

Audit is handled in code today.

audit_log captures actor, action, entity, and before/after JSON. security_events records severity-tagged security signals through a dedicated helper.

Delete

Session invalidation is the delete path we publish today.

Today the concrete delete path we publish is session invalidation: expired cookies are zeroed out, page requests redirect to /login, and API requests return 401.

Auth and access

Store-aware access, time-boxed sessions, and role flags that are explicit.

The live auth shape is not abstract marketing copy. The session payload, expiry window, and role model are all visible in the current web app code.

Session lifetime

24 hours

The session helper sets expiry 24 hours ahead, and the canonical cookie writer uses a 24-hour max-age to match it.

Role model

repmanageradmin

Store access is modeled as explicit role booleans in rolesJson. Session resolution promotes the active role from those flags and can layer in district_manager context when needed.

Session payload today

userId, uid, displayName, storeId, storeName, storeCode, districtId, roles, activeRole, monthId, monthKey, expiresAt, and isTemporaryAccess.

Primary store roles

store_users.rolesJson defaults to rep, manager, and admin flags. Session resolution can also add district_manager context when district access applies.

Cookie guardrails

The canonical cookie writer sets alliance_session as httpOnly, secure, sameSite=lax, and maxAge=24h. Middleware enforces expiresAt at the edge.

Payload fields

userId / uid / displayName / storeId / storeName / storeCode / districtId / roles / activeRole / monthId / monthKey / expiresAt / isTemporaryAccess

Vulnerability reporting

If you find a security issue, send it straight to us.

Report suspected vulnerabilities to our security inbox. Include the route, environment, reproduction steps, and anything that helps us verify safely without guesswork.

Response window

72-hour acknowledgement

We will confirm receipt within 72 hours and use this page to publish bigger security updates only after they are real.

On the roadmap

The commitments we are willing to name before they are complete.

These are not current certifications or completed programs. They stay here as roadmap items until the signed work exists and can be published honestly.

On the roadmap

SOC 2

We intend to publish scope and signed audit status here after the work is complete. It is not a current claim.

On the roadmap

Independent penetration test

We plan to commission a formal pen test and publish the result only after the report and remediation pass are finished.

On the roadmap

Bug bounty

We want a structured external program after core auth, audit, and disclosure workflows are stable enough to support it well.

Nothing in this section should be read as a present-tense security claim. When work graduates from roadmap to shipped, it moves up the page with the evidence behind it.