Release day should not be stressful. If your security checks are built into the process rather than bolted on at the end, releasing becomes a verification exercise rather than a discovery exercise. You are confirming that everything is already in order, not finding out what you missed.
This checklist covers the security activities that should be completed before every production release. Some of these are automated and happen in CI/CD. Others require human judgment. All of them should be documented as completed for audit purposes.
Pre-Release Checklist
1. Dependency Verification
Lock file integrity. Verify that the lock file (package-lock.json, yarn.lock, Pipfile.lock, go.sum) is committed and matches the manifest file. A lock file that is out of sync with the manifest means the build is not deterministic.
No new unreviewed dependencies. Check whether any new dependencies were added since the last release. Each new dependency should have been evaluated for:
- Maintenance status (active maintainer, recent releases)
- Vulnerability history
- License compatibility
- Necessity (is this dependency needed, or can the functionality be implemented without it?)
No dependency downgrades. Verify that no dependency has been downgraded to a version with known vulnerabilities. Downgrades sometimes happen accidentally during merge conflict resolution.
Transitive dependency changes. Review changes to the transitive dependency tree. Significant changes (new packages, major version bumps in transitive dependencies) should be flagged for review even if the direct dependencies have not changed.
2. Vulnerability Scan
Zero critical/high vulnerabilities without documented exceptions. Run a vulnerability scan against the complete dependency tree. There should be no critical or high severity vulnerabilities without a documented risk acceptance.
Scan with current data. Verify that the vulnerability database used for scanning was updated within the last 24 hours. A scan against a week-old database may miss recently disclosed vulnerabilities.
Reachability assessment for accepted risks. For any vulnerabilities accepted as risk, verify that the reachability assessment is still valid. Code changes since the risk acceptance may have changed whether the vulnerable function is called.
3. SBOM Generation
SBOM generated from the release build. Generate the SBOM from the actual release artifact, not from the source code or a separate build. The SBOM must reflect exactly what will be deployed.
SBOM completeness. Verify that the SBOM includes:
- All direct dependencies with exact versions
- All transitive dependencies with exact versions
- License information for each component
- Package URLs (purls) for each component
- The SBOM format is valid (CycloneDX or SPDX)
SBOM diff review. Compare the release SBOM against the previous release SBOM. Review all additions, removals, and version changes. This catches dependency changes that may have slipped through code review.
4. Static Analysis
SAST scan completed. Static application security testing has run against the release candidate with no new critical findings.
Secret scanning. Verify that no secrets (API keys, passwords, tokens) are present in the codebase or configuration files that will be deployed.
License scan. Verify that all dependencies comply with your organization's license policy. Pay attention to copyleft licenses (GPL, AGPL) that may have implications for your distribution model.
5. Artifact Integrity
Artifact signed. The release artifact is cryptographically signed with the production signing key. The signature covers the complete artifact, not just a manifest.
Provenance recorded. A provenance attestation has been generated linking the artifact to the source commit, build configuration, and build environment.
Hash recorded. The SHA-256 hash of the release artifact is recorded in the release metadata and will be available for post-deployment verification.
6. Configuration Review
Environment-specific configuration. Verify that production configuration does not include development settings:
- Debug mode is disabled
- Verbose logging is set to production levels
- Source maps are not included (or are uploaded to error tracking separately)
- Development API endpoints are not referenced
- Test credentials are not present
Security headers and policies. For web applications, verify that security headers are configured:
- Content-Security-Policy
- Strict-Transport-Security
- X-Content-Type-Options
- X-Frame-Options
- Referrer-Policy
7. Access and Permissions
Deployment credentials rotated. If deployment credentials have not been rotated within the defined period (typically 90 days), rotate them before the release.
Minimum permissions verified. The deployment process runs with the minimum permissions required. No deployment step has broader access than it needs.
Approval workflow completed. For production deployments, the required approvals are documented. The person deploying is authorized to do so.
8. Rollback Plan
Rollback procedure documented. The procedure to roll back to the previous version is documented and tested.
Previous version available. The previous production artifact is available and can be redeployed within the defined RTO (Recovery Time Objective).
Rollback criteria defined. The conditions under which a rollback will be triggered are defined (error rate threshold, latency threshold, security finding).
9. Monitoring
Alerting configured. Production monitoring and alerting are configured for the release:
- Error rate monitoring
- Performance monitoring
- Security event monitoring
- Dependency vulnerability monitoring (for post-release disclosures)
Post-release check schedule. Define when post-release checks will be performed (1 hour, 4 hours, 24 hours, 1 week after release) and what will be checked at each interval.
10. Documentation
Changelog updated. The changelog reflects all changes in this release, including security fixes (without disclosing vulnerability details that could aid exploitation).
Release notes prepared. User-facing release notes are prepared, including any security-relevant changes that users need to be aware of.
Compliance evidence collected. All checklist items are documented with timestamps and responsible parties for compliance audit purposes.
Automating the Checklist
Most checklist items should be automated as CI/CD pipeline gates:
- Dependency verification: Automated lock file validation and dependency diff
- Vulnerability scanning: Automated SCA with policy gate enforcement
- SBOM generation: Automated as a build step
- Static analysis: Automated SAST in CI
- Artifact signing: Automated signing in the release pipeline
- Configuration validation: Automated checks for debug settings and development references
Human review is still needed for:
- New dependency evaluation (automated flagging, human judgment)
- Risk acceptance decisions
- Rollback plan verification
- Approval workflow sign-off
How Safeguard.sh Helps
Safeguard.sh automates the supply chain security portions of the release checklist: dependency verification, vulnerability scanning, SBOM generation, and policy gate enforcement. Each release pipeline evaluation is logged with complete audit data, providing the compliance evidence needed for post-release documentation. The policy gate engine enforces that no release proceeds without meeting defined security criteria, turning the checklist from a manual process into an automated gate that cannot be skipped.