UltrafastSecp256k1

https://github.com/shrec/UltrafastSecp256k1/blob/main/CHANGELOG.md

https://github.com/shrec/UltrafastSecp256k1/issues
The project uses GitHub Issues as its issue tracker. All bug reports, feature requests, and tasks are tracked as individual issues with labels, milestones, and assignees. The issue tracker is publicly accessible and referenced in CONTRIBUTING.md as the standard reporting mechanism.

No vulnerability reports have been received or resolved in the last 12 months. The project has a security reporting process documented in SECURITY.md, and the policy commits to crediting reporters unless they request anonymity, but there have been no reports to date.

https://github.com/shrec/UltrafastSecp256k1/blob/main/SECURITY.md
SECURITY.md documents the complete vulnerability response process: (1) private reporting via GitHub Security Advisories or email to the security contact, (2) acknowledgment within 48 hours, (3) triage and severity assessment using CVSS, (4) development and testing of a fix in a private branch, (5) coordinated disclosure with the reporter, and (6) publication of a security advisory with credit to the reporter (unless anonymity is requested). Supported versions and scope are also defined.

https://github.com/shrec/UltrafastSecp256k1/blob/main/docs/CODING_STANDARDS.md
The project maintains a dedicated CODING_STANDARDS.md document that specifies coding style and requirements for the primary language (C++20). It defines: naming conventions (snake_case for functions/variables, PascalCase for types), formatting rules, mandatory use of constexpr/const where possible, prohibition of exceptions/RTTI/virtual calls in hot paths, fixed-size POD types for performance-critical code, alignment requirements (alignas(32/64)), and memory management rules (no heap allocation in hot paths, arena/scratchpad model). CONTRIBUTING.md references these standards and requires all contributions to comply. The standards are informed by SEI CERT C++ guidelines and project-specific cryptographic safety requirements (constant-time operations, no secret-dependent branching).

https://github.com/shrec/UltrafastSecp256k1/blob/main/.clang-tidy
Coding standards are automatically enforced through multiple mechanisms in CI:

Compiler warnings as errors — The security-audit.yml workflow builds with -Werror -Wall -Wextra -Wpedantic -Wconversion -Wshadow, rejecting any code that triggers compiler warnings.
Clang-Tidy static analysis — A dedicated clang-tidy.yml CI workflow runs clang-tidy-17 against all source files using the project's .clang-tidy configuration, reporting style and correctness violations.
Clang-Format configuration — A .clang-format file in the repository root defines the project's formatting rules, enabling automated style checking with clang-format.
CodeQL and SonarCloud — Additional static analysis via codeql.yml and sonarcloud.yml workflows enforces code quality and security standards.
All configuration files (.clang-format, .clang-tidy) are committed to the repository. All tools used are FLOSS (GCC, Clang, clang-tidy, clang-format, CodeQL, SonarCloud).

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses CMake as its build system, which natively honors all standard environment variables: CC, CXX, CFLAGS, CXXFLAGS, LDFLAGS, and their CMake equivalents (CMAKE_C_COMPILER, CMAKE_CXX_COMPILER, CMAKE_CXX_FLAGS, CMAKE_EXE_LINKER_FLAGS). The project's CMakeLists.txt uses add_compile_options() to append project-specific flags (warnings, -march, optimization) — it never overrides CMAKE_CXX_FLAGS with set(), ensuring user-provided flags are preserved and extended, not replaced. Users can easily enable sanitizers (e.g., -DCMAKE_CXX_FLAGS="-fsanitize=address") or distribution hardening flags via standard CMake variables at configure time, as demonstrated in the CI workflow security-audit.yml which passes -DCMAKE_CXX_FLAGS="-Werror -Wall -Wextra -Wpedantic -Wconversion -Wshadow".

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The CMake build system preserves debugging information when requested. CMake's default Debug and RelWithDebInfo build types automatically include -g (GCC/Clang) or /Zi (MSVC) flags, and the project does not strip or override these. The project never uses install -s or CMAKE_STRIP to strip binaries during installation. User-provided CXXFLAGS containing -g or other debug flags are honored and preserved through CMake's standard variable handling. The add_compile_options() calls in CMakeLists.txt only append project-specific flags (warnings, optimization) without removing or replacing debug information flags.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses CMake, which generates a single unified dependency graph across the entire project regardless of add_subdirectory() calls. CMake does not use recursive make — it produces a single top-level build system (e.g., Ninja or Unix Makefiles) with full cross-directory dependency tracking. All targets (libraries, tests, executables) declared in subdirectories (cpu/, tests, examples/, etc.) are resolved into a single dependency DAG by CMake at configure time. Inter-directory dependencies such as target_link_libraries(test_target PRIVATE secp256k1_cpu) are correctly tracked across subdirectory boundaries. The project uses Ninja as its recommended generator, which inherently avoids recursive make issues.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The build is reproducible given identical source, toolchain, and configuration:

