aegis-vault-v7

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 public git repository (https://github.com/hafgit99/aegis-vault-v7/commits/main) contains 800+ commits of interim development history between releases, including conventional-commit messages, review-ready branches, and automated CI runs — not only final release snapshots. Development happens in the open on main and via pull request branches.

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

Every user-facing release has a unique version identifier (e.g., 7.0.1.0, 7.0.2.0). Versions are recorded consistently across CHANGELOG.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/CHANGELOG.md), RELEASE_NOTES.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/RELEASE_NOTES.md), package.json / metadata.json, and as git tags. The release pipeline enforces version consistency across these files as a release gate.

Each release is identified by a git tag in the repository: v7.0.1.0, v7.0.2, and v7.0.2.0 are visible at https://github.com/hafgit99/aegis-vault-v7/tags. Future releases will continue this tagging convention.

Non-trivial release notes file in repository: https://github.com/hafgit99/aegis-vault-v7/blob/main/CHANGELOG.md.

N/A. The project results themselves have had no publicly known vulnerabilities with CVE assignments fixed in any release to date. The RUSTSEC advisories referenced by the OpenSSF Scorecard affect third-party dependencies, not the project's own code; the criterion explicitly applies only to the project results. Dependency vulnerabilities are continuously tracked via Dependabot and documented in the threat model (https://github.com/hafgit99/aegis-vault-v7/blob/main/docs/THREAT_MODEL.md).

Non-trivial SECURITY[.md] file found file in repository: https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY.md. [osps_do_02_01]

The project uses GitHub Issues as its issue tracker: https://github.com/hafgit99/aegis-vault-v7/issues — individual issues are tracked, labelled, and publicly visible.

The repository was made public on 2026-09-01 and has received no unacknowledged bug reports; every report received to date has been acknowledged. The project commits in SECURITY.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY.md) to acknowledging every report within 48 hours, and this SLA will be applied to all future reports.

No enhancement requests have been received in the last 2-12 months (the repository went public on 2026-09-01). All future enhancement requests will be responded to via GitHub Issues; the project's published SLAs (48h acknowledgment, 7-day triage decision) in SECURITY.md apply to them as well.

All bug reports and responses are archived and publicly searchable in GitHub Issues (https://github.com/hafgit99/aegis-vault-v7/issues), with stable per-issue URLs that anyone can access without installing proprietary software.

The vulnerability reporting process is published in SECURITY.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY.md): it defines the supported versions, what to include in a report, the in-scope components (crypto, IPC, extension messaging, storage, Android), the out-of-scope boundaries, and the disclosure timeline.

Private reporting is supported and documented in SECURITY.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY.md): reporters are instructed NOT to open public issues and are given a private channel (email to admin@aegisvault.xyz). Reports can also be submitted via GitHub's private vulnerability reporting (Security tab → Report a vulnerability), which keeps all correspondence private. A 90-day coordinated disclosure timeline is published.

No vulnerability reports have been received in the last 6 months (the repository went public on 2026-09-01). The project publishes a binding initial-response SLA in SECURITY.md: acknowledgment within 48 hours and a triage decision within 7 days — both well under the 14-day requirement — and this commitment will apply to every future report.

