Aegis-BPF

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.

AegisBPF uses a public Git repository where interim versions are available as commits and pull requests between releases. The repository does not publish only final release snapshots. Commits and PRs can be reviewed publicly before or between tagged releases.

Repository: https://github.com/ErenAri/Aegis-BPF
Commits: https://github.com/ErenAri/Aegis-BPF/commits/main
Pull requests: https://github.com/ErenAri/Aegis-BPF/pulls

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

AegisBPF uses unique version identifiers for user-facing releases through Git tags and GitHub Releases, such as v0.5.1, v0.5.0, v0.4.1, v0.4.0, v0.3.0, v0.2.x, and v0.1.1.

Releases: https://github.com/ErenAri/Aegis-BPF/releases
Tags: https://github.com/ErenAri/Aegis-BPF/tags

AegisBPF identifies releases using Git tags in the public repository. Each release tag points to a specific version-controlled commit.

Tags: https://github.com/ErenAri/Aegis-BPF/tags

AegisBPF provides human-readable release notes through GitHub Releases. The release notes summarize major changes, upgrade notes, release integrity details, documentation changes, and security-related fixes.

Releases: https://github.com/ErenAri/Aegis-BPF/releases
Example: https://github.com/ErenAri/Aegis-BPF/releases/tag/v0.5.1

N/A — no fixed run-time vulnerability with a CVE assignment or similar public vulnerability identifier was known for the current release notes requirement. Security-related fixes are documented in release notes when applicable, including the v0.1.1 security fix.

AegisBPF provides a public bug reporting process through GitHub Issues. Users can submit bug reports through the issue tracker, and the repository provides a dedicated bug report template that asks for summary, reproduction steps, environment details, and relevant logs. URL: https://github.com/ErenAri/Aegis-BPF/issues

AegisBPF uses GitHub Issues as its public issue tracker: https://github.com/ErenAri/Aegis-BPF/issues

No public bug reports were submitted in the last 2-12 months through the public issue tracker. AegisBPF accepts bug reports through GitHub Issues and provides a dedicated bug report template for public bug intake.

AegisBPF tracks enhancement requests through GitHub Issues and has maintainer acknowledgement on the open enhancement requests submitted in the last 2-12 months. See issues #54 and #55: https://github.com/ErenAri/Aegis-BPF/issues

AegisBPF uses GitHub Issues as a publicly available, searchable archive for reports and responses: https://github.com/ErenAri/Aegis-BPF/issues

AegisBPF publishes its vulnerability reporting process in its Security Policy: https://github.com/ErenAri/Aegis-BPF/security/policy

AegisBPF supports private vulnerability reporting through GitHub Security Advisories. The Security Policy instructs reporters to open the Security tab, go to Advisories, and click “Report a vulnerability.” URL: https://github.com/ErenAri/Aegis-BPF/security/policy

No external vulnerability reports were received in the last 6 months.

Non-trivial build file in repository: https://github.com/ErenAri/Aegis-BPF/blob/main/CMakeLists.txt.

Non-trivial build file in repository: https://github.com/ErenAri/Aegis-BPF/blob/main/CMakeLists.txt.

AegisBPF is buildable using FLOSS tools. The documented build uses CMake, Ninja, Clang/LLVM, libbpf, pkg-config, GoogleTest, and standard Linux tooling. The repository also provides CI builds using the same open-source toolchain.

Build file: https://github.com/ErenAri/Aegis-BPF/blob/main/CMakeLists.txt
CI: https://github.com/ErenAri/Aegis-BPF/blob/main/.github/workflows/ci.yml

AegisBPF provides an automated test suite using CTest and GoogleTest. The CMake build enables testing, defines test sources, builds the aegisbpf_test target, discovers GoogleTest tests, and also includes Python/contract tests and CLI regression tests.

Tests: https://github.com/ErenAri/Aegis-BPF/tree/main/tests
Build file: https://github.com/ErenAri/Aegis-BPF/blob/main/CMakeLists.txt

The test suite can be invoked through the standard CTest interface:

cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTING=ON
cmake --build build
ctest --test-dir build --output-on-failure

These commands are documented in CONTRIBUTING.md and used in CI.

AegisBPF has broad automated test coverage across unit tests, policy parsing, crypto safety, kernel feature detection, network handling, event formatting, metrics, tracing, BPF integrity, capability checks, CLI regression tests, schema validation, upgrade compatibility, failure-mode contracts, and runbook/operational contract tests. CI also enforces coverage thresholds and a coverage ratchet policy.

AegisBPF implements continuous integration through GitHub Actions. The CI workflow builds the project, runs CTest, runs sanitizer jobs, generates coverage reports, runs lint/static-analysis checks, runs fuzz smoke tests, and validates project contracts.

AegisBPF has a contribution policy requiring behavior changes to include tests. CONTRIBUTING.md states that pull requests should include tests for behavior changes and keep changes small, tested, and reviewable.

Recent major changes include corresponding automated tests. For example, the v0.1.1 security fix added crypto safety tests and updated the build/test configuration to include them. The repository also enforces automated tests through CTest and CI.

The policy for adding tests is documented in CONTRIBUTING.md under pull request expectations. It states that behavior changes should include tests, and the development setup documents how contributors run the test suite locally.

AegisBPF enables compiler warning flags and static-analysis tooling. CMake enables -Wall and -Wextra for C++ builds, Release/RelWithDebInfo builds use -Werror, and CI runs clang-format, cppcheck, clang-tidy, and related quality checks.

Warnings and static-analysis findings are addressed through the enforced build and CI checks. Release builds treat compiler warnings as errors, and CI fails on clang-format/cppcheck errors. This prevents known warnings and static-analysis findings from being ignored.

