1.0 CC Component Search & Export

This section groups requirements related to the C5-DEC Common Criteria Toolbox (CCT) component browser and export subsystem. It covers browsing the hierarchical CC security component database, querying it with full-text and attribute-based search, exporting selected Security Requirements to standard formats, and tailoring exported requirements to project-specific needs while maintaining CC traceability.

1.1 Access and Browse Database for CC Security Components SRS-001

As a General User, I want to access and browse the database so that I can identify Common Criteria Security Components relevant to my project.

Assuming I am logged in as an authorized user:

I access the database containing the CC Security Components
Then I should be able to see the Security Class Types Assurance and Functional.
When I select a Security Class Type the list of all respective Security Classes is displayed.
Then I should be able return to the Security Class Type selection (see Step 5) or to select a Security Class (see Step 6).
When I return to the Security Class Type selection, I resume to Step 2.
When I select a Security Class, I should be able to see the content of the Security Class, and the list of Security Families pertaining to that Security Class.
Then I should be able to return to the list of Security Classes (see Step 8) or select a Security Family (see Step 9).
When I return to the list of Security Classes, I resume to Step 4.
Repeat Steps 5 to 7 traversing the hierarchical structure until a Security Requirement is reached.
At any time I am able to exit the database.

Rationale

Security Components are of core relevance in the CC process. Efficient browsing of these will significantly ease the process of identifying Security Components appropriate for the project.

Dependencies

Related requirements

Acceptance criteria

General User can access the database.
General User can view and traverse the Common Criteria Security Components in their hierarchical structure
General User can view content of each Security Component element.
General User can access detailed information about each Security Component Element such as hierarchies, dependencies, and parent-child relations.
General User can exit the database at any time.

Parent links: MRS-030 Store SFRs/SARs, MRS-036 Store CC classes

Child links: TCS-001 Test accessing and browsing the CC Database

Attribute	Value
status	In Progress
importance	5
urgency	5
risk	1
outlay	2
type	F
version	0.1

1.2 Query the Database of Security Components. SRS-002

As a General User, I want to search and filter the database for Security Component Elements using full-text search and/or attributes.

Assuming I am logged in as an authorized user:

I access the database containing the CC Security Components.
Then I am able to define a query and search the database.
When I query the database I am provided with best matching results in descending order, from best to worst.
When I select a match, the respective Security Component Element is shown.
Then I can traverse the Security Component structure as defined in SRS-001 or define a new query.
When I define a new query, I resume to Step 3.
At all times I am able to exit the database.

Rationale

In addition to the browsing option, the General User should be able to query the database for keywords, further enhancing the identification process.

Dependencies

Related requirements

Acceptance criteria

General User can access the database.
General User can define full-text and/or attributes queries to search the database.
General User is successfully presented with search matches in descending order, from best to worst.
General User can select a match to view the respective Security Component Element.
General User can traverse the Security Component structure.
General User can define a new query.
General User can exit the database at any time.

Parent links: MRS-028 Search and filter, MRS-030 Store SFRs/SARs, MRS-036 Store CC classes

Child links: TCS-002 Test query the CC Database

Attribute	Value
dependence	['SRS-001']
status	In Progress
importance	3
urgency	3
risk	1
outlay	2
type	F
version	0.1

1.3 Export Security Components SRS-003

As a Developer, I want to be able to (select Security Components and) export (their respective) Security Requirements into a file so that I can e.g. import them into my project's REM system.

Assuming that I am logged in as an authorized user:

I access the database containing the CC Security Components
Then I am able to specify or select a (set of) Security Component/s of type 'functional' and/or 'assurance'.
When I specify or select a (set of) Security Component/s I expect the system to automatically assess the validity of the selection in terms of consideration of hierarchical and dependency relationships and to display the result
Then I am able to export the selected Security Components' Security Requirements.
When I select the export option I expect the system to warn me in case of an invalid selection
Then I am able to ignore the warning or adjust my selection.
When I proceed I am able to (at least) define the - filepath, - filename, - and format (csv, xlsx). Additional customizability to ease export to project's REM system format is desirable.
Then all Security Requirements of the selected Security Components are exported to the defined filepath with the filename and in the defined format.

Rationale

Enabling developers to export selected CC Security Requirements into standard file formats (CSV, XLSX) allows straightforward import into project Requirements Engineering Management (REM) systems. Automated validation of hierarchical and dependency relationships before export prevents invalid component sets from being used as a foundation for project security requirements, reducing rework and ensuring CC compliance from the outset.

Dependencies

Related requirements

Acceptance criteria

Developer can specify or select a set of Security Components
Selection is automatically validated in terms of the components' hierarchical and dependency relationships.
Respective Security Requirements are correctly exported according to the defined settings.

Parent links: MRS-053 Include CC-TMM, MRS-055 Define CC activities

Child links: TCS-003 Test exporting Security Components

Attribute	Value
dependence	['SRS-001', 'SRS-002']
status	In Progress
importance	3
urgency	3
type	F
version	0.1

1.4 Tailor Security Requirements SRS-004

As a Developer, I want to tailor Security Requirements to my project's needs, So that the tailoring process and the resultant Security Requirements comply with the Common Criteria. Assuming I am logged in as an authorized user:

Option 1: Export tailoring

I access the database containing the CC Security Components.
Then I am able to specify or select a (set of) Security Component/s of type 'functional' and/or 'assurance'.
When I specify or select a (set of) Security Component/s I expect the system to automatically assess the validity of the selection in terms of consideration of hierarchical and dependency relationships and to display the result.
Then I am able to export the selected Security Components' Security Requirements.
When I proceed to export I will be able to iterate through all Security Requirements and tailor each to my project's needs.
Then the system tracks the changes made to the original Security Requirements and includes the Common Criteria required information in the exported file.

Option 2: Parse tailored Requirements

I access the database containing the CC Security Components
Then I am able to provide a (set of) tailored Security Requirement/s in (TBD) format
When I provide a (set of) tailored Security Requirements the system is able to automatically validate made changes and generate the Common Criteria required information for the tailored Security Requirement.
Then I am able to export the provided (set of) tailored Security Requirement(s) with the additional information.

Rationale

Ensuring that the Security Requirements can be tailored in compliance with the Common Criteria is crucial for aligning the project needs with standardized security benchmarks. Facilitating a structured and traceable method of managing requirement modifications while maintaining an archival system of original requirements ensures auditability and adherence to the Common Criteria, particularly for PP/ST.

Dependencies

Related requirements

Acceptance criteria

The system successfully parses and validates Security Requirements against the DTD.
The system allows manipulations of the requirement according to defined operations.
The system provides options to select and edit operations as needed.
The tailored requirement provides a detailed list of conducted operations and modifications.

Parent links: MRS-032 Provide CCT implementation, MRS-053 Include CC-TMM, MRS-055 Define CC activities

Child links: TCS-004 Test tailoring Security Requirements

Attribute	Value
dependence	['SRS-003']
status	Open
importance	3
urgency	3
risk	1
type	F
version	0.1

2.0 Component Validation

This section groups requirements related to validating sets of Common Criteria security components selected for a project. It covers automated checking of hierarchical and dependency relationships between SFRs and SARs, rejection of invalid component sets with corrective suggestions, and generation of Impact Analysis Reports (IARs) to quantify the re-evaluation scope following changes to certified artefacts.

2.1 Validate Hierarchies and Dependencies in Security Components SRS-044

As a User, I want the system to validate the hierarchies and dependencies among the selected security components, so that I can ensure that my set of components is coherent and conforms to the CC.

When I select or provide a set of Security Components
Then I expect the system's validation mechanism to check whether the provided component set meets the hierarchical and dependency requirements of each selected Security Component.
When I provide an invalid set
Then I expect the system to classify the set as 'invalid' and optionally to provide potential valid sets based on the provided selection.
When I provide a valid set
Then I expect the system to classify the set as 'valid'

Rationale

To ensure that the specified and selected security components are coherent and abide by the CC guidelines, all hierarchical and dependency relations among them must be validated.

Dependencies

Related requirements

Acceptance criteria

The system enables the selection or provision of security components for a project.
Upon selection, the system automatically validates the hierarchical and dependency relationships among the chosen components, in accordance with CC guidelines.
The system provides clear feedback about the validation status, highlighting any inconsistencies or deviations from the CC guidelines.
Adjustments made to the components are accurately reflected and can be re-validated by the system.

Parent links: MRS-032 Provide CCT implementation, MRS-053 Include CC-TMM, MRS-055 Define CC activities

Child links: TCS-033 Test hierarchies and dependencies of Security Component sets

Attribute	Value
status	In Progress
importance	3
urgency	3
risk	1
outlay	3
type	F
version	1.0

2.2 Generate Impact Analysis Reports for Certification Maintenance. SRS-045

As a Developer, I want the system to automatically infer the impact of changes in both code and documentation, So that these insights are summarized in comprehensive Impact Analysis Reports (IARs), ensuring effective management of compliance and certification aspects throughout project alterations.

Note: This requirement is planned for a future release. The steps below describe the intended interaction model.

A developer commits changes to code or documentation in the project repository.
C5-DEC detects the changes by comparing the current state against the last certified baseline (stored as a tagged commit or baseline artifact).
The system identifies which Doorstop items (SRS, SWD, TST) are directly or transitively linked to the changed artefacts.
An Impact Analysis Report (IAR) is generated listing: - Changed artefacts (files, specifications, test cases). - Doorstop items impacted by each change. - CC work units potentially affected by the changes. - Re-evaluation scope recommendation (which SARs/work units need re-evaluation).
The IAR is exported as a structured Markdown/PDF document via the DocEngine.
The IAR exit code is non-zero if critical certification-scope items are impacted, enabling CI/CD integration.

Rationale

To maintain existing certifications and facilitate incremental certification processes in the face of changes, the system needs to automatically deduce and report the impacts stemming from alterations in code and documentation. Impact Analysis Reports (IARs) crystallize these impacts in a structured format, offering a clear overview of potential repercussions and are a required evaluation evidence for certification maintanence.

Dependencies

Related requirements

Acceptance criteria

The system must identify and track changes in both code and documentation.
The system must automatically infer the impacts of these changes.
An Impact Analysis Report (IAR) is generated, summarizing the inferred impacts.
The IAR must be comprehensible and encapsulate all necessary impact details.
The IAR should be structured to support certification maintenance and incremental certification processes.

Parent links: MRS-032 Provide CCT implementation, MRS-053 Include CC-TMM, MRS-055 Define CC activities

Child links: TCS-034 Test generation of Impact Analysis Report

Attribute	Value
status	Open
importance	2
urgency	2
risk	2
type	F
version	1.0

3.0 Infrastructure & Tooling

This section groups requirements related to the C5-DEC deployment infrastructure and toolchain. It covers containerized deployment via Docker DevContainers for reproducible environments on x86-64 and arm64, automated SSDLC project scaffolding via c5dec new, DocEngine report and presentation template creation, and the post-quantum cryptography (PQC) container backed by OpenSSL with the OQS provider.

3.1 Containerized Deployment via Docker DevContainer SRS-005

As a User, I want to deploy C5-DEC CAD using Docker DevContainers so that I can run the full toolchain in a reproducible environment on x86-64 and arm64 hardware.

I clone the C5-DEC repository from the canonical Git source.
I open the project folder in VS Code.
VS Code detects the .devcontainer/devcontainer.json configuration and offers a "Reopen in Container" prompt.
I select the C5-DEC CAD dev container configuration.
Docker builds the container image (or pulls a cached one).
A VS Code terminal opens inside the container with the Poetry shell activated.
I can run c5dec -h and receive the command help output.

Rationale

Containerized deployment via Docker DevContainer ensures a consistent, reproducible environment for all C5-DEC users regardless of host OS (x86-64 and arm64), removing dependency resolution friction and enabling the full toolchain (Poetry, Quarto, TeX Live, OQS-OpenSSL) to be available immediately after a single setup step in VS Code.

Dependencies

Related requirements

Acceptance criteria

The devcontainer builds and starts without errors on x86-64 and arm64 platforms.
The Poetry shell is activated automatically upon container start.
The c5dec CLI is available and responds to c5dec -h.
All required tools (Doorstop, Quarto, Pandoc, Git) are available in PATH.

Parent links: MRS-002 Unified repository storage, MRS-003 Open file format, MRS-026 Baseline module implementation

Child links: TCS-064 TC: Test containerized deployment on x86-64, TCS-065 TC: Test containerized deployment on arm64

Attribute	Value
status	In Progress
importance	5
urgency	5
risk	1
outlay	2
type	F
version	1.0

3.2 SSDLC New Project Scaffolding SRS-006

As a User, I want to create a new C5-DEC-based SSDLC project using the c5dec new command so that a fully structured project repository is scaffolded automatically.

I invoke c5dec new -p <project_name> -u <user_name> from the terminal.
C5-DEC creates a directory named <project_name> in the current working directory.
The created directory contains at minimum: - .devcontainer/ with devcontainer.json and Docker configuration - Dockerfile and dev.Dockerfile - A Doorstop-based document tree (MRS, SRS, SWD, TST stubs) - A DocEngine report template (report/) and presentation template (presentation/) - build.sh and session.sh scripts for container lifecycle management - README.md explaining the project structure
I can navigate into the project directory and open it in VS Code.
The devcontainer for the new project builds successfully.
The c5dec CLI is available inside the new project's container.

Rationale

Providing a project scaffolding command (c5dec new) automates the creation of a fully structured SSDLC project repository, complete with devcontainer configuration, Dockerfiles, Doorstop document trees, and DocEngine templates, enabling teams to follow C5-DEC-aligned SSDLC practices from day one without manual setup.

