Security Validations before Deployment
This document defines the technical and security validations that are mandatory before the approval of a deployment, based on the application's risk, the criticality of the release and the execution context.
It applies to QA, staging and production environments, and must be incorporated as a gate in the pipeline or validated manually in organisations with less automation.
📊 Table of validations by type
| Validation type | Description | Example / Tool |
|---|---|---|
| Functional tests | Validation of the main functionality | Regression tests / QA |
| Security tests | Verification of vulnerabilities, credentials, misconfiguration | SAST, DAST, trivy, Semgrep |
| SBOM / dependencies | Generation and validation of the list of components (SBOM) | CycloneDX, Syft, OWASP Dependency Check |
| Findings analysis | List of open findings, with classification and a justified decision | Jira, Kiuwan, AppSec backlog |
| Control rules | Compliance with specific criteria by risk | Checklists, conditional gates |
| Formal approval | Approval by a segregated profile (AppSec, QA, management) | Azure DevOps, GitHub reviewers |
🚫 Examples of recommended blocks (gates)
| Risk level | Blocking gate if... |
|---|---|
| L1 (low) | Open critical findings OR tests fail |
| L2 (medium) | Open findings ≥ high OR no SBOM OR no rollback defined |
| L3 (high) | No AppSec review OR no dynamic tests OR no validated rollback plan |
🔎 These gates must be parameterised in the pipeline or included in the manual validation checklist.
🔗 Recommended integration in the CI/CD pipeline
-
Build stage:
- Generates the SBOM automatically
- Runs SAST + semantic linting
-
Validation stage:
- Analyses open findings
- Verifies that a rollback plan is present
-
Gating / approval stage:
- Blocks if the risk level is ≥ L2 and there has been no review
- Allows manual approval by a security reviewer
🏢 Integration with organisational control
-
Releases must be linked to a validation artefact:
- Findings report by risk
- Release signature (hash, metadata, date)
- Approvers and justifications
-
There must be a record of:
- Who approved the deployment
- Under what conditions (version, environment, scope)
- Link to tests or requirements traceability
✅ Examples of approval criteria
- All automated tests passed
- Open findings were reviewed and justified
- A validated, functional rollback exists
- SBOM generated and stored for audit
- The release was approved by a qualified reviewer
- Cards/tasks were created for pending findings (if applicable)
👍 These criteria must be binary, verifiable and traceable.