Production Hardening Checklist

Use this checklist before each release to self-audit security posture for protected builds. This page is designed to be practical: check each control, fix gaps, then publish.

Audit Buckets

Required Controls

Release Rule

0 Critical Gaps

1) Secrets and Configuration

Prevent accidental credential exposure and remove plaintext secret distribution from release artifacts.

No `.env` files with real secrets are included in distributable artifacts.

Keep `.env` for local development only. Never ship it to clients.

Runtime secrets are injected via CI/vault, not hardcoded.

Use GitHub/GitLab secrets, cloud secret manager, or equivalent.

Local CLI config files are treated as sensitive plaintext.

`~/.bolt/config.json` has restricted permissions but is not encrypted at rest.

All exposed keys have documented rotation steps.

Prepare immediate key revocation and re-issue flow.

2) Build and Artifact Hygiene

Ensure output bundles are hardened and do not leak internals.

Source maps are disabled in production build output.

If maps are required for debugging, host privately with strict access controls.

Only release-mode builds are published.

No debug symbols, test hooks, or verbose metadata in release artifacts.

Release artifact inventory is reviewed before distribution.

Inspect file list for accidental keys, configs, logs, or temporary files.

Integrity manifests are generated and verified in release flow.

Run protect/hash in CI and verify startup checks in a clean environment.

3) Runtime and Policy Controls

Validate trust enforcement and deny-by-default behavior before shipping.

License and entitlement failures resolve to deny, not allow.

Test degraded dependency scenarios to confirm fail-closed behavior.

Signed-response verification is active for critical control paths.

Reject missing signatures and stale timestamps.

Integrity self-check remains enabled in production startup path.

Avoid disabling checks except in controlled local development workflows.

Webhook targets are validated against SSRF/private-network rules.

Allowlist trusted domains and review DNS resolution behavior.

4) CI/CD and Supply Chain

Protect pipelines because release compromise often starts at automation boundaries.

Pipeline secrets are scoped to minimum required permissions.

Use short-lived tokens where possible.

Build logs are scrubbed for key material and sensitive URLs.

Mask or redact credentials in all logs.

Artifact retention is limited and lifecycle policies are enforced.

Delete old artifacts that may contain sensitive metadata.

Dependency updates are reviewed and pinned intentionally.

Avoid uncontrolled transitive drift before release.

5) Operations and Incident Readiness

Prepare for rapid containment if a security issue appears after release.

Alerting exists for signature failures and replay rejection spikes.

Track abnormal trust-validation trends.

Audit logs are retained and searchable for investigations.

Ensure key mutation and entitlement actions are traceable.

Emergency revoke/kill procedure is documented and tested.

Practice response drills at least once per quarter.

Support escalation path is available for customer incidents.

Define owner, on-call handoff, and communication template.

6) Release Sign-off

Use this gate right before publishing.

No critical or high-risk unchecked items remain.

Security owner approves deployment window and rollback plan.

Final artifact hash and release notes are archived.

Post-release validation run is scheduled.

Ship only when all critical controls are green. Hardening is most effective when repeated for every release candidate, not only major versions.

Open Main Docs Secrets and .env Handling Architecture and Security Report