Dependencies

Related requirements

Acceptance criteria

c5dec new completes without errors given valid project name and user inputs.
The generated project directory exactly matches the C5-DEC project template structure.
The new project's devcontainer builds and starts successfully (x86-64 and arm64).
The Doorstop document tree is valid (doorstop reports no errors on the new project).

Parent links: MRS-002 Unified repository storage, MRS-003 Open file format, MRS-026 Baseline module implementation

Child links: TCS-068 TC: Test the creation of an empty C5-DEC-based project, TCS-069 TC: Test build and run of new project via scripts, TCS-070 TC: Test new project in VS Code

Attribute	Value
dependence	['SRS-005']
status	In Progress
importance	5
urgency	5
risk	1
outlay	3
type	F
version	1.0

3.3 DocEngine Report and Presentation Template Creation SRS-007

As a User, I want to create a DocEngine report or presentation template using c5dec docengine so that I can produce professionally formatted documents from Markdown/Quarto sources.

Report template

I invoke c5dec docengine report -n <report_name> from within a C5-DEC project.
C5-DEC creates a <report_name>/ directory pre-populated with: - _quarto.yml, _variables.yml, c5dec_config.yml - index.qmd as the entry point - chapters/ directory with starter .qmd chapter files - figs/, scripts/, tex/ support directories - references.bib, ieee.csl
I navigate into the report directory and run quarto render.
Quarto compiles the report to PDF (via LaTeX) and/or HTML without errors.

Presentation template

I invoke c5dec docengine presentation -n <presentation_name>.
C5-DEC creates a <presentation_name>/ directory pre-populated with a RevealJS-based Quarto presentation template.
quarto render produces a valid RevealJS HTML presentation.

CRA technical documentation template

I invoke c5dec docengine cra-tech-doc -n <doc_name>.
C5-DEC creates a <doc_name>/ directory pre-populated with the c5dec/assets/cra_tech_doc_template/ source tree, including: - c5dec_config_v2.yml for project metadata - Six Quarto .qmd chapter files aligned with CRA Annex V obligations (product description, design/development, risk assessment, applied standards, EU declaration, SBOM) - scripts/generate_doc.py for batch PDF generation - LaTeX preamble and bibliography stubs
I edit c5dec_config_v2.yml with product details and run python scripts/generate_doc.py or quarto render to produce a CRA-compliant PDF technical document.

Rationale

The DocEngine enables teams to produce professional technical reports, presentations, and CRA-compliant technical documentation from Quarto/Markdown sources with pre-configured C5-DEC styling (LaTeX/PDF and RevealJS). The cra-tech-doc template type was introduced in C5-DEC CAD v1.2 to reduce the manual effort of preparing CRA Annex V technical documentation by providing a pre-structured, pre-populated Quarto template aligned with regulatory obligations.

Dependencies

Related requirements

Acceptance criteria

c5dec docengine report -n <name> creates a valid Quarto report template.
c5dec docengine presentation -n <name> creates a valid Quarto presentation template.
c5dec docengine cra-tech-doc -n <name> creates a valid CRA technical documentation template with all six CRA Annex V chapter files present.
quarto render on any template type produces output without compilation errors.
Generated output (PDF/HTML) is formatted according to C5-DEC styling guidelines.
c5dec_config_v2.yml is present in the scaffolded directory for v2 template types.

Parent links: MRS-003 Open file format, MRS-026 Baseline module implementation

Child links: TCS-067 TC: Test DocEngine, TCS-076 TC: Test DocEngine CRA technical documentation template, TCS-077 TC: Test DocEngine presentation template

Attribute	Value
dependence	['SRS-005']
status	In Progress
importance	4
urgency	4
risk	1
outlay	3
type	F
version	1.0

3.4 Post-Quantum Cryptography Container Deployment SRS-008

As a User, I want to deploy the C5-DEC cryptography DevContainer so that I have access to post-quantum cryptography (PQC) tools including OpenSSL with the OQS provider.

I open the C5-DEC project in VS Code.
I select "Reopen in Container" and choose the C5-DEC CAD cryptography dev container.
Docker builds the cryptography container image based on openquantumsafe/oqs-ossl3.
A VS Code terminal opens inside the cryptography container.
I verify that openssl list -providers includes the OQS provider.
I can perform PQC key generation: openssl genpkey -algorithm kyber512.
I can sign files using a hybrid classical/PQC scheme.

Rationale

Post-quantum cryptography (PQC) operations require a dedicated container that bundles OpenSSL with the OQS provider, enabling file signing (GPG + PQC) and PQC encryption/decryption within the C5-DEC environment. This container is complementary to the main dev container and provides quantum-resistant security primitives accessible to C5-DEC users.

Dependencies

Related requirements

Acceptance criteria

The cryptography devcontainer builds and starts without errors.
The OQS provider is loaded in OpenSSL within the container.
PQC key generation (Kyber, Dilithium) succeeds without errors.
File signing with classical (RSA/ECDSA) and PQC algorithms succeeds.
All cryptographic operations produce valid output verifiable within the container.

Parent links: MRS-046 File signing feature, MRS-047 PQC encryption feature

Child links: TCS-066 TC: Test PQ cryptography container

Attribute	Value
status	In Progress
importance	3
urgency	3
risk	2
outlay	3
type	F
version	1.0

3.5 Shamir's secret sharing split and recovery SRS-054

As a Security Engineer, I want C5-DEC to split a hex-encoded secret into n shares with a recovery threshold of k, so that the secret can only be reconstructed when at least k out of n share holders cooperate.

I invoke c5dec crypto secret-split --secret <hex> -n <total> -k <threshold>, where <hex> is a hex-encoded byte string, n is the total number of shares, and k is the minimum number of shares required for recovery.
The system generates n Shamir shares over a prime field using the cryptography.split_secret() function and returns each share as a (x, y) integer pair.
I invoke c5dec crypto secret-recover --shares <share1> <share2> ... providing at least k shares.
The system reconstructs the original secret via Lagrange interpolation using cryptography.recover_secret() and returns the hex-encoded secret.
Providing fewer than k shares results in an error with a descriptive message.

Rationale

Shamir's secret sharing enables secure distribution of sensitive material (e.g. encryption keys, master passwords) across multiple custodians without any single party holding the full secret at rest.

Related requirements

SRS-INF (Infrastructure & Tooling)

Acceptance criteria

split_secret(secret_hex, n, k) returns n shares.
recover_secret(shares) with any k of those shares returns the original secret_hex.
recover_secret(shares) with fewer than k shares raises an error.
The function executes entirely in Python without external process calls.

Parent links: MRS-024 Secret sharing feature

Child links: TCS-083 TC: Test Shamir's Secret Sharing split and recovery

Attribute	Value
status	In Progress
importance	3
urgency	2
risk	2
outlay	2
type	F
version	1.0

3.6 GPG-based file signing, verification, and encryption SRS-055

As a Security Engineer, I want C5-DEC to wrap GPG operations (sign, verify, encrypt, decrypt) for files, so that project artefacts can be authenticated and protected using the user's existing GPG keyring without leaving the C5-DEC toolchain.

Signing: c5dec crypto gpg-sign --file <path> --key <key-id> produces a detached .sig file via cryptography.gpg_sign_file().
Verification: c5dec crypto gpg-verify --file <path> --sig <sig-path> verifies the detached signature via cryptography.gpg_verify_signature().
Encryption: c5dec crypto gpg-encrypt --file <path> --recipients <r1> [<r2>...] encrypts a file for one or more GPG recipients via cryptography.gpg_encrypt_file().
Decryption: c5dec crypto gpg-decrypt --file <path> decrypts a previously encrypted file via cryptography.gpg_decrypt_file().
All operations delegate to the system gpg binary; the user's GPG keyring and agent are used without modification.
Each function returns the path to the output file on success, or raises common.C5decError with a descriptive message on failure.

Rationale

GPG is the de-facto standard for artifact signing in open-source security toolchains. Wrapping GPG operations in C5-DEC CLI commands reduces key-management friction and ensures signing metadata is captured consistently across projects.

Related requirements

SRS-INF (Infrastructure & Tooling)
SRS-008 (PQC cryptography devcontainer)

Acceptance criteria

gpg_sign_file(path, key_id) produces a .sig file adjacent to the input.
gpg_verify_signature(file_path, sig_path) returns True for a valid signature and raises an error for a mismatched or tampered signature.
gpg_encrypt_file and gpg_decrypt_file are inverses: encrypting then decrypting a file returns the original content unchanged.

Parent links: MRS-046 File signing feature

Child links: TCS-084 TC: Test GPG file signing and signature verification, TCS-085 TC: Test GPG file encryption and decryption

Attribute	Value
status	In Progress
importance	3
urgency	2
risk	2
outlay	2
type	F
version	1.0

3.7 NaCl/Ed25519 key generation, signing, and verification SRS-056

As a Security Engineer, I want C5-DEC to provide Ed25519 key generation, signing, and verification operations via PyNaCl, so that artefacts can be digitally signed with modern elliptic-curve cryptography as an alternative to GPG.

c5dec crypto nacl-keygen generates an Ed25519 key pair via cryptography.nacl_keygen_signing() and returns the signing key and verification key as hex-encoded strings.
c5dec crypto nacl-sign --message <hex> --signing-key <hex> signs a hex-encoded message via cryptography.nacl_sign() and returns the signed message bytes as hex.
c5dec crypto nacl-verify --signed-message <hex> --verify-key <hex> verifies the signed message via cryptography.nacl_verify() and returns the original message bytes as hex on success, or raises common.C5decError on verification failure.
All three operations use PyNaCl; no external binary process is invoked.

Rationale

Ed25519 provides stronger security guarantees than RSA at much smaller key sizes. PyNaCl is a well-audited, pure-Python binding to libsodium, making it appropriate for environments where GPG infrastructure may not be available.

Related requirements

SRS-INF (Infrastructure & Tooling)
SRS-055 (GPG file signing)

Acceptance criteria

nacl_keygen_signing() returns two non-empty hex strings of consistent length.
nacl_sign(message_hex, signing_key_hex) returns a signed message that is longer than the original input by exactly 64 bytes (the Ed25519 signature prefix).
nacl_verify(signed_message_hex, verify_key_hex) with the matching key returns the original message hex unchanged.
nacl_verify raises an error when called with a mismatched verification key or tampered signed message.

Parent links: MRS-046 File signing feature

Child links: TCS-086 TC: Test NaCl Ed25519 key generation, signing, and verification

Attribute	Value
status	In Progress
importance	3
urgency	2
risk	2
outlay	2
type	F
version	1.0

3.8 Doorstop and Git as artifact management infrastructure SRS-058

C5-DEC uses Doorstop (v3.0b10) as the requirements management tool and Git as the distributed version control system for all project artefacts. This item documents how Doorstop and Git collectively satisfy the foundational artifact management requirements for which no dedicated C5-DEC module is needed.

MRS UID	Requirement	Provided by
MRS-004	Unique artifact IDs	Doorstop auto-generates UIDs (e.g. `SRS-001`) from prefix + digits
MRS-005	Requirements management tool	Doorstop
MRS-006	Artifact linking by ID	Doorstop `links:` field
MRS-007	Distributed VCS	Git
MRS-008	Use Git software	Git
MRS-009	Requirement hierarchies	Doorstop `parent:` in `.doorstop.yml`
MRS-011	V&V test features	Every Doorstop item links to TST/TRA items; pass/fail verdict stored in item
MRS-012	Testing framework integration	pytest via `poetry run pytest`
MRS-013	Artifact tagging	Doorstop custom attributes (e.g. `status:`, `type:`) serve as tags

No additional C5-DEC implementation is required for these capabilities beyond the existing Doorstop project configuration and Git repository.

Rationale

Documenting the mapping between MRS requirements and infrastructure tools ensures full upward traceability is maintained in the Doorstop tree even for capabilities that are satisfied by third-party tooling rather than custom C5-DEC code.

Acceptance criteria

A doorstop on the repository exits with zero errors.
All MRS items in this table have at least one SRS descendant or are covered by this item.

Parent links: MRS-004 Unique artifact IDs, MRS-005 Requirements management tool, MRS-006 Artifact linking feature, MRS-007 Version control system, MRS-008 Use Git software, MRS-009 Requirement hierarchies, MRS-011 V&V test features, MRS-012 Testing framework integration, MRS-013 Artifact tagging

Attribute	Value
status	Active
importance	3
urgency	1
risk	1
outlay	1
type	C
version	1.0

3.9 Platform-delegated features (out of scope for custom implementation) SRS-059

The following MRS requirements are satisfied by the underlying web-based software development platform (GitLab, GitHub, or Gitea) and are explicitly out of scope for custom C5-DEC module implementation. No dedicated C5-DEC code is planned for these items.

MRS UID	Requirement	Delegated to
MRS-017	Import/export artefacts in open format	Doorstop export/import + Git push/pull
MRS-018	Collaboration feature	GitLab/GitHub merge requests, issues
MRS-019	User management	GitLab/GitHub user administration
MRS-020	User authentication	GitLab/GitHub authentication (SSO, 2FA)
MRS-021	User authorization	GitLab/GitHub repository access control
MRS-022	Access control levels (admin/standard)	GitLab/GitHub role-based permissions
MRS-023	Web-based asset sharing	GitLab/GitHub web interface + CI/CD pages
MRS-056	Persistent NoSQL document-oriented datastore	Doorstop YAML files in Git serve as a document-oriented store
MRS-057	Web-based software development platform	GitLab/GitHub/Gitea instance
MRS-059	Enforce user management, access control, authentication	GitLab/GitHub enforces all three
MRS-060	Store assets for TRICK	Out of scope for the current release

