GigaChad GRC
GigaChad GRC is a self-hosted, containerized Governance, Risk, and Compliance platform covering controls/evidence, framework assessments, policy lifecycle, third-party risk management (TPRM), a trust center, and audit management. It's built as Node.js/NestJS microservices behind a Traefik gateway with PostgreSQL, Redis, Keycloak SSO, and RustFS storage, deployable via a one-command Docker Compose script, and licensed under Elastic License 2.0.
What it is
GigaChad GRC's setup and troubleshooting documentation, which surfaces one security-relevant detail the summary omits: the platform ships with a Dev Login auth bypass that skips Keycloak SSO entirely, requiring no username or password and logging in as a local account.
How it works
The bypass is gated by a single frontend build-time variable, VITE_ENABLE_DEV_AUTH=true. When set, a "Dev Login" button appears on the login screen at http://localhost:3000 that authenticates with no credentials. The bundled ./start.sh (and start.bat on Windows) sets this variable automatically, so the default one-command install path enables the bypass out of the box. The page frames this as necessary because Keycloak requires HTTPS, which "is not available in local Docker development" — so the documented fix for any SSO failure is to fall back to Dev Login rather than configure TLS.
Preconditions / Affected
- Any instance built with
VITE_ENABLE_DEV_AUTH=true. Because it is a Vite build variable, toggling it requires rebuilding the frontend (docker compose up -d --build frontend), not just a restart. - Anyone reachable on port 3000 of such an instance can log in with no credentials.
- Manual
.envsetups do not get this automatically —.env.exampleholds placeholders that "will not work as-is," and Compose refuses to start with missing/empty secrets.
What to do
If deploying beyond a throwaway local box, do not use ./start.sh unmodified — build the .env by hand and leave VITE_ENABLE_DEV_AUTH unset (or false), then rebuild the frontend so the button is absent. Generate real secrets rather than relying on the script:
# ENCRYPTION_KEY
openssl rand -hex 32
# JWT_SECRET, SESSION_SECRET
openssl rand -base64 64
# POSTGRES_PASSWORD, REDIS_PASSWORD, MINIO_ROOT_PASSWORD,
# GRAFANA_ADMIN_PASSWORD, KEYCLOAK_ADMIN_PASSWORD, PHISHING_TRACKING_SECRET
openssl rand -base64 24Update DATABASE_URL to match the generated Postgres password. Note the non-default ports it exposes: Postgres 5433, Redis 6380, Traefik 80/443, RustFS 9000/9001, plus per-service ports 3001–3007. Grafana credentials (GRAFANA_ADMIN_USER/GRAFANA_ADMIN_PASSWORD) must be added manually if not using the script.
flowchart TD
A[Install] --> B{Path?}
B -->|"./start.sh"| C[VITE_ENABLE_DEV_AUTH=true set]
B -->|manual .env| D[flag unset]
C --> E[Dev Login button: no-credential access]
D --> F[Keycloak SSO enforced]Caveats
The page presents Dev Login purely as a local-development convenience and does not claim it is safe for shared or production use; it also points to a separate "Production Deployment Checklist" and "Deployment Guide" not reproduced here. Whether the bypass can leak into a production build depends entirely on the build-time flag, so verify the compiled frontend, not just the runtime config.
Technologies named here
Related in GRC

Orca Security: NIST AI Risk Management Framework (AI RMF) Explained

FOSSA: CISA Releases the 2026 SBOM Minimum Elements
Teach Yourself to Phish | Huntress
