Secret Scanning: A Critical Practice for Protecting Sensitive Data in Code

With the rise of CI/CD pipelines, cloud-native development, and globally distributed teams, sensitive credentials like API keys, tokens, and database passwords often slip into source code. Sometimes accidentally, sometimes under pressure to deploy fast.

This is not a rare mishap. A recent study found that 34% of API security incidents involve sensitive data exposure. And according to Cyble, over 1.5 million .env files containing secrets have been discovered in publicly accessible environments.

Leaked credentials are often exploited within minutes, enabling attackers to access cloud storage, spin up crypto-mining servers, or exfiltrate sensitive data.

To help address this growing threat, Indusface WAS now includes Automated Secret Scanning, a feature designed to give organizations complete visibility into leaked or hard-coded secrets across all their applications and onboarded subdomains.

What are Secrets in Code?

Secrets are sensitive pieces of information that should remain confidential. When embedded in code repositories, they pose a serious security risk.

Examples of Secrets:

• API keys (e.g., AWS, Stripe, Twilio)
• OAuth tokens
• SSH private keys
• Database credentials
• JWT signing secrets
• TLS/SSL certificates
• Encryption keys
• Cloud provider access keys

Hardcoding these values or including them in configuration files can expose them to version control systems like Git, where they may inadvertently be shared or pushed to public repositories.

What is Secret Scanning?

Secret scanning is the automated process of detecting secrets (like keys or passwords) that are accidentally included in source code, repositories, or configuration files.

It is designed to:

• Prevent secret leaks before code is pushed to production.
• Alert developers and security teams about exposures.
• Reduce the attack surface by enforcing proper credential handling.

Secret scanning can be integrated into local development environments, CI/CD pipelines, and repository monitoring tools to ensure secrets do not slip through undetected.

Why Secret Scanning Is Critical

The importance of secret scanning cannot be overstated. A single leaked API key can give attackers access to:

• Your cloud infrastructure (e.g., AWS S3 buckets)
• Customer PII or financial data
• CI/CD environments
• Internal services and source code
• Third-party integrations

Without secret scanning, these risks remain invisible until exploited.

How Secrets Get Exposed in the First Place

Secrets typically find their way into code during the chaos of development. Developers working under tight deadlines may embed credentials to speed up testing, enable certain features, or integrate third-party services. These might be overlooked or forgotten by the time the code goes into production.

In some cases, staging and production environments share the same configuration files or credentials, increasing the risk of sensitive information ending up in live user-facing code. APIs used in front-end logic may also carry authentication tokens in headers or as part of JavaScript bundles.

Furthermore, tools used for error tracking, analytics, and debugging can unintentionally leak sensitive environment variables or data in payloads. Over time, these practices accumulate and expose the organization to significant risk.

Common Sources of Secret Exposure

• Hardcoded credentials in codebases during development
• Configuration files checked into version control (.env, config.json)
• Developer notes or comments accidentally committed
• Debug logs that capture runtime secrets
• Copy-pasting keys in shared channels or documents
• CI/CD environment variables exposed in build logs

Even if secrets are rotated regularly, their exposure even for a short time can lead to major breaches if attackers act quickly.

The Impact of Exposed Secrets

The consequences of leaked secrets are both immediate and severe. In the past year, 83% of organizations experienced at least one security incident linked to hardcoded secrets (Thales Group, 2024).

These breaches are not just technical slip-ups they come with a high price tag. On average, incidents involving exposed secrets cost organizations $4.5 million per breach, factoring in operational downtime, regulatory penalties, and remediation efforts (IBM Cost of a Data Breach Report, 2024).

Exposed secrets can allow:

• Unauthorized Access to Systems: Cloud provider credentials embedded in JavaScript can be used to access S3 buckets, databases, or even execute privileged operations via APIs.
• Privilege Escalation: Hardcoded JWT signing secrets or static tokens can allow attackers to forge valid tokens, impersonate users, or bypass authentication mechanisms.
• Service Disruption and Data Loss: API keys exposed in the frontend can be misused to delete data, exhaust usage quotas, or trigger service outages.
• Internal Reconnaissance: Leaked internal hostnames, IPs, or references to private infrastructure components can provide attackers with a blueprint of the internal network, easing lateral movement during an attack.

Each exposed secret represents a potential entry point into your system. The more critical the secret, the more devastating the impact.

Real-world breaches highlight the growing risk:

• Unit 42 Analysis (2024): A scan of publicly accessible .env files revealed 1,185 exposed AWS keys across 110,000 domains, illustrating the scale of unattended secret leaks.
• Football Australia (2024): Leaked credentials enabled unauthorized access to 127 storage repositories, exposing player contracts, passport details, and customer purchase records.
• Schneider Electric (2024): Hackers used exposed credentials to steal 40GB of sensitive data, including names and email addresses of over 75,000 employees and customers.
• GitHub Repositories (2021): Security researchers discovered over 100,000 public repositories containing at least one exposed credential, token, or API key, highlighting widespread mismanagement of secrets in code.

Expert Recommendations to Prevent Secret Leaks

Based on recurring patterns observed during assessments, we recommend the following best practices to build long-term resilience against secret exposure. These insights are drawn from real-world cases and refined through years of hands-on experience across varied application stacks.

