pam-approver

The repository's default GitHub Actions token permission is set to read-only (default_workflow_permissions: read, with can_approve_pull_request_reviews: false), so any task executed without explicit permissions defaults to the lowest level rather than write. In addition, every workflow declares least privilege explicitly: cd.yml, release-drafter.yml, and scorecard.yml set top-level permissions: {} (deny-all) and grant only the specific scopes each job needs, and tailwind-update.yml defaults to contents: read. See https://github.com/schack/pam-approver/blob/main/.github/workflows/cd.yml

Every official release is assigned a unique CalVer identifier of the form YEAR.MONTH.SEQUENCE (e.g. 2026.6.0). The version is computed automatically from existing tags so each release gets a distinct, non-reused number, and the scheme is documented in CONTRIBUTING.md "Releases". Released git tags and container image tags carry that identifier. See https://github.com/schack/pam-approver/releases

The pipeline ingests dependencies with standardized tooling where available: ▎ - Container base images (nginx, Debian) are pulled via standard Docker/BuildKit (FROM + multi-arch buildx), pinned by tag and digest. ▎ - GitHub Actions are consumed via the native uses: mechanism, pinned by commit SHA, and tracked for updates by Dependabot (.github/dependabot.yml). ▎ - There are no language-package runtime dependencies to ingest (the app ships zero npm dependencies by design), so no package-manager install step is needed. ▎ - The single standalone tool, the Tailwind CSS CLI, has no suitable package-manager distribution for this use, so it is fetched over HTTPS from its official GitHub release and verified against the publisher's sha256sums.txt (and re-verified in the Dockerfile with sha256sum -c) before use.

Every official release's container image is signed with Sigstore cosign (keyless, via GitHub OIDC). The signature is applied to the multi-arch image index digest, and that OCI manifest accounts for each asset (per-architecture manifests and layers) by its SHA-256 digest, so the signed object cryptographically covers every component. Releases also ship SLSA provenance and an SBOM attestation. Verification steps are documented in SECURITY.md (https://github.com/schack/pam-approver/blob/main/SECURITY.md):

The primary branch (main) is protected by a GitHub repository ruleset that requires a pull request and requires the test and build status checks (from .github/workflows/cd.yml) to pass before merging, with strict up-to-date enforcement and no bypass actors. Changes therefore cannot land on main unless the automated checks pass.

The software builds with a single command using Docker, which is the only required tool. docker build . (or docker compose up --build, README "Run locally": https://github.com/schack/pam-approver#run-locally) builds the image. All libraries, frameworks, and SDKs are fetched and version-pinned inside the multi-stage Dockerfile (https://github.com/schack/pam-approver/blob/main/Dockerfile) — the Tailwind CSS standalone CLI (downloaded and SHA-256 verified) and the nginx base image — so nothing needs manual installation. The build runs in CI on every PR (.github/workflows/cd.yml) and the Dockerfile is hadolint-linted.

pam-approver is a single-maintainer project. SECURITY.md lists the sole member with access to sensitive resources (Henrik Schack, @schack), who holds GitHub repository admin and GHCR package publish access, and documents that there are no long-lived secrets or signing keys to manage (keyless OIDC signing via cosign, a public OAuth client ID, and no stored client secret or deployment credential). See https://github.com/schack/pam-approver/blob/main/SECURITY.md#maintainers-and-access-to-sensitive-resources

SECURITY.md documents the roles and responsibilities. As the sole maintainer, Henrik Schack (@schack) is responsible for reviewing and merging pull requests, cutting and signing releases, keeping dependencies current, and triaging and resolving bug and security reports, with no other members or delegated roles at this time. See https://github.com/schack/pam-approver/blob/main/SECURITY.md#maintainers-and-access-to-sensitive-resources

https://github.com/schack/pam-approver/blob/main/CONTRIBUTING.md [contribution_requirements]

The primary branch (main) is protected by a GitHub repository ruleset that requires a pull request plus passing test and build status checks (from .github/workflows/cd.yml) before any change can merge, with strict up-to-date enforcement and no bypass actors. Status checks must pass for a change to land on main.

Every pull request runs the test job in .github/workflows/cd.yml before it can be merged: it runs the shell test suite (tests/entrypoint_test.sh), the JS unit tests (node --test over tests/app.test.js), and the container header tests (tests/nginx_headers_test.sh), plus hadolint and shellcheck. The build job depends on test, and both are required status checks in the main branch ruleset, so no change is accepted to the primary branch unless the automated test suite passes.

The README "How it fits together" section (https://github.com/schack/pam-approver#how-it-fits-together) documents the design with an architecture diagram and describes all actors and data flows: the approver (browser), IAP (gateway in front of the static nginx pod), Google Identity Services (browser-based OAuth), the Google PAM REST API (called directly from the browser with a Bearer token), and Google IAM (which enforces per-user authorization). The actions are documented too: sign in, list entitlements/pending grants, and approve or deny with a reason ("Approving grants" section). SECURITY.md "Security model" further documents the actors, the token flow, and the trust boundaries. Given there is no backend and no server-side state, these cover the full set of actors and actions in the system.

https://github.com/schack/pam-approver#required-environment
https://github.com/schack/pam-approver#how-it-fits-together [documentation_interface]

A security assessment of the system is documented across SECURITY.md "Security model" (https://github.com/schack/pam-approver/blob/main/SECURITY.md) and the README "Security posture" section (https://github.com/schack/pam-approver#security-posture). Because the app is a static single-page app with no backend, the most likely and impactful risks are identified and mitigated: client-side XSS (strict CSP with no unsafe-inline, output via textContent), credential exposure (no client secret or refresh tokens, public OAuth client ID, access token kept only in the browser and never written to the image), clickjacking (frame-ancestors none, X-Frame-Options DENY), authorization bypass (enforced by Google IAM on the PAM API, not the app, plus OAuth hd domain checks), injection into the rendered config.js (entrypoint.sh validates env values), and supply-chain risk (pinned/digest-locked dependencies, SBOM, cosign-signed images, Dependabot, Trivy/Scorecard scanning).

SECURITY.md documents a coordinated vulnerability disclosure policy (https://github.com/schack/pam-approver/blob/main/SECURITY.md#reporting-a-vulnerability): vulnerabilities are reported privately via GitHub private vulnerability reporting or email (not public issues); the maintainer acknowledges within a few days; and once a fix is available a new image is published and the advisory is disclosed. This is coordinated (private until a fix ships) with a stated response timeframe.

SECURITY.md provides two private reporting channels directly to the security contact (https://github.com/schack/pam-approver/blob/main/SECURITY.md#reporting-a-vulnerability): GitHub private vulnerability reporting via the repository Security tab (enabled on the repo, so "Report a vulnerability" → https://github.com/schack/pam-approver/security/advisories/new works), and email to the maintainer at henrik@schack.dk. Reporters are explicitly asked not to open public issues.

SECURITY.md states that once a fix is available, a new image is published and the advisory is disclosed (https://github.com/schack/pam-approver/blob/main/SECURITY.md#reporting-a-vulnerability). Disclosure uses GitHub Security Advisories on the repository, which are public, receive a GHSA identifier, and are syndicated to the GitHub Advisory Database. No vulnerabilities have been discovered to date, so none have needed publishing yet, but the channel (GitHub Security Advisories) and the documented practice to disclose after a fix are in place.