🧱Capítulo Basilar

This chapter is considered foundational in the Security by Design – Theory of Everything (SbD-ToE) model. Its application is mandatory to guarantee the coherence, traceability and effectiveness of the remaining security practices.

The foundational chapters constitute the technical and methodological foundation of the model. The absence or partial application of any of them compromises the overall integrity of SbD-ToE, making the coherent adoption of operational and governance practices unfeasible.

Security Requirements

This chapter defines the normative framework of application security requirements of SbD-ToE, as well as the process for their correct application, validation and traceability throughout the entire development lifecycle.

The central focus is on:

• proportionality to risk, determined by the classification of the application (L1–L3);
• practical verifiability, ensuring that each requirement can be validated objectively;
• complete traceability, linking risk, requirement, control and evidence;
• governance of the requirement lifecycle, ensuring review, versioning and explicit updating whenever material changes occur in risk, architecture, exposure or integrations.

The chapter also addresses good practices in requirements management, the definition of acceptance criteria, the use of reusable catalogues and the integration of security requirements into agile development processes (e.g. backlog, user stories, acceptance criteria).

In this sense, the chapter functions not only as a normative catalogue, but also as the governance centre for security requirements: from here derive the minimum rules for risk-proportional selection, review and versioning, the link to Threat Modelling, the link to validation and the formal handling of exceptions.

It includes, in particular:

• A normative catalogue of technical requirements, organised by theme and application type
  → see Requirements Catalogue
• A traceability taxonomy with normalised identifiers and tags
  → see Traceability Taxonomy
• Recommendations for the objective and testable validation of requirements
  → see Requirements Validation
• A formal exception management process, including justification and risk acceptance
  → see Exception Management
• Detailed explanations of the rationale behind the requirements and their alignment with frameworks such as OWASP ASVS and NIST SSDF (see the corresponding sections in this chapter)

---

📊 Summary Table of Requirements Themes

The requirements catalogue is organised into 20 technical themes, identified by the codes T01–T20.
Each theme groups requirements with technical and operational affinity, and is applied proportionally to the risk level of the application.

Code	Theme	Short description
T01	Authentication and Identity Management	MFA, sessions, credential management
T02	Access Control	RBAC, least privilege, segregation of duties
T03	Logging, Auditing and Monitoring	Logs, critical events, retention, SIEM
T04	Session Management	Tokens, timeouts, logout, protection against theft
T05	Data Validation and Sanitisation	Input validation, safe output, protection against injection
T06	Protection of Sensitive Data	Ciphers, hashing, classification, access policies
T07	Cryptography and Key Management	Algorithms, rotation, secure storage, use of vaults
T08	Error and Message Handling	Stack traces, generic messages, exceptions
T09	API and Integration Security	Mutual authentication, whitelisting, rate limiting, mTLS
T10	Secure Configuration	Environment separation, parameterisation, configuration validation
T11	Code and Build Security	Linters, SAST, pipelines, internal dependencies
T12	Dependency Management and SBOM	Updates, SCA, SBOM, severity policies
T13	Secure CI/CD	Environment control, provenance, pipelines and validation
T14	Infrastructure as Code	Terraform, Ansible, policy validation
T15	Containers and Isolated Execution	Trusted images, hardening, scanning, runtime controls
T16	Deploy, Release and Runtime Controls	Reversibility, pre-production validation, environment segregation
T17	Security Testing	SAST, DAST, fuzzing, pipeline integration
T18	Continuous Monitoring and Alerting	Incident detection, real-time alerts
T19	Training, Onboarding and Profiles	Secure profiles, segregation, awareness
T20	Governance, Reviews and Compliance	Security reviews, contractual clauses, risk acceptance

📌 The selection of the themes to apply is made on the basis of the
Controls Matrix by Risk.

---

🧪 Practical prescription: what, who, how, when, why and to what end

📌 What must be done

1. Identify and document security requirements on the basis of risk
   (see Chapter 1 - Classification)
