suxrobgm/depvault

Summary

DepVault is a full-stack SaaS dashboard that scans dependency files (package.json, requirements.txt, Cargo.toml, etc.) for vulnerabilities via OSV.dev, and provides an AES-256-GCM encrypted vault for storing environment variables and secret files with one-time sharing links and CI/CD token injection. It's a monorepo combining a Bun/Elysia.js REST API, Next.js 16 frontend, a .NET 10 Native AOT CLI, and a Nextra docs site.

Great for

people interested in building security-focused developer tooling — specifically secrets management, dependency auditing, and encrypted vault infrastructure — using a modern TypeScript stack with Bun, Elysia.js, and Next.js 16 alongside a .NET AOT CLI

Easy wins

• +Write a CONTRIBUTING.md — the CLAUDE.md has all the branch naming, commit conventions, and PR workflow already documented; it just needs to be surfaced for external contributors
• +Add GitHub issue labels and triage a few 'good first issue' or 'help wanted' items (e.g., adding a new ecosystem parser for a missing package manager)
• +The 'apps/demo-video' Remotion scene (ShareLinkScene.tsx) is purely static mock data — replacing it with a proper data-driven demo or removing it as dead weight would clean up the monorepo
• +Write integration tests for the encryption round-trip (encrypt → store → decrypt) since current test coverage is unit-only with mocked encryption utilities

Red flags

• !Only 1 commit in history — the entire codebase appears to have been pushed in one shot, making it impossible to evaluate development trajectory or maintainer responsiveness
• !No CONTRIBUTING.md despite the CLAUDE.md containing detailed workflow docs — suggests this was built with AI assistance for a portfolio and not yet set up for external contribution
• !Encryption utilities are fully mocked in tests (spyOn encryption.encrypt, encryption.decrypt) — the actual AES-256-GCM code path has no test coverage, which is a gap for a project whose primary value proposition is encrypted storage
• !apps/demo-video/ with Remotion is shipping in the monorepo as a top-level app — this is a marketing artifact, not a deployable service, and inflates the apparent scope of the project
• !skills-lock.json in the root is an unusual file not explained anywhere — likely a GitHub Skills course artifact, suggesting this may have been built as a course project rather than an organic product

Code quality

The test files reviewed (auth.service.test.ts, plan-enforcement.service.test.ts, shared-secret.service.test.ts) show solid unit testing discipline: mock factories are clean, edge cases are explicitly tested (replay attack revocation, soft-deleted users, boundary conditions on plan limits), and error types are asserted by instance not just message. The SharedSecretService correctly wipes encrypted payload fields after access ('encryptedPayload: "", iv: "", authTag: ""'), which is a meaningful security detail. The md-to-html.ts script is well-structured with clean separation of config, rendering, and theming. One concern: spyOn of the encryption module in tests means the AES-256-GCM implementation itself is never exercised in the test suite — someone could break the real crypto without failing any tests.

What makes it unique

The combination of dependency vulnerability scanning + encrypted secrets vault in one dashboard is a reasonable product niche (competing with Doppler, Infisical, and Snyk separately), but the open-source implementation is not differentiated from Infisical in particular. The genuinely interesting technical choices are the Elysia.js Eden Treaty for end-to-end type safety and the .NET Native AOT CLI generating its client from OpenAPI via Kiota — that stack combination is uncommon and worth exploring for contributors interested in polyglot type-safe APIs.