Seal the Leaks
Spin the Keys
Stay in Control

Manually rotating secrets is a tedious and time-consuming process prone to human error. Fortunately, many secret managers offer built-in rotation features to automate this task.

Most secret managers rely on a long-lived two-secret strategy to avoid downtime during secret rotations. This approach involves generating a new secret in the background and waiting for eventual consistency before revoking the current secret version. Consequently, previous secret versions may remain active for weeks or even months until they are finally revoked.

Vault++ integrates directly with your deployment pipelines, enabling immediate secret rotation and instant application updates without waiting for eventual consistency. This allows you to revoke old secrets as soon as the deployment completes. With this approach, Vault++ supports advanced use cases, such as automated secret rotation and revocation upon detecting a leak, minimizing breach exposure without any human intervention.

In most cases, developers do not require access to production secrets. Granting such access violates the principle of least privilege. However, since developers are responsible for managing secrets in the vault, completely restricting their access can hinder them from performing essential tasks when needed.

A common workaround involves using password managers to share secrets between developers with and without direct vault access. This approach, however, results in secrets being transferred outside the vault, making audits difficult and increasing the risk of leaks or breaches.

Vault++ offers a more secure solution through Merge Requests, allowing developers to propose changes to production secrets without elevated permissions. Additionally, Reveal Requests enable selective, per-item, and temporary access to production secrets when necessary. This eliminates the need for password managers and ensures that production secrets remain securely within Vault++.

Most secret scanners detect secrets by matching strings against specific regular expressions or by analyzing high Shannon entropy. However, this approach often results in a high false positive rate, leading to alert fatigue.

In contrast, Vault++'s secret scanner uses a programming-language-specific parser to understand the context of your code and identify potential secrets. It then verifies these potential secrets against its API to determine if they are real, active secrets. This approach eliminates false positives and reduces alert fatigue.

Most secret scanners rely on pre-defined secret patterns. Internally, they use hundreds of regex patterns baked in during development. This is why their main selling point is often the number of known patterns they can detect.

However, despite having hundreds or thousands of detectors, these scanners struggle to detect secret types they don't have predefined knowledge of, such as internal API keys, passwords, or secrets in the form of UUIDs. To address this, some use a generic detector that flags strings with high Shannon entropy, but this approach often leads to a high false-positive rate and alert fatigue.

Vault++, on the other hand, uses a programming-language-specific parser to understand your code's context. It then extracts potential secrets and securely checks them against Vault++ by comparing secret hashes. This allows Vault++ to detect any kind of secret—whether it's an internal API key, password, or other—without exception.

It is common for secrets to be accidentally committed to a repository, only to be removed in a subsequent commit. However, since Git tracks the history of code changes, the secrets that were previously committed remain in the repository's history and are still accessible to anyone.

Vault++ goes beyond just scanning the surface—it also scans deep into your Git history to identify any active secrets that may have been left behind. This allows you to rotate or revoke these secrets to ensure they are no longer exposed.

Asymmetric-key cryptography (also known as Public-key cryptography) is the cornerstone of modern internet security. Its most common applications include securing the HTTP protocol (SSL/TLS) and providing Digital Signatures. It operates by using a pair of keys: a private key, which must remain secret, and a public key, which is intended to be shared or publicly available. The public key can encrypt data, but only the corresponding private key can decrypt it.

For example, when Amazon customers wish to send their credit card information to complete an order, they encrypt the data using Amazon's well-known public key before transmitting it over the network. This ensures that only Amazon can decrypt the data, as no one else in the network path (such as ISP providers or public hotspot operators) possesses Amazon's private key.

In Vault++, every actor (whether user or service account) has its own pair of private and public keys. Key generation occurs exclusively on the client-side (in web browsers) during registration, login, or service account creation. Private keys remain on the client-side, while public keys are uploaded to Vault++ and associated with the actor's identity.

To store secrets in Vault++, the secrets are encrypted on the client-side using the public keys of the actors granted access to those secrets. Since encryption happens solely on the client-side, Vault++ only receives encrypted versions of the secrets and never their plain-text form. When an actor requests access to a secret, Vault++ returns the secret encrypted with that actor's public key. The actor can then decrypt the secret using their private key, ensuring that the secrets are always protected.