Periodic Review Checklist - Secure Development
This checklist applies to all applications subject to the practices defined in Chapter 06 - Secure Development.
It serves as a binary, auditable verification instrument of the practical adoption of the prescriptions of this chapter (DEV-001 to DEV-009), enabling:
- Continuous control of the application of secure development practices
- Verification per project at key moments of the lifecycle
- Generation of operational indicators that can be aggregated by team
🗓️ Its application is recommended at every significant release, or whenever there are changes of stack, dependencies or critical code areas.
📋 Verification Items
| Item | Verified? |
|---|---|
Is there a secure code guideline per stack, versioned and formally approved (Technical Manager and AppSec), within its validity period? (DEV-001) | ☐ |
Are versioned security linters/rulesets configured, with local and pipeline enforcement, and do critical violations block commit or merge? (DEV-002) | ☐ |
Is SAST integrated as a gate, with high/critical severity findings blocking merge and a false-positive baseline approved by AppSec? (DEV-003) | ☐ |
Does the pipeline detect and block dangerous patterns (eval/exec, SQL concatenation, XSS, hardcoded secrets)? (DEV-002/DEV-003) | ☐ |
| Are external dependencies validated (SCA/CVE) and justified, with a SBOM record (CycloneDX or SPDX)? | ☐ |
Are critical components reviewed with a formal security checklist, with evidence per PR? (DEV-004) | ☐ |
Are technical exceptions recorded with justification, mitigation, approval by an authorised role, deadline and owner, and reviewed periodically? (DEV-005) | ☐ |
Is the provenance of incorporated code (reused, adapted or generated by GenAI) identified before incorporation, with human review for non-internal provenance? (DEV-006) | ☐ |
Is the use of GenAI to generate code subject to explicit, versioned technical constraints, with no automatic incorporation without review? (DEV-007) | ☐ |
| Are prompts, skill files, agent files and rules treated as code (versioned, code review, secret scanning, drift detection, inventory with an owner)? | ☐ |
| Is structured model output validated server-side (versioned schema, syntactic and semantic validation) before being consumed? | ☐ |
Are there quality profiles with security thresholds per risk level, versioned, with deviations blocking the pipeline or requiring approval? (DEV-008) | ☐ |
Are validations and exceptions annotated in the code/tests with a traceable reference (@sec:) to the requirement or decision? (DEV-009) | ☐ |
| Is validation evidence (linters, scanners, tests) versioned or archived, and is there a mandatory security gate before each release? | ☐ |
| Are the implemented controls aligned with the application's risk level (L1–L3) defined in Ch. 01? | ☐ |
🔄 Notes on practical application
- This checklist can be turned into a digital form, a CI/CD step or a technical compliance dashboard.
- Each item can be converted into a binary KPI (yes/no) per project, team or technology stack.
- Complete validation of this checklist makes it possible to assert technical compliance with Chapter 06, for the purposes of organisational maturity SbD-ToE.
❗ This chapter is essential for the coherent application of the requirements defined in Chapter 2. The absence of these practices compromises the objective, auditable validation of security in development.