Security-Focused Release Management Practices
🌟 Objective
To describe and systematise secure practices for version, release and software distribution management, with a focus on:
- Reducing risk and impact in production;
- Formal validation and traceability of the decision;
- Reversibility and rapid recovery;
- Alignment with normative frameworks (SSDF, SLSA, SAMM).
🧬 What Secure Release Management is
Release Management is the process of preparing, approving, distributing and monitoring a new software version. A secure release must:
- Be predictable, validated and reversible;
- Have defined ownership and approval criteria;
- Be accompanied by technical and security documentation;
- Include formal rollback mechanisms.
🛠️ How to apply
🗂️ Essential elements of a secure release
| Element | Description |
|---|---|
| Technical changelog | List of relevant changes, including security patches |
| Security changelog | Highlight of fixed CVEs, changed dependencies or critical features |
| Release owner | Person or team responsible for the release |
| Approval checklist | Minimum criteria before production (e.g. findings resolved) |
| Rollback plan | Clear and tested strategy for returning to the previous version |
| Integrated validations | Automated tests, reviews, SBOM scan, alerts |
| Activation criteria | Toggle conditions, scope and approval of functionality |
🧪 Recommended validations by risk level
| Risk level | Minimum validations before production |
|---|---|
| L1 (low) | Manual checklists, basic functional validation |
| L2 (medium) | Dual approval, AppSec review, dependency scan |
| L3 (high) | Formal validation, fuzzing, impact analysis, rollback validated in staging |
✅ Example of a release checklist (recommended minimum)
- All tests passed in CI/CD
- Critical findings resolved or justified
- SBOM updated and signed
- Rollback plan defined and validated
- Toggles and feature flags documented
- Logs and metrics defined for observation
- Approval by the functional owner and a technical reviewer
- Release recorded with hash, version and date
💡 This checklist can be used as a gate in the production pipeline.
🔁 Versioning and Reversibility
📁 Secure versioning
- Use semantic versioning (
MAJOR.MINOR.PATCH) with documented conventions; - Associate with each release:
- Commit or build hash;
- Date and time;
- Owner / responsible team;
- Justification (e.g. urgent fix, new feature, refactor).
📉 Rollback
- Must be planned as part of the release, not as an exception;
- Must make it possible to:
- Restore the previous version without loss of state;
- Deactivate toggles of critical functionality;
- Reverse database migrations (where feasible);
- Include rollback tests as part of pre-production validation.
📊 Risk indicators per release
- No. of active toggles;
- No. of open findings;
- No. of manual changes (vs automatic);
- Test coverage score;
- Confidence level defined by the owner (
alta / média / experimental).
🧰 Supporting tools
| Category | Recommended tools |
|---|---|
| Versioning | Git tags, GitHub Releases |
| Approval | Azure DevOps, Jira workflows |
| Declarative releases | Argo CD, Flux, Spinnaker |
| Observability | Dashboards with metrics per release (e.g. Grafana) |
✅ Good practices
- Integrate security into the release process (shift-left + shift-right);
- Require explicit approval for releases to production;
- Avoid manual releases outside the documented process;
- Document every step, change and decision;
- Ensure rollback and fallback tests before go-live;
- Automate the generation of SBOMs and their association with the release;
- Track each release with versioned artefacts.
📎 Cross-references
| Document / Chapter | Relation to this topic |
|---|---|
| Ch. 07 - Secure CI/CD | Automated process and controls per stage |
| Ch. 05 - Dependencies and SBOM | SBOM as a requirement for release |
| Ch. 10 - Security Testing | Validation before deployment |
| Ch. 12 - Monitoring and Operations | Post-release observation |
| SLSA L3/L4 | Release provenance and secure rollback |
| NIST SSDF PM.3, RV.1 | Formal approval and risk management |
🎯 Release management must be treated as a formal and secure process - not as a mere technical deployment.
A good release process is essential to sustain advanced security practices and to ensure confidence in the changes delivered.