These MRS requirements remain in the specification to preserve contractual completeness. Their implementation is governance-level rather than toolchain-level: projects adopting C5-DEC are expected to provision an appropriate Git hosting platform.

Rationale

Delegating authentication, authorisation, and collaboration to the hosting platform avoids reinventing security-critical infrastructure and leverages enterprise-grade access control that would be disproportionately costly to replicate within C5-DEC.

Parent links: MRS-017 Import/export artifacts, 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-056 Use NoSQL datastore, MRS-057 Use web dev platform, MRS-059 Enforce user management, MRS-060 Store assets for TRICK

Attribute	Value
status	Out of scope
importance	2
urgency	1
risk	1
outlay	1
type	C
version	1.0

4.0 Compliance & Project Management

This section groups requirements related to compliance tooling and project management support within C5-DEC. It covers conversion of OpenProject CSV time reports to the IAL tabular format, consolidation and cost reporting of multiple timesheets, ISMS folder content verification against a reference document list, SBOM generation/import/diff/validation via Syft integration, and automated CRA Annex I/V compliance checklist generation.

4.1 Project Management Time Report Conversion SRS-009

As a Project Manager, I want to convert an OpenProject CSV time report to the IAL tabular format using c5dec timerep so that I can prepare data for consolidation and cost analysis.

I export a time report from OpenProject in CSV format.
I invoke c5dec timerep -i <input_csv> -o <output_path>.
C5-DEC reads the CSV and transforms it into the IAL tabular format.
The output file is saved at <output_path> in the expected format.
Each row in the output corresponds to one time entry with columns for user, date, hours, project, and work package.

Rationale

Converting OpenProject-exported CSV time reports to the IAL tabular format enables teams to standardize time tracking data before consolidation and cost analysis, removing manual spreadsheet manipulation and ensuring consistent output across projects.

Dependencies

Related requirements

Acceptance criteria

c5dec timerep produces a non-empty output file for a valid OpenProject CSV input.
The output format conforms to the IAL tabular specification (columns, date format).
Invalid or malformed CSV input produces a descriptive error message.
Time entries are preserved without data loss during conversion.

Parent links: MRS-014 Project management feature, MRS-015 Time report consolidation

Child links: TCS-071 TC: Test time report conversion from OpenProject CSV

Attribute	Value
status	In Progress
importance	4
urgency	4
risk	1
outlay	2
type	F
version	1.0

4.2 Project Management Timesheet Consolidation and Cost Reporting SRS-010

As a Project Manager, I want to consolidate multiple IAL-format timesheets and compute a cost report using c5dec consolidate and c5dec costrep so that I can produce a unified financial overview of project effort.

Consolidation

I invoke c5dec consolidate -i <input_dir> -o <output_file>.
C5-DEC reads all IAL-format timesheet files from <input_dir>.
It merges all entries into a single consolidated timesheet saved at <output_file>.
Duplicate entries are detected and handled according to the consolidation rules.

Cost report

I invoke c5dec costrep -i <consolidated_file> -p <params_file> -o <output_file>.
C5-DEC reads the consolidated timesheet and personnel cost parameters.
It computes direct costs per person (hours × day rate) and adds overhead.
The cost report is saved at <output_file> in tabular/CSV format.

Rationale

Consolidating multiple converted timesheets into a single unified view and computing cost reports from personnel salary data and overhead rates automates a key PM activity, reducing errors and enabling consistent cost tracking across multi-team projects.

Dependencies

Related requirements

Acceptance criteria

c5dec consolidate merges all timesheets in the input directory without data loss.
c5dec costrep produces a cost report with per-person and total cost breakdowns.
The cost report output matches expected values for a reference dataset.
Missing or malformed parameter files produce a descriptive error.

Parent links: MRS-015 Time report consolidation

Child links: TCS-072 TC: Test timesheet consolidation and cost report generation

Attribute	Value
dependence	['SRS-009']
status	In Progress
importance	4
urgency	4
risk	1
outlay	2
type	F
version	1.0

4.3 ISMS Folder Content Verification SRS-011

As an ISMS Manager, I want to verify that an ISMS folder structure matches a reference document list using C5-DEC so that I can detect missing or undocumented artifacts before an audit.

I configure the ISMS folder path and reference document list in the C5-DEC configuration file.
I invoke the ISMS verification function (via CLI or API).
C5-DEC scans the ISMS folder and compares its contents against the reference list.
The tool outputs: - A list of documents present in the folder but not in the reference list (unexpected). - A list of documents in the reference list but not found in the folder (missing). - A summary count of total, matching, missing, and unexpected documents.
If all documents match exactly, the tool reports a compliant status.

Rationale

Organizations following an ISMS must keep their document repository aligned with a reference list of controlled documents. Automating the verification of ISMS folder content against a defined document list prevents compliance gaps and ensures audit readiness by flagging missing or unexpected documents.

Dependencies

Related requirements

Acceptance criteria

The ISMS verifier correctly identifies all missing documents from the reference list.
The ISMS verifier correctly identifies all unexpected documents in the folder.
A compliant folder (all documents present, no extras) reports zero discrepancies.
The tool handles nested folder structures and document subdirectories.

Parent links: MRS-016 ISMS folder verification

Child links: TCS-073 TC: Test ISMS folder content verification

Attribute	Value
status	In Progress
importance	3
urgency	3
risk	1
outlay	2
type	F
version	1.0

4.4 SBOM Generation, Import, Diff, and Validation SRS-012

As a Security Engineer, I want to generate, import, compare, and validate SBOMs using c5dec sbom so that I can maintain traceable software inventory data as part of SSDLC artifacts.

Generate

I invoke c5dec sbom generate -t <target_dir> -f <format> -o <output_file>.
C5-DEC calls Syft on the target directory and produces an SBOM in CycloneDX or SPDX format at <output_file>.

Import

I invoke c5dec sbom import -i <sbom_file> -d <doorstop_doc>.
C5-DEC parses the SBOM and imports components as Doorstop items in <doorstop_doc>.

Diff

I invoke c5dec sbom diff -a <sbom_v1> -b <sbom_v2> -o <diff_report>.
C5-DEC compares the two SBOMs and produces a diff report listing added, removed, and changed components.

Validate

I invoke c5dec sbom validate -i <sbom_file>.
C5-DEC validates the SBOM against the CycloneDX or SPDX JSON schema and reports any schema violations.

Rationale

Software Bill of Materials (SBOM) management is a security and supply chain transparency requirement under frameworks such as the EU CRA. C5-DEC provides SBOM generation (via Syft), import into the Doorstop artifact store, diff comparison between versions, and schema validation, enabling teams to maintain traceable, version-controlled SBOMs as SSDLC artifacts.

Dependencies

Related requirements

Acceptance criteria

c5dec sbom generate produces a valid CycloneDX or SPDX SBOM for a given target.
c5dec sbom import creates Doorstop items with correct component metadata.
c5dec sbom diff correctly identifies added, removed, and modified components.
c5dec sbom validate returns success for a schema-valid SBOM and reports errors for an invalid one.

Parent links: MRS-025 File integrity check, MRS-026 Baseline module implementation, MRS-064 Generate SBOM using Syft, MRS-065 Import SBOM into Doorstop traceability

Child links: TCS-074 TC: Test SBOM generation, import, diff, and validation, TCS-080 TC: Test SBOM import to Doorstop and validate completeness, TCS-081 TC: Test SBOM SPDX format and Syft-not-installed error path, TCS-082 TC: Test SHA-256 hash computation and verification

Attribute	Value
status	In Progress
importance	4
urgency	4
risk	2
outlay	3
type	F
version	1.0

4.5 CRA Annex I and V Compliance Checklist Generation and Export SRS-013

As a Compliance Engineer, I want to generate a CRA compliance checklist using c5dec cra-checklist and link SBOM data to CRA requirements so that I can track and demonstrate compliance with the EU Cyber Resilience Act.

I invoke c5dec cra-checklist -o <output_file>.
C5-DEC loads the internal CRA Annex I/V/VII database.
It generates a checklist containing all CRA requirements with columns for: requirement ID, description, category, compliance status, and evidence reference.
The checklist is exported to Excel format at <output_file>.
I optionally link an existing SBOM to CRA requirements using c5dec cra-checklist --sbom <sbom_file>, which auto-verifies applicable SBOM-related requirements.
I review the checklist and mark compliance status for each requirement.

Rationale

The EU Cyber Resilience Act (CRA) requires manufacturers of products with digital elements to demonstrate compliance with Annex I essential security requirements and Annex V/VII technical documentation obligations. Providing an automated checklist generator tied to the CRA database reduces manual compliance effort and enables traceability between product features and regulatory requirements.

Dependencies

Related requirements

Acceptance criteria

c5dec cra-checklist generates a non-empty Excel checklist covering all CRA Annex I categories.
The checklist includes all mandatory and recommended requirements from the database.
SBOM linking auto-marks applicable requirements as verified.
The output file is a valid Excel workbook readable by common spreadsheet tools.
Re-running the command with updated parameters preserves existing status fields.

Parent links: MRS-026 Baseline module implementation, MRS-035 Risk management tool, MRS-061 Integrate CRA requirements database, MRS-062 Generate CRA compliance checklist, MRS-063 Generate CRA technical documentation template

Child links: TCS-075 TC: Test CRA compliance checklist generation and export, TCS-078 TC: Test CRA checklist category filtering, TCS-079 TC: Test CRA SBOM auto-verification

Attribute	Value
status	In Progress
importance	4
urgency	4
risk	2
outlay	3
type	F
version	1.0

5.0 Knowledge Base

This section groups requirements related to the C5-DEC embedded Knowledge Base (KB) for Common Criteria concepts. It covers navigation and access to KB sections and articles, user-friendly explanations of technical terminology and acronyms, seamless cross-referenced navigation between interconnected articles, availability of pragmatic guidance and best practices, continuous synchronization with the latest CC version, integration of multimedia elements, FAQ section links, and provision of a link to CC-specific community forums.

5.1 Access and Navigation Through Knowledge Base SRS-014

As a General User, I want to access and navigate through the Knowledge Base so that I can effortlessly locate and explore information relevant to my needs. Assuming I am on the Knowledge Base landing page:

I access the Knowledge Base interface.
Then I should see different sections/categories of the Knowledge Base.
When I select a section, a list of relevant articles or topics is displayed.
I can select an article or topic to view more details.
I can navigate back to the previous article or to other sections at any point.
At any time, I can exit the Knowledge Base.

Rationale

Facilitating smooth access and navigation through the KB ensures that users can explore and understand the Common Criteria with ease, promoting effective usage of the provided information.

Dependencies

Related requirements

Acceptance criteria

General User can access the Knowledge Base.
General User can view various sections or categories in the KB.
General User can view articles or topics under a selected section.
General User can navigate through articles and sections and exit at any time.

Parent links: MRS-032 Provide CCT implementation, MRS-039 Maintain CC knowledge base

Child links: TCS-005 Test navigating the Knowledge Base

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	1
outlay	3
type	F
version	0.2

5.2 Comprehensive and User-Friendly Explanations SRS-015

As a General User, I want to read comprehensive and user-friendly explanations of technical terms and concepts so that I can understand the Common Criteria without specialized prior knowledge. Assuming I am viewing an Article in the Knowledge Base

When I encounter a technical term or acronym, it should be clearly defined or explained in layman’s terms.
Optionally, a link to a detailed explanation or dedicated page for the term/acronym is available.
I can navigate to this detailed explanation Article, if available, and return to the original content.

Rationale

Providing user-friendly explanations will demystify the complex language of the \nCommon Criteria, making it accessible and understandable to a wider audience.

Dependencies

Related requirements

Acceptance criteria

Technical terms and acronyms within articles are clearly defined or explained.
Detailed explanation pages or dedicated pages are optionally available and accessible.

Parent links: MRS-032 Provide CCT implementation, MRS-039 Maintain CC knowledge base

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	1
outlay	2
type	F
version	0.2

5.3 Interconnected Framework and Seamless Navigation SRS-016

As a General User, I want to traverse through interconnected Articles effortlessly via cross-references and hyperlinks, in markdown or exported HTML format, so that I can explore related concepts without difficulty.

Assuming I am viewing a Knowledge Article in the Knowledge Base:

I see hyperlinks or cross-references that guide me to related topics or articles, regardless of viewing format (markdown/HTML).
Clicking a hyperlink navigates me to the related topic or article with no broken links encountered.
If a linked article is not available, the hyperlink directs me to a standard placeholder article that communicates the upcoming availability of the desired content.
I can easily navigate back to the initial article or to other interconnected topics, with a clear and user-friendly navigation path.

Rationale

A seamless and interconnected navigation system, which includes guidance to upcoming content via a standard placeholder, ensures a clear, consistent, and enriching user experience throughout the KB in both markdown and HTML formats.

Dependencies

Related requirements

Acceptance criteria

General User can navigate seamlessly between interconnected topics via cross-references and hyperlinks, both in markdown and exported HTML format.
No broken links are present, ensuring a consistent user experience and unhindered navigation.
Links leading to not-yet-available content direct users to a standard placeholder article, ensuring a consistent and clear message regarding upcoming content.
User can return to the initial KA or navigate to related articles easily, with clear paths to navigate back or explore further.

Parent links: MRS-032 Provide CCT implementation, MRS-039 Maintain CC knowledge base

Child links: TCS-007 Test interconnection of Knowledge Base, TCS-006 Test comprehensiveness of Knowledge Base

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	1
outlay	3
type	F
version	0.3

5.4 Availability of Pragmatic Guidance and Best Practices SRS-017