The project provides a working, automated build system. The README (https://github.com/hafgit99/aegis-vault-v7#readme) documents all build commands: npm run desktop:build (Tauri desktop), npm run build:extension (browser extension), and Android build commands. The build is driven by npm scripts orchestrating Vite (frontend), Cargo/Tauri (native backend), and can rebuild the software entirely from source.

The build uses standard, widely-adopted tools for each language: npm and Vite for the TypeScript frontend, Cargo and Tauri for the Rust native backend, and Gradle for the Android target — all invoked through conventional npm scripts documented in the README (https://github.com/hafgit99/aegis-vault-v7#readme).

All build tooling for the primary targets is FLOSS: Node.js, npm, Vite, Rust, Cargo, and Tauri. The optional Android APK build uses the Android SDK/NDK (free but not fully FLOSS); desktop, web, and browser-extension builds — the primary deliverables — require only FLOSS tools.

The project ships a FLOSS automated test suite with 1,800+ tests using Vitest, fast-check (property-based fuzzing), Stryker (mutation testing), and Playwright (e2e) — all FLOSS. How to run them is documented in the README "Verification & Testing" section (https://github.com/hafgit99/aegis-vault-v7#readme) and in CONTRIBUTING.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/CONTRIBUTING.md).

All test suites are invocable via the standard npm run interface for the JavaScript/TypeScript ecosystem (npm run test:unit, npm run test:coverage, npm run test:fuzz, npm run test:e2e, npm run test:mutation:*), and Rust backend tests via standard cargo test — documented in README and CONTRIBUTING.md.

Test coverage is measured and gated per module; reported coverage includes e.g. Storage Orchestration 88.4%, Core Crypto 81.7%, Importer 80.4%, Search 81.3% (see the coverage table in the README: https://github.com/hafgit99/aegis-vault-v7#readme). Beyond line coverage, 8 Stryker mutation suites verify test strength on security-critical modules and fast-check property-based fuzzing exercises crypto and parser inputs.

Continuous integration runs on every push and pull request via GitHub Actions: the CI workflow (.github/workflows/ci.yml, https://github.com/hafgit99/aegis-vault-v7/blob/main/.github/workflows/ci.yml) executes typecheck and the unit test suite; the CodeQL workflow (.github/workflows/codeql.yml) performs SAST analysis on the same triggers.

CONTRIBUTING.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/CONTRIBUTING.md) establishes the policy: all verification gates (typecheck, unit/coverage, fuzzing, mutation suites, e2e, cargo tests) must pass before merge, security-sensitive changes must keep the security mutation suites within their configured score bands, and threat-model impact must be justified in the PR — in practice this requires new tests for new functionality.

Evidence in the codebase: every core module has a co-located test file (e.g., src/lib/security.ts → security.test.ts, src/lib/nativeSecurity.ts → nativeSecurity.test.ts, storage layers with dedicated mutation suites). Recent major changes added tests with the feature — e.g., hardware-bound unlock support (commit 8c3b020) and the CLI Argon2id parameter floor enforcement (commit 6ba605b) landed with dedicated test coverage, and the mutation suites (stryker.security.conf.mjs, stryker.storage.conf.mjs) enforce that security-critical changes carry test strength.

The policy is documented in CONTRIBUTING.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/CONTRIBUTING.md), the instructions for change proposals: the "Verification Checklist" section lists the required test gates, and the "Security Review Guidance" section requires threat-model justification for security-sensitive changes.

The project enables multiple static analysis layers: TypeScript strict mode compiler flags (tsconfig.json), ESLint with typescript-eslint (eslint.config.mjs), CodeQL SAST with the security-extended query suite running in CI (.github/workflows/codeql.yml), and Rust compiler warnings checked during cargo build/cargo test for the native backend.

Warnings are treated as blockers: the typecheck gate (TypeScript strict mode) must pass in CI before merge, the codebase contains zero @ts-ignore suppressions and zero known ESLint errors, and the Rust backend builds warning-free. The internal audit process (three full audit rounds) explicitly tracked and fixed quality-gate findings, documented in QUALITY_GATES.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY_AUDIT_PACKAGE/QUALITY_GATES.md).

The project is maximally strict where practical: strict: true TypeScript compiler options, typescript-eslint strict rules via eslint.config.mjs, and mutation testing score bands that security modules must maintain — a stricter bar than plain compilation warnings.

The primary developer has designed and implemented a documented secure architecture: a local-first, zero-materialization design where master credentials never persist and keys are derived via Argon2id. This is formalized in the published threat model (https://github.com/hafgit99/aegis-vault-v7/blob/main/docs/THREAT_MODEL.md) covering trust boundaries, attacker model, and a residual risk register, and validated through three internal security audit rounds with documented findings and remediation (SECURITY_AUDIT_PACKAGE/QUALITY_GATES.md).

The project demonstrates awareness of vulnerability classes specific to password managers and their countermeasures: XSS → strict CSP with no unsafe-inline (enforced by an automated gate, scripts/security-csp-no-unsafe-inline.cjs); secret leakage → gitleaks scanning of all 835 commits plus push protection; credential-string exposure in logs/memory → zero-materialization architecture and a master-string classification gate (scripts/security-no-js-master-string.cjs); weak KDF parameters → enforced Argon2id parameter floor (commit 6ba605b); crypto misuse → mutation and property-based fuzz suites dedicated to crypto modules. All are codified as automated CI gates rather than manual promises.

All cryptographic primitives are publicly published and expert-reviewed standards: Argon2id (RFC 9106, PHC winner) for key derivation, AES-256-GCM (NIST SP 800-38D) and XChaCha20-Poly1305 (draft-irtf-cfrg-xchacha) as AEAD ciphers, HMAC-SHA-256 and SHA-2 family (FIPS 180-4). No custom or proprietary algorithms are used.

The project does not re-implement cryptographic primitives. The Rust backend uses the well-audited RustCrypto crate family (argon2, chacha20poly1305, hmac, sha2 — see src-tauri/Cargo.toml) plus subtle (constant-time comparison) and zeroize (key material wiping); the TypeScript layer uses argon2-browser (WASM Argon2) and platform WebCrypto APIs for AEAD operations.

All cryptographic dependencies are FLOSS: the RustCrypto crates (Apache-2.0/MIT dual-licensed), argon2-browser (Apache-2.0/MIT), and the WebCrypto API implemented by the FLOSS browser/runtime engines. Nothing in the crypto stack requires proprietary software.

Default key lengths provide at least 128-bit security (NIST minimum through 2030): AES-256 and XChaCha20-Poly1305 use 256-bit keys, HMAC-SHA-256 uses 256-bit keys. Argon2id parameters have an enforced floor (memory, iterations, parallelism) validated by the CLI gate introduced in commit 6ba605b, and the software provides no configuration to weaken these below the enforced floor.

No broken cryptographic algorithms (MD4, MD5, single DES, RC4, Dual_EC_DRBG) are used anywhere, and no inappropriate cipher modes are used: all encryption is AEAD (AES-256-GCM / XChaCha20-Poly1305) with per-message nonces. SHA-2 and HMAC-SHA-256 are used for hashing/MACs. No interoperability requirement forces a legacy algorithm.

The default mechanisms avoid algorithms with known serious weaknesses: no SHA-1, no CBC mode, no unauthenticated encryption. All confidentiality paths use AEAD constructions (GCM or XChaCha20-Poly1305) with associated-data binding, which also prevents truncation/substitution attacks.

N/A. The software implements no interactive key-agreement protocol with long-term session keys. It is local-first: vault keys are derived locally via Argon2id from the user's master credential, per-object keys are generated independently, and sync providers (WebDAV/S3) transport already-encrypted opaque blobs. There is no long-term session key whose future compromise would expose past session keys.

The master credential is never stored — not in plaintext, hash, or encrypted form. It is stretched in memory via Argon2id (memory-hard, iterated, with a per-vault random salt) to derive the vault encryption key; only the derived key verification data exists, computed by Argon2id. User-stored credentials (the vault contents) are protected at rest with AEAD (AES-256-GCM / XChaCha20-Poly1305) encryption. This exceeds the OWASP Password Storage Cheat Sheet requirements.

All keys, nonces, and salts are generated from cryptographically secure sources: the Rust backend uses the rand crate backed by the OS CSPRNG (getrandom), and the TypeScript layer uses the platform WebCrypto crypto.getRandomValues. No Math.random, no custom PRNGs, and no time-based nonce generation is used anywhere in security paths — enforced by the property-based fuzz suites on crypto modules (src/lib/encryption.fuzz.test.ts and others).

Distribution channels use HTTPS exclusively. [osps_br_03_02]

Release artifacts and their SHA-256 checksum manifests (SHA256SUMS.txt) are only ever retrieved over HTTPS (GitHub repository and GitHub Releases), which counters MITM. No hash is ever retrieved over plain HTTP. The audit package additionally documents a signature workflow (minisign/gpg) for hand-off scenarios, and the release pipeline computes checksums reproducibly (scripts/generate-audit-package-checksums.cjs).

The project's own code has no publicly known unpatched vulnerabilities. Dependency advisories (RUSTSEC, from the RustCrypto/transitive dependency ecosystem) are continuously monitored via Dependabot and CodeQL; each advisory is assessed against the threat model (https://github.com/hafgit99/aegis-vault-v7/blob/main/docs/THREAT_MODEL.md) — the currently open ones sit in dependency code paths outside the trust boundary or require preconditions excluded by the design assumptions. Dependency updates are merged weekly through the Dependabot PR pipeline with CI validation.

No critical vulnerability has ever been reported to the project. The published vulnerability-handling SLA in SECURITY.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY.md) — 48h acknowledgment, 7-day triage, 90-day coordinated disclosure — ensures critical vulnerabilities are fixed rapidly if reported.

The repository is continuously scanned for leaked credentials: gitleaks runs against the entire git history (835+ commits, currently zero findings) with a committed configuration (.gitleaks.toml: https://github.com/hafgit99/aegis-vault-v7/blob/main/.gitleaks.toml), and GitHub Push Protection is enabled to block secret-bearing pushes before they land.

CodeQL (security-extended query suite) runs via GitHub Actions on every push and every pull request targeting main before merge (.github/workflows/codeql.yml — https://github.com/hafgit99/aegis-vault-v7/blob/main/.github/workflows/codeql.yml), and results are published to code scanning. It is complemented by ESLint with typescript-eslint and the TypeScript strict-mode compiler gate, all of which must pass before any release candidate is built.

The primary static analysis tool, CodeQL, runs the security-extended query suite, which explicitly targets common vulnerability classes for the JavaScript/TypeScript environment (XSS, injection, prototype pollution, path traversal, insecure deserialization, etc.). The project additionally maintains custom lint-based security gates targeting its own vulnerability classes: scripts/security-csp-no-unsafe-inline.cjs (CSP unsafe-inline) and scripts/security-no-js-master-string.cjs (master-credential string exposure).

No medium or higher severity exploitable vulnerability has been found by static analysis to date (code scanning: https://github.com/hafgit99/aegis-vault-v7/security/code-scanning). The published policy in SECURITY.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY.md) commits to 48-hour acknowledgment and 7-day triage, and confirmed findings are fixed under the 90-day coordinated disclosure timeline; the same process applies to static analysis findings.

Static analysis runs on every commit: CodeQL (security-extended), the CI workflow's typecheck job (TypeScript strict), and the security lint gates all trigger on every push to main and every pull request (.github/workflows/codeql.yml and .github/workflows/ci.yml). This exceeds the suggested daily cadence.

Dynamic analysis is applied during development and before releases: fast-check property-based fuzzing exercises the crypto, parsing, and validation layers (e.g., src/lib/encryption.fuzz.test.ts, otp, recoveryKey, importer, backupValidation fuzz suites), Playwright end-to-end tests exercise the real application across Chromium/Firefox/WebKit and mobile viewports, and eight Stryker mutation suites validate that these analyses actually detect injected defects. All are documented in README and CONTRIBUTING.md.

N/A for the criterion's intent (C/C++-class memory-unsafe languages). The native layer is Rust, which is memory-safe by design; the only unsafe code in the project is six narrow Windows FFI call sites in src-tauri/src/lib.rs (display-capture affinity and native file dialogs) that marshal well-typed handles — no C or C++ is compiled, and no hand-managed memory exists. Nevertheless, dynamic analysis is used routinely: the fast-check property-based fuzz suites and the Playwright e2e suite described under dynamic_analysis run on every development cycle.

The fuzz and test suites run with full assertion density: Vitest executes assertions on every property iteration of the fast-check fuzz suites, Rust test builds enable debug assertions and overflow checks by default (cargo test), and the mutation suites (Stryker) verify assertion strength by requiring that injected mutants are killed. These assertion-heavy configurations are used in development and CI; production builds use the release profile with assertions disabled as intended.

No medium or higher severity exploitable vulnerability has been discovered by dynamic analysis to date. The project's published process in SECURITY.md (https://github.com/hafgit99/aegis-vault-v7/blob/main/SECURITY.md) — 48-hour acknowledgment, 7-day triage, fixes within the 90-day coordinated disclosure window — governs the handling of any confirmed dynamic analysis finding, and the three completed internal audit rounds (documented in SECURITY_AUDIT_PACKAGE/QUALITY_GATES.md) closed all identified findings within measured remediation cycles.