Vectis

Repository on GitHub, which provides public git repositories with URLs.

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Vectis is developed in its public Git repository. The main branch contains intermediate development commits between releases, and the complete commit
history and proposed pull-request changes are available for review. The repository is not limited to final release snapshots or generated artifacts.

Evidence:
https://github.com/liesware/Vectis/commits/main/
https://github.com/liesware/Vectis/pulls
https://github.com/liesware/Vectis

Repository on GitHub, which uses git. git is distributed.

Each Vectis release is assigned a unique Semantic Versioning identifier from Cargo.toml. The version is exposed by vectis version, recorded in
CHANGELOG.md, and used in release artifact names.

The release workflow requires the Git tag to match v${Cargo.toml.version} before publishing release artifacts, preventing a release from being published under an inconsistent version identifier.

Evidence:
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml

Non-trivial release notes file in repository: https://github.com/liesware/Vectis/blob/main/CHANGELOG.md.

N/A. At the time Vectis v0.8.5 was prepared, there were no publicly known run-time vulnerabilities in Vectis with a CVE or equivalent public identifier that were fixed by the release.

Dependency advisories are monitored separately and are not treated as vulnerabilities in the Vectis project results for this criterion.

Evidence:
https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
https://github.com/liesware/Vectis/blob/main/SECURITY.md

Non-trivial SECURITY[.md] file found file in repository: https://github.com/liesware/Vectis/blob/main/SECURITY.md. [osps_do_02_01]

Vectis uses GitHub Issues as its public issue tracker. Individual bug reports,
enhancement proposals, documentation problems, and user questions can be created, discussed, tracked, and closed there.

Suspected unpatched vulnerabilities are handled separately through the private reporting process documented in SECURITY.md.

Evidence:
https://github.com/liesware/Vectis/issues
https://github.com/liesware/Vectis/blob/main/SECURITY.md

Vectis uses GitHub Issues as a publicly available and searchable archive for bug reports, enhancement requests, questions, and maintainer responses. Open and closed reports remain available for later review and searching.

Public archive:
https://github.com/liesware/Vectis/issues?q=is%3Aissue

Vectis publishes its vulnerability-reporting process in SECURITY.md. The policy defines the private reporting channel, requested report contents, supported versions, expected acknowledgment period, disclosure process, and information that reporters must not include.

Vulnerability-reporting process:
https://github.com/liesware/Vectis/blob/main/SECURITY.md

Vectis accepts private vulnerability reports through the maintainer's direct email address, using the subject specified in SECURITY.md. Reporters are instructed not to open a public issue for an unpatched vulnerability. If a more protected exchange is needed, the reporter can request an appropriate channel
in the initial private message.

Private reporting instructions:
https://github.com/liesware/Vectis/blob/main/SECURITY.md#reporting-a-vulnerability

N/A. Vectis has not received any vulnerability reports during the last six months. SECURITY.md establishes a target acknowledgment period of five business
days for future reports.

Evidence:
https://github.com/liesware/Vectis/blob/main/SECURITY.md

Vectis uses Cargo as its automated build system. The complete application can be rebuilt from source with cargo build --locked or cargo build --release --locked.

Cargo.toml defines the package and dependencies, Cargo.lock pins dependency resolution, and rust-toolchain.toml defines the Rust toolchain. GitHub Actions
continuously verifies that the project builds from source.

Evidence:
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/Cargo.lock
https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml

Vectis uses Cargo and rustup, the standard build and toolchain-management tools of the Rust ecosystem. Common Cargo commands are used for development, testing, linting, and release builds; no proprietary or project-specific build system is required.

Typical commands include:

cargo build --locked
cargo test --locked
cargo clippy --locked --all-targets --all-features -- -D warnings

Evidence:
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md

Vectis can be built entirely with FLOSS tools. Its standard build uses the open-source Rust compiler, Cargo, LLVM-based tooling, and common GNU/Linux build
tools.

The container build demonstrates this path using Debian with Cargo, rustc, Clang, GCC, CMake, Make, and other open-source packages, followed by
cargo build --release --locked. No proprietary compiler or build system is required.

Evidence:
https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml

Vectis includes publicly available automated test suites released under the project's Apache-2.0 license. The primary Rust suite runs with cargo test --locked.

