1.1 Verify persisted output locations for VECTOR-Code artifacts TCS-001

Preconditions and setup actions

  • Prepare a readable sample project directory.
  • Ensure the current workspace is writable.

Test steps

  1. Run python3 main.py <sample-project> --name sample-app from the VECTOR-Code directory.
  2. Inspect the output/databases, output/results, and output/cbom directories after execution.
  3. Confirm that generated artifacts remain accessible after the process exits.

Expected outcome

  1. VECTOR-Code creates the expected output directory structure.
  2. Generated analysis artifacts are written to local files.
  3. Artifact paths remain inspectable after completion.

Parent links: SRS-001 Persist output artifacts in predictable locations

Child links: TRP-001 Starter report for persisted output verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data A readable sample project path with writable local output directories
version 0.1

1.2 Verify supported language detection TCS-002

Preconditions and setup actions

  • Prepare sample repositories containing known language mixes.
  • Ensure cloc is available in the runtime environment.

Test steps

  1. Run the VECTOR-Code workflow against a sample project containing supported languages.
  2. Observe the reported detected languages and percentages.
  3. Repeat with a project that contains no supported language above threshold.

Expected outcome

  1. Supported languages above threshold are reported.
  2. Python, C, and C++ map to the implemented source-analysis path.
  3. A project with no supported language above threshold terminates with an explicit warning or failure.

Parent links: SRS-002 Detect supported source languages from the target project

Child links: TRP-002 Starter report for language detection verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data Sample projects containing Python, C, and C++ code above and below threshold
version 0.1

1.3 Verify CodeQL database creation TCS-003

Preconditions and setup actions

  • Prepare a readable sample project.
  • Ensure the CodeQL CLI is installed and reachable from PATH.

Test steps

  1. Run VECTOR-Code against the sample project.
  2. Inspect the created database directories under output/databases.
  3. Verify that languages mapping to the same CodeQL language do not produce duplicate database names.

Expected outcome

  1. CodeQL databases are created for the detected CodeQL languages.
  2. Database names follow the db-<codeql-language> convention.
  3. Duplicate databases are not created for multiple source languages that share the same CodeQL target.

Parent links: SRS-003 Create CodeQL databases through the external CLI

Child links: TRP-003 Starter report for CodeQL database verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 3
test_data Sample project with detectable supported language content and CodeQL CLI installed
version 0.1

1.4 Verify SARIF generation from CodeQL queries TCS-004

Preconditions and setup actions

  • Prepare created CodeQL databases.
  • Ensure the configured query paths exist.

Test steps

  1. Run the VECTOR-Code workflow until the query stage completes.
  2. Inspect the output/results directory.
  3. Confirm that missing query paths or failed queries are reported explicitly.

Expected outcome

  1. Successful query execution creates SARIF output files.
  2. SARIF files follow the crypto-<language>.sarif naming pattern.
  3. Query-path or execution failures do not appear as successful findings.

Parent links: SRS-004 Run cryptographic inventory queries on created databases

Child links: TRP-004 Starter report for SARIF generation verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 3
test_data Created CodeQL databases and available inventory query packs
version 0.1

1.5 Verify SARIF-to-CBOM conversion TCS-005

Preconditions and setup actions

  • Prepare one or more valid SARIF result files.
  • Ensure the cryptobom command is available.

Test steps

  1. Run the VECTOR-Code workflow through the CBOM generation stage.
  2. Inspect the output/cbom directory.
  3. Confirm that failed conversions are reported and omitted from the successful output set.

Expected outcome

  1. CBOM JSON files are created from valid SARIF files.
  2. Generated file names derive from the source SARIF stem.
  3. Failed conversions do not appear as successful outputs.

Parent links: SRS-005 Convert source-analysis findings into CBOM artifacts

Child links: TRP-005 Starter report for SARIF-to-CBOM verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data Valid SARIF output files and cryptobom CLI installed
version 0.1