AegisBPF uses strict warning and analysis settings where practical: -Wall, -Wextra, -Werror for release builds, cppcheck --enable=all with error-exitcode, clang-format --Werror, clang-tidy on changed C++ files, sanitizers, fuzzing, and CI quality gates.

The primary maintainer has designed and documented AegisBPF as a security-focused runtime enforcement project. The repository includes a Security Policy, threat model boundaries, security hardening guidance, private vulnerability reporting, seccomp hardening, policy/signature verification, and secure code review expectations.

Security policy: https://github.com/ErenAri/Aegis-BPF/blob/main/SECURITY.md
Contributing/security checklist: https://github.com/ErenAri/Aegis-BPF/blob/main/CONTRIBUTING.md

The project documents and addresses common vulnerability classes relevant to this software, including malformed input handling, unsafe parsing, resource exhaustion, excessive privileges, insecure logging, timing-sensitive comparisons, and cryptographic verification failures. CONTRIBUTING.md includes a security review checklist, and the project has already fixed and tested a critical TweetNaCl memory exhaustion vulnerability.

AegisBPF uses publicly known cryptographic primitives for policy integrity and authenticity: SHA-256 hashing and Ed25519/TweetNaCl signatures. It does not use a private or proprietary cryptographic algorithm.

AegisBPF uses TweetNaCl for Ed25519 signature operations, but the repository also includes an internal SHA-256 implementation. This should be replaced with a maintained FLOSS cryptographic library implementation, or documented as a vetted imported implementation, before this criterion is marked as met.

All cryptographic functionality used by AegisBPF is implemented using FLOSS code available in the public repository, including TweetNaCl-based signature operations, SHA-256 policy integrity checks, and the project’s safe crypto wrappers.

AegisBPF uses Ed25519 signatures for policy signing and verification. Ed25519 provides approximately a 128-bit security level, and the project does not provide weaker configurable key sizes for this mechanism.

AegisBPF’s default cryptographic mechanisms do not depend on broken algorithms such as MD4, MD5, single DES, RC4, Dual_EC_DRBG, or inappropriate weak cipher modes. The project uses SHA-256 for integrity and Ed25519/TweetNaCl signatures for authenticity.

AegisBPF does not use SHA-1, CBC-mode SSH, RC4, MD5, DES, or similar weak cryptographic mechanisms for its default security mechanisms. It uses SHA-256 and Ed25519/TweetNaCl signatures for policy integrity and authenticity.

AegisBPF does not implement a session key agreement protocol. Its cryptographic use is limited to policy integrity, policy signing, signature verification, and local key-based authorization mechanisms.

AegisBPF does not store external user passwords for authentication.

AegisBPF’s TweetNaCl key generation path obtains random bytes from /dev/urandom for key generation. It does not use rand(), random(), or another non-cryptographic PRNG for key generation.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

AegisBPF does not retrieve cryptographic hashes over plain HTTP for trust decisions. Public source and release delivery use GitHub over HTTPS, and policy bundle integrity is verified with SHA-256 plus Ed25519 signature verification rather than trusting an unsigned hash retrieved over HTTP.

There are no publicly tracked open medium-or-higher security vulnerabilities known to be unpatched for more than 60 days. Public GitHub issue searches for open security/vulnerability issues currently show no results, and the previously documented critical TweetNaCl memory exhaustion issue was fixed in v0.1.1.

AegisBPF fixed the documented critical TweetNaCl memory exhaustion vulnerability in release v0.1.1. The release notes state that the vulnerability was fixed, tested, documented, and verified.

No valid private credentials are intentionally stored in the public repository. A local secret scan was run against the repository and did not identify valid private credentials intended to limit public access.

AegisBPF applies static analysis through CI before release and on repository changes. The project uses cppcheck, clang-tidy, Semgrep, and CodeQL as part of its quality/security gates.

Quality gates: https://github.com/ErenAri/Aegis-BPF/blob/main/docs/QUALITY_GATES.md
Security workflow: https://github.com/ErenAri/Aegis-BPF/blob/main/.github/workflows/security.yml

AegisBPF uses security-oriented static analysis tools that look for common vulnerability patterns, including CodeQL for C/C++, Semgrep rules, cppcheck, and clang-tidy.

There are no confirmed, unfixed medium-or-higher severity exploitable vulnerabilities from static analysis currently tracked as open. Static-analysis and security findings are handled through CI gates, including CodeQL, Semgrep, cppcheck, clang-tidy, and dependency/security checks.

AegisBPF runs static analysis regularly through GitHub Actions. Static-analysis/security workflows run on pull requests, pushes to main/develop, scheduled runs, and manual workflow dispatch. Semgrep runs on changed code and full scans are scheduled.

AegisBPF applies dynamic analysis through sanitizers, fuzzing, smoke tests, and E2E enforcement tests before release. The project includes AddressSanitizer, UndefinedBehaviorSanitizer, ThreadSanitizer, libFuzzer/ClusterFuzzLite fuzzing, and BPF LSM E2E tests in CI.

AegisBPF includes C and C++ code, so it routinely uses memory-safety dynamic analysis. CI runs AddressSanitizer, UndefinedBehaviorSanitizer, and ThreadSanitizer builds, and the project also runs fuzzing through libFuzzer and ClusterFuzzLite.

AegisBPF supports debug, sanitizer, fuzzing, and test configurations for dynamic analysis. Release builds define NDEBUG, while debug/test/sanitizer configurations are used for CI testing and dynamic analysis. The build also enables libstdc++ assertion hardening where supported.

There are no confirmed, unfixed medium-or-higher severity exploitable vulnerabilities from dynamic analysis currently tracked as open. Sanitizer, fuzzing, and E2E failures are treated as CI quality/security issues and are expected to block or fail the relevant checks until fixed.