The project also includes Python HTTP integration tests, Schemathesis OpenAPI contract testing, native cargo-fuzz targets, and dedicated CLI and cryptographic integration tests. Execution instructions and the role of each suite are documented in doc/Test.md, and the standard suite runs automatically through GitHub Actions.

Evidence:
https://github.com/liesware/Vectis/blob/main/doc/Test.md
https://github.com/liesware/Vectis/tree/main/tests
https://github.com/liesware/Vectis/tree/main/fuzz
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
https://github.com/liesware/Vectis/blob/main/LICENSE

Vectis uses Cargo's standard Rust test interface. The primary unit and integration test suite is invoked with:

cargo test --locked

Targeted Rust tests can also be selected through Cargo's standard test filters. Additional Python, Schemathesis, and cargo-fuzz suites are documented separately, but they do not replace the standard Cargo test entry point.

Evidence:
https://github.com/liesware/Vectis/blob/main/doc/Test.md
https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml

Vectis uses GitHub Actions for continuous integration. The Rust workflow runs automatically for every pull request targeting main and for every push to main.

The workflow checks formatting, runs the complete Rust test suite, runs Clippy with warnings treated as errors, validates shell scripts, audits dependencies,
builds the binary, and then executes the Python integration tests.

Evidence:
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
https://github.com/liesware/Vectis/actions/workflows/Rust.yml

Vectis requires tests to be added alongside new behavior. Its engineering rules state that validation functions require unit tests and public contracts require
positive and negative end-to-end tests. New endpoints are expected to add validators, limits, unit tests, and negative contract coverage as part of the
same change.

CONTRIBUTING.md also states that tests must not be omitted to make a change appear smaller and requires contributors to run the automated Rust suite before submitting.

Evidence:
https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md

Recent major Vectis capabilities were implemented together with automated tests:

• SLH-DSA artifact signing added unit tests, parser validation tests, four native fuzz targets, and seed corpora.
• One-time tokenization added SQLite transaction tests, HTTP positive and negative tests, CLI tests, and fuzz coverage.
• Authenticated Shamir secret sharing added core and operation tests, positive and negative HTTP tests, CLI coverage, and fuzz inputs.
• Cryptographic commitments added unit, HTTP contract, negative, CLI, and fuzz tests.

This commit history demonstrates that the project's policy of adding tests with new functionality is followed in practice.

Evidence:
https://github.com/liesware/Vectis/commit/154cb816c41667d521c1f30cf25c50f6f524321d
https://github.com/liesware/Vectis/commit/7f7f0fa4814494f7dad7fc740e1c70dd2606ba1d
https://github.com/liesware/Vectis/commit/a337628e14e69ca4f2116a55d292fa9915a5eeca
https://github.com/liesware/Vectis/commit/4bbf0047773cdc590da923f465a6b13cd7f02ea6

Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

Evidence:
https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline

Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

Evidence:
https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline

Vectis treats compiler and Clippy warnings as errors. The continuous integration workflow runs Clippy with -D warnings across all targets and features, so any
new warning causes the check to fail and must be resolved before the change can be accepted.

The project's engineering rules define zero warnings as the required state, and the same check is documented for contributors.

Evidence:
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
https://github.com/liesware/Vectis/actions/workflows/Rust.yml

Vectis applies strict warning handling across all targets and features. Clippy and compiler warnings are promoted to errors through -D warnings, so warnings
cannot be merged while the CI check is required.

The project uses only narrow, local lint allowances for specific cases such as intentionally unused internal helpers and configuration functions whose
signatures reflect explicit validation hooks. It does not disable warning categories globally.

Evidence:
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline

Eduardo Lopez is the original author, primary developer, maintainer, release operator, and recipient of private vulnerability reports for Vectis.

Vectis applies secure-design principles throughout its implementation and documentation: narrow scope and economy of mechanism; fail-closed sealed
startup and authorization; centralized lifecycle and permission mediation; public design and threat-model documentation; separation of policy, keys, and
operations; least-privilege container execution; bounded inputs and attack surface; allowlist-based validation; explicit trust boundaries; and simple,
inspectable HTTP, CLI, JSON, and OpenAPI interfaces.

