1.0 System overview
This section provides a high-level overview of the C5-DEC CAD system, including its system context and functional decomposition.
1.1 C5-DEC CAD context diagram ARC-001
Diagram
The C5-DEC CAD system is divided into five modules providing diverse functionality for different kinds of users. These modules interact with and/or build upon external open-source tools to provide an integrated CAD solution.
Parent links: MRS-058 Follow modular design
1.2 C5-DEC CAD functional tree ARC-002
Diagram
The diagram below depicts the functional tree of C5-DEC CAD.
Parent links: MRS-012 Testing framework integration, MRS-014 Project management feature, MRS-015 Time report consolidation, MRS-016 ISMS folder verification, MRS-026 Baseline module implementation, MRS-058 Follow modular design
2.0 Architecture views
This section presents architecture diagrams of the C5-DEC CAD system at different levels of abstraction, covering subsystem structure and overall system architecture.
2.1 C5-DEC CAD subsystems architecture ARC-003
Diagram
The diagram below depicts a view of the C5-DEC CAD subsystems.
Parent links: MRS-001 Diagram generation tool, MRS-002 Unified repository storage, MRS-003 Open file format, MRS-004 Unique artifact IDs, MRS-005 Requirements management tool, MRS-006 Artifact linking feature, MRS-009 Requirement hierarchies, MRS-010 Requirements traceability, MRS-011 V&V test features, MRS-013 Artifact tagging, MRS-017 Import/export artifacts, MRS-024 Secret sharing feature, MRS-025 File integrity check, MRS-026 Baseline module implementation, MRS-027 Link requirements to code, MRS-028 Search and filter, MRS-031 Threat modelling solution, MRS-033 Threat modelling tool, MRS-034 Export design assets, MRS-035 Risk management tool, MRS-046 File signing feature, MRS-047 PQC encryption feature, MRS-048 Include SDPM model, MRS-049 Include VVPM model, MRS-050 Include SPMM model, MRS-051 Include SSDLC publication, MRS-052 Include CC model, MRS-053 Include CC-TMM, MRS-054 Include SRA model, MRS-055 Define CC activities, MRS-056 Use NoSQL datastore, MRS-058 Follow modular design
Child links: SWD-001 CCT class diagram, SWD-002 C5-DEC CAD classes, SWD-003 C5-DEC CAD packages, SWD-018 Centralized settings module, SWD-004 C5-DEC CCT data model part 1, SWD-005 C5-DEC CCT data model part 2, SWD-006 C5-DEC CCT Doorstop metadata, SWD-007 C5-DEC CCT Doorstop Markdown body, SWD-008 C5-DEC CCT security functional class, SWD-009 C5-DEC CCT security assurance class, SWD-010 C5-DEC CCT element operations, SWD-011 C5-DEC CCT CEM evaluation activities, SWD-012 C5-DEC CCT sec. assurance and eval. act. dependencies, SWD-013 C5-DEC CCT generic Doorstop document, SWD-014 C5-DEC CCT security target data model, SWD-015 CRA module class diagram, SWD-016 SBOM module design, SWD-017 DocEngine template types and configuration design
2.2 C5-DEC CAD system architecture ARC-004
Diagram
The diagram below depicts the high-level architecture of C5-DEC CAD.
Parent links: MRS-001 Diagram generation tool, MRS-002 Unified repository storage, MRS-003 Open file format, MRS-005 Requirements management tool, MRS-007 Version control system, MRS-008 Use Git software, MRS-011 V&V test features, MRS-013 Artifact tagging, MRS-018 Collaboration feature, MRS-019 User management, MRS-020 User authentication, MRS-021 User authorization, MRS-022 Access control levels, MRS-023 Web-based asset sharing, MRS-026 Baseline module implementation, MRS-029 Filter by tags, MRS-033 Threat modelling tool, MRS-034 Export design assets, MRS-035 Risk management tool, MRS-040 CC forum and FAQ, MRS-041 Threats and risks DB, MRS-044 EUCC evaluation support, MRS-056 Use NoSQL datastore, MRS-057 Use web dev platform, MRS-058 Follow modular design, MRS-059 Enforce user management, MRS-060 Store assets for TRICK
Child links: SWD-001 CCT class diagram, SWD-002 C5-DEC CAD classes, SWD-003 C5-DEC CAD packages, SWD-004 C5-DEC CCT data model part 1, SWD-005 C5-DEC CCT data model part 2, SWD-006 C5-DEC CCT Doorstop metadata, SWD-007 C5-DEC CCT Doorstop Markdown body, SWD-008 C5-DEC CCT security functional class, SWD-009 C5-DEC CCT security assurance class, SWD-010 C5-DEC CCT element operations, SWD-011 C5-DEC CCT CEM evaluation activities, SWD-012 C5-DEC CCT sec. assurance and eval. act. dependencies, SWD-013 C5-DEC CCT generic Doorstop document, SWD-014 C5-DEC CCT security target data model, SWD-015 CRA module class diagram, SWD-016 SBOM module design
3.0 PlantUML architecture diagrams
This section provides architecture diagrams expressed in PlantUML at multiple levels of abstraction, from system context down to component-level detail and key interaction sequences. These diagrams complement the overview diagrams in sections 1 and 2 and are intended to remain in sync with the source code.
3.1 System context diagram (C4 level 1) ARC-006
Description
The system context diagram places C5-DEC CAD in its operational environment. It identifies the three primary user roles and the external software systems that C5-DEC CAD integrates with or depends upon.
Diagram
Parent links: MRS-058 Follow modular design
3.2 Container diagram (C4 level 2) ARC-007
Description
The container diagram decomposes C5-DEC CAD into its major runtime and logical containers. Three frontend layers expose all functionality to users; they delegate operations to eight core domain modules that in turn share a static assets store.
Diagram
Parent links: MRS-058 Follow modular design
3.3 CCT module – class hierarchy ARC-008
Description
The Common Criteria Toolbox (c5dec/core/cct.py) implements an object-oriented model of every CC construct defined in CC v3.1 R5 and CC 2022. Abstract base classes provide a shared interface; concrete domain classes mirror the CC document hierarchy from CCDocument down to individual FElement / AElement leaves. Paired *Builder classes parse the CC XML database into the corresponding model objects. The ChecklistBuilder and CLIChecklistHandler classes bridge the CC model to Doorstop-managed evaluation checklists.
Diagram
Parent links: MRS-058 Follow modular design
3.4 CPSSA subsystem – component diagram ARC-009
Description
The Cyber-Physical System Security Assessment (CPSSA) module (c5dec/core/cpssa/cpssa.py) is a single-module integration layer that bridges Doorstop architecture artifacts with three external OSS tools: OWASP pytm (threat modelling), Threagile (threat model YAML schema), and pyfair (FAIR-based quantitative risk analysis). The module reads Doorstop ARC/HARC/LARC items from a project's specs tree and produces threat models, DFDs, and risk analysis reports. A YAML mapping file (threagile-mappings.yml) translates Doorstop field values to Threagile schema terms; a JSON schema file (threagile-schema.json) validates Threagile export output. The module exposes five public functions that are invoked from the CLI via run_cpssa() in cli/commands.py.
Diagram
Parent links: MRS-058 Follow modular design
Child links: SWD-019 Doorstop ingestion helpers, SWD-020 Threagile mapping layer, SWD-021 Threat model generation — create_threat_model(), SWD-022 CPSSA report generation — generate_cpssa_report(), SWD-023 DFD generation — generate_dfd(), SWD-024 FAIR input template generation — generate_fair_input_template(), SWD-025 Quantitative risk analysis — run_quantitative_risk_analysis(), SWD-026 Sidecar files and Doorstop field conventions, SWD-027 CPSSA orchestration and CLI integration
3.5 Frontend layer – component diagram ARC-010
Description
C5-DEC CAD exposes three user-facing front-ends that share a single command dispatch layer (commands.py). The CLI is the primary interface; the TUI and GUI are alternative shells that delegate their business logic to the same command functions. All three front-ends write to a common command log file.
settings.EXECUTION_MODE is set at startup to "CLI", "TUI", or "GUI" so that core modules can adapt their output formatting accordingly.
Diagram
Parent links: MRS-058 Follow modular design
3.6 CC checklist creation – sequence diagram ARC-011
Description
This diagram traces the end-to-end flow when a user creates a CC evaluation checklist with c5dec checklist --create. The CLI dispatches to CLIChecklistHandler, which drives ChecklistBuilder to build the full CC object model from the XML database and then materialise one Doorstop work-unit item per SAR work unit in the target Doorstop document prefix.
Diagram
Parent links: MRS-058 Follow modular design
3.7 Deployment diagram ARC-012
Description
C5-DEC CAD ships three Docker images that mirror the runtime environments from development to production. The development image and the devcontainer are the primary daily-use targets. A PostQuantum Cryptography (PQC) side-car image provides an oqs-openssl3 environment for post-quantum operations accessed over a shared Docker network.
Diagram
Parent links: MRS-058 Follow modular design
4.0 Security architecture — threat model layer
This section captures the system components, trust boundaries, interfaces, data assets, and data flows of C5-DEC CAD at the level of granularity required to derive a full threat model using CPSSA. Items in this section carry CPSSA-consumable attributes (type, zone, flows, CIA ratings, data assets) and can be read directly by c5dec cpssa create-threat-model and c5dec cpssa generate-dfd.
4.1 Developer and operator workstation ARC-020
Description
Physical or virtual machine used by security engineers, software developers, and evaluators to invoke C5-DEC CAD. All tool execution occurs inside the c5dec-dev container, which is mounted from this host via VS Code devcontainer. The host's working directory is bind-mounted into the container, making the workstation the origin of all user-initiated commands and the destination for all generated output artefacts.
Parent links: MRS-058 Follow modular design
4.2 Frontend layer ARC-FRN
CLI, TUI, and GUI components that accept user input and dispatch commands to the core module layer. All three interfaces share the same underlying command infrastructure and settings module.
4.2.1 C5-DEC CLI ARC-021
Description
Click-based command-line interface (c5dec/frontend/cli/). Parses sys.argv, routes commands to per-module handler classes, and logs execution to the rotating command log. Dispatches to all nine core modules via direct Python function calls. TUI and GUI frontends both delegate their command execution through this layer.
Parent links: MRS-058 Follow modular design
4.2.2 C5-DEC TUI ARC-022
Description
Textual-based terminal user interface (c5dec/frontend/tui/). Wraps the CLI command layer with an interactive menu system. All data processing is delegated to ARC-021 (CLI); the TUI itself handles only user-input capture and terminal rendering.
Parent links: MRS-058 Follow modular design
4.2.3 C5-DEC GUI ARC-023
Description
Dear PyGui-based graphical interface (c5dec/frontend/gui/). Provides a windowed desktop experience by wrapping the CLI command layer. All command execution and data processing is delegated to ARC-021 (CLI). Requires X11 or Wayland forwarding from the host workstation into the container.
Parent links: MRS-058 Follow modular design
4.3 Core modules ARC-COR
The nine domain-specific processing modules that implement the C5-DEC CAD functional capabilities. Each module runs inside the c5dec container with access to shared configuration and the output workspace.
4.3.1 CCT — Common Criteria Toolbox module ARC-024
Description
The CCT module (c5dec/core/cct.py) implements the full Common Criteria toolbox. It parses the CC XML database (ARC-033) to build in-memory SFR/SAR trees, constructs evaluation checklists, generates ETR documents, and persists artefacts to the output workspace (ARC-035) via the Doorstop API (ARC-038). The class hierarchy spans base infrastructure, text/document primitives, Functional and Assurance requirement trees, and paired builder/exporter classes. Incorrect CC requirement mapping can directly invalidate a security evaluation, making integrity critical.
Parent links: MRS-058 Follow modular design
4.3.2 SSDLC module ARC-025
Description
The SSDLC module (c5dec/core/ssdlc.py) implements Secure Software Development Lifecycle project management. It reads project templates and config (ARC-034), initialises Doorstop document trees via the Doorstop Python API (ARC-038), and writes generated project scaffolding to the output workspace (ARC-035). Supports creation of full SSDLC traceability hierarchies (MRS, SRS, TST, SWD, TRA, TRB, etc.).
Parent links: MRS-058 Follow modular design
4.3.3 Transformer module ARC-026
Description
The Transformer module (c5dec/core/transformer.py) converts Doorstop Markdown/TeX/Quarto source artefacts into rendered output documents (HTML, PDF, PPTX). It reads source materials from the output workspace (ARC-035), dispatches render jobs to the DocEngine container (ARC-037) via HTTP, and writes final published documents back to ARC-035. Also handles translation pipelines and acronym expansion. HTTP calls to the DocEngine cross a container boundary and represent an unencrypted internal network data flow.
Parent links: MRS-058 Follow modular design
4.3.4 PM — Project management module ARC-027
Description
The PM module (c5dec/core/pm.py) integrates with OpenProject (ARC-041) via its REST API using a personal access token from the config store (ARC-034). It retrieves work-item and time-tracking data, generates cost and effort reports, and writes structured CSV/JSON output to the output workspace (ARC-035). The OpenProject REST call is the only outbound internet-facing data flow in C5-DEC CAD, making the API token a critical secret.
Parent links: MRS-058 Follow modular design
4.3.5 CPSSA module ARC-028
Description
The CPSSA module (c5dec/core/cpssa/) reads ARC Doorstop items (including this document, docs/specs/arc/) from the filesystem (ARC-033 for the CC XML asset space, or directly from the specs dir) and via the Doorstop Python API (ARC-038). It constructs an in-memory threat model and emits Threagile YAML, pytm DFD Python scripts, and CPSSA analysis reports to the output workspace (ARC-035). Configuration and sidecar paths are resolved from the config store (ARC-034).
Parent links: MRS-058 Follow modular design
4.3.6 Crypto module ARC-029
Description
The Crypto module (c5dec/core/cryptography.py) provides symmetric/asymmetric encryption, signing, hashing, and post-quantum cryptography. Classical crypto operations are delegated to GnuPG (ARC-039) via subprocess. PQC operations (ML-KEM, ML-DSA, SLH-DSA per FIPS 203/204/205) are delegated to the PQC sidecar container (ARC-036) via subprocess using the OpenSSL 3 OQS provider. Both external calls cross a process or container trust boundary. Encrypted output is written to the output workspace (ARC-035). Key material is the most sensitive data asset in the system.
Parent links: MRS-058 Follow modular design
4.3.7 CRA module ARC-030
Description
The CRA module (c5dec/core/cra.py) implements EU Cyber Resilience Act compliance workflows. It reads product declarations and CRA parameters from the config store (ARC-034), performs requirement gap analysis, and writes CRA technical documentation, checklists, and Quarto source files to the output workspace (ARC-035). Supports the full CRA technical documentation template workflow, including CycloneDX SBOM integration for vulnerability handling declarations.
Parent links: MRS-058 Follow modular design
4.3.8 SBOM module ARC-031
Description
The SBOM module (c5dec/core/sbom.py) generates Software Bill of Materials documents by invoking Syft (ARC-040) as a managed subprocess. Syft scans a target source tree or container image and returns CycloneDX or SPDX SBOM JSON/XML. The module processes and optionally enriches the output, then writes the final SBOM artefact to the output workspace (ARC-035). The subprocess call crosses a process trust boundary: Syft runs on the container host with broader filesystem access.
Parent links: MRS-058 Follow modular design
4.3.9 ISMS module ARC-032
Description
The ISMS module (c5dec/core/isms.py) supports Information Security Management System workflows. It reads risk catalogue and control mapping configuration from the config store (ARC-034), processes risk assessment data, and produces ISMS artefacts (SoA, risk treatment plans, control matrices) written to the output workspace (ARC-035) for downstream publishing by the Transformer module. ISMS outputs describe an organisation's security posture and are classified confidential.
Parent links: MRS-058 Follow modular design
4.4 Data stores ARC-DAT
Persistent data elements accessed by the core modules: the read-only CC XML database, the mutable configuration and parameters store, and the output artifact workspace where generated documents are written.
4.4.1 CC XML database ARC-033
Description
Read-only XML dataset bundled inside c5dec/assets/database/. Contains CC v3.1 R5 and CC 2022 SFR/SAR catalogues plus Protection Profile and package XML. Consumed exclusively by the CCT module (ARC-024) at runtime via direct file reads. Never written at runtime; updated only via package installation. Tampering with this dataset would silently corrupt all CC requirement lookups, making integrity critical despite the data being publicly available.
Parent links: MRS-058 Follow modular design
4.4.2 Config and parameters store ARC-034
Description
Mutable YAML/JSON configuration store comprising c5dec_params.yml, c5dec/assets/config.json, and working-directory config files. Holds tool parameters, module settings, Quarto template variables, and sensitive credentials (OpenProject API token, GnuPG key identifiers). All core modules read from this store; some write updated parameters. The API token stored here is the only network credential in the system, making this the most sensitive data store from a credential-theft perspective.
Parent links: MRS-058 Follow modular design
4.4.3 Output artifact workspace ARC-035
Description
Host-mounted bind-mount directory that receives all C5-DEC CAD output. Written to by all nine core modules: CC checklists/ETRs (CCT), SSDLC traceability trees (SSDLC), rendered HTML/PDF/PPTX (Transformer), cost reports (PM), Threagile/pytm threat models (CPSSA), encrypted files (Crypto), CRA documentation (CRA), SBOM JSON/XML (SBOM), and ISMS reports (ISMS). The bind mount creates a data pathway from the container to the host workstation, so any data written here is immediately accessible outside the container trust boundary.
Parent links: MRS-058 Follow modular design
4.5 Infrastructure and sidecars ARC-INF
Containerised infrastructure services that extend or support the core c5dec container. The PQC sidecar exposes post-quantum cryptographic primitives, and the DocEngine container provides Quarto-based document rendering.
4.5.1 PQC cryptographic sidecar ARC-036
Description
Container built from the oqs-ossl3 Dockerfile, providing an OpenSSL 3 environment with the Open Quantum Safe provider. Exposes ML-KEM, ML-DSA, and SLH-DSA (FIPS 203/204/205) algorithms via the standard OpenSSL CLI. Invoked as a subprocess by the Crypto module (ARC-029) over the Docker internal network. Key material is ephemeral and never stored at rest inside the sidecar. The container trust boundary between the c5dec container and the PQC sidecar is the primary data-flow risk for key material exposure.
Parent links: MRS-058 Follow modular design
4.5.2 DocEngine container ARC-037
Description
Document rendering container (docEngine.Dockerfile) hosting Quarto, TeX Live, and Pandoc. Exposes an HTTP endpoint on port 8080 for render-job submission from the Transformer module (ARC-026). Mounts the output workspace (ARC-035) as a bind mount to read source files and write rendered HTML/PDF/PPTX. No internet connectivity during normal operation. The HTTP interface between Transformer and DocEngine represents an unencrypted intra-Docker-network data flow.
Parent links: MRS-058 Follow modular design
4.6 External systems ARC-EXT
Out-of-process systems invoked by C5-DEC CAD core modules. These are treated as external entities at the trust boundary of the c5dec container: Doorstop (Python API, same process), GnuPG (subprocess on host), Syft (subprocess on host), and OpenProject (remote REST API over HTTPS).
4.6.1 Doorstop requirements manager ARC-038
Description
In-process Doorstop Python library providing the requirements-traceability API for CCT (ARC-024), SSDLC (ARC-025), and CPSSA (ARC-028) modules. Despite being an in-process library, it is modelled as an external entity at the EXTERNAL trust zone boundary because it accesses the filesystem independently, maintains its own document cache, and carries third-party supply-chain risk. A tampered Doorstop package could silently corrupt traceability documents or misreport review status.
Parent links: MRS-058 Follow modular design
4.6.2 GnuPG cryptographic engine ARC-039
Description
System GnuPG binary invoked via subprocess by the Crypto module (ARC-029). Handles symmetric/asymmetric encryption, signing, verification, and key management. Stores key material in the GnuPG keyring on the container filesystem (or bind-mounted host). GnuPG is the trust anchor for all classical cryptographic operations; a supply-chain compromise of the installed GPG binary would be a critical integrity failure. The keyring location on the bind-mount makes key material accessible on the host workstation.
Parent links: MRS-058 Follow modular design
4.6.3 Syft SBOM generator ARC-040
Description
Anchore Syft binary invoked as a managed subprocess by the SBOM module (ARC-031). Scans source directories or container images and emits CycloneDX or SPDX JSON/XML SBOMs via stdout. Runs with broader filesystem access than the calling module. If Docker-socket access is granted for container-image scanning, Syft can reach any locally available container image, representing a privilege escalation risk if the SBOM module is called with an attacker-controlled image reference.
Parent links: MRS-058 Follow modular design
4.6.4 OpenProject server ARC-041
Description
Remote OpenProject instance accessed by the PM module (ARC-027) via REST API v3 over HTTPS (port 443). Token-authenticated with a personal access token stored in ARC-034. The PM module issues read-only requests (work packages, time entries, project metadata); no write operations are performed against OpenProject from C5-DEC CAD. This is the only internet-facing outbound connection in the system. Token compromise would expose all projects visible to the token owner.
Parent links: MRS-058 Follow modular design