CogZ

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.

The repository contains the complete granular commit history between releases (every feature, fix, and merge is an individual public commit, not squashed release snapshots). Reviewers can inspect any interim state. https://github.com/balaianu/CogZ/commits/master

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

Each release has a unique semver identifier: git tags (v0. 5. 4, v0. 5. 5) mapped to GitHub Releases, with the version embedded in the binary via Cargo.toml (cogz --version reports it). https://github.com/balaianu/CogZ/releases

Every release is marked with a git tag matching the version (v0. 5. 4, v0. 5. 5, etc.). https://github.com/balaianu/CogZ/tags

Each GitHub release carries human-readable notes summarizing the release's purpose and user-visible changes (e.g., v0. 5. 5 lists the dependency refreshes and CI updates; v0. 5. 4 lists the security hardening and fuzz additions). Notes are written per release, not generated from git log. https://github.com/balaianu/CogZ/releases

The project has no publicly known vulnerabilities or CVEs in its own code. Dependency advisories (e.g., RUSTSEC notices in transitive deps) are tracked via cargo audit in CI and noted in release notes where relevant.

Non-trivial SECURITY[.md] file found file in repository: https://github.com/balaianu/CogZ/blob/master/SECURITY.md. [osps_do_02_01]

Public GitHub Issues tracker is the canonical issue tracker: bugs, features, and backlog items are filed, labeled, and closed there. https://github.com/balaianu/CogZ/issues

No bug reports have been submitted in the last 12 months (the tracker is public and monitored; reports will be acknowledged promptly).

No enhancement requests have been submitted in the last 12 months (public tracker is monitored; requests will receive a response).

All reports and responses are publicly archived and searchable at https://github.com/balaianu/CogZ/issues (closed issues included via the "is: closed" search filter).

SECURITY.md at the repo root documents the process: report via GitHub private vulnerability reporting (Security > Advisories > Report a vulnerability), what to include, and what to expect. https://github.com/balaianu/CogZ/blob/master/SECURITY.md

GitHub private vulnerability reporting is enabled on the repository, which keeps reports confidential between reporter and maintainer until disclosed. SECURITY.md documents this channel with the direct link: https://github.com/balaianu/CogZ/security/advisories/new. Full doc: https://github.com/balaianu/CogZ/blob/master/SECURITY.md

No vulnerability reports have been received in the last 6 months (private reporting via GitHub advisories is enabled and monitored).

cargo build --release rebuilds the full binary from source on a clean checkout (documented in CONTRIBUTING.md, exercised by CI on every push across Linux, macOS, and Windows). https://github.com/balaianu/CogZ/blob/master/CONTRIBUTING.md

Standard Cargo toolchain (the canonical Rust build system). No custom build scripts or exotic tooling required.

Builds with entirely FLOSS tools: Rust toolchain (rustc/cargo, MIT/Apache-2. 0) plus a C compiler (gcc/clang/MSVC) for the bundled SQLite. No proprietary tools required.

The test suite is part of the MIT-licensed repo itself (528+ unit tests plus integration suites, all runnable via cargo test, fully offline). Running it is documented in CONTRIBUTING.md and enforced by . github/workflows/ci.yml on every push.

cargo test — the canonical Rust test invocation. No custom harness or wrapper needed.

528+ unit and integration tests cover the core functional surface: frontmatter/entity file parsing and serialization, storage CRUD and schema migrations, FTS and hybrid search, graph expansion, context-pack assembly, all 15 MCP tools, lifecycle hooks, configuration parsing, and path sanitization. A cargo-fuzz suite exercises the file-format parsers and sanitizers with 5 targets. Branch coverage is not formally measured.

GitHub Actions CI runs on every push and PR: fmt check, clippy -D warnings, release build, full test suite, cargo audit, plus CodeQL analysis. See . github/workflows/ci.yml.

CONTRIBUTING.md states the policy: "Write tests alongside the implementation. Every non-trivial change needs tests" and points to docs/dev/testing.md for what each feature area must cover. CI enforces the suite passing.

The most recent fixes (v0. 5. 4) shipped with regression tests: the two fuzz-discovered bugs (frontmatter control-character serialization, unbounded sanitize_category) each landed with dedicated tests (frontmatter_tests.rs, entities_tests.rs), and the rmcp/tree-sitter upgrade fixes were verified against the full suite. Commits 65683a3 and 3dab215 on master show tests accompanying the changes.

The test policy is stated directly in CONTRIBUTING.md ("Proposing changes" section, step 3: "Write tests alongside the implementation. Every non-trivial change needs tests").

CI runs cargo clippy -- -D warnings (all warnings deny-promoted to errors) plus cargo fmt --check on every push and PR. rustc's own warning set is also enabled by default.

Warnings are promoted to errors by -D warnings in CI, so they cannot be ignored — any warning fails the build and must be fixed. The codebase currently compiles warning-free.

Maximal strictness is already the policy: cargo clippy --all-targets -- -D warnings denies every warning across lib, bins, and tests. There are no #[allow] escape hatches beyond a couple of targeted, justified suppressions.

I (the primary developer) demonstrate secure-software knowledge through the codebase itself: parameterized SQL throughout (no string-built queries), path sanitization with traversal protection, deny-by-default warning policy, a fuzz suite targeting all input parsers (which caught real input-validation bugs), minimal CI token permissions, SHA-pinned actions, dependency auditing via cargo audit, and explicit handling of dangerous inputs (TOML/JSON from untrusted agent contexts).