As a General User, I want to access pragmatic guidance and best practices in the Knowledge Base so that I can effectively implement the Common Criteria's requisites in a practical manner. Assuming I am viewing an article or topic in the Knowledge Base

The content includes actionable guidance and best practices related to the topic.
The guidance is presented in a user-friendly manner, offering tangible steps or advice.
I can navigate to related topics for additional information and guidance.

Rationale

Facilitating users with pragmatic guidance and best practices assists them in effectively implementing the Common Criteria, bridging the gap between theory and practical application, and enhancing organizational security practices.'

Dependencies

Related requirements

Acceptance criteria

Articles contain actionable guidance and best practices for implementing the Common Criteria.
The guidance provided is pragmatic, offering step-by-step instructions or tangible advice for application.

Parent links: MRS-032 Provide CCT implementation, MRS-039 Maintain CC knowledge base

Child links: TCS-008 Test currency of Knowledge Base

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	1
outlay	3
type	F
version	0.2

5.5 Continuous Updates and Assurance of Current Information SRS-018

As a General User, I want assurance that the information in the Knowledge Base is up-to-date and relevant to specific CC versions, so that I can trust and effectively utilize the provided insights. Assuming I am viewing an article or topic in the Knowledge Base:

I can see a timestamp or revision history indicating the last update or revision date.
The content reflects the most current information of the Common Criteria.
The articles or topics are reviewed and updated with each new release of the Common Criteria.
The relevant CC version(s) are clearly indicated on the articles or within general sections of the Knowledge Base.

Rationale

Ensuring that the Knowledge Base reflects the most recent information of the Common Criteria guarantees users access to the most relevant and applicable insights.

Dependencies

Related requirements

Acceptance criteria

The Knowledge Base articles are reviewed and updated with each new issuance of the Common Criteria.
A revision history or last-updated timestamp is visible to users to ensure transparency regarding the currency of the information.
Each article or general section of the Knowledge Base clearly states the version(s) of the Common Criteria it is relevant to.

Parent links: MRS-032 Provide CCT implementation, MRS-039 Maintain CC knowledge base

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	1
outlay	2
type	F
version	0.2

5.6 Integration of Multimedia Elements in Knowledge Articles SRS-019

As a Content Developer, I want to integrate multimedia elements in Knowledge Articles, so that I can enhance the learning and user experience.

When creating or editing a Knowledge Article, I should have the ability to embed multimedia elements such as images, videos, and interactive diagrams.
Then, these multimedia elements should be accessible and interactable (if applicable) when viewing through markdown editors and in the exported HTML format.
I should also be able to provide alternative descriptions for multimedia elements to ensure accessibility.

Rationale

Embedding multimedia elements enhances learning experiences by catering to various learning styles and enriching textual content, thus increasing user engagement and understanding.

Dependencies

Related requirements

Acceptance criteria

Multimedia elements such as images, videos, and interactive diagrams are embeddable in the Knowledge Articles.
Users can access and interact (if applicable) with the multimedia elements when viewing through markdown editors and in the exported HTML format.
Alternative descriptions for multimedia elements are present and accurately describe the \ncontent or function of the media.

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-009 Test cosmetic features of Knowledge Base

Attribute	Value
dependence	['SRS-014']
status	Not Started
importance	2
urgency	1
risk	1
outlay	3
type	F
version	0.1

5.7 Integrating Links to FAQ Section SRS-020

As a General User, I want to have direct access to a relevant FAQ section from Knowledge Articles, so that I can swiftly find concise answers to related questions.

While reading a Knowledge Article, I should encounter links that direct me to an FAQ section.
These links should be contextually relevant and provide additional, succinct information pertaining to the content being read.
Links should direct users to a placeholder page if the FAQ section is not yet developed or available.

Rationale

Providing direct links to an FAQ section allows users to quickly access concise, straightforward answers to potential queries, enhancing user efficiency and satisfaction in interacting with the platform.

Dependencies

Related requirements

Acceptance criteria

Users can access an internal or external FAQ section via links embedded within the Knowledge Articles.
Links to the FAQ section are relevant, accurate and guide users toward information pertinent\n to the Knowledge Article's context.

Parent links: MRS-032 Provide CCT implementation, MRS-040 CC forum and FAQ

Child links: TCS-009 Test cosmetic features of Knowledge Base

Attribute	Value
dependence	['SRS-014']
status	Not Started
importance	2
urgency	2
risk	1
outlay	2
type	F
version	0.1

5.8 Provision of General Link to a CC-Specific Forum SRS-021

As a General User, I want a straightforward way to access a CC-specific forum from the Knowledge Base, so that I can explore, contribute to, and learn from discussions and interactions within a community of CC practitioners and experts.

When I am on the main page or any part of the Knowledge Base, I should easily identify and access a link that navigates to a CC-specific forum.
The link directs me to a forum where I can view and participate in discussions related to the Common Criteria.

Rationale

A CC-specific forum enhances user engagement and community interaction by providing a platform for discussions, knowledge-sharing, and collaborative problem-solving related to Common Criteria, without overcomplicating the navigation within the Knowledge Base.

Dependencies

Related requirements

Acceptance criteria

A prominently visible link to a CC-specific forum is available on the main page or navigation bar of the Knowledge Base.
Users can effortlessly navigate to the forum to participate in or view discussions related to CC topics.

Parent links: MRS-032 Provide CCT implementation, MRS-040 CC forum and FAQ

Child links: TCS-009 Test cosmetic features of Knowledge Base

Attribute	Value
dependence	['SRS-014']
status	Not Started
importance	2
urgency	2
risk	1
outlay	1
type	F
version	0.1

5.9 SSDLC methodology models and secure development lifecycle content SRS-060

C5-DEC SHALL include and maintain methodology models covering the secure software development lifecycle, project management, and testing practices. The models are published as Markdown content in docs/manual/ and are used by the SSDLC project scaffolding feature (see SRS-006).

MRS UID	Requirement	Provided by
MRS-048	Software Development Plan Model (SDPM)	SSDLC project template + `docs/manual/ssdlc.md`
MRS-049	Verification & Validation Plan Model (VVPM)	SSDLC project template + test scaffolding
MRS-050	Software Project Management Model (SPMM)	PM module (`c5dec/core/pm.py`) + time-report templates
MRS-051	Secure SDLC publication	`docs/manual/ssdlc.md` + CRA tech-doc template
MRS-052	Common Criteria Model (CCM) in the knowledge base	`docs/manual/cct.md` + CCT knowledge base content

Rationale

The SSDLC methodology models form the theoretical backbone of the C5-DEC toolchain. Keeping them in Markdown in the same repository as the code ensures they stay as the authoritative reference for the scaffolded project templates.

Acceptance criteria

docs/manual/ssdlc.md covers SDPM, VVPM, and SPMM topics to a level usable by a project team during evaluation preparation.
docs/manual/cct.md provides a description of the Common Criteria Model.
The SSDLC project scaffolding (c5dec new) includes placeholder documents for each of the five model areas.

Parent links: 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

Attribute	Value
status	In Progress
importance	3
urgency	2
risk	1
outlay	2
type	C
version	1.0

6.0 Data Management & Storage

This section groups requirements related to the storage and transformation of Common Criteria data within C5-DEC. It covers mapping CC data to the XML schema and validating against the corresponding DTD, bidirectional transformation between the internal representation and the CC-defined XML format, a threats/risks/countermeasures database integrating content from BSI Grundschutz, ISO 27005, NIST SPs, and the CC, the EUCC additional evaluation evidence support mechanism, storage of CSA Article 51 generic Security Objectives, and the unified open-format storage mechanism for all CC artefacts.

6.1 Data Storage and Format Mapping SRS-022

As a System, ensure that the CC data model is stored in a format that maintains a mapping to the available CC XML-file and can be validated against the corresponding DTD file while preserving semantic relationships between CC concepts.

When the CC XML source file is ingested the system parses each element and maps it to the internal Doorstop/YAML representation using a defined schema mapping table.
Every internal item retains a reference to the originating CC XML element identifier (e.g., f_cls, f_fam, f_comp) so that the mapping is bidirectional and auditable.
After ingestion the system validates the internal store by re-serializing a sample to XML and confirming it validates successfully against the CC DTD.
Semantic relationships (hierarchy, dependency, iteration) encoded in the XML are preserved as typed Doorstop links or dedicated YAML attributes.
Any mapping inconsistency or validation error is reported to the administrator with the offending element identifier and a description of the rule violated.

Rationale

Ensuring that the CC data model is stored and mapped accurately in a format that can be validated against the DTD file and maintains semantic relationships is critical for the integrity, reliability, and usability of the CC data. Accurate data storage and mapping are essential for ensuring that CC data retrieval, modification, and usage within the system are correct and reliable.

Dependencies

Related requirements

Acceptance criteria

The System is able to store the CC data model in a specific format.
The stored format maintains a mapping to the available CC XML-file.
The System can validate the stored data against the corresponding DTD file.
The System preserves semantic relationships between CC concepts during storage and retrieval.

Parent links: MRS-032 Provide CCT implementation, MRS-037 Adopt CC storage format

Child links: TCS-010 Inspect CC Database-DTD mapping, TCS-011 Test correctness of CC Database, TCS-012 Test validity and conistency of bidirectional transformation

Attribute	Value
status	In Progress
importance	4
urgency	1
risk	3
outlay	3
type	F
version	1.0

6.2 Bidirectional Transformation and Consistency SRS-023

As a Data Administrator/General User, I want the system to ensure the automatic transformation of content from and to the CC defined XML format, so that I can trust that the data remains consistent and coherent across all stored data and representations, ensuring that data retrievals, modifications, and other interactions with the data are reliable and accurate.

I navigate to the CC data management section of C5-DEC and select the import/export option.
I choose "Import from CC XML" and provide the path to a valid CC XML file.
C5-DEC parses the file, validates it against the corresponding DTD, and imports the data into the internal representation (YAML/Markdown Doorstop store).
I can confirm the import by browsing the CC component tree (see SRS-001) and verifying that components, families, and requirements are present.
I choose "Export to CC XML" for a selected set of components.
C5-DEC serializes the internal representation back to a well-formed CC XML file.
The exported XML file is schema-valid and can be validated against the CC DTD without errors.
Running the export on previously imported data produces an XML file semantically equivalent to the original input (round-trip consistency).

Rationale

The ability to perform bidirectional transformations between the internal data representation and the CC defined XML format is crucial to facilitate data exchanges and modifications while maintaining data integrity and consistency. Ensuring that the transformation processes are accurate and coherent safeguards the quality and reliability of the stored Common Criteria data, supporting its effective usage and application.

Dependencies

Related requirements

Acceptance criteria

The system can successfully transform content from CC defined XML format to an internal representation.
The system can transform content from the internal representation back to the CC defined XML format.
Consistency and coherence of the stored data and representations are maintained during transformations.
Data transformations adhere to the defined mappings and respect the structural and semantic integrity of the original CC XML format.

Parent links: MRS-032 Provide CCT implementation, MRS-038 Transform CC content

Child links: TCS-012 Test validity and conistency of bidirectional transformation

Attribute	Value
status	In Progress
importance	3
urgency	1
risk	3
outlay	4
type	F
version	1.0

6.3 Threats, Risks, and Countermeasures Database SRS-024

As a General User,I want the system to provide a database that encompasses generic threats, risks, and countermeasures, so that I can leverage a comprehensive and integrated source of security-related data that assimilates content from BSI Grundschutz, ISO 27005, NIST SPs, and the CC, ensuring diverse and standards-compliant support for dealing with security considerations in varied contexts.

I navigate to the Security Controls section of C5-DEC CAD.
The system presents a list of threat categories sourced from BSI Grundschutz, ISO 27005, NIST SP 800-30, and the Common Criteria.
I can filter threats by source category, and security domain.
I select a threat entry and view its full details including description, likelihood, impact rating, and associated countermeasures.
I can search for threats using keywords across name and description fields.
I can export selected threats and countermeasures to CSV or JSON format.
Each threat entry references its originating standard and publication.

Rationale

Maintaining a database that encompasses and integrates diverse and generic threats, risks, and countermeasures from different standardized sources (like BSI Grundschutz, ISO 27005, NIST SPs, and the CC) ensures that the system can provide a comprehensive and standards-compliant set of data for users or other system components dealing with security-related aspects. This centralized and integrated approach facilitates streamlined, consistent, and efficient handling and mitigation of security-related concerns.

Dependencies

Related requirements

Acceptance criteria

The System provides a database that includes generic threats, risks, and countermeasures.
The database can integrate content from BSI Grundschutz, ISO 27005, NIST SPs, and the CC.

Parent links: MRS-041 Threats and risks DB, MRS-042 Threat DB sources

Child links: TCS-013 Test threats, risks, and countermeasures database

Attribute	Value
status	Open
importance	4
urgency	2
risk	1
outlay	4
type	F
version	1.0

6.4 Support Mechanism for EUCC Additional Evaluation Evidence SRS-025

As a Security Evaluator, I want the system to implement a support mechanism that assists in generating additional evaluation evidence and provides guides for tailoring existing evaluation evidence, so that I can ensure that all produced evidence is conformant with EUCC requirements and navigate the EUCC evaluation process effectively and efficiently.

Note: This requirement is planned for a future release. The steps below describe the intended interaction model.

I navigate to the EUCC evaluation support section of C5-DEC CAD.
I select a target evaluation assurance level (EAL) and scheme (EUCC).
The system displays required additional evaluation evidence items specific to the selected assurance level under the EUCC scheme.
For each evidence item the system indicates whether existing project artifacts satisfy the requirement.
For unsatisfied items the system provides tailoring guidance describing what must be produced or adapted.
I can generate a gap analysis report listing unsatisfied evidence items.
The report is exportable in Markdown and PDF via the DocEngine.

