While developers, DevOps, and DevSecOps teams work tirelessly to ship secure code, the steps that enable collaboration can lead to security risks.
In the “old days,” programmers wrote code locally on a desktop or laptop. To gain access to source code, malicious actors needed to be physically present to compromise a device. Today, all they need is access to the internet and a valid credential. Even riskier, developers often share code snippets in public repositories which can expose secrets in plaintext, hardcoded into the source code.
With nearly every organization building its own applications, DevSecOps and security teams face unique challenges trying to mitigate risks, especially when trying to mitigate risks outside their control. Dynamic application security testing (DAST) and static application security testing (SAST) tools identify vulnerabilities in source code, but they may not always identify all potentially compromised secrets that sit in the team’s tools. Increasingly, security teams need insights into the risks outside the traditional network perimeter to protect their applications.
Secrets: What they are and why they get shared
In IT, secrets are typically sensitive data that help provide access to or secure an application or an environment. Some examples of secrets may include:
- Authentication tokens
- API keys
- Usernames
- Passwords
- Encryption keys
- Security certificates
When developers are pushing to ship code faster, data leaks are commonly caused by hardcoded secrets in the source code. Some reasons that programmers may leave these secrets in the source code include:
- Simplify workflows: Hardcoding secrets in code can allow for faster code sharing and testing since they don’t need to manually input credentials each time.
- Training and awareness: Programmers may assume that the internal repository is secure enough to protect the source code containing secrets.
- Complex CI/CD pipelines: Hardcoding secrets streamlines the multiple stages of changing keys and secure secrets storage during the phases of development, testing, and deployment, which push code live on tight deadlines.
When developers hardcode secrets, they create security risks. Secrets stored in plaintext can be vulnerable to unauthorized access. As threat actors scan public GitHub repositories, they can find and exploit these accidentally leaked or hardcoded credentials. Once they have this information, they can compromise the service that the secret is authenticating to.
Finally, developers’ failure to remove the hardcoded secrets means this information can spread during the typical development processes of cloning, forking, or checking out source code.
Finding a hardcoded needle in a GitHub haystack
Security teams are already overwhelmed trying to keep the organization’s IT resources secure. While DAST and SAST tools should help identify hardcoded secrets, many companies use a combination of automated and manual processes which can lead to undetectable human error when trying to review thousands of lines of code. Additionally, these tools only identify hardcoded secrets in locations that the organization knows or can control.
According to a
Often, AppSec and security teams need to review multiple locations for hardcoded secrets, including:
- Source code: Large projects can have hundreds — or even thousands — of lines of code that need scanning.
- Configuration files: File paths uploaded to repositories can expose secrets when they trace back to resources.
- Environment variables: Values affecting how processes run and behave can have hardcoded secrets that pass to the function code at runtime, exposing the secrets.
- Container images: Accidentally copying sensitive files with hardcoded secrets can expose them during the image build.
- Developers’ personal repositories: Team members may accidentally push code to their personal repositories and default settings are public.
Taking off the blinders with data leak monitoring
Security teams work ceaselessly to monitor the organization’s enterprise IT environment yet still face challenges trying to protect development and testing environments. Monitoring repositories and identifying leaked information is critical but time-consuming. Security teams should incorporate auditing their code repositories in their data leak monitoring. While typical data loss prevention (DLP) tools are a good addition to DAST/SAST, these traditional enterprise environment tools focus more on monitoring sensitive files so they often fail to account for external risks like public code.
To gain full insight into leaked hardcoded credentials, organizations need solutions to augment their DLP solutions. Data leaks can easily turn into data breaches, and organizations' security teams need to mitigate these risks. Source code leaks and hardcoded secrets are often overlooked because teams face time and staffing limitations.
However, automated threat intelligence solutions that scan the clear, dark, and deep web as well as illicit channels on the messaging app Telegram where malicious actors sell and share stolen data can provide the additional coverage necessary. These solutions can help security teams identify data leaks and remediate risks by monitoring outside the network to detect potential exposures, like:
- Compromised credentials that attackers could use to gain access to the repository itself.
- Infected devices with stealer malware collecting sensitive information, including secrets and credentials.
- Leaked source code containing hardcoded secrets.
- Accidental commits from full-time employees or contractors that contain hardcoded secrets.
As security teams work to mitigate risk across the ever-expanding attack surface, they need to monitor more than just internally controlled resources, like the enterprise IT environment. They need to expand their reach to understand the external threat exposures that exist outside the traditional network perimeter, like GitHub. By augmenting traditional DLP, DAST, and SAST tools with clear, deep, and dark web monitoring, as well as monitoring illicit Telegram channels, security teams gain full visibility into risk across internal and external locations.
Beyond the perimeter: Strengthening security against hardcoded secrets
Hardcoded secrets in public code repositories remain a persistent security risk, exposing organizations to potential breaches and unauthorized access. While traditional security tools like DAST, SAST, and DLP provide a strong foundation, they often fail to capture the full scope of external threats. To stay ahead, security teams must expand their monitoring beyond internal environments, leveraging automated threat intelligence solutions that scan public GitHub repositories, the dark web, and illicit Telegram channels. By taking a proactive, data-driven approach, organizations can mitigate the risks of leaked secrets and safeguard their applications from evolving cyber threats.