Security

Vendor Access Vault is built for small-to-mid teams who currently share API keys, database URLs, and SSH keys over Slack DMs, email, or shared password managers. The threat model we design against reflects that buyer:

• Insider misuse. An employee or contractor with legitimate org access who reveals a credential they should not have, or who continues to read credentials after they should have been offboarded. Mitigated by per-credential just-in-time access requests, an append-only audit log of every reveal with actor / IP / user agent, automatic expiry of approved access, and automatic revocation when a credential is rotated.
• Stale standing access. Vendors and contractors keeping access long after the relationship ends. Mitigated by JIT-by-default for viewers, vendor offboarding that auto-denies pending requests, and rotation reminders for credentials.
• Database compromise. An attacker exfiltrating the production database snapshot. Credential secret values are encrypted at the application layer with AES-256-GCM before they land in the database; the encryption key is held only in the server runtime environment. A database dump alone does not yield plaintext credentials.
• Brute-force and credential-stuffing on login.Mitigated by bcrypt password hashing (cost factor 12), Cloudflare Turnstile bot protection on signup and password-reset flows, and an option for users to enable TOTP two-factor authentication. Rate limiting and account lockout are planned for a future hardening phase.
• Credential leak via the audit log. The audit log never stores the plaintext value of a revealed credential, only metadata about the reveal event (which user, which credential, when, from what IP and user agent).

Threats we explicitly do not aim to defend against in this product: state-level adversaries, hardware-side-channel attacks, fully compromised end-user devices, and physical access to our server infrastructure (which is operated by third-party providers under their own physical-security programs).

At rest, application layer.Credential secret values are encrypted with AES-256-GCM using Node.js's standard crypto module before insertion into the database. Each credential receives a fresh 12-byte initialization vector (IV) and a 16-byte authentication tag, stored alongside the ciphertext. The 32-byte symmetric key is held only in the server-side runtime environment and is never present in any client-shipped JavaScript bundle.

At rest, storage layer. Our managed PostgreSQL provider operates encryption at rest at the disk level. This is additive to our application-layer encryption; an attacker would need to defeat both layers to recover a credential plaintext.

In transit.All connections to the Service are HTTPS (TLS 1.2 or higher), terminated at our hosting provider with modern cipher suites. Connections from the application to the managed database use the provider's TLS-protected connection pooler.

Two-factor authentication secrets. If you enable TOTP, your TOTP secret is encrypted at rest with the same AES-256-GCM construction. Backup codes are SHA-256 hashed and used at most once.

Passwords. Account passwords are hashed with bcrypt (cost factor 12) and never stored in plaintext or in any reversible form.

Roles. Every member of an organization has one of three roles: owner (full control, including delete and ownership transfer), admin (manage vendors, credentials, members, and review access requests), or viewer (read-only metadata; can request access to credentials but cannot reveal without an approval).

Just-in-time reveal gating. Viewers cannot reveal a credential without an admin-approved access request that has not yet expired. Admins can reveal directly. Every reveal, successful or denied, is logged.

Auto-expiry. Approved access requests have a required expiry window (1 hour to 1 week). A daily cron job transitions expired requests to the expired state and notifies the requester. Pending requests that go unreviewed for 7 days are also auto-expired.

Auto-revoke on rotation. When a credential is rotated, all currently approved active access for that credential is atomically revoked in the same database transaction, and each affected requester is notified by email.

Last-owner protection. An owner cannot leave or delete their account while they are the sole owner of an organization with active members. This prevents accidental loss of administrative control.

The audit log is append-only by design. There is no API surface exposed by the application that updates or deletes entries, and the schema is structured to preserve history for the lifetime of the organization.

Each entry records the action (e.g. credential.viewed, request.approved, credential.rotated), the resource type and ID, the actor (or null for system actions like cron-driven expiry), the IP address from request headers, the user-agent string, and a structured metadata blob describing context. Failed reveals by unauthorized viewers are recorded as credential.reveal_denied.

Admins can filter, search, and export the entire audit log to CSV for evidence retention or incident response. The CSV export uses RFC 4180 quoting and includes one row per event with a deterministic column order.

Bot protection. Cloudflare Turnstile guards the signup form, password-reset request form, and verification-email resend endpoint. Real humans pass invisibly; automated traffic is challenged. This blocks common abuse patterns: account-creation floods, password-reset spam, and verification-email enumeration.

Email verification. A new account cannot sign in until the email address is verified through a single-use token delivered by email. Tokens expire after 24 hours.

Two-factor authentication. Account owners and members can enable TOTP two-factor authentication, with single-use backup codes for recovery. Disabling 2FA requires both the current password and a valid TOTP code or backup code.

Session invalidation. Changing your password invalidates all active sessions across all devices via a password-changed timestamp checked at every session refresh.

Hosting. The application runs on Vercel. Vercel operates SOC 2 Type II and ISO 27001 attested infrastructure under their own programs.

Database. User data is stored in a managed PostgreSQL database operated by Neon. Neon operates SOC 2 Type II attested infrastructure under their own program, with encryption at rest at the storage layer and automated backups.

Email delivery. Transactional email is delivered via Resend.

Bot protection. Cloudflare Turnstile.

We rely on these providers for the parts of the security surface they own (physical security, hypervisor isolation, network DDoS protection, hardware-key custody for storage encryption). We do not inherit their certifications. Those are properties of their services, not ours.

What we are not. Vendor Access Vault is not SOC 2 attested, not ISO 27001 certified, not HIPAA-aligned, and not PCI DSS validated. We do not claim to be. Any vendor or platform that tells you that storing data in their tool by itself makes your organization compliant with one of these frameworks is misleading you.

What we provide for your compliance program.Several controls that compliance frameworks expect from a credential-management surface are built into the product: per-user authentication with optional 2FA, role-based access control, encryption at rest with documented key management, an immutable audit trail of credential access with actor and source attribution, and exportable evidence of that audit trail. These are inputs to your compliance program, not substitutes for the audit itself.

We try to be precise about what the Service does and does not do. The following statements are not claims we make:

• We do not claim that AES-256-GCM, bcrypt, TOTP, or any other cryptographic primitive is unbreakable. They are widely studied, but cryptography evolves and so does cryptanalysis.
• We do not claim zero-trust architecture. The application is account-and-role gated. Users with sufficient role can take sufficient actions; the audit log surfaces what they did but does not prevent them from doing it.
• We do not claim to detect every malicious action by an authorized user. We surface activity for your review and for incident response.
• We do not claim that the audit log is tamper-evident in a cryptographic sense (e.g., signed entries with a hash chain). Tamper evidence is on the roadmap but is not present today.
• We do not claim disaster-recovery objectives or formal RPO/RTO commitments. The managed providers we depend on operate their own backups and recovery programs, and we depend on those.

If you believe you have discovered a security vulnerability in Vendor Access Vault, please disclose it responsibly by emailing the address below with a description of the issue, reproduction steps, and any relevant artifacts. Please do not publicly disclose before we have had a reasonable opportunity to investigate and remediate.

We do not currently operate a paid bug bounty program. We will acknowledge receipt and provide a status update as we triage.

For security questions, vulnerability reports, or compliance inquiries:

ORYGN LLC

Email: [email protected]