Rationale

Implementing a support mechanism that assists in generating additional evaluation evidence and guides for tailoring existing evidence to conform with EUCC requirements ensures that the system adheres to relevant regulatory standards and efficiently navigates the EUCC evaluation process. This not only fosters compliance and mitigates regulatory risks but also enhances the robustness and credibility of the system by aligning it with established European cybersecurity standards and practices.

Dependencies

Related requirements

Acceptance criteria

The System implements a mechanism that assists in generating additional evaluation evidence as required by the EUCC.
The System provides guides that assist in tailoring existing evaluation evidence to be conformant with EUCC requirements.

Parent links: MRS-044 EUCC evaluation support

Child links: TCS-014 Test EUCC support

Attribute	Value
status	Open
importance	3
urgency	1
risk	1
outlay	4
type	F
version	1.0

6.5 Storing Generic Security Objectives of CSA Article 51 SRS-026

As a Security Analyst, I want the system to store and provide accessibility to the generic Security Objectives defined by Article 51 of the CSA, So that I can efficiently retrieve, analyze, and utilize these objectives for compliance, evaluation, and management processes in a manner that is interoperable with both human and automated (machine) activities and assessments.

Note: This requirement is planned for a future release. The steps below describe the intended interaction model.

I navigate to the CSA Security Objectives section of C5-DEC CAD.
The system presents the full list of generic Security Objectives defined by Article 51 of the EU Cybersecurity Act organized by category.
I can search and filter objectives by category or keyword.
I select a Security Objective and view its normative text, source reference, and mapping to related CC SFRs or SARs where applicable.
I can export the full list of CSA Article 51 objectives to CSV, JSON, or Markdown format.
The stored objectives conform to the C5-DEC open YAML/Markdown artifact format.

Rationale

Ensuring the storage and accessibility of generic Security Objectives as defined by Article 51 of the CSA in a structured, human, and machine-readable format enables efficient retrieval, analysis, and utilization of the objectives for various purposes such as compliance checks, threat modeling, or security analysis. This supports maintaining alignment with regulatory requirements and fosters a standardized approach towards handling and considering CSA-defined security objectives in cybersecurity evaluation and management processes.

Dependencies

Related requirements

Acceptance criteria

The System stores generic Security Objectives as defined by Article 51 of the CSA.
The stored Security Objectives are in a structured format.
The stored Security Objectives are accessible and readable by both humans and machines.

Parent links: MRS-045 Store CSA objectives

Child links: TCS-015 Test availabilty of CSA Article 51 defined Security Objectives

Attribute	Value
status	Open
importance	3
urgency	1
risk	1
outlay	3
type	F
version	1.0

6.6 Unified Storage Mechanism for CC Artifacts and Security Elements SRS-027

As a User, I want the CC toolbox within the C5-DEC software to enable consistent and structured storage of various CC artifacts and security elements, ensuring ease of data management and integrity.

When I choose to store SFRs/SARs, Security Functional Classes, Security Assurance Classes, Evaluation Activities, and Packages in the CC toolbox,
I want the storage process to utilize the same open file format used for all artifacts ensuring uniformity,
And store all elements in a structured, human and machine-readable format within the C5-DEC document-based data store, enabling efficient data retrieval and management.
Thus, I can consistently and efficiently manage, access, and utilize the stored data in varied formats without loss of integrity and structure.

Rationale

Implementing a unified and structured storage mechanism ensures that data related to SFRs/SARs and other CC elements is consistently stored and managed within the C5-DEC document-based data store, facilitating efficient data retrieval, management, and overall system reliability.

Dependencies

Related requirements

Acceptance criteria

User can store SFRs/SARs and all relevant CC artifacts and security elements in the CC toolbox.
All stored artifacts utilize the same open file format ensuring consistent data management.
Data for all elements (including Security Functional Classes, Security Assurance Classes, etc.) is stored in a structured, human and machine-readable format.
User can retrieve and manage the stored data efficiently without loss of integrity and structure.

Parent links: MRS-030 Store SFRs/SARs, MRS-036 Store CC classes

Child links: TCS-016 Test uniformity of storage mechanisms in CCT module

Attribute	Value
status	In Progress
importance	3
urgency	2
risk	3
outlay	4
type	F
version	1.0

7.0 Traceability & Consistency

This section groups requirements related to automated traceability and consistency management within C5-DEC SSDLC artefacts. It covers automated generation of rationale-annotated traceability matrices for all parent-child Doorstop link pairs, validation that generated rationales and matrices comprehensively cover all links in adherence with CC requirements, detailed automated consistency and completeness checks on CC data relationships and attributes, and automated validation of dependency rules across the Doorstop document tree.

7.1 Automated Rationale and Traceability Matrix Generation SRS-028

As a Developer, I want the system to automatically generate rationales as required by the CC, that captures and justifies each parent-child relation, so that documentation adheres to CC requirements and maintains a structured and justified linkage throughout the development and evaluation processes.

I invoke c5dec view <document_prefix> or call generate_rtm() via the SSDLC API for a Doorstop document tree.
C5-DEC traverses all items in the document and their upward links.
For each parent-child link pair the system checks whether a rationale field is populated in the child item.
The system generates a traceability matrix in CSV format mapping each child item UID to its parent UID(s), rationale text, and link status.
A summary report lists all parent-child pairs with and without rationales.
The traceability matrix is saved to docs/traceability/ and publishable via doorstop publish or c5dec publish <prefix>.

Rationale

To comply with the Common Criteria, ensuring that every parent-child link within the CC data model is justified and traceable is crucial. Automated generation of a traceability matrix and rationale compilation facilitates consistent documentation and adherence to these requirements.

Dependencies

Related requirements

Acceptance criteria

For each created parent-child relationship a rationale is defined.
A traceability matrix between all parent-child elements of a given level is automatically generated.
A list of justifications, justifying each parent-child link, is automatically compiled.

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-017 Test automated rationale and traceability matrix generation

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	1
outlay	3
type	F
version	1.0

7.2 Verification of Rationales and Traceability Matrices SRS-029

As an Evaluator, I want the system to validate that the generated rationales and traceability matrices comprehensively cover all parent-child elements and are in strict adherence with CC requirements, so that I can confidently validate and certify the coherence and completeness of the security documentation.

I invoke poetry run doorstop from the project root.
Doorstop traverses the full document tree and validates all upward links.
The output lists items with missing rationale fields, unreviewed or suspect links, and inactive items still referenced by child items.
I invoke c5dec validate <prefix> to run C5-DEC-specific consistency checks on a given Doorstop document.
The validation report is displayed in the terminal and optionally saved as a structured log file.
All warnings and errors can be addressed by running doorstop review for fingerprint updates or editing the relevant YAML/Markdown item files.

Rationale

For an Evaluator, ensuring that the provided rationales and traceability matrices comprehensively cover all elements and adhere to CC standards is paramount for validating the coherence and comprehensiveness of the security documentation.

Dependencies

Related requirements

Acceptance criteria

The system verifies that every parent-child relationship has an associated rationale.
A traceability matrix is provided that covers all parent-child elements of a given level.
An exhaustive list of justifications is available, ensuring full coverage of all parent-child links.

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-018 Test verificaiton of rationales and traceability matrices

Attribute	Value
status	Not Started
importance	4
urgency	3
risk	1
outlay	3
type	F
version	1.0

7.3 Detailed Consistency and Completeness Checks SRS-030

As an Administrator, I want the system to perform detailed automated consistency and completeness checks on CC data, specifically validating relationships, attributes, and dependencies, so that the integrity, quality, and reliability of the stored data are ensured and maintained in adherence with predefined standards.

I invoke c5dec validate <prefix> for a Doorstop document containing CC artifacts.
The system checks each item for required attributes present and non-empty, valid upward links, no circular dependencies, and unique level numbering.
The system performs cross-document consistency checks: - All SRS items link to at least one MRS item. - All SWD items link to at least one ARC item. - All TST items link to at least one SRS item.
A detailed report lists all violations by category with item UID and description.
The report exit code is non-zero if any ERROR-level violations are found, enabling integration with CI/CD pipelines.

Rationale

Employing automated checks that validate relationships, attributes, and dependencies and ensure completeness in CC data not only safeguards the data integrity and quality but also bolsters reliability and adherence to predefined standards.

Dependencies

Related requirements

Acceptance criteria

Automated consistency checks validate relationships, attributes, and dependencies within the CC data.
Automated completeness checks ensure all necessary data points are present and properly configured in the CC data.
All data adheres to predefined standards, maintaining its integrity and quality.

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-019 Test automated consistency and completeness checks

Attribute	Value
status	Open
importance	4
urgency	3
risk	1
outlay	3
type	F
version	1.0

7.4 Automated Validation of Relationships, Attributes, and Dependencies SRS-031

As a Developer, I want the system to automatically validate relationships, attributes, and dependencies between data points, and ensure the completeness of all necessary data entries within the CC data, so that development is guided by accurate, reliable, and complete data, thereby reducing the potential for errors and rework.

I invoke c5dec validate <prefix> on a CC-related Doorstop document.
The system validates that all normative items have a non-empty text field, a non-empty header field, and at least one upward links entry.
The system validates relationships by checking that all dependence UIDs reference existing active items and that CC SFR dependency rules from the CC XML database are respected in the checklist data model.
Incomplete or invalid items are listed in a detailed validation report.
The system optionally auto-fixes items with common issues such as missing active: true when invoked with a --fix flag.

Rationale

Ensuring the validity of relationships, attributes, and dependencies and the completeness of CC data entries ensures a robust and reliable data structure, which in turn streamlines development activities by reducing the potential for errors and unnecessary rework, thus ensuring compliance and efficiency in adhering to CC.

Dependencies

Related requirements

Acceptance criteria

The system identifies and alerts to any inconsistencies or incomplete data entries within the CC\n data.
Relationships, attributes, and dependencies between data points are automatically validated by the system.
A report log can be generated to provide insights into the validation checks and any issues identified.

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-020 Test automated validation

Attribute	Value
status	Open
importance	4
urgency	3
risk	1
outlay	3
type	F
version	1.0

7.5 Doorstop artifact publish and export pipeline SRS-057

As a Developer or Project Manager, I want C5-DEC to publish all Doorstop specification documents to open formats in a single command, so that the full traceability matrix and human-readable requirement documents are always available alongside the source artifacts.

I invoke c5dec publish [--prefix <doc>] [--output <dir>] [--format <fmt>].
When no --prefix is given, the system archives the current docs/specs folder (via transformer.publish()) and then publishes all Doorstop documents.
When --prefix is given, only that document is published (via transformer.publish_ssdlc_document()).
The default output format is Markdown; HTML is also supported.
Output files are written to the specified directory, creating it if it does not exist.
Import (c5dec import) and export (c5dec export) operations are also available for individual Doorstop documents in Markdown, CSV, or XLSX formats, via transformer.import_ssdlc_document() and transformer.export_ssdlc_document() respectively.

Rationale

Publishing the entire Doorstop tree with a single command ensures that the published artefacts are always consistent with the source items, and that open-format outputs (Markdown, HTML) are available for inclusion in release packages or static site generators.

Related requirements

SRS-TRZ (Traceability & Consistency)

Acceptance criteria

Running c5dec publish on a project with at least two Doorstop documents produces one published file per document without error.
Published Markdown files contain all active items from the source document.
Running c5dec export --label <doc> --output <path> produces a file in the requested format at the specified path.

Parent links: MRS-003 Open file format, MRS-010 Requirements traceability

Attribute	Value
status	In Progress
importance	3
urgency	2
risk	1
outlay	2
type	F
version	1.0

7.6 Code-level traceability, tag-based filtering, and modular architecture SRS-061

C5-DEC satisfies three cross-cutting quality requirements through the combination of Doorstop traceability links, custom item attributes, and its module-per-domain source code layout.

MRS UID	Requirement	Provided by
MRS-027	Link requirements/tests to source code via annotations	Doorstop TST → SRS links establish requirement-to-test traceability; Doorstop SWD items reference implementing modules by path or function name
MRS-029	Search/filter by labels or tags	Doorstop custom attributes (`type:`, `status:`, `urgency:`, etc.) serve as filterable tags; `doorstop publish` renders them in published HTML
MRS-058	Modular design	C5-DEC source tree follows one module per domain (`cct`, `cpssa`, `cra`, `ssdlc`, `pm`, `sbom`, `cryptography`, `transformer`) under `c5dec/core/`; each module exposes a stable public API with no circular imports

Rationale

Code-level traceability through Doorstop SWD items enables gap analysis between design specifications and implementation. Tag-based filtering is inherent to Doorstop's attribute model. The modular source layout enforces separation of concerns without requiring a custom plugin mechanism.

Acceptance criteria

A Doorstop SWD item exists for each significant C5-DEC module and references the corresponding source file path.
doorstop detects no unlinked TST items (all test cases trace to SRS).
import c5dec.core.<module> succeeds for each core module independently without importing any other C5-DEC core module.

Parent links: MRS-027 Link requirements to code, MRS-029 Filter by tags, MRS-058 Follow modular design

Attribute	Value
status	In Progress
importance	3
urgency	2
risk	1
outlay	2
type	C
version	1.0

8.0 Threat Management

This section groups requirements related to importing and managing threat information from external repositories within C5-DEC. It covers API-based importation of threats from MITRE ATT&CK and CVE/NVD sources, deduplication and normalization of imported threat entries, and automated transformation of imported threats into a CC-conformant format using configurable field-mapping templates.

