Skip to content

Latest commit

 

History

History
213 lines (140 loc) · 4.26 KB

File metadata and controls

213 lines (140 loc) · 4.26 KB

Vix.cpp — Security Testing Guide

This document describes how to audit, test, and validate the security properties of Vix.cpp. It is primarily intended for maintainers and core contributors.

The goal is to ensure that every release of Vix.cpp remains safe, robust, and predictable under real-world conditions.


Overview

Security in Vix.cpp is based on defensive engineering practices, not on custom or opaque security layers.

The project relies on:

  • Modern C++ memory safety patterns (RAII, clear ownership)
  • Compiler-based runtime checks (sanitizers)
  • Static analysis tools
  • Careful validation of external inputs
  • Continuous testing and review

There is no custom security framework inside Vix.cpp.
All security testing relies on standard, well-known tooling.


1. Runtime Sanitizer Testing

Sanitizers are the primary security signal during development.

Supported Sanitizers

  • AddressSanitizer (ASan)
  • UndefinedBehaviorSanitizer (UBSan)
  • ThreadSanitizer (TSan, when applicable)

Build with Sanitizers

cmake -S . -B build-san \
  -DCMAKE_BUILD_TYPE=Debug \
  -DVIX_ENABLE_SANITIZERS=ON
cmake --build build-san -j

Run the CLI or examples:

cd build-san
./vix --help

Any sanitizer finding must be treated as a blocking error.


2. CLI & Script Mode Validation

The Vix CLI is part of the attack surface and must be tested accordingly.

Recommended checks:

vix check .
vix check main.cpp
vix run main.cpp --san
vix tests

Verify that:

  • Invalid inputs do not crash the CLI
  • Errors are reported clearly
  • Exit codes are consistent
  • No undefined behavior occurs under sanitizers

3. Static Analysis

Static analysis complements runtime checks.

clang-tidy

cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
clang-tidy -p build $(find . -name '*.cpp')

Focus areas:

  • Undefined behavior warnings
  • Lifetime and ownership issues
  • Dangerous casts and conversions

cppcheck

cppcheck --enable=all --std=c++20 --inconclusive --quiet .

4. Fuzz Testing (Advanced)

Fuzz testing is optional but recommended for parsers and protocol boundaries.

Vix.cpp does not provide built-in fuzz targets. Contributors may create standalone fuzz harnesses using LLVM libFuzzer.

Example structure:

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
    // Feed arbitrary input into parsing or decoding logic
    // Ensure no crashes, UB, or infinite loops
    return 0;
}

Build and run:

clang++ -fsanitize=fuzzer,address,undefined fuzz_target.cpp -o fuzz_target
./fuzz_target

Any crash or sanitizer report is considered a security defect.


5. Unit Tests & Regression Coverage

All security-related fixes must include regression tests.

Guidelines:

  • Tests must fail before the fix
  • Tests must pass after the fix
  • Prefer minimal reproductions

Run the test suite:

ctest --output-on-failure

6. Compiler Hardening Flags (Release Builds)

Release builds should enable standard hardening flags.

Recommended flags:

-fstack-protector-strong
-D_FORTIFY_SOURCE=2
-fno-omit-frame-pointer

Example:

cmake -S . -B build-rel \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CXX_FLAGS="-fstack-protector-strong -D_FORTIFY_SOURCE=2"

7. Valgrind (Optional)

Valgrind can be used as a secondary memory diagnostic tool:

valgrind --leak-check=full ./build-rel/vix

Expected result:

  • No invalid reads or writes
  • No definitely lost memory

8. Recommended Testing Frequency

Test Type Recommended Frequency
Unit tests Every commit / PR
Sanitizers Before every release
Static analysis Regularly or via CI
Fuzz testing Before large refactors
Valgrind Optional, targeted checks

Summary

Security in Vix.cpp is ensured through:

  • Compiler-based runtime checks
  • Strict testing discipline
  • Standard and transparent tooling
  • Clear failure semantics

Every release must pass sanitizers, tests, and static analysis before being considered stable.


Maintained by the Vix.cpp maintainers
Contact: gaspardkirira@outlook.com