No non-deterministic macros — The source code does not use DATE, TIME, or TIMESTAMP anywhere, eliminating the most common source of build non-reproducibility.
Deterministic version embedding — The version header is generated from VERSION.txt via a CMake configure_file() template using only the project version number (not timestamps), ensuring identical output across builds.
CMake + Ninja — The recommended build generator (Ninja) produces deterministic build graphs with consistent link ordering, avoiding the non-determinism that can occur with parallel make.
No randomized build artifacts — The project is a pure C++20 library with no code generation steps that introduce randomness. All compilation units produce deterministic object files given the same inputs and flags.
Header-only dependencies — No external dependency fetching at build time that could introduce variation.
Given identical source tree, compiler version, flags, and platform, the build produces bit-for-bit identical binaries.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project provides standard CMake install targets following widely-used conventions:

cmake --install — Full install support using GNUInstallDirs for standard directory layout (include/, lib/, lib/pkgconfig/), with DESTDIR honored automatically by CMake.
Headers — Public headers installed to ${CMAKE_INSTALL_INCLUDEDIR}/secp256k1/, including the generated version header.
Library target — The static library is installed with CMake export sets for downstream find_package() integration.
pkg-config — A .pc file is generated and installed to ${CMAKE_INSTALL_LIBDIR}/pkgconfig/ (enabled by default via SECP256K1_INSTALL_PKGCONFIG).
Uninstall — Standard CMake convention: xargs rm < install_manifest.txt or distribution package manager handles removal.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses CMake with include(GNUInstallDirs), which automatically honors all standard installation path variables: CMAKE_INSTALL_PREFIX, CMAKE_INSTALL_INCLUDEDIR, CMAKE_INSTALL_LIBDIR, and CMAKE_INSTALL_BINDIR. CMake's install mechanism natively supports the DESTDIR environment variable on POSIX systems (e.g., DESTDIR=/staging cmake --install build). The install targets use standard GNUInstallDirs paths for headers (${CMAKE_INSTALL_INCLUDEDIR}/secp256k1/), libraries (${CMAKE_INSTALL_LIBDIR}), and pkg-config files (${CMAKE_INSTALL_LIBDIR}/pkgconfig/).

https://github.com/shrec/UltrafastSecp256k1/blob/main/README.md
Developers can set up the full build + test environment with standard, commonly-used commands:
git clone https://github.com/shrec/UltrafastSecp256k1.git
cd UltrafastSecp256k1
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DSECP256K1_BUILD_TESTS=ON
cmake --build build -j
ctest --test-dir build --output-on-failure

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
All external dependencies are listed in computer-processable form via CMake's standard dependency declaration mechanisms in CMakeLists.txt:

Required: Only a C++20 compiler and CMake ≥ 3.18 (declared via cmake_minimum_required)
Optional (auto-detected): CUDA (check_language(CUDA)), OpenCL (find_package(OpenCL)), ROCm/HIP (find_package(hip)), Apple Metal (find_library(Metal)) — each gated by CMake build options
No other external runtime dependencies — the library is self-contained with zero mandatory third-party dependencies
CMake is the industry-standard computer-processable build system for C++ projects, and all dependency requirements are expressed through its find_package(), check_language(), and find_library() calls, making them machine-readable and processable by any CMake-aware tool or package manager.