8.1 API Provision for Threat Importation SRS-033

As a Security Analyst, I want the system to provide APIs for seamless importation of threats from external repositories like MITRE ATT&CK and CVE, so that I can efficiently integrate and utilize external threat data within C5-DEC.

Note: This requirement is planned for a future release. The steps below describe the intended interaction model.

I navigate to the Threat Importation section of C5-DEC CAD.
I configure the import source by selecting MITRE ATT\&CK, CVE/NVD, or a custom URL endpoint.
I initiate the import. C5-DEC calls the configured API and retrieves the threat data payload.
The system parses the response and normalizes entries into the C5-DEC internal threat schema.
Imported threats are stored in the threats database and shown in the Threats, Risks and Countermeasures view (SRS-024).
Duplicate entries are detected by ID and skipped or flagged for review.
An import summary reports the number of threats added, skipped, and failed.

Rationale

Integrating external threat data from reputable sources like MITRE ATT&CK and CVE enriches the C5-DEC database, providing a comprehensive threat landscape for better-informed security analysis and decision-making.

Dependencies

Related requirements

Acceptance criteria

APIs enable seamless importation of threats from MITRE ATT&CK and CVE.
Imported threats are accurately represented within C5-DEC.

Parent links: MRS-032 Provide CCT implementation, MRS-041 Threats and risks DB

Child links: TCS-022 Test API provision for threat import

Attribute	Value
status	Open
importance	3
urgency	2
risk	1
outlay	3
type	F
version	1.0

8.2 Transformation of Imported Threats to CC-conformant Format SRS-034

As a Developer, I want the system to provide transformation templates, guidelines, and custom mapping options for converting imported threats into a CC-conformant format, so that all threats, native or imported, ensure compliance with CC standards and integration within the C5-DEC encoded CC data model.

Note: This requirement is planned for a future release. The steps below describe the intended interaction model.

After importing threat data (see SRS-033), I navigate to the threat transformation view.
The system presents a mapping template that aligns MITRE ATT\&CK/CVE fields to the CC threat data model attributes (threat agent, assets, adverse actions, likelihood, countermeasures).
I review and optionally adjust the auto-generated field mappings.
I confirm the transformation. The system applies the mapping and converts raw imported threats into CC-conformant threat entries.
Transformed entries are validated against the CC threat schema and stored in the threats database.
A transformation report lists successful, partial, and failed conversions.

Rationale

Ensuring that all threats, whether internally defined or imported from external sources, adhere to CC standards and can be seamlessly integrated within the C5-DEC data model promotes consistency, traceability, and compliance throughout the security evaluation and assurance processes.

Dependencies

Related requirements

Acceptance criteria

The system provides templates, guidelines, and custom mapping options for transforming imported threats.
Transformed threats comply with CC standards and integrate with the C5-DEC CC data model.

Parent links: MRS-032 Provide CCT implementation, MRS-041 Threats and risks DB

Child links: TCS-023 Test transforming imported threats to CC-conformant format

Attribute	Value
status	Open
importance	3
urgency	2
risk	1
type	F
version	1.0

9.0 Evaluation Management

This section groups requirements related to managing the full lifecycle of a Common Criteria evaluation within C5-DEC. It covers seamless aggregation and display of SARs and associated work units, automated Evaluation Checklist creation from selected SAR sets or assurance packages, real-time evaluation progress tracking, work unit artefact linking for traceability, automated Observation Report (OR) generation from failed work units, automated Evaluation Technical Report (ETR) generation upon evaluation completion, cascading flags on failed and dependent work units, logging of evaluated work units for audit purposes, and export/archival of evaluation results.

9.1 Seamless Aggregation and Presentation of SARs and Work Units SRS-032

As an Evaluator, I want the system to seamlessly aggregate and present SARs and associated work units, aligning them with specific security assurance components, so that the process of evaluating the readiness and compliance of a Target of Evaluation (TOE) is simplified and streamlined.

I navigate to the CC Toolbox evaluation section and invoke the SAR browser.
I select a Security Assurance Class (e.g., ALC) to expand its families.
I select a Security Assurance Family (e.g., ALC_CMC) to view its components.
I select a specific SAR component (e.g., ALC_CMC.2). The system presents: - The SAR component description and hierarchical level. - All developer action elements (DAEs) and content and presentation elements (CPEs). - The complete list of Work Units with their detailed task descriptions.
I can expand individual Work Units to view the full evaluator action element text and any associated evaluation activities.
I can navigate back to the family or class level and select sibling components for comparison.
The aggregated SAR and Work Units view is exportable to CSV or Markdown.

Rationale

The efficient evaluation of the TOE readiness and compliance with relevant standards is vital for ensuring the security and reliability of the developed system. By automatically aggregating and presenting SARs and work units in alignment with respective security assurance components, evaluators can swiftly and accurately assess adherence to security assurance requirements, ensuring robust evaluation processes and confidence in the TOE.

Dependencies

Related requirements

Acceptance criteria

SARs and work units are accurately and seamlessly aggregated by the system.
The system displays SARs and work units in an organized manner, aligned with the respective security assurance components.
Evaluators can easily navigate and interpret the aggregated data to assess the readiness and compliance of the TOE.

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-021 Test aggregation of SARs and Work Units

Attribute	Value
dependence	['MRS-030']
status	In Progress
importance	4
urgency	3
risk	1
outlay	3
type	F
version	1.0

9.2 Automated Evaluation Checklist Creation SRS-035

As a Developer or Evaluator, I want to select a set of Security Assurance Components or Assurance Package and have the system automatically generate an Evaluation Checklist, so that I can efficiently assess the evaluation readiness of or evaluate a Target of Evaluation.

When I select a set of Security Assurance Components or a pre-defined Assurance Package (e.g. EAL 2) to assess the readiness of or to evaluate a Target of Evaluation.
Then I expect the system to automatically validate the selected set of components in terms of the consideration of hierarchical and dependency relationships.
When a valid set is selected I want the system to create an Evaluation Checklist based on the selected set.
Then I want to have the option to start the evaluation using the created Evaluation Checklist.

Rationale

Enabling automated creation of Evaluation Checklists ensures that the evaluators can efficiently initialize the evaluation process by quickly defining the scope and requirements of the evaluation, thereby ensuring compliance and readiness from the project inception.

Dependencies

Related requirements

Acceptance criteria

User can select and de-select security assurance components or assurance packages (augmentations also allowed)
Based on the (valid) selection, a checklist is generated that contains Evaluation Items that correspond to the respective Work Units.
Each Evaluation Item contains all relevant information for the Work Unit, i.e., Evaluator Action Element, Content or Developer Element, and the Work Unit task.
Furthermore, the User must be able to assign each Evaluation Item an Evaluator, an Evaluation Date, the Evaluation Evidence, and the Evaluation Verdict.
An index of required evaluation evidence documentation is created.

Parent links: MRS-032 Provide CCT implementation, MRS-043 Automate OR/ETR generation

Child links: TCS-024 Test automated creation of Evaluation Checklist

Attribute	Value
dependence	['SRS-034']
status	In Progress
importance	3
urgency	1
risk	1
outlay	3
type	F
version	1.0

9.3 Evaluation Progress Tracking SRS-036

As a User, I want the system to track and display the evaluation progress of the Evaluation, as well as the evaluation status of individual Evaluation Items, so that the ongoing status of the Evaluation is clear and easily accessible.

When I load an Evaluation Checklist I expect to see the overall evaluation progress, as well as the evaluation status (pass, fail, inconclusive) of each Evaluation Item.
When I select and edit an Evaluation Item I expect the Item's status as well as the overall evaluation progress to account for the changes in real time.

Rationale

Tracking the evaluation progress centrally and transparently supports project management by allowing all stakeholders to have a clear, real-time insight into the ongoing evaluation status, thereby enabling timely decision-making and issue mitigation.

Dependencies

Related requirements

Acceptance criteria

The overall evaluation progress is accurately and visually represented in the system, e.g., as a percentage of passed evaluation items.
The status of each Evaluation Item is accurately and visually represented, e.g., as [X],[O], or [ ] for failed, passed, or inconclusive, respectively.
Both the overall evaluation progress and the Item's status are updated in real time, i.e., evaluation progess and status are immediately updated when changes are made.
At all times the evaluation progress as well as any Evaluation Item's status can be extracted.

Parent links: MRS-032 Provide CCT implementation, MRS-043 Automate OR/ETR generation

Child links: TCS-025 Test evaluation progress tracking

Attribute	Value
dependence	[{'SRS-035': None}]
status	In Progress
importance	3
urgency	1
risk	1
outlay	3
type	F
version	1.0

9.4 Work Unit Artifact Linking SRS-037

As a User, I want to link work units within an Evaluation Checklist to applicable artifacts, so that there is clear traceability between work units and related project artifacts.

When I treat an Evaluation Item and hence the associated Work Unit and want to link relevant artifacts to the Evaluation Item/Work Unit.
Then I want to be able to differentiate between linking internal (items stored in the same open file format and managed by C5-DEC) and external artifacts.
When I want to link internal artifacts I can do so by providing the artifact's item UID.
Then I expect the system to acknowledge linking the artifact to the Evaluation Item or inform me (visually) if the UID is invalid.
When I want to link internal artifacts I want to be able to define queries to search for the artifact. (OPTIONAL) 6 Then I expect the system to provide potentially matching items with a preview of the item's content. (OPTIONAL) 7 When I select a match I want the system to link the Evaluation Item to the selected item. (OPTIONAL)
When I want to link external artifacts I can do so by providing the path to the external resource.
When I select an Evaluation Item's link
Then I want to be able to modify, remove, or open/preview the linked Item.

Rationale

Ensuring traceability between work units and related artifacts reinforces the transparency and verifiability of the evaluation process, thereby strengthening the credibility and compliance of the evaluation outcome.

Dependencies

Related requirements

Acceptance criteria

Users can create, modify, and remove links between work units and applicable artifacts.
Links are visibly represented and can be navigated within the system.
Links are differentiated between internal and external links.

Parent links: MRS-032 Provide CCT implementation, MRS-043 Automate OR/ETR generation

Child links: TCS-026 Test Work Unit-Artifact linking

Attribute	Value
dependence	['SRS-035']
status	Open
importance	4
urgency	3
risk	1
outlay	3
type	F
version	1.0

9.5 Automated OR Generation SRS-038

As a User, I want the system to generate Observation Reports (ORs), so that issues encountered during the evaluation are summarized and communicated effectively.

I navigate to the Evaluation section and select a completed or in-progress evaluation checklist.
I invoke the Observation Report generation action (CLI: c5dec etr --or or through the GUI evaluation panel).
The system collects all work units marked as failed or incomplete.
For each failed work unit the OR includes: work unit ID, description, evaluator notes, failure reason, and linked artifacts.
The system compiles these into a structured Observation Report document following the EUCC OR template.
The OR is saved as a Markdown document in the project output directory and optionally rendered to PDF via the DocEngine.
The OR creation date, evaluator identity, and TOE reference are included in the document header.

Rationale

Automated generation of Observation Reports (ORs) ensures that any discrepancies, issues, or failures during the evaluation are systematically documented and communicated, which is vital for transparency and subsequent remediation activities.

Dependencies

Related requirements

Acceptance criteria

The system gathers and compiles information related to failed work units.
An OR is generated, summarizing issues encountered during the evaluation.

Parent links: MRS-032 Provide CCT implementation, MRS-043 Automate OR/ETR generation

Child links: TCS-027 Test automated generation of Observation Reports

Attribute	Value
dependence	['SRS-037', 'SRS-036', 'SRS-035']
status	Open
importance	3
urgency	2
risk	1
outlay	3
type	F
version	1.0

9.6 Automated ETR Generation SRS-039

As a User, I want the system to generate the Evaluation Technical Report (ETR) upon completion of the evaluation, so that all verdicts and evaluation results are summarized and the overall verdict is derived according to predefined rules.

Upon completing all Evaluation Checklist items I invoke c5dec etr --generate or select "Generate ETR" in the GUI evaluation panel.
The system verifies that there are no items in an incomplete state; if any remain incomplete a warning is shown and generation can be forced with --force.
C5-DEC collects all Evaluation Item records including status, evaluator identity, evaluation date, evidence references, and verdict for each work unit.
The system applies the CC verdict derivation rules: - If all work unit verdicts are PASS the overall verdict is PASS. - Any FAIL work unit verdict propagates to the SAR component verdict. - Any failed SAR component verdict propagates to the overall verdict as FAIL.
C5-DEC populates the ETR template (see SRS-043) with the collected data, including the TOE reference, evaluation scheme (e.g., EUCC), EAL, and the derived overall verdict.
The ETR is saved as a structured Markdown document in the project output directory and optionally compiled to PDF via the DocEngine.
A summary section in the ETR lists all Observation Reports (see SRS-038) generated during the evaluation.

Rationale

Streamlining the creation of the Evaluation Technical Report (ETR) by automating the compilation and derivation of overall verdicts ensures a swift, consistent, and objective consolidation of evaluation outcomes, which is crucial for substantiating evaluation claims and finalizing the evaluation process.

Dependencies

Related requirements

Acceptance criteria

All Evaluation Item verdicts and supporting evidence references are included in the ETR.
The overall verdict is derived according to CC verdict aggregation rules (FAIL propagates upward).
The ETR document identifies the TOE, evaluation scheme, assurance package, and evaluation date.
All Observation Reports generated during the evaluation are referenced as annexes.
The ETR is exportable to PDF via the DocEngine without compilation errors.
A non-zero exit code is produced if the overall verdict is FAIL, enabling CI/CD integration.