1.6 Verify raw TLS scan output generation TCS-006

Preconditions and setup actions

  • Prepare a reachable TLS-enabled endpoint.
  • Ensure testssl.sh is available at the configured path.

Test steps

  1. Run python3 network-scanning.py --protocol tls --target <target> --port <port>.
  2. Inspect the created raw TLS scan file.
  3. Confirm that the file is non-empty and associated with the requested target.

Expected outcome

  1. The TLS workflow accepts valid target and port input.
  2. A raw JSON scan file is created.
  3. Empty or missing output files are treated as failure conditions.

Parent links: SRS-006 Scan TLS-enabled services by target and port

Child links: TRP-006 Starter report for raw TLS scan verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data Controlled TLS endpoint and reachable port
version 0.1

1.7 Verify TLS CBOM decomposition TCS-007

Preconditions and setup actions

  • Prepare a valid raw TLS scan JSON file.
  • Ensure the TLS converter script and mapping files are present.

Test steps

  1. Run the TLS workflow through CBOM generation.
  2. Inspect the generated TLS CBOM file.
  3. Confirm that the output contains decomposed algorithm elements rather than only opaque suite names.

Expected outcome

  1. The converter generates a CBOM JSON file for the TLS scan.
  2. Mapped cipher-suite components appear as explicit algorithm records.
  3. Hybrid or PQ-related entries are represented when present in the mapped input data.

Parent links: SRS-007 Model TLS findings with classical, hybrid, and PQ-aware decomposition

Child links: TRP-007 Starter report for TLS CBOM verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 3
test_data TLS scan JSON containing cipher suites, groups, and supported mapped entries
version 0.1

1.8 Verify raw SSH scan output generation TCS-008

Preconditions and setup actions

  • Prepare a reachable SSH-enabled endpoint.
  • Ensure zgrab2 is available in PATH.

Test steps

  1. Run python3 network-scanning.py --protocol ssh --target <target> --port <port>.
  2. Inspect the created raw SSH scan file.
  3. Confirm that the file is non-empty and associated with the requested target.

Expected outcome

  1. The SSH workflow accepts valid target and port input.
  2. A raw JSON scan file is created.
  3. Empty or missing output files are treated as failure conditions.

Parent links: SRS-008 Scan SSH-enabled services by target and port

Child links: TRP-008 Starter report for raw SSH scan verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data Controlled SSH endpoint and reachable port
version 0.1

1.9 Verify Linux runtime assumptions and tool-path checks TCS-009

Preconditions and setup actions

  • Prepare one environment that satisfies the expected runtime layout.
  • Prepare one environment with a missing required script or unwritable output location.

Test steps

  1. Run VECTOR-Code and VECTOR-Network in the valid environment.
  2. Observe creation of required directories and use of configured tool paths.
  3. Repeat in the invalid environment and record the resulting failure behavior.

Expected outcome

  1. The valid environment supports normal startup and artifact generation.
  2. Required tool paths and writable directories are part of the runtime contract.
  3. Missing required scripts or paths are surfaced explicitly.

Parent links: SRS-009 Execute within a Linux workspace with explicit runtime assumptions

Child links: TRP-009 Starter report for runtime assumption verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data Runtime environment with and without required tool paths and writable output locations
version 0.1

1.10 Verify safe failure behavior TCS-010

Preconditions and setup actions

  • Prepare invalid target input, an out-of-range port, and one environment with a missing required tool.

Test steps

  1. Run the network workflow with an invalid port.
  2. Run the network workflow with an empty target.
  3. Run a workflow with a missing required tool or missing expected result file.

Expected outcome

  1. Invalid input is rejected before the scanner runs.
  2. Missing tools or files produce explicit failures.
  3. Conversion does not continue after a validation failure.

Parent links: SRS-010 Fail safely for invalid inputs, missing tools, and incomplete outputs

Child links: TRP-010 Starter report for safe failure verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data Invalid ports, empty targets, missing tools, and empty result files
version 0.1