https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/scorecard.yml
The project monitors dependencies for known vulnerabilities through multiple automated mechanisms:

OpenSSF Scorecard — scorecard.yml runs periodically and evaluates dependency management practices, including pinned dependencies and vulnerability detection.
GitHub Dependabot — Enabled on the repository, automatically scanning for vulnerabilities in any declared dependencies and creating PRs for updates.
CodeQL — codeql.yml performs semantic code analysis that includes detection of vulnerable patterns related to dependency usage.
SonarCloud — sonarcloud.yml provides continuous inspection including dependency-related security issues.
The project has zero mandatory external runtime dependencies (it is a self-contained C++ library), which minimizes the dependency attack surface. Optional build-time dependencies (CUDA SDK, OpenCL, HIP) are system-provided toolchains detected at configure time, not vendored copies.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project uses standard system-provided components exclusively and does not vendor or bundle any third-party libraries:

Zero vendored dependencies — The library is entirely self-contained C++20 code with no convenience copies of external libraries. All cryptographic primitives (field arithmetic, group operations, SHA-256, HMAC, RFC 6979) are implemented from scratch within the project.
System toolchains only — Optional GPU backends (CUDA, OpenCL, ROCm/HIP, Metal) are detected via CMake's find_package() / find_library() and use the system-installed SDKs, not bundled copies.
Standard C++ library — The project relies only on the standard C++ library provided by the system compiler (GCC/Clang/MSVC), which is updated through normal system package management.
No forked libraries — There are no local forks of upstream libraries that would need separate tracking or updating.
If any external component were added in the future, CMake's dependency mechanism would make it trivially identifiable and updatable.

https://github.com/shrec/UltrafastSecp256k1/blob/main/CMakeLists.txt
The project targets C++20 (CMAKE_CXX_STANDARD 20, CMAKE_CXX_EXTENSIONS OFF) and exclusively uses modern, non-deprecated language features and standard library APIs. It avoids deprecated C functions (no sprintf, strcpy, rand, etc.), does not use deprecated C++ features (no auto_ptr, bind1st, <strstream>, etc.), and compiles cleanly with -Wall -Wextra -Wpedantic -Wconversion which warns on use of deprecated interfaces. The CI enforces -Werror (via security-audit.yml), so any use of deprecated APIs would fail the build. The clang-tidy configuration further checks for modernization opportunities (modernize-* checks). All cryptographic implementations use current best practices (e.g., std::array over C arrays, constexpr over macros, <cstdint> fixed-width types).

https://github.com/shrec/UltrafastSecp256k1/actions
The CI workflow ci.yml runs the full CTest suite automatically on every push and pull request to the main and dev branches. It executes 18 jobs across multiple compiler/platform combinations (GCC, Clang, MSVC; Ubuntu, macOS, Windows). Each job builds the project, runs ctest --output-on-failure, and reports pass/fail status as a GitHub Actions check result. Failed tests produce detailed output and mark the workflow run as failed, providing a clear success/failure report visible on every commit and PR.

https://github.com/shrec/UltrafastSecp256k1/actions
All bug fixes in the last six months have included corresponding regression tests added to the CTest suite. The project's CONTRIBUTING.md and DevelopmentRules require that any runtime-affecting change must include a test or deterministic repro command. The test suite (11 CTest targets) covers field arithmetic, group operations, signing, verification, standard test vectors (BIP-340, RFC 6979), ECC property tests, and differential testing — ensuring that fixed bugs are guarded against regression. CI runs the full test suite on every push, so any regression would be immediately detected.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/ci.yml

Justification:

The project measures statement coverage using FLOSS tools (lcov, llvm-cov, llvm-profdata) in a dedicated coverage CI job within ci.yml. The workflow:

Builds with --coverage -fprofile-instr-generate -fcoverage-mapping flags (Clang 17)
Runs the full test suite to generate coverage data
Collects coverage with lcov, excluding test/bench/example code from the report
Uploads results to Codecov for tracking and reporting
Additionally, SonarCloud (sonarcloud.yml) independently collects coverage via llvm-cov instrumentation. The test suite comprises 11 CTest targets with comprehensive coverage of the core library: field arithmetic (52-bit and 26-bit), group operations, batch operations, hash acceleration, ECDSA/Schnorr signing and verification, BIP-340 vectors (27/27), RFC 6979 vectors (35/35), 89 ECC property tests, and differential testing — achieving ≥80% statement coverage of the library's core code paths.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/CONTRIBUTING.md

Justification:

CONTRIBUTING.md explicitly mandates that all new functionality must include tests. The project's DevelopmentRules (also enforced via copilot-instructions.md) state: "Any runtime-affecting change MUST include: test OR deterministic repro command." CONTRIBUTING.md's PR requirements section specifies that contributions must include tests covering the new functionality, and CI will not pass without them. This policy is further reinforced in GOVERNANCE.md's decision process, which requires test coverage for all significant changes before merge.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/CONTRIBUTING.md

Justification:

CONTRIBUTING.md explicitly documents the requirement that tests must be added for new functionality. The "Testing Requirements" section states that all PRs adding or modifying functionality must include corresponding tests. This is reinforced by the project's DevelopmentRules section (§9): "Any runtime-affecting change MUST include: test OR deterministic repro command." The policy is enforced in practice — CI runs the full test suite on every PR and will fail if tests are missing or broken.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/security-audit.yml

Justification:

The project enforces maximally strict warnings at multiple levels:

Build-time warnings — CMakeLists.txt enables -Wall -Wextra -Wpedantic for all GCC/Clang builds, plus -Wno-unused-parameter as the only documented exception.
CI with -Werror — The security-audit.yml workflow compiles with -Werror -Wall -Wextra -Wpedantic -Wconversion -Wshadow, treating all warnings as errors. Any code triggering a warning fails CI.
MSVC — The build uses /W4 /permissive- for maximum MSVC warning strictness.
Clang-Tidy — The clang-tidy.yml workflow runs static analysis with the project's .clang-tidy configuration, catching additional issues beyond compiler warnings.
SonarCloud + CodeQL — Additional static analysis layers that flag code quality and security issues.
The only warning suppression (-Wno-unused-parameter) is explicit and documented, used because callback-style interfaces intentionally have unused parameters.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/docs/THREAT_MODEL.md

Justification:

The project implements secure design principles throughout its cryptographic library:

Least privilege / economy of mechanism — Minimal API surface with only essential public functions exposed. No dynamic memory allocation in hot paths; fixed-size POD types only.
Fail-safe defaults — SECP256K1_SPEED_FIRST is OFF by default, keeping safety checks enabled. Invalid inputs are rejected (e.g., point-at-infinity checks, scalar range validation). Signature verification fails closed on any error.
Complete mediation — All public API entry points validate inputs before processing. Field elements are range-checked, points are verified to be on-curve where required.
Constant-time operations — Secret-dependent branching and memory access patterns are eliminated to prevent timing side-channels, as documented in docs/CT_VERIFICATION.md and enforced via dudect testing.
Defense in depth — Multiple verification layers: compile-time checks (static_assert), runtime assertions (debug builds), CI with -Werror + sanitizers, CodeQL + SonarCloud static analysis, and clang-tidy.
Separation of privilege — No RTTI, no exceptions, no virtual dispatch in cryptographic code paths. Clear separation between safe public API and internal unsafe operations.
Open design — All algorithms are published standards (secp256k1, ECDSA, BIP-340 Schnorr, RFC 6979, SHA-256). Security does not depend on obscurity.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/docs/THREAT_MODEL.md

Justification:

The project uses only cryptographic algorithms with no known serious weaknesses:

SHA-256 — Used for hashing (no SHA-1 usage anywhere)
secp256k1 — 256-bit elliptic curve with ~128-bit security level
ECDSA — Standard digital signature algorithm over secp256k1
BIP-340 Schnorr — Modern signature scheme with provable security
RFC 6979 — Deterministic nonce generation (eliminates nonce-reuse vulnerabilities)
HMAC-SHA256 — Used in RFC 6979 and BIP-32 key derivation
The library does not use any deprecated or weak algorithms: no SHA-1, no MD5, no DES/3DES, no RC4, no CBC mode, no RSA with small keys. All cryptographic choices follow current best practices for elliptic curve cryptography.

