Recommended Free Tools
Keep API keys, passwords, tokens, private keys, certificates, and other credentials out of code, Git history, logs, and build artifacts. Store them in a dedicated secrets manager or a tightly controlled CI/CD secret store, grant access only to the people and workloads that need it, and prefer short-lived credentials where possible. If a credential reaches a repository, treat it as compromised: revoke it first, then investigate where it may have spread.
What counts as an application secret?
A secret is authorization material: whoever can use it may gain the permissions attached to it. Common examples include API keys, database credentials, passwords, access tokens, connection strings, SSH keys, certificates, private keys, and credentials that grant cloud or other IAM permissions. Protect them according to what they authorize, not according to whether they look like a password.
A value does not stop being sensitive because it is encoded, placed in a configuration file, or deleted from the latest version of a file. If a valid credential has been exposed, assume someone could have copied it.
Where should application secrets live?
Use a dedicated secrets-management system where practical, or a tightly controlled secret store provided by your CI/CD platform for pipeline use. Avoid hard-coding credentials or checking plaintext configuration containing them into source control. Keep access narrowly scoped: people and workloads should be able to retrieve only the secrets their role requires.
#1 Best Overall
- ✅ PROTECT ONLINE ACCOUNTS – A password manager, two-factor security key, and secure communication token in one, OnlyKey can keep your accounts safe even if your computer or a website is compromised. OnlyKey is open source, verified, and trustworthy.
- ✅ UNIVERSALLY SUPPORTED – Works with all websites including Twitter, Facebook, GitHub, and Google. Onlykey supports multiple methods of two-factor authentication including FIDO2 / U2F, Yubico OTP, TOTP, Challenge-response.
- ✅ PORTABLE PROTECTION – Extremely durable, waterproof, and tamper resistant design allows you to take your OnlyKey with you everywhere.
- ✅ PIN PROTECTED – The PIN used to unlock OnlyKey is entered directly on it. This means that if this device is stolen, data remains secure, after 10 failed attempts to unlock all data is securely erased.
- ✅ EASY LOG IN –No need to remember multiple passwords because by plugging OnlyKey to your computer, it automatically inputs your username and password. It works with Windows, Mac OS, Linux, or Chromebook, just press a button to login securely!
| Approach | Useful boundary | Controls to require | What to verify before relying on it |
|---|---|---|---|
| Dedicated secrets manager | A centralized system for storing and distributing secrets to authorized users or workloads. | Object-level and component-level access controls; least-privilege access; audit records; a protected bootstrap or recovery credential. | How it authenticates callers, supports rotation or short-lived credentials, records access, remains available, and recovers from a vault or identity-system outage. |
| CI/CD platform secret store | A controlled boundary for secrets needed by builds, tests, or deployment jobs. | Restrict pipeline and runner administration; limit which workflows can access secrets; prevent plaintext persistence or output. | How secret access is scoped, audited, rotated, and blocked for forks or untrusted pull-request workflows; whether the store meets your runtime needs. |
| Dynamic or short-lived credentials | Credentials issued for a limited period or generated for a specific use, where the platform supports them. | Limit permissions and lifetime; track issuance and use; ensure expired values cannot be reused. | How issuance, expiry, renewal, revocation, and recovery work for the service and environment using them. |
Product capabilities, availability, and operating costs vary, so evaluate them against your identity model, audit requirements, integrations, recovery process, and the impact of an outage. A secret manager also needs a carefully protected bootstrap or recovery credential; storing that credential beside the vault it unlocks defeats the separation.
How to keep secrets out of Git
- Put secret values in an approved store. Keep application configuration in the repository only when it contains no live credentials. Have local tools, deployment workflows, or running workloads obtain the needed value through an authorized path.
- Limit who and what can retrieve each value. Separate environments and services instead of reusing one broad credential. A developer or workload that needs one database credential should not automatically gain access to unrelated production secrets.
- Scan before a commit reaches a shared repository. Add secret checks to developer workflows, such as pre-commit hooks, so common mistakes can be caught early.
- Scan in CI and at the repository host. Checks at multiple points catch different paths to exposure; no single scan makes it safe to commit credentials.
- Review repository history, not just the current files. GitHub says its secret scanning checks the entire Git history on all branches for hardcoded credentials and periodically rescans as new secret types are added. GitHub push protection can scan during
git pushand block commits containing detected secrets.
OWASP recommends scanning repository history, using pre-commit hooks, and checking build pipelines. Scanning is a prevention and detection layer—not a substitute for revoking a credential that has already been exposed.
Rank #2
- POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
How to handle secrets in CI/CD
A pipeline can expose a secret even when no source file contains it. Protect the path from secret store to job, the job’s output, and any files or artifacts it creates.
- Encrypt secrets at rest and prevent them from being written in plaintext to persistent storage.
- Keep commands, logs, artifacts, and debug output from echoing secret values. Review diagnostic modes and scripts that print environment or configuration data.
- Restrict administration of pipelines and runners. Apply strong authentication, authorization, and accounting to the CI/CD system itself.
- Ensure forks and untrusted pull-request workflows cannot access or exfiltrate protected secrets. Treat workflow changes and runner administration as security-sensitive.
- Use credentials limited to the job’s task and environment; prefer short-lived or dynamically generated values when the platform supports them.
Do not assume that masking a value in logs makes it safe to pass to an untrusted job or persist it in an artifact. Control whether the job can access the credential in the first place.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
- Requires 3 "AAA" batteries (included)
- Unit auto-locks for 30 minutes after 5 consecutive incorrect PINs
What to do after a secret is committed or exposed
Deleting the line or rewriting Git history does not prove that every copy is gone. OWASP’s DevSecOps Guideline states: “when a credential is leaked, it is already compromised and should be invalidated.” Act on the credential, not just the visible copy.
- Revoke or invalidate the exposed credential immediately. Do not wait for a scan result or for repository cleanup to finish.
- Issue a replacement through the approved secrets store. Update the workloads that need it, and confirm they can authenticate with the replacement.
- Rotate dependent credentials if necessary. Determine what systems the exposed credential could reach and whether it could reveal or change other secrets.
- Find likely copies. Check repository history and branches, logs, build artifacts, forks, caches, and any other locations the value may have entered.
- Review access records for misuse. Look for unexpected use of the credential and related authentication or authorization activity.
- Remove the exposed value from repositories and other locations where possible. This reduces future accidental use, but it does not replace revocation because copies may persist beyond your control.
- Close the path that allowed the exposure. Add or tune scanning, access restrictions, workflow controls, or developer guidance as appropriate.
What to audit and manage over a secret’s lifetime
Keep an accountable record of secret access and administrative changes. At minimum, record who requested a secret, the system and role it was for, whether the request was approved, when it was used and expired, attempts to reuse expired values, authentication or authorization errors, updates, and administrative actions. Protect audit logs from tampering and synchronize system clocks so event timestamps can be compared reliably.
For static credentials, automate rotation where possible and define how replacements reach dependent workloads. Where supported, prefer dynamic or short-lived credentials to reduce how long a stolen value remains useful. Keep a recovery or break-glass procedure for vault or identity failures, but tightly restrict and audit its use.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How to choose and review a secrets approach
Compare candidate systems and workflows against the same operational questions rather than choosing by feature labels alone:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →Best Value
- FIDO-ONLY FUNCTIONALITY: Supports FIDO2 (passkeys) and FIDO U2F protocols for passwordless and second-factor authentication. Does not support OTP, TOTP, Smart Card (PIV), or other advanced features - upgrade to YubiKey 5 Series for extended functionality
- SECURE AND CONVENIENT: Passwordless MFA login with the YubiKey Bio authenticator and biometric information using a fingerprint, with a PIN as a fallback. Simply plug in via USB and use your fingerprint to authenticate
- DEVICE & OS COMPATIBILITY: Compatible with Windows, macOS, ChromeOS, and Linux. Works seamlessly with supported services like Google and Microsoft accounts, and major password managers. See the full compatibility list at "Works With YubiKey"
- DURABLE & RELIABLE: Resistant to tampering, water, and crushing. No batteries or network connectivity required, offering dependable authentication without any downtime. Securely manufactured in USA & Sweden
- Yubico Authenticator App - Fingerprint enrollment, passkey management and PIN configuration available via the app app - Upgrade to YubiKey 5 Series to generate one-time-passwords (OTP) via Yubico Authenticator and for advanced compatibility (OATH, PIV)
- Storage boundary: Where is each secret stored, and which services or administrators can reach it?
- Identity and least privilege: Can access be limited by person, workload, environment, and individual secret?
- Lifetime and rotation: Can credentials be short-lived or dynamically generated? If they are static, can rotation be automated without unsafe downtime?
- Audit and alerting: Are requests, uses, failures, changes, and administrative actions recorded and reviewable?
- Scanning coverage: Are checks run before commit, in CI, and across repository history?
- Integration: Can authorized CI/CD jobs and running services obtain secrets without writing them into source or artifacts?
- Recovery and availability: What happens if the secrets manager, identity provider, or CI/CD platform is unavailable? How are bootstrap and emergency credentials protected?
- Operational cost: What effort is required to administer access, rotate values, review alerts, and test recovery?
OWASP’s Secrets Management Cheat Sheet advises limiting or removing human interaction with the secrets themselves: “Therefore, it is better to limit or remove the human interaction with the actual secrets.” In practice, automate authorized delivery and rotation where feasible, while keeping human access exceptional, constrained, and auditable.
Practice detection without risking real credentials
OWASP WrongSecrets is an intentionally vulnerable application designed for secrets-management training, awareness demonstrations, and testing secret-detection tools. It provides a way to exercise detection and response workflows without putting actual credentials into workshop material.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
