pam-approver

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

pam-approver is developed in a public Git repository on GitHub with full commit history. Every change lands as a reviewable interim version (commits on pull-request branches, merged to main) well before any release is cut. The repository is the live source tree, not a drop of final-release snapshots. See the commit history: https://github.com/schack/pam-approver/commits/main

Repository on GitHub, which uses git. git is distributed.

Each release has a unique CalVer identifier, YEAR.MONTH.SEQUENCE (e.g. 2026.6.4), used as both the GitHub release tag and the container image tag. The version is computed automatically from existing tags so numbers are never reused. See releases: https://github.com/schack/pam-approver/releases

Each release is identified in version control by a Git tag matching its CalVer version (e.g. 2026.6.4), created when the GitHub release is published. Tags are visible at https://github.com/schack/pam-approver/tags and back the GitHub Releases at https://github.com/schack/pam-approver/releases. The CD pipeline triggers on the published release/tag to build and sign the corresponding image.

Each release has human-readable, categorized release notes (✨ Features, 🐛 Fixes, 🔒 Security, 📦 Dependencies) summarizing the changes, generated by Release Drafter from merged pull request titles rather than raw VCS log output. Example: https://github.com/schack/pam-approver/releases/tag/2026.6.4 — all releases at https://github.com/schack/pam-approver/releases

No publicly known, CVE-assigned run-time vulnerabilities have affected the project's own results, so there have been none to call out in release notes. (This criterion concerns the project results, not dependencies.) If a vulnerability is ever fixed, it will be named in that release's notes and a GitHub Security Advisory. Per the criterion, N/A applies when there have been no publicly known vulnerabilities.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/schack/pam-approver/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues as its issue tracker: https://github.com/schack/pam-approver/issues (CONTRIBUTING.md directs bug and feature reports there; security issues go through private reporting per SECURITY.md).

pam-approver is a new, single-maintainer project; there have been no externally submitted bug reports in the last 2-12 months. The maintainer monitors GitHub Issues and acknowledges reports as they arrive, so a majority of any reports received are acknowledged. With effectively zero reports to date, the criterion is satisfied trivially.

As a new, single-maintainer project, there have been no externally submitted enhancement requests in the last 2-12 months. The maintainer monitors GitHub Issues and responds to feature requests as they arrive (a response can be a decline). With effectively zero requests to date, a majority are responded to, so the criterion is satisfied.

Bug reports, enhancement requests, and the responses to them are tracked in GitHub Issues, which provides a public, permanent, searchable archive of both open and closed items: https://github.com/schack/pam-approver/issues?q=is%3Aissue

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. [osps_vm_01_01]

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. [osps_vm_03_01]

