Skip to main content

Integration with IriusRisk and Automated Tools

🌟 Objective​

Demonstrate how to apply the normative principles of this chapter using automated Threat Modelling platforms, such as IriusRisk, replacing the manual files and maintaining traceability with the requirements defined in Chapter 2 - Security Requirements.

This integration aims to:

  • Automate the threat → requirement → control mapping;
  • Eliminate the need for manual files (yaml, md, csv);
  • Enable continuous validation via CI/CD, maintaining coherence with the SbD-ToE model.

🧭 What the tool replaces​

Manual file (local model)Equivalent in IriusRisk
threats.yamlThreats generated automatically from templates
requisitos.yamlSecurity Requirements assigned per threat
mitigations.mdList of controls with status (implemented / planned / n/a)
decisions.mdRisk Decisions documented with justification and date
mapeamento.mdExport of threat → requirement → control mappings

🔗 Link with Chapter 2 - Security Requirements​

To maintain consistency and traceability, the requirements defined in IriusRisk must:

  • Reference the same requirement codes as Ch. 2, e.g. AUT-003, ACC-010;
  • Be classified in the same functional category (authentication, access control, privacy);
  • Have an associated criticality (low / medium / high) according to the risk context;
  • Indicate the current status of the implementation.

Example of correspondence:​

Threat (IriusRisk)Derived requirement (Ch. 2)Status
Unsigned JWT tokenEX-AUT-003: Mandatory signatureImplemented
Endpoint /admin/config exposedEX-AC-010: Mandatory RBACIn progress
Excessive claims in the JWTEX-DAT-005: Minimal claimsJustified

Illustrative identifiers (EX-…); they do not correspond to the Requirements Catalogue of Ch. 02.

📁 Export structure in the project​

📁 threat-model/
├── iriusrisk-export/
│   ├── threats.json         # Lista de ameaças exportadas via API
│   ├── requirements.csv     # Requisitos de segurança atribuídos por ameaça
│   ├── controls.csv         # Estado de controlos aplicados
│   ├── decisions.csv        # Justificações de risco
├── threat-model.yml         # Metadados (última sincronização, projeto, versão)

🛠️ How to apply with IriusRisk in CI/CD​

The pipeline may include validations such as:

  • Checking that all threats with high criticality have:
    • a control applied OR
    • a documented justification;
  • Confirming that Ch. 2 requirements with estado != implemented have an associated ticket;
  • Exporting a summary report with the percentage of threats covered.

Example (bash pseudocode):​

# Verifica se há threats sem mitigação nem justificação

cat threats.json | jq '.[] | select(.criticality == "High")' |
  while read threat; do
    REQ=$(jq '.requirement_id' <<< "$threat")
    STATUS=$(grep $REQ requirements.csv | cut -d',' -f3)
    if [[ "$STATUS" != "Implemented" && "$STATUS" != "Justified" ]]; then
      echo "❌ Ameaça $REQ sem controlo válido"
      exit 1
    fi
  done

✅ Benefits of the Integration​

BenefitImpact
Eliminates manual filesReduces the risk of outdated information, increases reliability
Maintains a direct link to requirementsFacilitates audits and cross-validation with Ch. 2
Enables validation in CI/CDAutomates security by design as a release requirement
Supports formal risk decisionsJustifications with owner, date and context

✅ Good practices​

  • Reuse the threat and requirement templates offered by the tool;
  • Keep naming and requirement codes synchronised with Chapter 2;
  • Include the automatic export in CI/CD for continuous auditing;
  • Use the tool's dashboards to measure coverage and status;
  • Validate exports with local scripts and integrate with the backlog.

📎 Cross-references​

DocumentRelation to this file
addon/07-mapeamento-threats-requisitos.mdManual alternative to the mapping between threats and requirements
addon/06-threat-modeling-ci.mdValidation of threat modelling in CI/CD pipelines
25-rastreabilidade.mdFormal traceability with frameworks and requirements
15-aplicacao-lifecycle.mdIntegration with the project lifecycle

The adoption of tools such as IriusRisk must be accompanied by processes that guarantee coherence with the taxonomy and security requirements defined in the SbD-ToE manual. The tool does not replace the responsibility for traceability - it only systematises and automates it.