Parent links: MRS-032 Provide CCT implementation, MRS-043 Automate OR/ETR generation

Child links: TCS-028 Test automated generation of Evaluation Technical Report

Attribute	Value
dependence	['SRS-035', 'SRS-036', 'SRS-037', 'SRS-038']
status	Open
importance	3
urgency	2
risk	1
outlay	3
type	F
version	1.0

9.7 Flagging and Addressing Failed Work Units with Cascading Flags SRS-040

As a User, I want failed work units to be visibly flagged and to inhibit progression until resolved. Additionally, I want all items linked to a flagged work unit to also be flagged, so that all issues and potential dependent problems are duly addressed, ensuring a reliable, thorough, and systematic evaluation and development process.

An evaluator marks a work unit as failed in the evaluation checklist.
The system visually flags the work unit with a "FAILED" status indicator in the checklist view.
Any work units that depend on (are linked to) the failed work unit are automatically inspected, and a cascade flag is applied to all dependent items that cannot be passed while the dependency is unresolved.
The overall evaluation status changes to "Blocked" if any critical work units are flagged.
The evaluator is shown a dependency impact view listing all cascaded items.
Progression (marking dependent items as passed) is prevented until the root failed work unit is resolved or explicitly overridden with a documented justification.
When the root failure is resolved the cascade flags are automatically cleared and items become eligible for evaluation again.

Rationale

Explicitly flagging failed work units and inhibiting progression until they are addressed ensures that issues are rectified promptly. Cascading these flags to linked items ensures a rigorous and thorough evaluation and validation process, maintaining the integrity and reliability of the evaluation and development process and ensuring that dependent elements are not overlooked.

Dependencies

Related requirements

Acceptance criteria

Failed work units are visibly flagged.
Items linked to the flagged work units are also flagged.
Progress cannot continue until flagged items are addressed.

Parent links: MRS-032 Provide CCT implementation, MRS-043 Automate OR/ETR generation

Child links: TCS-029 Test flagging failed Work Units and affected artifacts

Attribute	Value
dependence	['SRS-037', 'SRS-036']
status	Open
importance	3
urgency	2
risk	1
outlay	3
type	F
version	1.0

9.8 Logging evaluated Work Units SRS-041

As a User, I want evaluated work units to be logged and stored, so that a clear record of successful evaluations is maintained for future reference and auditing.

An evaluator records a verdict (PASS, FAIL, or INCONCLUSIVE) on an Evaluation Item in the checklist.
On verdict submission the system creates or updates a log entry for that work unit, capturing: work unit ID, evaluator identity, verdict, evaluation date, evidence references, and any attached evaluator notes.
Log entries are stored as structured Doorstop items in the project document store, using the same open YAML/Markdown format as all other artefacts.
The evaluation log is queryable; a user can list all PASS/FAIL entries, filter by evaluator or date range, and export the log to CSV or JSON.
Log entries are immutable once written; corrections require a new superseding entry with a reference to the original, preserving the audit trail.
The complete log is included as an annex when generating the ETR (see SRS-039).

Rationale

Systematically logging and archiving evaluated work units provides a clear record, which can be vital for future reviews, audits, and project insights, thereby supporting transparency and historical tracking of project evolution. Immutable log entries with evaluator attribution reinforce the non-repudiation and auditability requirements of the CC evaluation scheme.

Dependencies

Related requirements

Acceptance criteria

Every verdict recorded on an Evaluation Item produces a corresponding log entry.
Log entries are persisted as Doorstop items and survive a system restart without data loss.
Users can review, filter, and export the full evaluation log.
Log entries are append-only; no existing entry can be silently overwritten.
The evaluation log is included in the generated ETR as an annex.

Parent links: MRS-032 Provide CCT implementation, MRS-043 Automate OR/ETR generation

Child links: TCS-030 Test auditability of Evaluation Items

Attribute	Value
dependence	['SRS-036']
status	In Progress
importance	3
urgency	2
risk	1
outlay	3
type	F
version	1.0

10 CC Data Model & Documents

This section groups requirements related to extending the C5-DEC data model to cover the full CC ecosystem and providing standardized CC document templates. It covers incremental extension of the data model to represent Protection Profiles (PPs) and Security Targets (STs) as first-class Doorstop entities with typed cross-references, and provision of pre-configured Quarto/Markdown templates for CC document types including ST, PP, ETR, Observation Report, and Site Certificate.

10.1 Extend Data Model Across Entire CC Ecosystem SRS-042

As a User, I want the data model to accurately encompass and interrelate all entities and documents within the CC ecosystem, so that I can efficiently navigate, manage, and derive insights from comprehensive, interconnected CC data, ensuring that the manipulation, association, and interpretation of all CC-relevant entities are coherent and traceable.

Note: This is a long-term architectural requirement. The steps below describe the intended incremental implementation approach.

The C5-DEC data model currently covers SFRs, SARs, evaluation activities, work units, and checklists (implemented in CCT).
In subsequent releases the model is extended to cover Protection Profile (PP) and Security Target (ST) documents as first-class entities.
ST components (TOE description, conformance claims, security objectives, threats, assumptions, OSPs) are represented as Doorstop items with typed relationships to SFRs and SARs.
PP documents are represented as parameterized ST templates with mandatory and optional SFR/SAR slots.
All CC document entities are navigable via the CC browser and editable through the existing GUI and CLI interfaces.
Cross-entity traceability (e.g., threat → security objective → SFR) is maintained through Doorstop upward links and queryable via generate_rtm.

Rationale

Extending the data model across the entire CC ecosystem ensures consistent and comprehensive management and manipulation of all CC entities and documents. It enables thorough adherence to CC standards and ensures all CC-relevant data can be accurately represented, related, and manipulated within the system.

Dependencies

Related requirements

Acceptance criteria

The data model encompasses all entities and documents within the CC ecosystem.
Each entity in the CC ecosystem can be represented, related, and manipulated within the system.

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-031 Test extended data model

Attribute	Value
status	Open
importance	3
urgency	1
risk	1
outlay	3
type	N
version	1.0

10.2 Provide CC Document Templates SRS-043

As a User, I want access to predefined templates for each type of CC document, so that I can efficiently create standardized, CC-compliant documents and optionally export them to supported formats.

I invoke c5dec docengine report -n <name> or access the Document Templates section in the GUI.
I select the CC document type: Security Target (ST), Protection Profile (PP), ETR, Observation Report, or Site Certificate.
The system instantiates a pre-configured Quarto/Markdown template for the selected document type, populated with placeholder sections aligned to the CC document structure requirements.
The template is saved to the project output directory.
I edit the template, filling in project-specific content.
I compile the document using quarto render or the DocEngine compilation command.
The output PDF or HTML document conforms to CC content and formatting requirements for the selected document type.

Rationale

Providing predefined templates for each type of CC document simplifies and standardizes the document creation process. It ensures that users can efficiently create documents adhering to CC content and formatting standards without requiring detailed manual input, thus enhancing consistency and reducing the potential for error across CC documentation.

Dependencies

Related requirements

Acceptance criteria

Templates for each type of CC document are available and adhere to CC standards.
Users can select, utilize, and export templates to supported formats (e.g., .docx, .tex, .xml).

Parent links: MRS-032 Provide CCT implementation

Child links: TCS-032 Test CC templates

Attribute	Value
dependence	['SRS-042']
status	Open
importance	3
urgency	2
risk	1
type	F
version	1.0

11 CPSSA Threat Modelling & Risk Analysis

This section groups requirements related to the C5-DEC Cyber-Physical System Security Assessment (CPSSA) subsystem. It covers automated threat model generation from Doorstop architecture artifacts (create_threat_model), Data Flow Diagram derivation (generate_dfd), CPSSA report generation from Threagile YAML (generate_cpssa_report), FAIR calibration input template generation (generate_fair_input_template), and Monte Carlo quantitative risk analysis using pyfair (run_quantitative_risk_analysis).

11.1 Create threat model from Doorstop architecture artifacts SRS-046

As a Security Analyst, I want C5-DEC to automatically generate a threat model from the project's Doorstop architecture artifacts, so that I can produce a structured threat model without manually authoring it from scratch.

I invoke c5dec cpssa threat-model --project <path> --format <fmt>, where <fmt> is one of threagile (default), pytm-python, or pytm-json.
The system locates the Doorstop specs root by searching docs/specs/ and adjacent paths for .doorstop.yml files.
Architecture items are read from the first arc, harc, or larc folder (case-insensitive) found under the specs root. If --arc-folder is provided, that path is used directly.
Up to 40 architecture items are processed; a warning is emitted if the project contains more.
For the threagile format, the system writes threat-model.yml to the output directory, containing:
- Project metadata (title, date, author).
- technical_assets mapped from architecture items.
- trust_boundaries derived from the zone attribute of items.
- communication_links derived from Doorstop links between architecture items.
- abuse_cases stubbed for each identified data flow.
For pytm-python, the system writes an executable threat-model-pytm.py script.
For pytm-json, the system writes threat-model-pytm.json.
The function returns the absolute path to the written file.

Rationale

Generating the threat model directly from Doorstop architecture items eliminates a manual translation step, keeps the threat model synchronized with the architectural design artifacts, and produces output in standard formats (Threagile, pytm) that integrate with downstream tooling.

Related requirements

SRS-047 (Architecture item format for threat model input)
SRS-048 (CPSSA report generation)
SRS-049 (DFD generation)

Acceptance criteria

Running the command on a project with ARC items produces a well-formed output file in the requested format.
The command exits with a non-zero code and a descriptive error if the project path does not exist or the format is invalid.
All three formats (threagile, pytm-python, pytm-json) produce syntactically valid output.

Parent links: MRS-031 Threat modelling solution, MRS-033 Threat modelling tool

Child links: TCS-087 TC: Test CPSSA threat model generation — Threagile format, TCS-088 TC: Test CPSSA threat model generation — pytm formats

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	2
outlay	3
type	F
version	2.0

11.2 Doorstop architecture item format for threat model input SRS-047

As a Security Analyst, I want the CPSSA module to define the required structure of Doorstop architecture items, so that projects providing compliant items are guaranteed to yield a valid threat model and DFD without manual post-processing.

The following attributes are recognised in ARC, HARC, and LARC Doorstop items when consumed by the CPSSA threat-model and DFD generation functions:

Required fields:

Each item must be a valid YAML file with active: true and a links: list (which may be empty). Items with active: false are silently skipped.
A unique UID must be derivable from the filename stem (e.g., ARC-001.yml → ARC-001).

Optional classification fields:

type — component type string. Values in ("datastore", "database", "historian", "repo") are classified as datastore; values in ("actor", "user", "operator", "external", "firewall", "gateway", "router", "switch", "rtu") are classified as external entity; all other values (including absent) default to process.
zone — network or security zone name (string). Items sharing the same zone value are grouped into the same trust boundary in Threagile output and PlantUML DFD.
header — short human-readable label used as the element title in the threat model and DFD (falls back to the first 60 characters of text if absent).

Communication links:

The Doorstop links: list on an architecture item is interpreted as directed communication links from the child item to each parent UID listed. These become communication_links in Threagile YAML and directed arrows in the PlantUML DFD.
The protocol attribute, if present on an item, is used as the link protocol label in both output formats.

Fallback behaviour:

Items with no type, no zone, or no header produce valid output using default values (process, empty zone, and UID-derived label respectively). No item is silently dropped due to missing optional fields.

Rationale

Explicit documentation of the expected artifact format prevents silent model-quality degradation caused by incomplete Doorstop items and establishes a contract between the SSDLC artifact producers and the CPSSA consumer functions.

Related requirements

SRS-046 (Threat model generation)
SRS-049 (DFD generation)

Acceptance criteria

Projects satisfying all structural requirements produce no parsing errors when passed to create_threat_model or generate_dfd.
Items with active: false are never reflected in the output artefacts.
A type: datastore item produces a database node in the PlantUML DFD.
Two items with the same zone value are enclosed in the same trust-boundary rectangle in both Threagile YAML and PlantUML output.
An item with no type field is classified as process without error.

Parent links: MRS-031 Threat modelling solution, MRS-033 Threat modelling tool

Child links: TCS-087 TC: Test CPSSA threat model generation — Threagile format

Attribute	Value
status	Stable
importance	5
urgency	3
risk	3
outlay	2
type	C
version	2.0

11.3 Generate CPSSA Markdown report from threat model SRS-048

As a Security Analyst, I want C5-DEC to generate a structured CPSSA Markdown report from a Threagile-compatible threat model YAML, so that I have a human-readable security assessment document without manually writing it.

I invoke c5dec cpssa report --model <threat-model.yml> [--output <path>].
The system reads the Threagile YAML file and extracts: title, date, author, management_summary_comment, business_overview, technical_overview, technical_assets, data_assets, security_requirements, abuse_cases, trust_boundaries, threat_actors, and assumptions.
The system produces a Markdown file containing the following sections:
- Executive summary — management summary comment.
- System description — business overview and technical overview.
- Assets — tables of technical assets and data assets.
- Security requirements — requirements extracted from the model.
- Abuse cases — list of identified abuse cases.
- Trust boundaries — trust boundary descriptions and member components.
- Threat actors — threat actor profiles.
- Assumptions — listed project assumptions.
If --output is omitted, the report is written as cpssa-report.md in the same directory as the threat model.
The function returns the absolute path to the written Markdown file.

Rationale

Automatic report generation from the threat model eliminates transcription effort and ensures that the CPSSA narrative stays in sync with the structured model data. Using Markdown as the output format makes the report publishable via the DocEngine workflow.

Related requirements

SRS-046 (Threat model generation)

Acceptance criteria