The project's Design and Threat Model documents explain these principles, their implementation, and the security properties Vectis deliberately leaves
to other layers.

Evidence:
https://github.com/liesware/Vectis/blob/main/doc/Design.md
https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
https://github.com/liesware/Vectis/blob/main/doc/Internal.md
https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
https://github.com/liesware/Vectis/blob/main/NOTICE

Vectis's primary developer understands common vulnerability classes relevant to a networked cryptographic data-protection service and applies corresponding
mitigations, including:

• SQL injection: SQLx queries use bound parameters; dynamic SQL is limited to internally generated placeholders.
• Missing authentication or authorization: protected endpoints use API-key authentication, signed permissions, KID scoping, peer authorization, and
  centralized lifecycle checks.
• SSRF and destination injection: peer and final-application destinations come from signed configuration, not request-supplied addresses.
• Invalid or malicious input: external fields are bounded and validated using allowlists, typed parsers, strict JSON contracts, and canonical structured
  contexts.
• Cryptographic misuse: Vectis uses published algorithms through Botan and established libraries, CSPRNG-generated material, profile-controlled policy,
  context-bound AEAD, and verify-before-decrypt.
• Timing attacks: API-key, MAC, commitment, signature-hash, and share authentication comparisons use constant-time comparison.
• Secret disclosure: sensitive values are redacted from errors and logs, zeroized where practical, and encrypted before application-level storage.
• Resource-exhaustion attacks: HTTP bodies, fields, batches, files, timeouts, and shutdown behavior have explicit bounds.
• Concurrency and state races: token consumption and lifecycle changes use transactions or compare-and-swap semantics where required.
• Memory-safety errors: Vectis is implemented in Rust and avoids manual memory management in production application logic.

These threats and mitigations are documented and tested through unit, integration, negative-contract, property-based, and fuzz testing.

Evidence:
https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
https://github.com/liesware/Vectis/blob/main/doc/Design.md
https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
https://github.com/liesware/Vectis/blob/main/src/core/validation.rs
https://github.com/liesware/Vectis/blob/main/src/core/storage/sqlite.rs

Vectis's primary purpose is to provide cryptographic data-protection capabilities, including encryption, signatures, FPE, tokenization, MACs,
commitments, secret sharing, and protected messaging. Therefore, the condition for this criterion does not apply.

Nevertheless, Vectis delegates established cryptographic primitives to specialized FLOSS implementations such as Botan, RustCrypto crates, rustls,
and the FF1 implementation maintained in liesware/fpe. Vectis does not implement block ciphers, cryptographic hash functions, digital-signature
algorithms, or post-quantum primitives from scratch. Project code primarily implements policy, validation, key derivation, formats, and compositions around
those primitives.

Evidence:
https://github.com/liesware/Vectis#readme
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
https://github.com/liesware/Vectis/blob/main/doc/Internal.md

All cryptography-dependent functionality in Vectis can be built and operated using FLOSS components. Vectis is licensed under Apache-2.0 and publishes its
complete source code.

Cryptographic primitives are provided by open-source implementations including Botan, RustCrypto crates, rustls, and the open-source Vectis FF1 fork. Vectis
does not require proprietary cryptographic libraries, SDKs, hardware, or hosted services for its current functionality. Dependencies are declared and pinned
through Cargo.toml and Cargo.lock, and the project can be rebuilt from source
using the documented FLOSS toolchain.

Evidence:
https://github.com/liesware/Vectis/blob/main/LICENSE
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/Cargo.lock
https://github.com/liesware/fpe
https://github.com/randombit/botan
https://github.com/rustls/rustls

Vectis uses cryptographic profiles whose weakest supported components provide at least 128 bits of security, exceeding the 112-bit NIST minimum required
through 2030.

The default hybrid-performance-v1 profile uses ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other profiles use AES-128, AES-192, or
AES-256 together with equal or stronger signature and key-establishment parameters. Internal encryption, FPE, tokenization, MAC, commitments, secret
sharing authentication, and key derivation use 256-bit key material.

Vectis does not expose legacy or reduced key sizes. The default VECTIS_CRYPTO_POLICY=profile-only rejects individual algorithm overrides and
allows only the fixed, validated profiles. Even development overrides are restricted to an allowlist containing no algorithms below the required
security strength.

