In everyday language, a secret can be any sensitive data that we want to keep private. When discussing secrets in the context of software development, secrets generally refer to digital authentication credentials that grant access to systems or data. These are most commonly API keys, usernames and passwords, or security certificates.
Secrets exist in the context of applications that are no longer standalone monoliths. Applications nowadays rely on thousands of independent building blocks: cloud infrastructure, databases, SaaS components such as Stripe, Slack, HubSpot…
Secrets are what tie together these different building blocks of a single application by creating a secure connection between each component.
Secrets are typically high entropy strings which means that they are strings or text that are very random in value. Some API keys can be pre or post fix which means they share the same characters at the start or at the end of the string but most secrets aren’t and are just a highly randomized value that contains different types of character.
A secret incident is a uniquely identified security event that has been determined to have an impact on the organization and necessitates remediation. An incident often has multiple occurrences across files or repositories.
A single incident generally encompasses multiple occurrences, which are the various locations across files or repositories where the secret was identified. Occurrences map to the magnitude of the sprawl, and are therefore correlated to the amount of work needed to redistribute the secret after it has been rotated. Occurrences can be assimilated to technical debt.
Unlike traditional credentials, secrets are meant to be distributed to developers, applications, and infrastructure systems. Adding more of these factors will inevitably make the number of secrets used in a development cycle increase, leading to a natural sprawling phenomenon: secrets start to appear hardcoded in source code. From an organization’s point of view, visibility and control over their distribution start to degrade. This is what secrets sprawl is all about.
When secrets are sprawled through multiple systems it increases what is referred to as the ‘attack surface’. This is the amount of points where an unauthorized user could gain access to your systems or data. In the case of secrets sprawl, each time a secret enters another system it is another point where an attacker could gain access to your secrets.
Most internal systems are not an appropriate place to store sensitive information, even if those systems are private. No company wants credit card numbers in plaintext in databases, PII in application logs, bank account credentials in a Google Doc. Secrets must benefit from the same kind of protective measures.
As a general security principle, where feasible, data should remain safe even if it leaves the devices, systems, infrastructure or networks that are under organizations’ control, or if they are compromised. This helps prevent credential stealing, which is a well-known adversary technique described in the MITRE ATT&CK framework:
“ Adversaries may search local file systems and remote file shares for files containing passwords. These can be files created by users to store their own credentials, shared credential stores for a group of individuals, configuration files containing passwords for a system or service, or source code/ binary files containing embedded passwords. ”
Secrets accessed by malicious threat actors can lead to information leakage and allow lateral movement or privilege escalation, as secrets very often lead to other secrets. Furthermore, once an attacker has the credentials to operate like a valid user, it is extremely difficult to detect the abuse and the threat can become persistent.