Invoking the command on a valid Threagile YAML produces a well-formed Markdown report containing all eight named sections.
Sections whose corresponding threat model fields are absent render with a placeholder note rather than causing an error.
The command exits with an error if the threat model file is not found or cannot be parsed as valid YAML.

Parent links: MRS-031 Threat modelling solution, MRS-035 Risk management tool

Child links: TCS-089 TC: Test CPSSA Markdown report generation

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	2
outlay	2
type	F
version	2.0

11.4 Generate PlantUML Data Flow Diagram from architecture items SRS-049

As a Security Analyst or Architect, I want C5-DEC to derive a PlantUML Data Flow Diagram (DFD) from Doorstop architecture items, so that I obtain a visual representation of system components and data flows without manually authoring a diagram.

I invoke c5dec cpssa dfd --project <path> [--output <file>] [--arc-folder <dir>].
The system discovers architecture items using the same auto-discovery logic as create_threat_model (see SRS-046): it searches the Doorstop specs root for the first arc, harc, or larc folder; --arc-folder overrides auto-discovery.
Up to 40 architecture items are processed; a warning is logged for projects with more.
Each item becomes a PlantUML element classified by its type attribute:
- process (default) → component
- external entity types (actor, user, external, firewall, etc.) → actor
- datastore types (datastore, database, historian, repo) → database; Type classification follows the same rules as create_threat_model (see SRS-047).
Items with the same non-empty zone attribute are enclosed in a shared PlantUML rectangle group labelled with the zone name.
Each Doorstop links: entry between two architecture items becomes a directed arrow labelled flow-N [protocol], where N is an incrementing counter and protocol is taken from the item's protocol attribute when present.
Element IDs in the PlantUML output use the same Threagile-safe ID format as create_threat_model (lowercase, hyphens, max 31 chars), making both artefacts cross-referenceable.
The output is written as cpssa-dfd.puml in the project root by default, or to --output if specified.
The function returns the absolute path to the written .puml file.

Rationale

Deriving the DFD automatically from the same Doorstop ARC items used for the threat model ensures both artefacts remain consistent, uses element IDs and trust-boundary groupings that are cross-referenceable with the Threagile output, and eliminates the effort of maintaining a separate diagram source.

Related requirements

SRS-046 (Threat model generation)
SRS-047 (Architecture item format)

Acceptance criteria

Running the command on a project with ARC items produces a syntactically valid PlantUML file renderable without errors.
Zone-based trust-boundary groupings appear as rectangle blocks enclosing all items that share the same zone value.
Data flow arrows between linked items are present and labelled flow-N.
Element IDs in the DFD match the corresponding technical_assets keys in the Threagile output produced by create_threat_model for the same project.

Parent links: MRS-001 Diagram generation tool, MRS-034 Export design assets

Child links: TCS-090 TC: Test PlantUML DFD generation from ARC items

Attribute	Value
status	In Progress
importance	5
urgency	3
risk	2
outlay	2
type	F
version	2.0

11.5 Generate FAIR risk analysis input template SRS-050

As a Security Analyst, I want C5-DEC to generate a pre-populated FAIR parameter template YAML from a threat model, so that I have a ready-to-edit calibration file for the quantitative risk analysis step.

I invoke c5dec cpssa fair-input --model <threat-model> [--output <path>], where <threat-model> is a Threagile YAML or pytm JSON threat model file.
The system reads the abuse_cases section of the threat model. For pytm JSON files that contain no explicit abuse_cases, it synthesises one scenario entry per element found in the elements list.
If no abuse cases can be found or synthesised, the command exits with an error.
The system writes fair-params.yml (or the --output destination) containing one entry per abuse case with PERT distribution placeholders at the simplest decomposition level (lef + lm). Advanced decomposition nodes (tef, vulnerability, contact, action, pl, sl, slef, slem, tc, cs) are included as YAML comments so the analyst can uncomment the level that matches their available data.
A header comment block in the file explains the full FAIR model tree and calibration instructions.
The function returns the absolute path to the written YAML template file.

Rationale

A template with all FAIR parameters pre-scaffolded per abuse case removes the analyst's need to remember the pyfair API, reduces calibration errors, and exposes advanced decomposition options without forcing them on users who only have top-level estimates.

Related requirements

SRS-046 (Threat model generation)
SRS-051 (Run FAIR quantitative risk analysis)

Acceptance criteria

Invoking on a valid Threagile YAML or pytm JSON produces a well-formed YAML file with one entry per abuse case.
PERT placeholders are present for lef and lm on each entry.
The command exits with an error if the threat model is absent or contains no abuse cases and cannot synthesise any.

Parent links: MRS-035 Risk management tool, MRS-054 Include SRA model

Child links: TCS-091 TC: Test FAIR risk input template and quantitative risk analysis

Attribute	Value
status	In Progress
importance	5
urgency	3
risk	2
outlay	2
type	F
version	2.0

11.6 Run FAIR-based quantitative risk analysis SRS-051

As a Security Analyst, I want C5-DEC to execute a FAIR-based Monte Carlo quantitative risk analysis over all abuse cases in a threat model, so that each scenario receives a statistically robust Annualised Loss Expectancy (ALE) estimate expressed in monetary terms.

I invoke c5dec cpssa risk --model <threat-model> [--output <dir>] [--simulations <N>] [--fair-params <yaml>], where <threat-model> is a Threagile YAML or pytm JSON file.
The system requires pyfair to be installed; it exits with a descriptive error if it is not available.
FAIR calibration parameters are loaded in order of precedence: a. A dedicated --fair-params YAML file mapping scenario names to PERT bounds (generated by generate_fair_input_template, see SRS-050). b. Inline dicts in the threat model's abuse_cases entries. c. Conservative default placeholders, with a per-scenario warning emitted.
For each abuse case a FairModel is created supporting PERT distributions at any decomposition level of the FAIR tree: - LEF side: lef directly, or tef + vulnerability, or contact + action and/or tc + cs. - LM side: lm directly, or pl + sl, or pl + slef + slem.
A FairMetaModel aggregating all per-scenario models is calculated over N simulations (default: 10 000).
Per-scenario results (mean ALE, 5th/95th percentile ALE, maximum) are exported to a CSV file alongside the threat model.
A Markdown summary table listing each abuse case, mean ALE, 95th-percentile ALE, and maximum ALE is written as fair-risk-summary.md.
The function returns the absolute path to the Markdown summary file.

Rationale

pyfair implements the FAIR (Factor Analysis of Information Risk) standard, which provides a well-defined monetary risk quantification model. Monte Carlo simulation over PERT-distributed inputs produces robust ALE estimates with explicit uncertainty intervals, which are more actionable than point estimates.

Related requirements

SRS-050 (FAIR input template generation)
SRS-052 (Risk output artifacts)

Acceptance criteria

The command produces both a CSV results file and a Markdown summary for every abuse case without error.
Running with --simulations 1000 completes in under 60 seconds on a standard development machine.
The command exits with a descriptive error when pyfair is not installed.
Scenarios using default calibration parameters each produce a warning in the log.

Parent links: MRS-035 Risk management tool, MRS-054 Include SRA model

Child links: TCS-091 TC: Test FAIR risk input template and quantitative risk analysis

Attribute	Value
status	In Progress
importance	5
urgency	3
risk	1
outlay	3
type	F
version	2.0

11.7 Risk analysis output artifacts: CSV results and Markdown summary SRS-052

As a Security Analyst, I want C5-DEC to produce machine-readable and human-readable output artefacts from the FAIR quantitative risk analysis, so that results can be integrated into project reporting pipelines and reviewed by non-technical stakeholders.

CSV results file:

A CSV file is written containing one row per abuse-case scenario with the columns: scenario, mean_ale, p5_ale, p95_ale, max_ale (all monetary values).
The CSV file is placed in the directory specified by --output, or in the same directory as the threat model when no output path is given.

Markdown summary file:

A Markdown file (fair-risk-summary.md) is written containing: - A heading identifying the threat model source and analysis date. - A summary table of all scenarios ranked by mean ALE descending. - A note listing any scenarios that used default FAIR calibration values.
The Markdown file is placed alongside the CSV file.

Reproducibility:

Both output files record the number of Monte Carlo simulations (N) used and the threat model filename so that results are traceable to their inputs.

Rationale

CSV output enables programmatic downstream processing (CI/CD risk gates, dashboard integration). The Markdown summary provides a reviewable narrative artefact compatible with the DocEngine publishing workflow. Recording simulation count and source filename ensures results can be reproduced or challenged during security reviews.

Related requirements

SRS-051 (Run FAIR quantitative risk analysis)

Acceptance criteria

Both a CSV file and a Markdown file are present in the output directory after a successful c5dec cpssa risk run.
The CSV is parseable by pandas and Excel without error.
The Markdown renders correctly without broken tables or syntax errors.
Both files contain the simulation count N and the threat model filename.

Parent links: MRS-035 Risk management tool, MRS-054 Include SRA model

Child links: TCS-091 TC: Test FAIR risk input template and quantitative risk analysis

Attribute	Value
status	In Progress
importance	4
urgency	3
risk	1
outlay	3
type	F
version	2.0

11.8 Generate interactive HTML graph for Doorstop specifications navigation SRS-053

As a Security Engineer or Architect, I want a utility that reads the Doorstop specifications tree and produces a single self-contained interactive HTML graph, so that I can navigate all requirement and architecture items, explore their traceability links by expanding nodes, and immediately identify items that lack upward coverage.

Input and scope:

The utility accepts a root path (default: docs/specs/) and discovers all Doorstop document directories within it by locating .doorstop.yml configuration files.
All active items (active: true) from every document prefix (MRS, SRS, ARC, SWD, TST, TRA, TRB, TRS, TSS, and any others present) are loaded.
Inactive items (active: false) are silently skipped and excluded from the graph.

Graph model:

Each Doorstop item becomes a node identified by its UID (e.g., SRS-049).
Each entry in an item's links: field defines a directed edge from the child item to its parent item (upward traceability), consistent with Doorstop's upward-only link convention.
The full edge set is also stored in reverse (parent → children) to support the expand-children interaction without re-parsing items at runtime.

Node labeling:

The utility extracts the first Markdown level-1 heading (# ...) from each item's body as the node display label. If no H1 heading is found, the UID is used as the fallback label.
The full label text is shown beneath the node circle in the rendered graph. Long labels are truncated to 60 characters in the default view, with the full text available in the hover tooltip.

Color coding:

A node is rendered green if its links: field contains at least one entry (the item traces upward to at least one parent item).
A node is rendered yellow if its links: field is empty (the item has no upward traceability and is therefore uncovered).
A color legend is included in the HTML output, explaining the green/yellow convention.

Interactivity:

The graph is rendered using Cytoscape.js with the dagre layout extension, producing a hierarchical top-down layout that reflects the natural document hierarchy (MRS at the top, then SRS/ARC, then SWD/TST, and so on).
The initial view renders only the top-level MRS root nodes and their direct children. All deeper nodes are hidden at startup to avoid visual clutter on large repositories.
Clicking a collapsed node expands its direct children (items that link upward to it), adding them to the visible graph and re-running the layout.
Clicking an already-expanded node collapses its subtree, removing all descendant nodes from the visible graph.
Hovering over any node shows a tooltip containing the full UID, the document prefix, and the complete untruncated H1 label.

Output:

The utility writes a single self-contained HTML file named specs-graph.html to the output directory specified by the caller (default: current working directory).
All JavaScript (Cytoscape.js core and the dagre layout plugin) and CSS are inlined into the HTML file. The output must function correctly in a browser with no internet connection and without a local HTTP server.
The graph data (nodes and edges as JSON) is embedded directly in the HTML as an inline <script> block, populated at generation time.

Rationale

A static self-contained HTML file is fully portable: it can be shared as an email attachment, committed to the repository alongside the Doorstop items, or published via the DocEngine workflow (SRS-DOC) without requiring a server or additional dependencies. Cytoscape.js with the dagre hierarchical layout is the best fit for a directed acyclic graph with depth ranging from 2 to 5 levels; it provides the layout algorithm quality and event API needed for expand/collapse interactivity without the complexity of D3.js. Color-coded upward coverage converts the traceability matrix into an immediately actionable visual gap analysis: a yellow node flags a concrete deliverable (a missing doorstop link invocation) rather than a numerical metric. This complements the machine-readable traceability CSV (docs/traceability/traceability.csv) produced by doorstop publish (SRS-TRZ) by providing a human-navigable counterpart.

Dependencies

Related requirements

SRS-TRZ (Traceability & Consistency)
SRS-DOC (CC Data Model & Documents)

Acceptance criteria

Running the utility on docs/specs/ produces specs-graph.html without errors or unhandled exceptions.
Every active Doorstop item across all discovered document prefixes appears as exactly one node in the output HTML.
Each node's display label matches the H1 heading text from that item's Markdown body, or falls back to the UID when no H1 is present.
All nodes whose links: field is empty are assigned the yellow color class; all nodes with at least one link entry are assigned the green color class.
Clicking a node in the rendered graph expands its direct children (items referencing it via their links: field); clicking it again collapses the subtree.
The output file opens and renders correctly in a modern browser (Chrome, Firefox) with no internet connection.
The output file contains no external <script src="..."> or <link href="..."> tags pointing to remote URLs (all assets are inlined).
A unit test in tests/ runs the utility against a minimal fixture Doorstop tree (at least one covered and one uncovered item across two document levels) and asserts the correct node count, edge count, and color assignments in the emitted HTML.

Parent links: MRS-001 Diagram generation tool, MRS-034 Export design assets

Attribute	Value
status	Open
importance	3
urgency	2
risk	2
outlay	2
type	F
version	1.0