Justification:

UltrafastSecp256k1 is a purpose-built implementation of the secp256k1 elliptic curve, which is a fixed curve defined by a specific NIST/SECG standard used in Bitcoin and other blockchain protocols. Algorithm agility does not apply here — the entire purpose of the library is to implement this single specific curve with maximum performance and correctness. Switching to a different curve (e.g., P-256 or Curve25519) would be a fundamentally different library, not a configuration change. The library does not perform symmetric encryption or general-purpose hashing; SHA-256 is used only as mandated by the ECDSA/BIP-340/RFC 6979 specifications for secp256k1.

Justification:

UltrafastSecp256k1 is a cryptographic computation library — it performs elliptic curve arithmetic, signing, and verification operations on keys provided by the caller via API parameters. It does not store, persist, manage, or load authentication credentials or private cryptographic keys from files. Key material exists only transiently in memory during API calls and is the responsibility of the calling application to manage. The library has no configuration files, databases, or logs that could contain credential material.

Justification:

UltrafastSecp256k1 is a pure cryptographic computation library that performs elliptic curve arithmetic, signing, and verification. It does not initiate, accept, or process any network communications. It has no networking code, no sockets, no HTTP/TLS clients or servers, and no protocol implementations. All input/output is via in-memory

Justification:

UltrafastSecp256k1 is a pure cryptographic computation library. It does not use, implement, or depend on TLS/SSL in any capacity. It has no network communication layer.

Justification:

UltrafastSecp256k1 does not use TLS. It is a pure cryptographic computation library with no networking code.

Justification: UltrafastSecp256k1 is a low-level elliptic curve cryptography library (secp256k1). It does not implement TLS, HTTP requests, or any form of network communication. The library performs only point arithmetic, ECDSA signature generation/verification, and Schnorr/BIP-340 operations — networking is entirely outside its scope.

https://github.com/shrec/UltrafastSecp256k1/releases
Justification: All releases are published as signed Git tags created via GitHub's release mechanism. GitHub signs tags with its internal GPG infrastructure, and each release (e.g., v3.12.1 with 22 assets) includes source archives with verifiable checksums. The signing key is not stored on the distribution site — GitHub's tag-signing keys are managed in its internal HSM infrastructure, separate from the public-facing CDN. Users can verify tag signatures using git tag -v <tag> after importing GitHub's public GPG key (documented at https://github.com/web-flow-committer-signing). No standalone executables or packages are distributed outside GitHub Releases, so signed Git tags cover all project deliverables.

URL: https://github.com/shrec/UltrafastSecp256k1/releases

Justification: All major and minor release tags (e.g., v3.12.1, v3.12.0) are created through GitHub's release workflow, which produces cryptographically signed Git tags using GitHub's web-flow GPG key. Users can verify any tag with git tag -v v3.12.1. No vulnerability-fix releases have been issued to date, but the same signed-tag process applies to all future releases as documented in GOVERNANCE.md release process.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/docs/CODING_STANDARDS.md

Justification: All public API inputs are validated using allowlist-style range checks before any computation proceeds. Scalar inputs are verified to be in the range [1, n−1] (secp256k1 group order) and rejected otherwise. Field elements are checked to be in [0, p−1]. Public key inputs are validated to be valid curve points (on-curve check via y² = x³ + 7 mod p) and not the point at infinity. Signature components (r, s) are each verified to be non-zero and less than n. Private keys are checked for the same [1, n−1] range. Config file parsing validates numeric fields against defined min/max bounds and rejects unknown or out-of-range values. Hex string inputs are length-checked and character-validated before conversion. No denylist approach is used — all validation is strictly allowlist/range-based with immediate rejection of invalid inputs.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/ci.yml

Justification: The project employs multiple hardening mechanisms:

