1 TOR MRSs MRS-TOR

Mission-level requirements for TOR (Transition via Observable Registry), an automated cryptographic inventory and analysis system that assesses organizational readiness for PQC migration.

1.1 Inventory cryptography across code and network surfaces MRS-001

VECTOR SHALL provide a single technical baseline for identifying cryptographic mechanisms used in software source code and in externally exposed network services.

Rationale

PQC migration planning depends on knowing where cryptography appears across both development-time and runtime-facing assets.

Acceptance criteria

  • The specification tree includes linked child requirements for source-code and network analysis.
  • Verification artifacts can trace both analysis paths back to this mission requirement.

Child links: ARC-003 Unified inventory coverage boundary, SRS-004 Run cryptographic inventory queries on created databases

Attribute Value
type F
importance 5
urgency 5
vm T
release Alpha

1.2 Recognize post-quantum and hybrid algorithms MRS-002

VECTOR SHALL identify both classical cryptographic mechanisms and post-quantum or hybrid mechanisms present in supported source-code and network-analysis outputs.

Rationale

Migration planning must distinguish legacy algorithms from transitional and quantum-safe mechanisms.

Acceptance criteria

  • The specification tree includes linked child requirements for PQC-aware modeling of supported scan results.
  • The design branch defines how hybrid or post-quantum mechanisms are represented in generated artifacts.

Child links: SRS-007 Model TLS findings with classical, hybrid, and PQ-aware decomposition, ARC-009 Algorithm modeling layer

Attribute Value
type F
importance 5
urgency 5
vm T
release Alpha

1.3 Produce standardized CBOM artifacts MRS-003

VECTOR SHALL generate machine-readable cryptographic inventory artifacts in a standardized CBOM format suitable for downstream processing.

Rationale

Standardized output is required for comparison, sharing, automation, and later migration analysis.

Acceptance criteria

  • Child requirements define how analysis results are converted into CBOM artifacts.
  • Verification artifacts confirm that generated inventory files are produced in JSON form.

Child links: SRS-005 Convert source-analysis findings into CBOM artifacts, ARC-007 CBOM generation and storage, SRS-014 Produce a single unified CBOM for multi-language projects

Attribute Value
type F
importance 5
urgency 4
vm T
release Alpha

1.4 Support source-code analysis for current target languages MRS-004

VECTOR SHALL support source-code cryptographic inventory for the languages currently implemented by the project baseline.

Rationale

The current TOR implementation provides practical value only when the supported language set is specified and verified.

Acceptance criteria

  • Child requirements define the supported language-detection and source-analysis workflow.
  • Verification artifacts demonstrate handling of the implemented source-language set.

Child links: ARC-002 VECTOR-Code processing component, SRS-002 Detect supported source languages from the target project, SRS-016 Accept a GitHub repository URL as a source analysis target

Attribute Value
type F
importance 4
urgency 4
vm T
release Alpha

1.5 Support TLS service assessment MRS-005

VECTOR SHALL assess TLS-enabled services and capture cryptographic configuration details needed for inventory generation.

Rationale

TLS deployments are a primary runtime surface for cryptographic exposure and migration risk.

Acceptance criteria

  • Child requirements define target-and-port-driven TLS scanning.
  • Verification artifacts demonstrate generation of TLS-derived inventory outputs.

Child links: ARC-005 TLS assessment workflow, SRS-006 Scan TLS-enabled services by target and port

Attribute Value
type F
importance 5
urgency 4
vm T
release Alpha

1.6 Support SSH service assessment MRS-006

VECTOR SHALL assess SSH-enabled services and capture cryptographic configuration details needed for inventory generation.

Rationale

SSH deployments expose key exchange, host-key, cipher, and MAC choices that are relevant to PQC transition planning.

Acceptance criteria

  • Child requirements define target-and-port-driven SSH scanning.
  • Verification artifacts demonstrate generation of SSH-derived inventory outputs.

Child links: ARC-006 SSH assessment workflow, SRS-008 Scan SSH-enabled services by target and port

Attribute Value
type F
importance 5
urgency 4
vm T
release Alpha

1.7 Run in a reproducible Linux-based environment MRS-007

VECTOR SHALL execute in a reproducible Linux-based environment with predictable local tool paths and writable artifact directories.

Rationale

The implemented pipelines rely on external command-line tools and filesystem outputs that must behave consistently across runs.

Acceptance criteria

  • Child requirements define the runtime assumptions for local execution and artifact generation.
  • Verification artifacts demonstrate that the runtime environment assumptions are explicit and testable.