1. Never Embed Secrets in Public Code

Code served to browsers such as HTML and JavaScript is always accessible. Secrets such as API keys, access tokens, or signing keys must never be embedded in these assets. All sensitive operations should be routed through secure backend endpoints, where secrets remain protected and access controlled.

2. Use Environment Variables and Secret Managers

Avoid hardcoding sensitive data. Instead, rely on environment variables and modern secret management solutions like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault. This ensures secrets are securely stored, rotated, and accessed only by authorized services at runtime.

3. Isolate Environments Completely

Keep QA, staging, and production environments strictly separated. Use unique sets of credentials for each person. Reusing secrets across environments increases the risk of leaks. Also, test or staging environments should never be publicly accessible without proper access controls.

4. Regularly Rotate and Revoke Secrets

Secrets should never live indefinitely. Rotate them periodically and immediately revoke any that have been exposed or are no longer in use. Implement short-lived tokens and time-bound credentials wherever possible to minimize the impact of a potential leak.

5. Audit Code and Configuration Repositories Periodically

Old repositories and legacy code often contain hardcoded secrets that are forgotten but still active. Make regular audits a part of your security routine. Even unused branches or archived projects should be reviewed periodically.

6. Train Developers on Secure Coding Practices

Security is a shared responsibility. Equip developers with training to recognize and avoid unsafe practices such as:

• Hardcoding secrets in config files or scripts
• Pasting credentials into chat or shared docs
• Committing .env or .pem files to version control

A security-aware development culture reduces risk at the source.

7. Log and Monitor for Secret Misuse

Even with strong prevention, leaks may still occur. Set up monitoring on API endpoints, cloud accounts, and authentication systems. Track suspicious access patterns, failed logins, or unusual geolocation activity to detect and respond to potential misuse.

How Indusface WAS Performs Automated Secret Scanning

Unlike traditional code repository scanners, Indusface WAS focuses on what is exposed on the internet, not just what exists internally. This makes its scanning approach highly practical, especially for identifying unintended leaks that reach production or staging systems.

Here is how the process works end-to-end:

Comprehensive Asset Discovery and Target Mapping

The process begins with the discovery of externally accessible digital assets. Using External Attack Surface Management (EASM), Indusface WAS continuously identifies public-facing assets associated with organizational domains, including websites, subdomains, application endpoints, and legacy components that may not yet be part of scheduled security testing.

These assets are mapped to determine which publicly accessible files and scripts are served to browsers or clients. This inventory-building step creates visibility into potential exposure points where secrets may be unintentionally published within client-side code or configuration files.

When secrets are found on assets that have not yet been onboarded into Indusface WAS, those domains or subdomains can be added directly to the assessment process, ensuring that all discovered exposure points become part of continuous monitoring.

Public Code Inspection and Secret Detection

Once assets are identified, Indusface WAS evaluates publicly exposed resources as part of routine scanning workflows. This includes the inspection of HTML pages, JavaScript files, configuration scripts, and other client-served artifacts. During analysis, data structures such as variables, encoded values, and configuration blocks are examined for patterns that may indicate exposed credentials.

Across onboarded applications and newly discovered assets, WAS scans for secret types including API keys, authentication tokens, passwords, encoded values, and cryptographic material that are unintentionally visible within public resources.

All detected secrets are safely masked and mapped to the specific subdomain and URL where they appear. This provides engineering teams with precise source-level visibility without displaying full credentials in dashboards or reports.

Validation and Contextual Review

Detected secrets are consolidated within the Secrets section of Indusface WAS for contextual review. Each record includes the affected asset, masked secret preview, and discovery date, enabling teams to validate findings and understand where remediation actions are required.

Findings are grouped by secret type and tracked over time, allowing security teams to monitor overall exposure trends while coordinating remediation activities with development teams.

Centralized Monitoring and Asset-Level Visibility

Indusface WAS provides a unified dashboard showing total secret scans segmented by completed and in-progress runs, the aggregate number of secrets identified across assets, and trend views reflecting open and closed secrets over time.

Security teams can drill down directly from the EASM interface or the Vulnerabilities → Secrets dashboard into individual findings to review exposure points at the asset level. If a detected asset is not already onboarded into routine scanning, it can be added immediately, ensuring discovery automatically feeds into continuous monitoring cycles.

Operational Filtering, Search, and Reporting

To support day-to-day operations, Indusface WAS offers built-in filtering, search, and reporting capabilities across all detected secrets. Analysts can locate findings by subdomain or secret pattern, organize results through filters, and export all-domain reports for coordination, governance, and documentation purposes.

Making Sensitive Data Visible Again

Exposed secrets are dangerous because they often go unnoticed. Indusface WAS closes that visibility gap by continuously scanning your external attack surface and highlighting any secrets embedded in publicly accessible code.

By combining automated detection with manual validation, Indusface WAS gives organizations the clarity and confidence needed to remove risky secrets, strengthen their security posture, and prevent costly breaches.

See Indusface WAS identify and surface exposed secrets across your external attack surface.

Ready to uncover hidden exposures?
Start your Free Indusface WAS trial and experience automated secret scanning in action.

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.