Evidence:
https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
https://github.com/liesware/Vectis/blob/main/src/core/config.rs
https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
https://github.com/liesware/Vectis/blob/main/doc/ENV.md
https://github.com/liesware/Vectis#crypto-profiles

Vectis does not use cryptographic algorithms known to be broken, including MD4, MD5, SHA-1, DES, Triple DES, RC4, or Dual_EC_DRBG.

The default profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other supported profiles use SHA-3, AES-GCM,
Ed25519 or Ed448, X25519 or X448, ML-DSA, and ML-KEM.

Encryption uses authenticated encryption modes: ChaCha20Poly1305 or AES-GCM. Stored internal material uses AES-256/GCM, and FPE uses FF1 with AES-256 and enforces a minimum domain size. Keyed operations use HMAC or KMAC. HTTPS uses rustls and its modern TLS defaults.

Algorithm selection is restricted through explicit allowlists. The default profile-only policy rejects request-supplied algorithm overrides, and no compatibility fallback enables broken algorithms or inappropriate cipher modes.

Vectis currently has no interoperability requirement that requires a broken algorithm, so no exception or legacy-risk mitigation is necessary.

Evidence:
https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
https://github.com/liesware/Vectis/blob/main/src/core/config.rs
https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md

Vectis default security mechanisms do not depend on cryptographic algorithms or modes with known serious weaknesses.

The default cryptographic profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Internal storage encryption uses
AES-256/GCM. Other supported profiles use SHA-3 and AES-GCM with stronger parameter sets.

Vectis does not use SHA-1, MD5, DES, Triple DES, RC4, ECB, unauthenticated CBC encryption, or legacy TLS cipher suites. Encryption uses authenticated
modes with contextual AAD, while TLS is provided through rustls with modern defaults.

FPE uses FF1 with AES-256 and validates the minimum domain size required by the current FF1 specification. The default profile-only policy also prevents
requests from selecting arbitrary cryptographic algorithms.

Evidence:
https://github.com/liesware/Vectis/blob/main/src/core/config.rs
https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
https://github.com/liesware/Vectis/blob/main/Cargo.toml
https://github.com/liesware/Vectis/blob/main/doc/ENV.md

Not applicable. Vectis does not provide password-based authentication and does not store passwords belonging to external users.

HTTP authentication uses high-entropy API keys generated from a CSPRNG. The server stores a keyed HMAC verifier derived from protected init key material,
rather than storing the API key in plaintext. Client authorization data uses the same keyed identifier model inside signed configuration.

The unseal key, database credentials, TLS private keys, and similar operator secrets are not external-user passwords and are governed by separate storage
and deployment controls.

Evidence:
https://github.com/liesware/Vectis/blob/main/src/ops/apikey.rs
https://github.com/liesware/Vectis/blob/main/src/ops/internal_keys.rs
https://github.com/liesware/Vectis/blob/main/src/core/permissions.rs
https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
https://github.com/liesware/Vectis/blob/main/doc/ENV.md

Vectis generates cryptographic keys, nonces, salts, tokens, commitment openings, and secret-sharing coefficients using Botan's cryptographically
secure random number generator.

The core crypto module centralizes random generation through RandomNumberGenerator::new(), random_bytes(), and random_bytes_with_rng(). Cryptographic operations may reuse one Botan RNG during a single operation, but they do not replace it with a non-cryptographic generator.

This CSPRNG is used for:

• symmetric and asymmetric operational key generation;
• EdDSA, X25519/X448, ML-DSA, ML-KEM, and SLH-DSA material;
• AES-GCM and ChaCha20Poly1305 nonces;
• ML-KEM and HKDF salts;
• reversible random tokens;
• commitment openings;
• Shamir secret-sharing coefficients and set identifiers;
• API keys, unseal keys, signature serials, and audit chain identifiers.

Non-cryptographic counters used for request correlation are not used as keys, nonces, salts, tokens, or other cryptographic material. Vectis does not use
thread_rng, fastrand, timestamps, counters, or similar non-cryptographic sources for security-sensitive randomness.

