BLOG

By David Chernitzky, Co-Founder and CEO, Armour Cybersecurity  |  Serving organizations across Canada, the US, and beyond  |  Last updated August 19, 2026

Quick answer: A hardcoded secret in software development is a credential, API key, database password, cryptographic key, or access token committed directly into source code or configuration files rather than loaded at runtime from a secure secrets management system. When that code is pushed to a version control repository, the secret becomes part of the commit history, which persists even if the secret is subsequently removed from the current version of the file. If the repository is public, the secret is immediately accessible to anyone. If the repository is private, the secret is accessible to everyone who has read access to the repository, and it remains accessible through the commit history to anyone who compromises the repository. Automated tools scan public and private repositories continuously for exposed secrets and sell or exploit what they find. A hardcoded secret in production code is not a potential future risk; it is an active vulnerability.

Key Takeaways

• Removing a secret from source code does not remove it from the repository. Version control systems like Git maintain the full history of every commit. A secret committed to a repository and then removed in a subsequent commit is still accessible in the commit history to anyone with repository access. The only safe response to a discovered secret in a repository is to rotate the credential immediately, invalidating the exposed version, and then remove it from the code. Rotation before removal is the correct order; removing from the code without rotation leaves the exposed credential active.
• Automated scanners continuously monitor public repositories for exposed secrets. Tools available to both security researchers and attackers scan GitHub, GitLab, Bitbucket, and other public hosting platforms continuously for patterns matching API keys, cloud credentials, database connection strings, and other credential formats. The time between a secret being committed to a public repository and being found by an automated scanner is measured in minutes, not hours or days. GitHub’s own secret scanning feature, which is free for public repositories, sends automatic alerts to service providers whose credential formats have been detected. The attacker tooling operates on the same timescale.
• Cloud provider credentials are the highest-risk secrets to expose because they provide direct access to cloud infrastructure. An AWS access key and secret pair exposed in a public repository gives the attacker the same access as the IAM user those credentials belong to. If that user has broad permissions, the attacker can provision new resources, exfiltrate data from S3 buckets, modify security configurations, and generate activity under the legitimate user’s identity that may be difficult to distinguish from normal operations. Cloud credential breaches resulting from repository exposure consistently appear in public incident reports and regulatory actions.
• Secrets detection in the CI/CD pipeline is the preventive control that catches secrets before they are committed to the main branch. A pre-commit hook or CI/CD gate that runs secrets detection on every pull request identifies exposed credentials before they merge, giving the developer the opportunity to remove the secret and replace it with a proper secrets management reference before the commit becomes part of the permanent history. Prevention at this stage is far less disruptive than rotation and remediation after the fact.
• Centralized secrets management eliminates the need for secrets in code entirely. A secrets management system such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Google Secret Manager stores credentials centrally and provides applications with the ability to retrieve secrets at runtime through authenticated API calls. Applications reference the secret by name rather than by value, so the secret value never appears in the source code. Access to secrets is governed by IAM-style policies, and access is logged so the security team knows which applications are accessing which secrets and when.

Why Secrets End Up in Code

Secrets end up in code primarily because it is the path of least resistance during development. A developer building a new feature that requires an API key needs that key available in the code to test the feature. The fastest way to make it available is to paste the key directly into the code or a configuration file. The developer intends to replace it with a proper environment variable or secrets manager reference before merging, but that step is forgotten, rushed, or deprioritized when the feature is working and the deadline is approaching. The key lands in the commit history of the pull request, and when the pull request is merged it becomes part of the main branch. Catching that moment is exactly what secrets detection in the DevSecOps pipeline is built to do.

Configuration files are another common source of committed secrets. Database connection strings, SMTP credentials for email sending, and API keys for third-party services are frequently stored in configuration files that are checked into version control alongside application code. In some cases this is intentional for development environments, where the secrets are placeholders without real access, but the same pattern is copied to production configuration without the secrets being separated into a secure store. In other cases, a developer adds a production credential to a configuration file intending to move it later and the move never happens.

Infrastructure-as-code files present the same risk at the infrastructure layer. Terraform configurations, Kubernetes secrets manifests, and Ansible playbooks that include credential values in plaintext commit those credentials to the same version control repository as application code, extending the exposure surface from the application layer to the cloud infrastructure and platform layer.

What Attackers Do With Exposed Secrets

Immediate automated exploitation of cloud credentials

Cloud provider credentials, particularly AWS access keys and Azure service principal credentials, are exploited within minutes of discovery by automated tooling. The attacker’s toolchain authenticates using the exposed credential, enumerates the permissions available to the compromised identity, and begins resource reconnaissance. Common immediate actions include listing S3 buckets and downloading accessible data, enumerating IAM policies and roles to identify escalation paths, provisioning compute resources in regions not used by the legitimate account for cryptocurrency mining, and establishing persistence mechanisms such as new IAM users or access keys that survive rotation of the originally compromised credential.

The speed of automated exploitation means that manual detection and response processes cannot operate fast enough to prevent exploitation after a cloud credential is publicly exposed. The detection and rotation of exposed cloud credentials must itself be automated: continuous repository monitoring that detects credential exposure and triggers automatic rotation is the only response mechanism that operates at the timescale required.

Authentication bypass and data access

Database credentials, application API keys, and service account passwords exposed in source code give attackers direct authentication to the systems those credentials protect. This API key exposure security problem is severe precisely because it bypasses every other control: a database password in a public repository gives the attacker who finds it the ability to authenticate to the database directly, bypassing every application-layer security control, and access or modify the data the database contains. An API key for a third-party service gives the attacker the same access as the application that key was issued for: reading customer data through the API, triggering actions in the third-party system, or exhausting API quotas in ways that disrupt the application’s functionality.

