What are secrets?
Secrets are credentials that authenticate or authorize access to sensitive actions in an enterprise's IT systems. To connect third-party services and enable communication between application components, your environment needs a way to authenticate each service—typically via a key, password, certificate, or token.
Unlike sensitive data such as payment card numbers, which belong to end users, secrets belong to enterprises. Common examples include API keys, encryption keys, SSH private keys, access tokens, and PKI/TLS certificates.
What is secret scanning?
Secret scanning is the practice of running automated scans on code repositories, execution pipelines, configuration files, commits, and other data sources to detect exposed secrets before attackers find them. It falls within the broader scope of secrets management, which encompasses the processes and tools for storing and protecting secrets from unauthorized access.
Stop Fixing in Production
Walk through how Wiz finds issues in code, blocks them in CI, enforces policy at deploy, and traces runtime risks back to the source
Who is responsible for secrets security?
Cloud providers offer native secrets management tools, such as AWS Secrets Manager and Azure Key Vault, but the shared responsibility model makes the division clear:
The cloud provider secures the underlying infrastructure, including the vaults, encryption services, and access control systems.
Your organization secures everything built on top of that infrastructure, including ensuring secrets aren't hardcoded in source code, CI/CD logs, container images, or configuration files.
This distinction matters because most secret exposure incidents stem from developer behavior during the SDLC, not from provider-side failures. When a developer hardcodes an API key into a repository for testing and pushes that code to a public GitHub repo, no cloud provider tool can prevent the exposure. That's where secret scanning, combined with developer education and policy enforcement, fills the gap.
Why is secret scanning important?
Secrets are the keys to your kingdom. When they are exposed, attackers do not need sophisticated exploits—they just need to know where to look. According to the Wiz State of Code Security 2025 report, 61% of organizations have secrets in at least one public repository, and the problem is accelerating. The following two risk categories show why the business impact is severe.
1. Preventing data breaches and unauthorized access
When a secret escapes into an exposed space, an attacker who finds it can move laterally through your environment, escalate privileges, and exfiltrate data from production systems. Our Wiz Research team found this exact scenario playing out in the wild: forgotten secrets in container image base layers and Linux bash history files gave attackers a foothold for remote code execution and software supply chain attacks.
A high-profile example: in 2023, a Microsoft research team accidentally published a link exposing 38 TB of private data on GitHub, including private keys, passwords, and over 30,000 internal Teams messages stored in an Azure storage account. Scanning the account for secrets before publishing the link would have prevented the incident entirely.
The persistence of leaked credentials significantly compounds the danger. Once a secret is exposed, organizations often fail to revoke it quickly. Only a small window is more than enough time for a threat actor monitoring public repositories to exploit the credentials.
2. Avoiding compliance violations and reputational damage
Many enterprises are subject to regulations designed to protect user data, including GDPR, PCI DSS, and HIPAA.
Because secrets guard access to the systems that store this data, an accidental secret release can trigger a data breach that results in noncompliance fines, legal fees, and settlements. Beyond the financial fallout, breaches erode customer trust in ways that outlast any fine.
Proactive secret scanning helps demonstrate due diligence to auditors and regulators, reducing both compliance risk and the reputational exposure that follows a headline breach.
How does secret scanning work?
Secret scanners run across your entire stack, inspecting code repositories, configuration files, container images, CI/CD pipelines, and observability pipelines for credential patterns. The process breaks down into three core steps.
Step 1: Scanning
Once a secret scanner connects to your stack, it runs either real-time or at-rest scans. Real-time scans are event-driven, triggered by pull requests in your version control system (VCS) or code changes across your repositories, containers, and DevOps toolchain. At-rest scans conduct historical reviews of the same components at scheduled intervals, catching secrets that slipped through before scanning was in place.
Secret scanners rely on several detection techniques, often in combination. Regular expressions (regex) search for patterns tied to specific service types, such as a Stripe API key with a known prefix and character count. Entropy analysis flags highly randomized strings that likely represent credentials.
Hybrid approaches combine these methods with machine learning to reduce false positives and improve coverage of generic secrets—the hardest category to catch with pattern-matching alone. Verizon's 2025 DBIR analyzed over 441,000 secrets found in public Git repositories, with web-app infrastructure secrets and CI/CD tokens making up the vast majority of exposures.
Step 2: Identifying and verifying secrets
When the scanner detects a potential secret, it either corresponds with the service provider or extracts metadata to identify which service the pattern matches. It then checks whether the credential is still valid.
This validation step is what separates high-quality scanners from noisy ones: unvalidated findings generate alert fatigue, while confirmed active secrets demand immediate remediation.
Step 3: Reporting and alerting
When the scanner confirms a match, it notifies the relevant stakeholders and, depending on the tooling, recommends remediation steps. Access to these reports should stay tightly restricted, since the reports themselves contain sensitive data.
Agentless scanning solutions generally offer faster setup and lower maintenance overhead. They connect to customer environments using a single org-level connector and scan workloads via cloud-native APIs, without the ongoing agent installation and update cycles that agent-based approaches require.
How are secrets exposed in cloud environments?
Secret exposure rarely happens because of a single dramatic mistake. More often, it results from ordinary development behavior compounded across teams and codebases. The most common patterns include the following.
Hardcoded secrets in repositories. Developers embed credentials directly into source code during testing, intending to remove them before pushing—but in practice, those credentials often reach public repositories unchanged. Wiz research found GitHub PATs ranking as one of the most commonly exposed secret types in public repos, giving any threat actor scanning GitHub a direct pivot point into your environment.
Secrets leaking in CI/CD pipeline logs. Secrets passed as environment variables or injected at runtime can surface in verbose build logs if not handled carefully. Many organizations have forgotten secrets persisting unnoticed for months in container image base layers, enabling lateral movement across developer infrastructure.
Misconfigured container images. Secrets baked into image layers during a build step can survive long after a developer assumed they were gone, since layers are often shared, cached, and reused. Wiz research also flagged supply chain risk in VS Code extension marketplaces, where compromised extensions can exfiltrate credentials from developer machines.
AI companies and AI-assisted development amplify exposure. AI coding assistants accelerate development, and the rate at which secrets find their way into code. Wiz research found verified secret leaks at 65% of the Forbes AI 50, collectively valued at over $400 billion, with credentials buried in deleted forks, gists, and developer repos that most scanners miss.
Beyond repositories, secrets now sprawl across collaboration tools like Jira, Slack, and Confluence, as well as container registries like Docker Hub. The perimeter for secrets management extends well beyond the codebase.
Secret management best practices for development teams
Scanning detects secrets after they appear. The following four practices aim to prevent their creation and minimize the damage if they occur.
Implement centralized secret storage and rotation
Store secrets in dedicated secrets management tools, such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. These tools encrypt secrets at rest and in transit and keep them out of repositories, configuration files, and container images. Pair centralized storage with regular rotation: dynamic secrets that expire after a defined timeframe or condition limit the window an attacker has if a credential is compromised. This is the foundational setup step that everything else builds on.
What is the Principle of Least Privilege (PoLP)? Use Cases, Benefits, and Implementation
Read more
Restrict access to secrets
Create and enforce secret access policies consistently across your stack using the principle of least privilege (PoLP), access control lists (ACLs), and role-based access control (RBAC). Users and applications should access only the secrets they need for a specific function, nothing more. When a credential is accidentally compromised, PoLP limits an attacker's ability to move laterally, shrinking the blast radius significantly.
Establish secret lifecycle management
Keep a complete inventory of secrets currently in use, track who accesses what and when through audit logs, and revoke compromised or unused secrets promptly. This ongoing practice closes the gap that makes leaked secrets so persistent: organizations often lack the visibility to know a secret is active until after an incident.
A robust lifecycle management process turns secret revocation from a reactive scramble into a routine operation. Avoid hardcoding secrets in source code, and use environment variables to reference secrets instead, so you can rotate them without touching the codebase.
Integrate scanning into developer workflows
Secret scanning delivers the most value when it runs continuously, early in the IDE, on pre-commit hooks, and in CI/CD pipelines as part of automated pull request checks. This shift-left approach catches exposed credentials before they reach repositories, rather than after.
Wiz's research on detecting secrets in AI-generated code shows how scanning techniques are evolving to keep pace with new development patterns, including those driven by AI coding assistants.
How Wiz helps secure secrets across your development lifecycle
Keeping secrets secure across a fast-moving development lifecycle requires more than good intentions. It requires scanning at every stage, from the IDE through CI/CD pipelines to production. Wiz connects code and cloud to give security teams and developers a unified view of secret exposure and its real-world impact. Here’s how.
Wiz Code identifies exposed secrets across repositories and CI/CD pipelines, then correlates those findings with cloud context through the Wiz Security Graph.
Wiz Cloud extends that visibility into the production environment, correlating secrets found in code with the cloud resources they connect to.
Wiz Defend then monitors those identities in real-time to detect suspicious access or exfiltration attempts before they escalate.
The result is a shift-left security approach, as an AI-led CNAPP, that does not ask developers to slow down. Instead, it integrates secret scanning into the workflows they already use, surfacing prioritized findings with the context needed for fast remediation.
Book a demo to see how Wiz secures secrets across code, cloud, and runtime in a single platform.
Stop Fixing in Production
Walk through how Wiz finds issues in code, blocks them in CI, enforces policy at deploy, and traces runtime risks back to the source