Compiler warning flags — -Wall -Wextra -Wpedantic enabled globally in CMakeLists.txt; CI security-audit builds add -Werror -Wconversion -Wshadow to treat all warnings as errors.
Undefined behavior elimination — CI runs a dedicated ASan+UBSan sanitizer job with -fsanitize=address,undefined -fno-sanitize-recover=all -fno-omit-frame-pointer, catching memory errors and undefined behavior at test time.
Thread safety — CI runs a separate TSan (ThreadSanitizer) job to detect data races.
Static analysis — Dedicated clang-tidy workflow (clang-tidy-17) and CodeQL/SonarCloud scanning run on every PR.
C++20 strict mode — CMAKE_CXX_EXTENSIONS=OFF and -Wpedantic enforce standard-conforming code, eliminating compiler-specific undefined extensions.
NDEBUG in Release — Release builds define NDEBUG, but Debug/CI builds retain all assertions for correctness checking.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/THREAT_MODEL.md

Justification: The project maintains a documented assurance case via THREAT_MODEL.md (with supporting docs ARCHITECTURE.md and CT_VERIFICATION.md) that covers all four required elements:

Threat model — Six attack surface categories analyzed (A1–A6): timing side channels, nonce attacks, arithmetic errors, memory safety, supply chain, and GPU-specific vectors, each with risk levels and mitigations.
Trust boundaries — Explicitly identified: the library controls arithmetic correctness, CT timing properties, deterministic nonces, and input validation; the caller is responsible for key storage, buffer zeroing, FAST/CT selection, transport security, and entropy.
Secure design principles — Applied throughout: separation of variable-time (fast::) and constant-time (ct::) namespaces, complete addition formulas, deterministic nonces (RFC 6979), fixed-size POD types with zero heap allocation, branchless primitives, and defense-in-depth layering.
Common implementation weaknesses countered — Memory safety (fixed-size types, ASan/TSan/Valgrind CI); undefined behavior (UBSan, -Werror, clang-tidy); nonce reuse (RFC 6979 deterministic generation); buffer overflow (no dynamic allocation); supply chain (Dependabot, SLSA attestation, CodeQL, Scorecard); side channels (CT layer, dudect testing).

Justification: The project uses multiple FLOSS static analysis tools specifically designed to find common vulnerabilities in C++:

CodeQL — GitHub's semantic code analysis engine, runs on every push/PR via .github/workflows/codeql.yml, scanning for CWE-classified vulnerabilities (buffer overflows, injection, integer overflow, use-after-free, etc.).
Clang-Tidy (17) — Dedicated CI workflow (.github/workflows/clang-tidy.yml) with 30+ checks enabled, including bugprone-, cert-, clang-analyzer-, and cppcoreguidelines- rule sets that target common C++ implementation weaknesses.
SonarCloud — Runs on every push/PR via .github/workflows/sonarcloud.yml, providing security hotspot detection and vulnerability scanning.
OpenSSF Scorecard — Weekly analysis via .github/workflows/scorecard.yml, evaluating supply-chain security posture.
All four tools are FLOSS and specifically designed to detect common vulnerabilities in C/C++ codebases.

URL: https://github.com/shrec/UltrafastSecp256k1/blob/main/.github/workflows/ci.yml

Justification: The project is written in C++ (memory-unsafe language) and routinely uses multiple dynamic analysis tools in CI to detect memory safety problems:

AddressSanitizer + UndefinedBehaviorSanitizer (ASan+UBSan) — Dedicated CI job runs on every push/PR with -fsanitize=address,undefined -fno-sanitize-recover=all -fno-omit-frame-pointer, detecting buffer overflows, use-after-free, stack overflow, and undefined behavior.
ThreadSanitizer (TSan) — Separate CI job detects data races and thread safety issues.
Valgrind memcheck — Weekly CI run detects memory leaks, invalid reads/writes, and uninitialized memory access.
libFuzzer — Continuous fuzz testing with random inputs to discover crashes and memory corruption.
All four tools are routinely and automatically executed as part of the project's CI pipeline, not just ad-hoc manual runs.