Evidence:
https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
https://github.com/liesware/Vectis/blob/main/src/ops/key_material.rs
https://github.com/liesware/Vectis/blob/main/src/ops/message.rs
https://github.com/liesware/Vectis/blob/main/src/core/tokenization.rs
https://github.com/liesware/Vectis/blob/main/src/core/sharing.rs
https://github.com/liesware/Vectis/blob/main/src/ops/commitments.rs
https://github.com/liesware/Vectis/blob/main/src/ops/init.rs

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Vectis does not retrieve cryptographic hashes over plain HTTP and use them for integrity decisions without signature verification.

Source and dependency downloads use HTTPS. Cargo dependencies are resolved through Cargo.lock, which records package checksums and pins the Git-based FPEdependency to a specific commit. Container base images are referenced by immutable SHA-256 digests.

Release SHA256SUMS are generated locally inside the trusted GitHub Actions release workflow; they are not downloaded from an untrusted HTTP source.
Release archives also receive GitHub build-provenance attestations before publication.

No build, installation, update, or release workflow retrieves a checksum over plain HTTP and then trusts that checksum without an authenticated mechanism.

Evidence:
https://github.com/liesware/Vectis/blob/main/Cargo.lock
https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml
https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml

As of 2026-08-21, Vectis has no publicly known unpatched vulnerability of Medium, High, or Critical severity that has remained unresolved for more than
60 days.

The project runs cargo audit in CI against the committed Cargo.lock. A current scan of 362 Rust dependencies completed successfully with no vulnerabilities.
The previously reported RUSTSEC-2026-0258 vulnerability in h2 was remediated by upgrading to h2 0.4.16.

Container release candidates are scanned with Trivy before publication, and CodeQL analyzes the source code. Security findings and dependency updates are
handled through the documented vulnerability-reporting process.

Evidence:
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
https://github.com/liesware/Vectis/blob/main/Cargo.lock
https://github.com/liesware/Vectis/blob/main/SECURITY.md
https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md

No Critical severity vulnerability has been reported or publicly identified in Vectis to date, and no confirmed Critical vulnerability remains unresolved.

Vectis accepts private vulnerability reports through its published security policy, aims to acknowledge reports within five business days, provides status
updates during investigation, and coordinates fixes and disclosure with the reporter.

Critical findings would receive immediate triage and an expedited tested release before coordinated public disclosure. Cargo Audit, CodeQL, Trivy,
OpenSSF Scorecard, and security-focused testing provide continuous detection paths for vulnerabilities requiring this response.

Because no Critical vulnerability has been reported, Vectis does not yet have a historical Critical-vulnerability remediation time to report.

Evidence:
https://github.com/liesware/Vectis/blob/main/SECURITY.md
https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md

Vectis public repositories do not contain valid private credentials intended to control access to private resources.

Runtime secret files such as .env, .unseal_key, init.json, TLS private keys, databases, generated configuration, and local demo state are excluded from
version control. Demo and integration scripts generate temporary credentials at runtime instead of embedding reusable credentials.

GitHub Actions retrieves publishing credentials through the GitHub Secrets context. The Helm chart accepts secrets through operator-supplied values or an
existing Kubernetes Secret and does not contain populated credentials.

Values shown in env.dist and documentation are synthetic localhost examples. They do not grant access to any public or private service and are not production
credentials.

A review of tracked files and repository history found no committed private-key blocks or recognizable live access-token formats.

Evidence:
https://github.com/liesware/Vectis/blob/main/.gitignore
https://github.com/liesware/Vectis/blob/main/env.dist
https://github.com/liesware/Vectis/blob/main/charts/vectis/values.yaml
https://github.com/liesware/Vectis/blob/main/charts/vectis/templates/secret.yaml
https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
https://github.com/liesware/Vectis/blob/main/SECURITY.md

Vectis uses CodeQL as a static source-code analysis tool beyond compiler warnings and Rust's memory-safety guarantees.

CodeQL analyzes both Rust source code and GitHub Actions workflows. It runs for pull requests targeting main, every push to main, on a weekly schedule, and on manual request. Proposed release commits are merged into main and reviewed through this analysis before being tagged for release.

Cargo Clippy, Cargo Audit, Trivy, and OpenSSF Scorecard provide additional analysis, but CodeQL is the static source-code analysis mechanism used to
satisfy this criterion.

