Security & Trust on psLens

Code & Supply Chain

Mon, 01 Jan 0001 00:00:00 +0000

This page is for security reviewers who need to understand what is running inside psLens before approving its deployment. It covers four questions:

What code is actually running?
Can we audit it?
How is it built and shipped?
How are vulnerabilities found, disclosed, and fixed?

If you’re looking for the higher-level read-only / whitelist story, start with Security & Trust and come back here for the detail.

1. What’s Inside the Image

psLens is a single Go binary plus an embedded NATS server, packaged as a multi-stage Docker image distributed from ghcr.io/cedarhillsgroup/pslens. There is no separate database, message broker, or external worker process; one container is the whole application.

Authentication & Access

Mon, 01 Jan 0001 00:00:00 +0000

This page covers how end users authenticate to psLens, what access controls exist (and which deliberately don’t), and how to front psLens with your existing identity provider today.

For SSO, see SSO Today.

1. How Users Log In Today

psLens ships with optional email magic-link authentication. It is off by default in the shipped config.yaml and must be turned on for production deployments.

When auth.enabled: true:

User visits any psLens URL → redirected to /login.
User enters their email address.
psLens emails a one-time verification code to that address (only if the address is on the configured AuthorizedUsers allowlist).
User enters the code at /verify-code.
Session created in NATS KV, identified by an HTTP-only psLens_auth cookie.

Property	Value
Mechanism	Email one-time code (no passwords)
Session storage	NATS KV bucket `auth-sessions`
Session TTL	1 year (configurable)
Cookie	`psLens_auth`, HTTP-only
User allowlist	`AuthorizedUsers` in `config.yaml`, case-insensitive
Public endpoints (no auth required)	`/healthz`, `/static/*`, the auth flow itself

There are no end-user passwords for psLens to store, leak, hash, or rotate.

Data Handling & Logging

Mon, 01 Jan 0001 00:00:00 +0000

This page is for compliance reviewers and DPOs who need a precise answer to “what data does psLens hold, where, and for how long?”, and for security teams checking encryption and audit-trail posture.

For PII handling, jump to Personal Data (PII).

1. What psLens Stores

psLens persists three categories of data, all inside the customer’s own dedicated instance. There is no shared multi-tenant backend.

Where	What	Retention	Notes
`/data/nats` (NATS JetStream KV)	Alert history	Rolling window (configurable; short by default)	Alerts are about current problems. History is for trend review, not long-term audit.
`/data/nats`	Report output (Markdown)	90 days	So you can revisit past audit findings; configurable
`/data/nats`	Recently-viewed objects per user	Session-scoped	Navigation convenience; not an audit log
`/data/nats`	Encrypted DB / SWS credentials	Until deleted	AES-256-GCM, key from `PSLENS_MASTER_KEY` env var
`/data/nats`	Auth sessions (if `auth.enabled`)	Up to 1 year TTL	See Authentication & Access
`/data/projects`	Uploaded PS project archives (`.zip`)	Until deleted	Used by Project Compare; you control the upload set
`/app/config.yaml`	Configuration (DB names, SWS endpoints, optional credentials)	Until you change it	Bind-mounted from your filesystem; secrets preferably via env vars

That is the complete persistent footprint. Everything else (query results, page renders, search hits) is generated on demand and not written to disk.

Deployment & Operations

Mon, 01 Jan 0001 00:00:00 +0000

This page consolidates the operational story that an IT or DBA reviewer needs in one place. It overlaps with Installation and Deployment Options; those are the how-to references, and this page is the what-to-expect security-review companion.

1. Deployment Model

One container per customer. Each customer gets a dedicated psLens deployment: separate process, separate NATS instance, separate /data volume.
No shared multi-tenant backend. There is no Cedar Hills Group SaaS plane that customer instances talk to. Your psLens instance talks to your PeopleSoft and (optionally) your SMTP, and that is it.

Two hosting options:

Mode	Operated by	Where it runs
Managed	Cedar Hills Group	fly.io, in the region you choose at provisioning
Self-hosted	You	Docker, docker-compose, Kubernetes, or systemd on a Linux VM. Your cloud, on-prem, or air-gapped.

The choice is reversible. You can start managed and migrate to self-hosted (or vice versa). The data volume is portable and the configuration travels.

Compliance & Vendor

Mon, 01 Jan 0001 00:00:00 +0000

This page is for procurement, legal, and vendor-risk reviewers. It states current posture plainly, including where certifications do not yet exist.

If you’re filling out a vendor questionnaire (SIG, CAIQ, custom), the Security Questionnaires section is the right place to start.

1. SOC 2 — Current Posture

Cedar Hills Group is not SOC 2 certified today. Certification is on the roadmap. No committed date.

In the interim, this site documents the controls a SOC 2 Type II report would cover, so a reviewer can map them to their own framework. The relevant Trust Service Criteria and where they’re addressed: