Secrets Detection

Secrets detection is the practice of scanning source code, configuration files, Git history, and CI/CD pipelines for hardcoded credentials — API keys, passwords, tokens, certificates, and private keys. These exposed secrets can give attackers direct access to cloud infrastructure, databases, and third-party services, making them one of the highest-risk vulnerabilities in modern software development.

It is important to identify any private or sensitive information that could potentially be used in an attack or data breach. This includes credentials (such as usernames or passwords that can grant a user or system access to resources or services), API keys or tokens (unique identifiers to authorize access to an API or web service), private keys or encryption keys (such as those used to encrypt/decrypt sensitive data or secure communication protocols), certificates (codes used to establish trust between two entities, such as between a server and a client), and private endpoint/webhook URLs.

Secrets can be exposed in a wide variety of places, including source code, configuration files (e.g., IaC files), CI/CD pipelines, developer productivity tools, collaboration tools, wikis, and generative AI tools. To minimize potential vulnerabilities, any secrets exposed in any non-private location must be identified, removed, and changed.

An effective secrets detection solution algorithm must exhibit high precision and high recall. High precision means a low number of false alerts. In other words, high precision means that a high percentage of identified secrets are actual secrets that are at risk of exposure. High recall means that a low number of secrets are missed. Given that even one undetected credential can introduce a large amount of risk, it is often considered preferable to have to investigate some false alerts to ensure that no real exposed secrets are overlooked.

There are many techniques that can prevent the exposure of secrets; when developers and DevOps professionals are aware of the dangers and available solutions, the incidence of exposed secrets drops sharply. Secrets can be stored in environment variables or separate files instead of hardcoding them (these files should be included in .gitignore to ensure that they are not synced to a repository). Another option is to encrypt all secrets, using a dedicated secrets management tool, and implement two-factor authentication (2FA) for any repositories that still might contain secrets. In all cases, automated scanning technology should be used to detect hardcoded secrets in source code and prevent them from being pushed to code repositories from where their leakage is more likely.

When a developer commits a secret and later deletes it, the credential still exists in every previous commit in the repository’s history. Anyone with Git access — including contractors, open-source contributors, or attackers who gain access — can retrieve it. Scanning only the current codebase misses these historical secrets entirely. Checkmarx scans the complete Git history to find credentials that have been “deleted” but never actually rotated.

Checkmarx combines multiple techniques to minimize false positives: high-entropy analysis to distinguish random-looking real credentials from placeholder values, contextual analysis to recognize test files and example code, structural pattern matching against known credential formats (e.g., AWS key prefixes), and allowlisting for common test credential patterns. The result is a high-confidence finding set that developers can act on immediately without drowning in noise.

Checkmarx detects 100+ secret types out of the box, including: AWS, Azure, and GCP credentials; GitHub, GitLab, and Bitbucket tokens; payment provider keys (Stripe, PayPal, Square); communication platform tokens (Slack, Twilio, SendGrid); RSA/DSA/EC private keys; JWT secrets; database connection strings with passwords; and many more. Custom patterns for internal secrets and proprietary systems are also configurable.

Checkmarx integrates at multiple points in the development lifecycle: IDE plugins for VS Code and IntelliJ provide real-time alerts as developers write code; pre-commit hooks prevent secrets from entering Git at all; CI/CD integrations with GitHub Actions, Jenkins, Azure DevOps, and TeamCity scan on every push and pull request; and the Checkmarx One platform provides a unified dashboard for security teams to monitor and manage findings across all repositories.

Any time an exposed secret is discovered, it is advisable to immediately revoke/replace the secret to remove the risk of the secret being used in an attack or breach. This is especially important if the secret was exposed in a public platform (such as GitHub), because once posted it might never be possible to completely remove it. And, of course, do not repeat the mistake and include the new secret in an exposed manner.

Checkmarx provides step-by-step remediation guidance for every finding. The general approach is: (1) immediately rotate the credential in the issuing service — do not just delete it from code; (2) update all environments using the old credential; (3) replace the hardcoded value with an environment variable or secrets manager reference; (4) audit access logs to check for unauthorized use during the exposure window. Checkmarx provides direct links to the rotation interface for each supported provider.

Yes. Secrets Detection is a native capability within Checkmarx One, the unified cloud-native AppSec platform. It integrates with SAST, SCA, DAST, and ASPM findings in a single dashboard — providing correlated risk prioritization so security teams can see which repositories have both code vulnerabilities and exposed credentials, and understand the combined blast radius.