SECURITY.md commits to acknowledging vulnerability reports within a few days, well under the 14-day threshold (https://github.com/schack/pam-approver/blob/main/SECURITY.md#reporting-a-vulnerability). No vulnerability reports have been received in the last 6 months (new project), so none exceeded the window, and the documented initial-response target is well within 14 days.

The project builds with a single automated command via Docker: docker build . (or docker compose up --build) drives the multi-stage Dockerfile (https://github.com/schack/pam-approver/blob/main/Dockerfile), which fetches and pins all build inputs (Tailwind CSS standalone CLI, nginx base) and produces the image with no manual steps. CI rebuilds the image from source automatically on every pull request and push (.github/workflows/cd.yml).

The build uses Docker (multi-stage Dockerfile), a ubiquitous and widely available build tool. The only other build component is the official Tailwind CSS standalone CLI, fetched and SHA-256 verified during the build. No uncommon or bespoke build tooling is required.

The build relies only on FLOSS tooling: a container build engine (Docker/BuildKit, or equivalently Podman/Buildah), the MIT-licensed Tailwind CSS standalone CLI, and the open-source nginx and Debian base images. No proprietary tools are required to build the software.

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. [osps_qa_06_01]

The JS test suite is invoked the standard way for the language: node --test (Node's built-in test runner), also wired as npm test in package.json. The shell and container test suites run with sh tests/entrypoint_test.sh and sh tests/nginx_headers_test.sh. Invocation is documented in CONTRIBUTING.md "Tests" and the README, and run in CI on every PR.

The test suite covers the project's pure logic and its build/runtime surface: the exported helper functions in public/app.js (formatting, parsing, normalization, concurrency limiter, theme selection), the entrypoint.sh environment validation and config rendering, and the running image's per-route Content-Type behavior. The remaining code is browser DOM wiring and direct calls to the Google PAM API, which require a browser/integration harness; these are exercised manually. Most of the independently testable logic and functionality is covered.

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. [osps_qa_06_01]

CONTRIBUTING.md states the policy explicitly under "Tests": changes to public/app.js or entrypoint.sh should add or extend a test covering the new behaviour, and bug fixes should come with a test that fails without the fix. See https://github.com/schack/pam-approver/blob/main/CONTRIBUTING.md#tests

The most recent major change, the dark-mode toggle (PR #15), added a unit test for the new logic (nextTheme) to tests/app.test.js, in line with the test policy. See the test file (https://github.com/schack/pam-approver/blob/main/tests/app.test.js) and PR https://github.com/schack/pam-approver/pull/15. Earlier pure helpers (normaliseGrant, formatDuration, etc.) are likewise covered by tests added with their functionality.

The test-addition policy is documented in CONTRIBUTING.md, the project's change-proposal instructions, in the "Tests" section right alongside the "Pull requests" workflow: https://github.com/schack/pam-approver/blob/main/CONTRIBUTING.md#tests

The Dockerfile is linted with hadolint (failure-threshold: warning) and the shell entrypoint with shellcheck, both run in CI on every pull request (.github/workflows/cd.yml). The JavaScript is written as ES modules, which execute in strict mode (a "safe" language mode), and is syntax/test-checked via Node's built-in runner. So a linter or safe-mode is in place for each language.

Warnings are treated as build failures, so they cannot accumulate. hadolint runs with failure-threshold: warning (any Dockerfile warning fails the test job) and shellcheck must pass clean; both run on every PR via .github/workflows/cd.yml, and the pipeline is green. The project's standing convention is to keep the Dockerfile hadolint-clean and shell shellcheck-clean (stated in CONTRIBUTING.md "Style").

The build is configured to fail on warnings, not just errors: hadolint runs with failure-threshold: warning, shellcheck reports all levels and must pass clean, and the JavaScript is strict-mode ES modules. Any warning fails the CI test job, so the project is maximally strict where practical.

The primary developer is a platform/security engineer, and the project demonstrably applies secure-design principles from the criterion's details: least privilege (image runs non-root as uid 101 on a read-only root filesystem with all Linux capabilities dropped), defense in depth (strict CSP plus security headers, with authorization enforced by Google IAM rather than the app), fail-safe/closed defaults (OAuth hd domain re-checked client-side, fail closed if unverifiable), input validation and safe output handling (entrypoint.sh validates env values to prevent breaking out of config.js; DOM is built via textContent to avoid XSS), and minimal attack surface (static SPA, no backend, no stored secrets). These choices are documented in SECURITY.md and the README "Security posture".

A primary developer is aware of the common vulnerability classes for a browser-based single-page app and the project mitigates each: cross-site scripting (strict CSP with no unsafe-inline; DOM built via textContent, not innerHTML, for untrusted data); credential/secret exposure (no client secret or refresh tokens, access token kept only in sessionStorage, public OAuth client ID, .env gitignored, GitHub secret scanning with push protection enabled); CSRF (Bearer-token requests straight to googleapis.com with no cookies on the data path, so CSRF does not apply); clickjacking (frame-ancestors 'none' and X-Frame-Options DENY); injection into the rendered config.js (entrypoint.sh validates environment values); insecure transport (HTTPS throughout, CSP connect-src restricted to specific Google origins); and vulnerable dependencies (pinned by digest, Dependabot, Trivy and OpenSSF Scorecard scanning). These are documented in SECURITY.md and the README "Security posture".

The application implements no custom cryptography. The only cryptography it relies on is via publicly published, expert-reviewed standards: TLS/HTTPS for all transport, and OAuth 2.0 / OpenID Connect (via Google Identity Services) for authentication. No proprietary or unpublished algorithms or protocols are used.

pam-approver's purpose is not cryptography, and it does not implement any. All cryptographic operations are delegated to established, purpose-built software: the browser's TLS stack for transport and Google Identity Services for the OAuth 2.0 / OpenID Connect flow. The project re-implements no cryptographic functions of its own.

The only cryptography-dependent functionality is TLS transport and the OAuth 2.0 / OpenID Connect sign-in flow, both of which are open standards implementable entirely with FLOSS (e.g. OpenSSL/BoringSSL for TLS; widely available FLOSS OAuth/OIDC client libraries). Nothing in the project depends on proprietary-only cryptographic functionality.

pam-approver implements and configures no cryptography of its own, so it sets no key lengths. The cryptography it relies on is the TLS session between the browser and Google's endpoints and the OAuth tokens issued by Google; key lengths there are determined by the browser and Google's servers, which use modern parameters meeting or exceeding the NIST minimums. The project has nothing to configure or disable in this regard.

The project implements no cryptography and depends on no broken algorithms. Its security mechanisms rely on TLS negotiated between the browser and Google's endpoints (modern cipher suites; Google's services do not offer MD5/RC4/single-DES/Dual_EC_DRBG) and on Google's OAuth 2.0 / OpenID Connect. No weak or broken algorithm or inappropriate cipher mode is used or required, so no interoperability exception applies.

The project implements no cryptography and does not depend on algorithms with known serious weaknesses. It relies on modern TLS negotiated with Google's endpoints and on Google's OAuth 2.0 / OpenID Connect; SHA-1 and weak cipher modes are not used or required. Image release signatures use Sigstore cosign (ECDSA/SHA-256 class), not SHA-1.

The project implements no key-agreement protocol of its own. All transport is TLS between the browser and Google's endpoints (googleapis.com, accounts.google.com), which negotiate ephemeral ECDHE key exchange providing perfect forward secrecy by default. There is no project-controlled session-key derivation that lacks PFS.

The project stores no passwords. Authentication is delegated entirely to Google via OAuth 2.0 / OpenID Connect; the app never sees or stores user credentials, only a short-lived access token held in the browser's sessionStorage. There is no password storage to protect.

The project generates no cryptographic keys or nonces of its own. Any cryptographic randomness in the authentication flow (OAuth state/nonce/PKCE) is produced by the Google Identity Services library and Google's servers, which use a cryptographically secure RNG. The application code uses no insecure generator (e.g. Math.random) for any security-relevant purpose.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

No cryptographic hash is retrieved over plain HTTP and trusted. The Tailwind CSS CLI's SHA-256 hashes are pinned directly in the Dockerfile (committed to the repo) and verified at build time with sha256sum -c; the update workflow fetches the publisher's sha256sums.txt and the binaries over HTTPS and verifies them before pinning. Base images are pinned by immutable digest and pulled over HTTPS from mirror.gcr.io. All downloads use HTTPS, and integrity is anchored to in-repo pinned digests rather than hashes fetched and trusted at build time.

There are no known unpatched vulnerabilities of medium or higher severity. The project's own code has no known vulnerabilities (no CVEs). Base-image and dependency vulnerabilities are surfaced by Trivy (HIGH/CRITICAL scan on every release, results in the Security tab) and OpenSSF Scorecard, and the base image and Actions are kept current by Dependabot, so any are addressed well within 60 days via pinned-digest bumps. Nothing of medium-or-higher severity has been publicly known and left unpatched for more than 60 days.

No critical vulnerabilities have been reported to date. The project is set up to fix them rapidly: private reporting via SECURITY.md, automated detection (Trivy on every release, Dependabot, OpenSSF Scorecard), and a fast single-maintainer release pipeline that can rebuild, sign, and publish a fixed image quickly. Any critical vulnerability would be patched promptly and disclosed via a GitHub Security Advisory.

Prevented by design, by .gitignore, and by an active control. .gitignore excludes .env/.env.* (only the placeholder .env.example is committed) and the runtime-rendered public/config.js. The app has no server-side secrets: SPA OAuth uses no client secret or refresh tokens, and the OAuth client ID is public by design. Additionally, GitHub secret scanning with push protection is enabled on the repository, which blocks accidental commits of known credential formats. User access tokens exist only in the browser at runtime and are never written to the repo or image. [osps_br_07_01]

Static analysis runs before every release: CodeQL analyzes the JavaScript source on every pull request, push, and weekly (.github/workflows/codeql.yml); hadolint analyzes the Dockerfile and shellcheck the shell entrypoint; and Trivy scans the built image. All run in CI and report to the Security tab. CodeQL is FLOSS and covers the project's primary language.

CodeQL runs its default security query suite for JavaScript/TypeScript, which includes rules for common web vulnerabilities (e.g. cross-site scripting, code/command injection, prototype pollution, unsafe DOM sinks). Trivy additionally applies known-CVE rules to the dependencies and base image. Both run in CI before release (.github/workflows/codeql.yml, .github/workflows/cd.yml).

Static analysis findings (CodeQL, Trivy, hadolint, shellcheck) surface in the Security tab and CI on every PR. There are no outstanding medium-or-higher exploitable findings; any confirmed would be fixed promptly via the fast single-maintainer release pipeline. Base-image CVEs flagged by Trivy are addressed through Dependabot digest bumps.

Static analysis runs on every push and pull request: CodeQL (.github/workflows/codeql.yml) and hadolint/shellcheck/Trivy (.github/workflows/cd.yml) all execute per change, with CodeQL also running on a weekly schedule. So analysis occurs on every commit, exceeding the "at least daily" suggestion.

The project produces no software written in a memory-unsafe language. The codebase is JavaScript, POSIX shell, HTML, and CSS, with nginx config; there is no C/C++ or other memory-unsafe code, so this criterion does not apply.

No dynamic analysis is performed, so no medium-or-higher exploitable vulnerabilities have been discovered through it; there are none outstanding. Were any found and confirmed, they would be fixed promptly via the fast single-maintainer release pipeline and disclosed via a GitHub Security Advisory.