# Code & Supply Chain > What code runs in psLens, how it's built and distributed, dependency posture, and the vulnerability disclosure & patching process. --- LLMS index: [llms.txt](/llms.txt) --- This page is for security reviewers who need to understand what is running inside psLens before approving its deployment. It covers four questions: 1. **What code is actually running?** 2. **Can we audit it?** 3. **How is it built and shipped?** 4. **How are vulnerabilities found, disclosed, and fixed?** If you're looking for the higher-level read-only / whitelist story, start with [Security & Trust](/docs/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. ### Runtime stack | Component | Purpose | | ------------------------------------------- | -------------------------------------------------------------- | | Go 1.27+ | Application language; binary statically linked | | `gorilla/mux` | HTTP routing | | `a-h/templ` | Server-rendered HTML templates | | Embedded NATS (`nats-server/v2`) | In-process key-value store for sessions, alerts, report output | | `data-star` (datastar.dev) | Hypermedia / SSE for interactive UI; no SPA framework | | Goldmark | Markdown rendering for report output | | Standard library `crypto/aes`, `crypto/tls` | Encryption at rest and in transit | There is no embedded browser, no third-party telemetry SDK, no analytics tracker. The full dependency list is `go.mod` in the source tree. ### Base image The runtime stage is `debian:bookworm-slim` with `ca-certificates`. No shell access is required for normal operation; `psLens` runs as PID 1. --- ## 2. Source Availability and Review psLens is **closed-source**. The source tree is not published publicly. **For customers who need to review the code:** Cedar Hills Group offers a **read-only source review under NDA** as part of the procurement process. Mechanics (on-site, screen-share, time-boxed access) are agreed during contracting. Reach out via the [contact page](/contact/) to arrange. This is the same model used by most enterprise PeopleSoft tooling: the binary is yours to run, the source is reviewable under contract, redistribution is not granted. --- ## 3. Build and Distribution ### Build pipeline | Stage | Where it runs | What it produces | | ------------- | ------------------------------------- | ------------------------------------------------------------------------------- | | Source commit | Cedar Hills Group internal repo | Tagged release commit (semver) | | CI build | GitHub Actions, GitHub-hosted runners | Multi-arch Docker image | | Publish | GitHub Container Registry (GHCR) | Private package, tagged `vMAJOR.MINOR.PATCH`, `vMAJOR.MINOR`, `latest`, git SHA | The release pipeline injects the version, commit SHA, and ISO-8601 build timestamp into the binary at compile time via Go `ldflags`. You can read them back from any running instance via `/healthz` and the startup banner in container logs. Useful for confirming exactly which build a customer is running. ### What we do today - **Traceable builds.** Every image embeds the git SHA and build timestamp in its label and binary; you can map any running container back to the exact source commit that produced it. - **Pinned tag flavors.** Production customers pin to `vMAJOR.MINOR` (or exact `vMAJOR.MINOR.PATCH`) so a `docker compose pull` never surprises them with a major-version change. See [Deployment Options](/docs/getting-started/deployment-options/) for the tag flavors and recommended pinning. - **Private package distribution.** GHCR access is gated by per-customer read-only fine-grained personal access tokens. ### What we don't do yet (roadmap) - **Image signing with cosign.** Planned. Once landed, every published tag will carry a sigstore-verifiable signature and you'll be able to verify provenance with `cosign verify`. - **SLSA build provenance attestation.** Planned alongside cosign. --- ## 4. Dependency Management ### Today - `go.mod` is the single source of truth; all dependencies are pinned by version and content hash (`go.sum`). - **Automated scanning.** We run `govulncheck` daily and on every push/PR in our GitHub Actions CI pipeline to verify there are no known exploitable vulnerabilities in our dependencies. - **Dependency monitoring.** Dependabot is enabled to track Go modules, GitHub Actions, and Dockerfile base images, raising automated pull requests for updates. - The dependency footprint is intentionally narrow (see the table above); Go standard library does most of the work. - **Public SBOM and license audit.** A machine-readable [CycloneDX SBOM JSON](/sbom.json) is published with every build. See the full [Software Bill of Materials (SBOM)](/docs/trust/sbom/) page for the complete inventory. --- ## 5. Vulnerability Disclosure and Patching ### Reporting a vulnerability Email `security@cedarhillsgroup.com`. Please include: - Affected version (the git SHA from `/healthz` is most precise) - Reproduction steps or proof-of-concept - Your assessment of severity (CVSS or descriptive) We commit to: - **Acknowledgement within 1 business day** of receipt. - **Coordinated disclosure.** We will agree a disclosure window with the reporter before publishing details. - **Crediting researchers** in the release notes unless they prefer otherwise. ### Patch SLA Specific patch targets (business days for Critical, High, Medium) are disclosed during contracting. When a fix ships, it goes out as a patch release in the same `vMAJOR.MINOR` stream you're already pinned to. `docker compose pull && docker compose up -d` picks it up. Critical fixes are also announced by email to deployment contacts. ### Subscribing to release notes Release notes are published as GitHub Releases on the source repo. Deployment contacts are notified by email for any release with a security note. --- ## 6. What Reviewers Usually Ask **"Is the binary statically linked?"** Yes. Go produces a static binary; no system library version drift. **"Does it phone home?"** No. There is no outbound connection from a running psLens instance other than (a) to your SWS endpoint and (b) to your SMTP server if you've enabled magic-link auth. No telemetry, no update checks, no license-server callbacks. **"What user does it run as inside the container?"** Confirm the current default with us on the demo call. Recommendation for self-hosters regardless: run with `--user 1000:1000` and a read-only root filesystem; only `/data` needs to be writable. **"How big is the attack surface?"** One HTTP listener (default port 8080 or whatever you configure), serving HTML and Server-Sent Events. No raw socket listeners, no UDP, no message-queue ingress, no plugin loader. --- ## Related - [Authentication & Access](/docs/trust/authentication-and-access/). How the HTTP listener authenticates users. - [Data Handling & Logging](/docs/trust/data-and-logging/). What's stored, how it's encrypted, what's logged. - [Deployment & Operations](/docs/trust/deployment-and-operations/). Backup, upgrade, sizing. - [Compliance & Vendor](/docs/trust/compliance-and-vendor/). SOC 2 posture, sub-processors, DPA.