Secure Development Requirements Catalogue
Scope: practices and processes during development
This catalogue covers security requirements that apply to the development process - the practices, mechanisms and controls that must be active while code is written, pull requests are reviewed and contributions are integrated, ensuring that security is built in systematically from the first commit.
The scope includes: curation of guidelines per stack, configuration of linters and security rulesets, static analysis as an integration gate, code review with formal checklists, management of technical exceptions, governance of code provenance (including code generated by AI tools) and traceable annotations of security decisions.
For the complete mapping of all SbD-ToE requirements catalogues by technical domain, canonical prefix and owner, see Ch. 02 - Catalogue Mapping.
On curation: Consolidated from OWASP SAMM (Practice: Secure Build, Code Review), NIST SSDF (PW.1, PW.2, PW.4), the CWE Top 25, the OWASP Top 10 and good practices of secure software engineering. It must be adapted to the technological context (stacks, languages, tools) and reviewed with each guideline curation cycle.
For project instantiation and the operational nomenclature (SEC-Lx-DEV-CODIGO), see Taxonomy and Traceability.
Conventions
| Symbol | Meaning |
|---|---|
| ✔ | Mandatory requirement at this level |
| - | Not applicable or not mandatory at this level |
The levels are cumulative: L3 includes all L1 and L2 requirements; L2 includes all L1 requirements.
DEV Catalogue - Secure Development
Requirements that guarantee that development practices and processes incorporate security controls that are systematic, verifiable and proportional to risk.
| ID | Name | L1 | L2 | L3 | Acceptance criterion |
|---|---|---|---|---|---|
| DEV-001 | Secure code guidelines versioned and approved per stack | ✔ | ✔ | ✔ | Guidelines per language/stack published in a versioned repository; formal approval by the Technical Manager and AppSec documented; date of last review available and within the validity period. |
| DEV-002 | Security linters and rulesets configured and enforced | ✔ | ✔ | ✔ | Linter with security rules active locally and in the pipeline; ruleset versioned in the project repository; tailoring documented and approved; violations of critical patterns block the commit or merge. |
| DEV-003 | Static analysis (SAST) integrated as an integration gate | ✔ | ✔ | ✔ | SAST scanner active on every PR or commit; findings of high or critical severity block the merge; rule profile versioned; baseline of false positives documented and approved by AppSec. |
| DEV-004 | Code review with a security checklist for critical components | ✔ | ✔ | ✔ | PRs with changes to security, authentication, authorisation or sensitive-data components subject to review with a formal checklist; evidence of the completed checklist available per PR. |
| DEV-005 | Formal management of technical exceptions and deviations from guidelines | - | ✔ | ✔ | Exceptions documented with: technical justification, defined mitigation, explicit approval by an authorised role and a validity period; register of active exceptions reviewed periodically and available for audit. |
| DEV-006 | Provenance of incorporated code identified and controlled | - | ✔ | ✔ | Code of external origin (reused, adapted, generated by AI tools) identified before incorporation; provenance policy documented; evidence of human review per PR for code of non-internal provenance. |
| DEV-007 | Explicit technical constraints for AI-generated code | - | ✔ | ✔ | Policy for the use of generative AI tools in development documented, versioned and communicated to the team; technical constraints (scope, validation, approval) defined and verifiable; no automatic incorporation of suggestions without explicit review. |
| DEV-008 | Quality profiles with minimum security thresholds by risk level | - | ✔ | ✔ | Quality profiles (e.g. SonarQube Quality Gates) with minimum thresholds defined by risk level; deviations block the pipeline or require explicit, documented approval; profiles versioned. |
| DEV-009 | Traceable security annotations in code and tests | - | - | ✔ | Relevant security decisions and exceptions annotated in the code with a traceable reference to the canonical requirement or documented decision (e.g. // SEC-L3-VAL-SQLI, @sec:exception:DEV-005); the link between code and requirement can be audited without external context. |
Explanatory notes
- DEV-001: The curation of guidelines must be treated as an internal product - with clear ownership, semantic versioning and a defined review cycle. Outdated guidelines are more dangerous than having none, because they create false confidence.
- DEV-002: The tailoring of rulesets (disabling rules, adjusting thresholds) must be explicitly documented and approved - preventing "customisation" from becoming a mechanism for circumventing controls.
- DEV-003: The baseline of false positives is critical to putting SAST into operation: without it, the noise of findings will undermine the effectiveness of the gate and create pressure to disable it.
- DEV-006 and DEV-007: The multiple provenance of code (human, reused, AI-generated) is a reality that cannot be ignored. The relevant criterion is not the origin of the code but its formal understanding, validation and accountability - regardless of who or what produced it.
- DEV-009: Traceable annotations are particularly valuable in contexts of audit, incident response and team turnover - they make it possible to reconstruct the security intent of a decision without access to the original context of the person who made it.
For good practices in writing secure code per stack, see Secure Code Good Practices. For the configuration of linters and automated validations, see Linters and Validations. For code provenance and traceability, see Code Provenance. For the management of exceptions and justifications, see Exceptions and Justifications. For the responsible use of AI tools in development, see AI and Security.