Demonstrated in the codebase: SQL injection mitigated by parameterized queries everywhere; path traversal mitigated by slug/category sanitizers with length bounds; memory-safety errors mitigated by Rust plus deny-warnings clippy; malformed-input crashes mitigated by a libfuzzer suite over every file-format parser; supply-chain risk mitigated by pinned dependencies, cargo audit, and SHA-pinned actions.

All cryptography is delegated to rustls (audited, widely reviewed TLS implementation using ring/aws-lc for primitives): standard TLS 1. 2/1. 3 with default certificate verification. No custom protocols, no homegrown algorithms. The only network path is the optional HTTPS model download via hf-hub.

No cryptographic functions are implemented in the project. All crypto is delegated to rustls/ring (purpose-built, audited libraries); the codebase contains no custom ciphers, hashes-for-security, or key handling.

rustls and its crypto backends (ring / aws-lc-rs) are FLOSS (MIT/Apache-2. 0/ISC). No proprietary crypto dependency anywhere in the chain.

CogZ never configures keylengths itself; all crypto parameters come from rustls defaults, which only offer TLS 1. 2/1. 3 suites at 128-bit security or higher (exceeding the NIST 2030 112-bit minimum). Smaller keylengths cannot be enabled at all, which satisfies the disableability requirement by construction.

No broken algorithms are reachable: rustls only exposes TLS 1. 2/1. 3 AEAD suites (AES-GCM, ChaCha20-Poly1305); MD4/MD5/DES/RC4 cannot be negotiated. The only non-TLS hashing in the project (SHA-256 checksums, content-addressing) uses a non-broken algorithm, and it is not used as a security boundary anyway.

All hash use is SHA-256 (release checksums, content addressing) or stronger; TLS is restricted to AEAD suites (AES-GCM/ChaCha20-Poly1305) — no SHA-1, no CBC, no ECB anywhere in a security role.

PFS is guaranteed by construction: rustls only supports ephemeral key exchange (ECDHE) — TLS 1. 3 mandates it, and rustls offers no static-RSA key-exchange suites even for TLS 1. 2. Session keys cannot be recovered from compromised long-term keys.

The software stores no passwords and has no user authentication — it is a local CLI/MCP tool with no external users or credential store.

The project generates no cryptographic keys or nonces itself. All key material for the TLS path is produced inside rustls/ring, which uses the OS CSPRNG (getrandom/BCryptGenRandom). The only RNG the project calls directly is for UUID v4 entity identifiers, which are identifiers, not security tokens — and even those come from a CSPRNG.

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Nothing is retrieved over plain HTTP anywhere in the project; the only fetch path is hf-hub (HTTPS, TLS-verified). Model files are content-addressed — hf-hub resolves them via SHA-256 LFS pointers, so integrity is checked by construction rather than by comparing a fetched hash.

cargo audit runs in CI on every push. All medium+ advisories in the dependency tree have been patched (rustls and git2 were updated to fixed releases). The only remaining advisories are unmaintained-crate informational notices in transitive dependencies (paste via tokenizers), which carry no demonstrated vulnerability. None known >60 days at medium+.

No critical vulnerabilities in project code have been reported to date. When dependency advisories surfaced via Scorecard (rustls, git2), they were patched the same day they were detected; cargo audit now catches new ones at push time.

The repository contains no credentials: it is a local-first tool that takes no API keys, tokens, or secrets in config (optional HF downloads need no auth). The tree has been audited for leaked secrets; agent/harness config written by cogz configure contains only paths, never credentials.

Two layers beyond rustc warnings: cargo clippy -- -D warnings (dedicated linter) runs on every push and PR, and CodeQL semantic analysis runs on every push to master via . github/workflows/codeql.yml — both FLOSS, both applied before every release since v0. 5. 4.

CodeQL runs its standard query suite, which includes security queries for Rust (dangerous patterns, injection, resource handling). clippy's correctness/suspicious lint groups catch common Rust bug classes, and cargo audit covers known-vulnerability scanning in dependencies — a layered defense rather than a single tool.

No confirmed medium+ static-analysis findings are outstanding: CodeQL reports zero alerts on master, and clippy warnings are denied at CI so any finding is fixed before merge rather than accumulating. The two real bugs found by analysis-grade tooling (the fuzz suite) were fixed with regression tests in the same release cycle they were discovered.

clippy -D warnings runs on every push and PR; CodeQL runs on every push to master; cargo audit runs on every push. Per-commit coverage, not periodic.

The cargo-fuzz/libfuzzer suite (5 targets over every input parser: frontmatter, entity files, slug sanitization, TOML config, path normalization) runs before releases; ~5. 9M executions before v0. 5. 4 found and fixed two real input-handling bugs. The integration test suite additionally exercises real SQLite/filesystem behavior under test on every push.

The project is written in Rust, a memory-safe language. (Bundled C dependencies like SQLite are upstream-vendored, not project-written code; the cargo-fuzz suite still exercises the Rust parse paths surrounding them.)

Debug assertions are enabled in all test and fuzz builds (cargo's dev/test profile keeps debug_assertions and overflow checks on; cargo-fuzz builds likewise). Production releases run with LTO + assertions off, matching the "assertions in analysis, not production" intent.

Nothing outstanding: the two real bugs the fuzzer confirmed (frontmatter control-character corruption, unbounded category slug) were fixed in the same session they were found, each with a regression test, and the crash inputs are kept as corpus seeds so they can never silently regress.