Skip to main content

Advanced Practices in Security Requirements

This annex presents non-mandatory advanced practices that may be adopted by organisations with greater maturity, normative demands (e.g. PCI-DSS, ISO 26262, IEC 62443), or a need for formal traceability and audit.

These recommendations do not replace the requirements of the SbD-ToE catalogue, nor are they considered in the calculation of maturity or threat mitigation.
They serve as an optional extension for critical contexts, and contribute to alignment with models such as DSOMM (Design & Development).

🔀 1. Automated Traceability​

Objective: Enable continuous traceability between requirements, code, tests and validations.

  • Use an ALM with traceability support (e.g. Codebeamer, Jama, Polarion, Jira + plugins)
  • Create bidirectional links between requirements and artefacts
  • Automate the extraction of coverage per requirement (e.g. CI validates that each requirement is covered)

🧪 2. Acceptance Criteria in BDD / Formal Language​

Objective: Make requirements testable and machine-verifiable.

  • Use Gherkin (Given–When–Then) or equivalent formats
  • For critical environments, consider languages such as OCL, TLA⁺ or EARS models
  • Example in Gherkin:
Feature: Autenticação multifator

  Scenario: Acesso por utilizador administrativo
    Given o utilizador possui privilégios de administrador
    When efetua login com credenciais válidas
    Then é solicitado a fornecer segundo fator de autenticação

📦 3. Internal Catalogues and Requirement Profiles​

Objective: Reuse and standardise common requirements by application type.

  • Create profiles by domain (e.g. internal API, mobile app)
  • Keep versioned templates with REQ-IDs and criteria by type
  • Validate the profiles with technical and architecture teams

📄 4. Integration with Threat Modelling​

Objective: Align requirements with real modelled threats.

  • Link REQ-IDs to threats (e.g. VAL-002 mitigates [STRIDE] Input Validation)
  • Justify requirements with model outputs (e.g. DFDs, IriusRisk)
  • Use automated annotations with tools such as ThreatSpec or Diagrams as Code

📊 5. Coverage Measurement and Management​

Objective: Monitor the definition, application and validation of requirements.

  • Useful metrics:

    • % with defined criteria
    • % with automated tests
    • % validated in QA
    • % traceable in the backlog

  • Generate reports per release or pipeline with the coverage status

🔐 6. Integration with Regulatory Compliance​

Objective: Guarantee that the requirements cover mandatory normative controls.

  • Maintain a mapping with:
    • PCI-DSS v4.0
    • ISO/IEC 27001 + 27002
    • NIST 800-53, 800-171
    • HIPAA, GDPR, ENS, etc.
  • Create layers of regulatory requirements with tags (e.g. #PCI-REQ-8.3)

🧠 7. Examples of High Maturity​

PracticeAdded valueSuggested tools
Automated link between REQ-ID and codeAuditability and complianceSemgrep, GitHub Adv. Security
Criteria in GherkinTestability and continuous validationCucumber, Behave
Bidirectional traceabilitySupport for regulated auditsJama, Jira Traceability Matrix
Requirements coverage metricsVisibility and continuous improvementTestRail, customised dashboards
Internal requirement profilesScalability and standardisationVersioned internal catalogue

✅ Final Considerations​

These practices are not mandatory, but are recommended when:

  • The organisation is subject to formal certifications
  • Criticality demands full traceability
  • There are large, multidisciplinary teams
  • Third-party audits need to be supported

📌 This annex may be extended with real examples and automatic traceability scripts.

🤖 8. Requirements as Code (Policy as Code)​

Objective: Represent requirements in a structured, automatically enforceable format.

  • Use YAML, Rego (OPA), JSON Schema, .policy
  • Integrate with pipelines for automatic validation
  • Example in Rego:
# Identificadores ilustrativos (EX-…); não correspondem ao Catálogo de Requisitos do Cap. 02.
package security.requisitos

default permitir = false

permitir {
  input.req_id == "EX-AUT-001"
  input.mfa_ativo == true
}

📍 This practice responds directly to DSOMM - Policy as Code.

🧰 9. Requirements Derived from Secure Design Principles​

Objective: Translate architecture principles into verifiable requirements.

  • Map REQ-IDs to principles such as Least Privilege, Fail Safe Defaults
  • Create "Design Guidelines to REQ" mappings
  • Ensure that architecture decisions result in traceable requirements

🧐 This practice reinforces alignment with DSOMM - Design & Development.