Child links: ARC-001 VECTOR runtime context, SRS-009 Provide a ready-to-use Linux execution environment, SRS-018 Support standalone container deployment

Attribute Value
type NF
importance 4
urgency 4
vm T
release Alpha

1.8 Orchestrate open-source analysis tooling MRS-008

VECTOR SHALL orchestrate the open-source analysis tools required to perform its source-code and network inventory workflows.

Rationale

The current implementation depends on external scanners and converters rather than reimplementing all analysis logic internally.

Acceptance criteria

  • Child requirements define how required external tools are invoked within the workflow.
  • Verification artifacts demonstrate that tool invocation is explicit and validated.

Child links: SRS-003 Create CodeQL databases through the external CLI, ARC-004 External analysis tool adapters

Attribute Value
type F
importance 4
urgency 4
vm T
release Alpha

1.9 Preserve non-invasive assessment behavior MRS-009

VECTOR SHALL perform network assessment in a non-invasive, read-only manner and SHALL fail safely when mandatory inputs or tools are unavailable.

Rationale

Inventory collection must not introduce avoidable operational risk to scanned targets.

Acceptance criteria

  • Child requirements define input validation, missing-tool handling, and non-invasive scan behavior.
  • Verification artifacts demonstrate that invalid or incomplete conditions stop or constrain execution safely.

Child links: ARC-008 Non-invasive network trust boundary, SRS-010 Fail safely for invalid inputs, missing tools, and incomplete outputs

Attribute Value
type NF
importance 5
urgency 4
vm T
release Alpha

1.10 Produce open, reusable output artifacts MRS-010

VECTOR SHALL store its generated inventory artifacts in open, reusable file formats and predictable filesystem locations.

Rationale

Downstream migration planning and automation require outputs that can be inspected and reused without proprietary tooling.

Acceptance criteria

  • Child requirements define the expected output files and locations for the implemented workflows.
  • Verification artifacts confirm that generated outputs are machine-readable and persist outside transient process state.

Child links: SRS-001 Persist output artifacts in predictable locations, ARC-010 Open artifact interfaces

Attribute Value
type NF
importance 4
urgency 4
vm T
release Alpha

1.11 Assess quantum risk of discovered cryptographic assets MRS-011

VECTOR SHALL provide a mechanism to assess the quantum risk posture of cryptographic assets discovered during inventory, classifying each algorithm according to its vulnerability to cryptographically relevant quantum computers.

Rationale

Producing a cryptographic inventory (CBOM) is a necessary but insufficient step for PQC migration readiness. Organizations need a risk classification layer that translates raw algorithm findings into actionable migration priorities. Without this layer, analysts must manually cross-reference each discovered algorithm against NIST, BSI, and ANSSI migration guidance — a time-consuming and error-prone process.

Acceptance criteria

  • Child requirements define the classification rules, output formats, and verification conditions for the quantum risk scoring workflow.
  • Verification artifacts confirm that known quantum-vulnerable algorithms (RSA, ECDH, DH), quantum-safe algorithms (AES-256, SHA-256), and post-quantum algorithms (ML-KEM, ML-DSA) are each classified correctly.

Child links: ARC-011 VECTOR-Score: standalone quantum risk scoring module, SRS-011 Classify cryptographic algorithms in a CBOM by quantum risk, SRS-012 Produce a CBOM annotated with quantum risk properties, SRS-013 Produce a Markdown risk report grouped by classification, SRS-015 Show source locations of VECTOR-Code output in risk report

Attribute Value
type F
importance 5
urgency 5
vm T
release Alpha

1.12 Provide a browser-accessible interface MRS-012

VECTOR SHALL expose its scan submission, progress monitoring, and results review capabilities through a web-based interface that requires no CLI access or Dev Container familiarity.

Rationale

Client engagements involve stakeholders - security managers, compliance officers, project leads - who need to initiate scans and review quantum risk findings without access to a terminal or a VS Code Dev Container. A browser-accessible interface removes this dependency and makes VECTOR usable by the full range of project participants, not only the engineers who set up the tooling.

Acceptance criteria

  • Child requirements define the scan submission forms, progress monitoring behaviour, results viewer, and configuration surface of the web interface.
  • Verification artifacts confirm that all three VECTOR workflows can be initiated and their results reviewed entirely through the browser without invoking the CLI.

Child links: SRS-017 Provide a web-based interface for running scans and visualizing results

Attribute Value
type F
importance 3
urgency 3
vm T
release Alpha