What a Secrets Management and Detection Program Requires

A secrets management and detection program has two components that operate at different stages of the development lifecycle. Secrets detection in the pipeline is the preventive control: repository scanning that identifies secrets already present in the codebase, pre-commit hooks or CI/CD gates that detect secrets in new commits before they merge, and alerting that immediately notifies the security team when a secret is detected. The detection covers common secret formats, including API keys from major providers, database connection strings, private keys, and generic high-entropy strings that match the pattern of a credential, across all files in the repository including configuration files, IaC files, and documentation.

Centralized secrets management is the architectural control that makes secrets detection unnecessary in the long run by eliminating the need for secrets in code. The implementation requires: selecting a secrets management platform appropriate to the organization’s cloud and application environment, migrating existing hardcoded secrets to the platform, updating application code to retrieve secrets at runtime rather than reading them from environment variables or configuration files, and establishing governance over secret creation, access, rotation, and retirement. Access to secrets is governed by the same identity and privilege access management discipline applied to any privileged resource, and a rotation policy specifies how frequently each secret is rotated and what the process is for emergency rotation when a secret is suspected to be compromised. Because access is logged centrally, the resulting audit trail is also the kind of access evidence a SOC 2 examination expects to see.

Armour Cybersecurity delivers both components as part of its DevSecOps engagement: initial repository scanning to surface all exposed secrets in the current codebase, secrets detection integrated into the CI/CD pipeline, a centralized secrets management implementation plan, and rotation of any credentials found during the initial assessment. The secrets management implementation is one of the service domains covered by the engagement.

Frequently Asked Questions

If we find a secret in our repository, what is the correct sequence of actions?

The correct sequence is: first, rotate the exposed credential immediately, invalidating the version that was committed. Second, verify that the rotation was effective and the old credential no longer works. Third, search the commit history and any forks or clones of the repository for the exposed credential to understand the full scope of exposure. Fourth, review the access logs for the compromised credential to determine whether it was used by unauthorized parties during the exposure window, and if there is any sign it was, move immediately into your breach response process. Fifth, remove the secret from the current codebase and replace it with a reference to the centralized secrets management system. Sixth, add the secret format to the repository scanning configuration to prevent the same class of secret from being committed in the future. The rotation step must precede the removal step; removing the secret from the code without rotating it leaves an active credential in the commit history.

What is the difference between a pre-commit hook and a CI/CD security gate for secrets detection?

A pre-commit hook runs on the developer’s local machine before the commit is recorded in the local repository. It catches secrets before they are committed at all, providing the earliest possible detection and the least disruptive remediation path (the developer simply removes the secret before the commit). The limitation of pre-commit hooks is that they run on the developer’s machine and can be bypassed or may not be installed consistently across all developers. A CI/CD security gate runs in the centralized pipeline on every pull request, providing detection that cannot be bypassed and that covers all contributions regardless of whether the developer has configured local hooks. The most effective configuration uses both: pre-commit hooks for developer convenience and CI/CD gates as an enforceable backstop.

What secrets management tools are most commonly used?

HashiCorp Vault is the most widely deployed dedicated secrets management platform for organizations with complex multi-cloud or hybrid environments. It provides a centralized secrets store, dynamic secrets generation (credentials that are created on demand and expire after use), detailed access logging, and a rich policy engine. AWS Secrets Manager, Azure Key Vault, and Google Secret Manager are the native secrets management services for each major cloud provider, tightly integrated with their respective IAM systems and well-suited for organizations that primarily operate in a single cloud. For organizations already using Kubernetes, Kubernetes Secrets provide basic secrets management, though they have limitations (secrets are base64-encoded rather than encrypted by default) that additional tools like External Secrets Operator or Sealed Secrets address. Tool selection follows the organization’s cloud environment and existing tooling, not vendor preference, which is the approach Armour Cybersecurity applies during the DevSecOps engagement.

Can secrets scanning tools catch all types of exposed credentials?

Secrets scanning tools use two main detection approaches: pattern matching against known credential formats (AWS access key patterns, GitHub personal access tokens, Google service account JSON files, and hundreds of other formats with distinctive structures) and entropy analysis that identifies high-randomness strings that may be credentials even if they do not match a known format. Pattern matching is highly accurate for the credential formats it covers. Entropy analysis catches custom credentials that do not match any known pattern but generates more false positives because not all high-entropy strings are secrets. The combination of both approaches provides reasonable coverage, with the caveat that any secrets detection tool will miss some categories of secrets that its patterns do not cover. This is why secrets management, which prevents secrets from entering code at all, is the more robust long-term control compared to detection alone.

The Bottom Line

A hardcoded secret is one of the few vulnerabilities that broadcasts itself: the moment a credential lands in a repository, automated scanners are racing your security team to find it, and on public repositories they usually win in minutes. The fix is not heroics after the fact; it is architecture before it. Detection in the pipeline catches secrets before they merge, and centralized secrets management removes the reason for them to be in code at all, so applications reference credentials by name and the values live in a governed, logged store. When a secret does slip through, the order is fixed: rotate first, then remove. The organizations that treat secrets as managed infrastructure rather than strings in a config file simply stop having this class of breach. A structured DevSecOps engagement puts both controls in place and rotates whatever the first scan turns up.