1.11 Verify classification of quantum-vulnerable algorithms TCS-011

Preconditions and setup actions

  • VECTOR-Score module is installed and importable from tor/VECTOR-Score/.
  • A sample CBOM fixture with RSA, ECDHE, DHE, and ECDSA algorithm components is available under tests/content/.

Test steps

  1. Import algorithm_classifier.classify from tor/VECTOR-Score/algorithm_classifier.py.
  2. Call classify("RSA", "pke", None) and assert result.classification == "quantum-vulnerable".
  3. Call classify("ECDHE", "key-agree", None) and assert result.classification == "quantum-vulnerable".
  4. Call classify("DHE", "key-agree", None) and assert result.classification == "quantum-vulnerable".
  5. Call classify("ECDSA", "signature", None) and assert result.classification == "quantum-vulnerable".

Expected outcome

All four calls return a RiskClassification with classification == "quantum-vulnerable" and risk_score == "high".

Parent links: SRS-011 Classify cryptographic algorithm components in a CBOM by quantum risk

Child links: TRP-011 Test report for quantum-vulnerable algorithm classification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data A CBOM fixture containing algorithm components named RSA, ECDHE, DHE, and ECDSA.
version 0.1

1.12 Verify classification of post-quantum algorithms TCS-012

Preconditions and setup actions

  • VECTOR-Score module is installed and importable from tor/VECTOR-Score/.
  • The algorithm risk catalog includes entries for ML-KEM, ML-DSA, and SLH-DSA.

Test steps

  1. Import algorithm_classifier.classify from tor/VECTOR-Score/algorithm_classifier.py.
  2. Call classify("ML-KEM-768", "kem", None) and assert result.classification == "post-quantum".
  3. Call classify("ML-KEM-1024", "kem", None) and assert result.classification == "post-quantum".
  4. Call classify("ML-DSA-65", "signature", None) and assert result.classification == "post-quantum".
  5. Call classify("SLH-DSA", "signature", None) and assert result.classification == "post-quantum".

Expected outcome

All four calls return a RiskClassification with classification == "post-quantum" and risk_score == "none".

Parent links: SRS-011 Classify cryptographic algorithm components in a CBOM by quantum risk

Child links: TRP-012 Test report for post-quantum algorithm classification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data Direct calls to algorithm_classifier.classify() with ML-KEM-768, ML-KEM-1024, ML-DSA-65, SLH-DSA.
version 0.1

1.13 Verify annotated CBOM contains pqcmat risk properties TCS-013

Preconditions and setup actions

  • VECTOR-Score module is installed and importable.
  • tests/content/sample_tls_cbom.json fixture is available with at least one algorithm component.

Test steps

  1. Load tests/content/sample_tls_cbom.json.
  2. Call cbom_scorer.score_cbom(cbom) to obtain the annotated CBOM.
  3. For each component in the annotated CBOM where cryptoProperties.assetType == "algorithm": a. Assert that a properties array is present. b. Assert that a properties entry with name == "pqcmat:risk-classification" exists and has a non-empty value. c. Assert that a properties entry with name == "pqcmat:risk-score" exists. d. Assert that a properties entry with name == "pqcmat:recommended-migration" exists.
  4. Assert that the annotated CBOM metadata.properties contains an entry with name == "pqcmat:scored-at".

Expected outcome

All algorithm components in the annotated CBOM carry the required pqcmat: properties. Non-algorithm components (protocol, certificate) have no pqcmat: properties added.

Parent links: SRS-012 Produce an annotated CBOM with quantum risk properties on each scored component

Child links: TRP-013 Test report for annotated CBOM pqcmat property verification

Attribute Value
platform GNU/Linux workstation or dev container
execution_type Manual
verification_method Test
release alpha
complexity 2
test_data tests/content/sample_tls_cbom.json — a minimal fixture containing RSA, AES-128-GCM, and ML-KEM-768 algorithm components.
version 0.1