2. Ensure that all requirements are verifiable and testable
3. Integrate security requirements into the application's functional backlog
4. Guarantee systematic traceability between risk, requirement, control and evidence, using the defined taxonomy
5. Establish clear acceptance criteria for each requirement
6. Review and version requirements whenever there are material changes in risk, architecture, exposure, integrations or data processed
7. Review, maintain and justify exceptions on the basis of formal risk acceptance criteria

⚙️ How it must be done

• Use catalogues such as the one proposed in this manual or consolidated references such as the OWASP ASVS
• Adapt the requirements to the risk level and application type
• Keep the requirements in a versioned and auditable format (e.g. Markdown, Excel, Jira)
• Associate requirements with clear acceptance criteria (e.g. Gherkin, checklists)
• Identify requirements with normalised tags from the SEC-Lx-XXX taxonomy
• Record review decisions, changes and the re-triggering of analysis whenever the application context changes materially
• Validate the requirements against the criteria defined in the validation section

🧩 Use traceability matrices (risk → requirement → control → validation)
🎯 Define objective rules for the testability of each requirement

📆 When to apply

• In the requirements definition and/or architecture phase
• After Threat Modelling is completed (Ch. 3)
• Whenever the risk, exposure or context of the application changes
• In security reviews, design reviews, sprint planning or milestones

👥 Who is involved

Role/Function	Main contribution
Software Architects / DevOps / SRE	Translation of risks into concrete technical requirements
Product Owner	Integration into the backlog and user stories
AppSec Engineer	Definition of models, validation and alignment
QA	Definition of acceptance criteria and practical validation

✅ Traceability and testability are shared responsibilities.

🎯 Why / To what end

• Reduce risk from the earliest phases
• Avoid rework and late correction costs
• Support audits and compliance obligations
• Increase confidence in releases
• Integrate security natively into agile processes

---

⚠️ Caveats and limitations

• Generic or untestable requirements add no value
• The uncritical application of checklists can create a false sense of security
• Manual traceability can be burdensome without the support of adequate tools
• The use of heavily automated processes does not dispense with independent validation, explicit responsibility or verifiable evidence

---

🔍 What more can be done (and why)

• Create reusable internal catalogues, taking the catalogue in this manual as a basis
• Adopt formal or semi-formal languages for acceptance criteria
• Link requirements to technical documentation, diagrams and automated tests
• Automate traceability between risk and requirement with ALM tools

---

📌 Note on scope, process and extensibility

This chapter defines an essential and cross-cutting set of application security requirements, applicable to most enterprise, web and cloud-native systems.

The characteristics of the development and delivery process - including a high degree of automation, automatic generation of artefacts, use of low-code/no-code platforms or greater dependence on third parties - do not change the base requirements catalogue or the L1–L3 classification of the application, which continue to be determined by the impact and exposure of the system.

However, these contexts demand greater rigour in the application, validation, evidence and traceability of requirements, implying the reinforcement of the practices described in the technical chapters of the manual, namely Secure Architecture, CI/CD, Infrastructure as Code, Secure Development and Security Testing.

Applications with specific technical profiles (e.g. embedded systems, IoT, SCADA, mobile, medical or industrial applications) may also require additional requirements and controls, and should be complemented with specialised references such as:

• OWASP Mobile Security Testing Guide (MSTG)
• OWASP Internet of Things Project
• IEC 62443 - Security for Industrial Systems
• NIST SP 800-213 - IoT Device Cybersecurity

The definition and maintenance of the requirements catalogue and its validation must always follow the principles of structural coherence, proportionality by risk level and complete traceability.

---

📜 Relevant Organisational Policies

Policy	Mandatory	Application	Minimum expected content
Security Requirements Policy	Yes	All applications	Definition, review, traceability, risk acceptance
Security Testing Strategy Policy	Yes	L2/L3 apps	Criteria, evidence, acceptance, review cycle
Traceability Policy	Optional	Critical apps	Requirement→control→validation mapping, audit
Exception Management Policy	Yes	All	Formal process of justification, recording and acceptance

📎 See the details of the policies recommended for this chapter
For the printed version, see the manual's policy annex.