Evidence:
https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
https://github.com/liesware/Vectis/actions/workflows/codeql.yml
https://github.com/liesware/Vectis/security/code-scanning

Vectis uses the CodeQL default security query suite for Rust and GitHub Actions.

The Rust query suite includes vulnerability-focused data-flow and source-to-sink analysis mapped to common CWE categories, including:

• SQL injection;
• server-side request forgery;
• path and regular-expression injection;
• log injection and sensitive-data logging;
• cleartext storage and transmission;
• disabled TLS certificate verification;
• hard-coded cryptographic values;
• weak cryptographic algorithms;
• uncontrolled allocation sizes;
• invalid pointer and lifetime access.

CodeQL also analyzes GitHub Actions workflows for security-relevant workflow issues. The analysis runs on pull requests, pushes to main, weekly, and on
manual request.

Evidence:
https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
https://github.com/liesware/Vectis/security/code-scanning
https://docs.github.com/en/code-security/code-scanning/managing-your-code-scanning-configuration/rust-built-in-queries
https://codeql.github.com/codeql-query-help/rust-cwe/

Not applicable at present. CodeQL has not produced a confirmed exploitable Medium, High, or Critical severity vulnerability in Vectis that requires
remediation.

CodeQL continues to analyze Rust source code and GitHub Actions on pull requests, pushes to main, weekly, and on manual request. Any future finding is
reviewed to distinguish an exploitable vulnerability from a false positive or non-security issue.

A confirmed exploitable finding of Medium severity or higher will be fixed, covered by a regression test where practical, and recorded in the relevant
release notes or security advisory.

Evidence:
https://github.com/liesware/Vectis/security/code-scanning
https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
https://github.com/liesware/Vectis/blob/main/SECURITY.md
https://github.com/liesware/Vectis/blob/main/CHANGELOG.md

Vectis runs static source-code analysis on every commit that is proposed for or integrated into the main branch.

The CodeQL workflow is triggered by:

• every push to main;
• every pull request targeting main, including new commits pushed to that PR;
• a weekly scheduled scan as a fallback;
• manual workflow dispatch.

Therefore, each commit entering the supported development and release branch is analyzed without relying solely on the scheduled scan.

Evidence:
https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
https://github.com/liesware/Vectis/actions/workflows/codeql.yml

Vectis applies dynamic analysis to every change proposed for or integrated into the main branch.

The CI integration job starts a real Vectis server with generated keys and configuration, then runs project-specific HTTP mutation testing and
OpenAPI-based property testing with Schemathesis. These tools exercise live handlers, parsers, validation, authorization, cryptographic workflows, and
failure paths using generated and mutated inputs.

Vectis also runs its native cargo-fuzz targets weekly with sanitizer instrumentation and accumulated corpora. This workflow can be triggered manually before a major production release.

Not applicable. Vectis is implemented in Rust and does not include project-maintained production code written in a memory-unsafe language such as
C or C++.

Vectis interfaces with Botan through FFI, but Botan is an external dependency rather than memory-unsafe source code produced or maintained by the Vectis
project. Native fuzzing and sanitizer-based testing are nevertheless used to exercise Vectis input-processing boundaries.

Vectis runs its automated test suite using Rust's test profile. This profile enables debug assertions and integer overflow checks that are not enabled by
default in production release builds.

The test suite contains assertions covering validation, cryptographic round-trips, lifecycle rules, authorization, storage, audit-chain integrity,
and HTTP contracts. Native cargo-fuzz targets add explicit semantic assertions for properties such as canonical serialization, stable encoding, sanitized
errors, and parser round-trips.

These assertion-enabled test and fuzz configurations are separate from the production release profile.

Not applicable at present. Vectis has no outstanding confirmed exploitable vulnerabilities of Medium or higher severity discovered through dynamic
analysis.

Findings produced by fuzzing and dynamic API testing are investigated before being dismissed. Confirmed defects are fixed, added to the regression test
suite, and preserved as readable fuzz seeds when applicable.

A recent canonical JSON fuzzing finding was corrected with centralized input validation, unit and HTTP regression tests, and a permanent cargo-fuzz seed. It was not formally classified as a Medium-or-higher vulnerability.