1.1 Persist output artifacts in predictable locations SRS-001
VECTOR SHALL write generated source-analysis and network-analysis artifacts to predictable output files and directories under the local workspace.
Rationale
The current implementation writes databases, SARIF results, raw scan results, and CBOM files to the filesystem for later inspection and reuse.
Acceptance criteria
- VECTOR-Code creates and uses dedicated output directories for databases, results, and CBOM files.
- VECTOR-Network writes raw scan files and generated CBOM files to named local JSON files.
- Output paths remain inspectable after process completion.
Parent links: MRS-010 Produce open, reusable output artifacts
Child links: TCS-001 Verify persisted output locations for VECTOR-Code artifacts
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 4 |
| urgency | 4 |
| vm | T |
1.2 Detect supported source languages from the target project SRS-002
VECTOR-Code SHALL run a language-detection step against the supplied project path and SHALL continue only when at least one supported language is detected above the configured threshold.
Rationale
The implemented source-analysis pipeline depends on a supported-language set before CodeQL databases can be created.
Acceptance criteria
- The input path is checked for existence, directory type, and read permission before analysis starts.
- Language detection is derived from
cloc --jsonoutput. - The current supported languages are Python, C, and C++.
Parent links: MRS-004 Support source-code analysis for current target languages
Child links: TCS-002 Verify supported language detection
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T |
1.3 Create CodeQL databases through the external CLI SRS-003
VECTOR-Code SHALL invoke the external CodeQL CLI to create one analysis database per detected CodeQL language.
Rationale
The current implementation uses external CodeQL tooling to prepare the source tree for cryptographic inventory queries.
Acceptance criteria
- Duplicate source languages that map to the same CodeQL language do not create redundant databases.
- Database creation uses
--build-mode=none. - Failed database creation for one language does not fabricate a successful result for that language.
Parent links: MRS-008 Orchestrate open-source analysis tooling
Child links: TCS-003 Verify CodeQL database creation
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 4 |
| urgency | 4 |
| vm | T |
1.4 Run cryptographic inventory queries on created databases SRS-004
VECTOR-Code SHALL run cryptographic inventory queries against each created CodeQL database and SHALL collect the resulting SARIF artifacts.
Rationale
Source-code inventory requires a query phase that transforms prepared databases into inspectable findings.
Acceptance criteria
- Each created CodeQL database is checked against a configured query path for its CodeQL language.
- Successful query execution produces a SARIF output file for that language.
- Missing query paths or failed query execution do not silently report successful findings.
Parent links: MRS-001 Inventory cryptography across code and network surfaces
Child links: TCS-004 Verify SARIF generation from CodeQL queries
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 5 |
| vm | T |
1.5 Convert source-analysis findings into CBOM artifacts SRS-005
VECTOR-Code SHALL convert generated SARIF files into CBOM JSON artifacts using the configured application name.
Rationale
The implemented pipeline currently ends with SARIF-to-CBOM conversion, which makes the inventory consumable by downstream tooling.
Acceptance criteria
- Every valid SARIF file is eligible for CBOM generation.
- Failed conversion for one SARIF file does not report that file as a generated CBOM artifact.
- Generated CBOM files are named from the SARIF artifact stem.
Parent links: MRS-003 Produce standardized CBOM artifacts
Child links: TCS-005 Verify SARIF-to-CBOM conversion
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T |
1.6 Scan TLS-enabled services by target and port SRS-006
VECTOR-Network SHALL accept a target and port for TLS assessment and SHALL invoke the configured TLS scanner to produce a raw JSON result file.
Rationale
The implemented TLS workflow is target-and-port driven and depends on persisted raw output before conversion.
Acceptance criteria
- TLS assessment validates that the target is non-empty and the port is within the supported range.
- Existing conflicting output files are removed before a new TLS scan starts.
- A successful scan produces a non-empty JSON result file.
Parent links: MRS-005 Support TLS service assessment
Child links: TCS-006 Verify raw TLS scan output generation
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T |
1.7 Model TLS findings with classical, hybrid, and PQ-aware decomposition SRS-007
VECTOR-Network SHALL convert TLS scan results into a CBOM representation that preserves decomposed cryptographic algorithms, including supported hybrid or post-quantum-related entries.
Rationale
The implemented TLS conversion logic decomposes cipher suites, curves, and hybrid constructions into explicit inventory components.
Acceptance criteria
- TLS conversion reads structured JSON scan input and produces a CBOM JSON document.
- Cipher-suite decomposition captures key exchange, authentication, encryption, and hashing elements when present.
- Hybrid or PQ-related curve identifiers are represented when they are present in the mapped input data.
Parent links: MRS-002 Recognize post-quantum and hybrid algorithms
Child links: TCS-007 Verify TLS CBOM decomposition
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T |
1.8 Scan SSH-enabled services by target and port SRS-008
VECTOR-Network SHALL accept a target and port for SSH assessment and SHALL invoke the configured SSH scanner to produce a raw JSON result file.
Rationale
The implemented SSH workflow depends on a persisted scan result that is later parsed into inventory components.
Acceptance criteria
- SSH assessment validates that the target is non-empty and the port is within the supported range.
- A successful SSH scan produces a non-empty JSON result file.
- The generated raw SSH output is suitable for later CBOM conversion.
Parent links: MRS-006 Support SSH service assessment
Child links: TCS-008 Verify raw SSH scan output generation
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T |
1.9 Execute within a Linux workspace with explicit runtime assumptions SRS-009
VECTOR SHALL rely on a Linux workspace that provides access to its expected local tool paths and writable output locations for both source-analysis and network-analysis workflows.
Rationale
The current implementation hard-codes several command-line tools and output locations, making runtime assumptions part of the operational contract.
Acceptance criteria
- VECTOR-Code creates its expected output directories before analysis steps start.
- VECTOR-Network checks that required converter scripts and scanner paths exist before conversion or scan processing continues.
- Runtime assumptions are explicit enough to verify in a controlled environment.
Parent links: MRS-007 Run in a reproducible Linux-based environment
Child links: TCS-009 Verify Linux runtime assumptions and tool-path checks
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 4 |
| urgency | 4 |
| vm | T |
1.10 Fail safely for invalid inputs, missing tools, and incomplete outputs SRS-010
VECTOR SHALL stop or constrain execution safely when required inputs are invalid, mandatory tools are unavailable, or expected result files are missing or empty.
Rationale
The implemented workflows already perform defensive checks around targets, ports, filesystem state, scanner presence, and generated outputs.
Acceptance criteria
- Invalid ports and empty targets are rejected before scanner invocation.
- Missing required tools or scripts terminate the affected workflow with an explicit error.
- Missing or empty result files do not proceed to CBOM conversion as if analysis succeeded.
Parent links: MRS-009 Preserve non-invasive assessment behavior
Child links: TCS-010 Verify safe failure behavior
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 4 |
| vm | T |
1.11 Classify cryptographic algorithm components in a CBOM by quantum risk SRS-011
VECTOR SHALL accept a CycloneDX CBOM JSON file as input and classify each algorithm component according to its quantum risk level, using a data-driven catalog that encodes normative guidance from NIST, BSI TR-02102, and ANSSI.
Rationale
The classification step decouples the scoring logic from the inventory tools, allowing any CBOM produced by VECTOR-Code or VECTOR-Network (or any third-party tool producing a compliant CycloneDX CBOM) to be scored. A data-driven catalog (YAML) ensures the classification rules can be updated as standards evolve without modifying source code.
Acceptance criteria
- Given a CBOM containing RSA, ECDH, or DH algorithm components, the scorer assigns the
quantum-vulnerableclassification to each. - Given a CBOM containing ML-KEM or ML-DSA components, the scorer assigns the
post-quantumclassification to each. - Given a CBOM containing AES-256 or SHA-256 components, the scorer assigns the
quantum-safeclassification. - Given an unrecognized algorithm name, the scorer assigns the
unknownclassification. - Only components with
cryptoProperties.assetTypeequal toalgorithmare scored; protocol, certificate, and related-crypto-material components are left unmodified.
Parent links: MRS-011 Assess quantum risk of discovered cryptographic assets
Child links: TCS-011 Verify classification of quantum-vulnerable algorithms, TCS-012 Verify classification of post-quantum algorithms
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 5 |
| vm | T |
1.12 Produce an annotated CBOM with quantum risk properties on each scored component SRS-012
VECTOR SHALL produce an annotated copy of the input CBOM in which each scored algorithm component carries additional pqcmat:-namespaced properties recording its risk classification, risk score, rationale, recommended migration target, and normative reference.
Rationale
Embedding the risk classification directly into the CBOM document allows downstream tools and workflows to consume the scored output using standard CycloneDX tooling. The pqcmat: namespace prefix prevents collisions with other CycloneDX tool annotations. The original CBOM structure and all existing fields are preserved.
Acceptance criteria
- The annotated CBOM is valid JSON and retains all fields from the input CBOM.
- Each scored algorithm component contains a
propertiesarray entry withname: "pqcmat:risk-classification"and a non-emptyvalue. - Each scored algorithm component contains a
propertiesarray entry withname: "pqcmat:risk-score"with value one ofhigh,medium,low, ornone. - Each scored algorithm component contains a
propertiesarray entry withname: "pqcmat:recommended-migration". - The annotated CBOM
metadata.propertiesarray contains apqcmat:scored-atentry recording the scoring timestamp.
Parent links: MRS-011 Assess quantum risk of discovered cryptographic assets
Child links: TCS-013 Verify annotated CBOM contains pqcmat risk properties
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 5 |
| urgency | 5 |
| vm | T |
1.13 Produce a human-readable Markdown risk report grouped by classification SRS-013
VECTOR SHALL produce a Markdown report summarising the quantum risk findings from a scored CBOM, grouping algorithm findings by risk classification and including a count summary table, per-finding details (algorithm name, primitive, key size, rationale, migration target), and a normative references section.
Rationale
While the annotated CBOM is the machine-readable output, security and engineering teams require a human-readable artefact that can be reviewed without CBOM tooling. Grouping findings by risk level allows reviewers to prioritise remediation efforts.
Acceptance criteria
- The report is a valid Markdown document with a header identifying the scored target and timestamp.
- The report contains a summary table with columns: risk classification and algorithm count.
- The report contains at least one section per non-empty risk classification present in the scored CBOM.
- Each per-classification section contains a table listing: algorithm name, primitive type, key size (if applicable), rationale, and recommended migration target.
- The report contains a normative references section listing all standards cited.
Parent links: MRS-011 Assess quantum risk of discovered cryptographic assets
| Attribute | Value |
|---|---|
| release | Alpha |
| type | F |
| importance | 4 |
| urgency | 4 |
| vm | T |