In 2023, a security researcher found that Toyota had left an access key exposed in public GitHub source code for nearly five years, granting access to a server holding customer data for over 296,000 people. In 2019, Capital One's misconfigured web application firewall exposed 106 million customer records — including unencrypted Social Security numbers stored in plaintext columns. These are not exotic zero-days. They are instances of CWE-311, Missing Encryption of Sensitive Data, one of the most common and most avoidable weaknesses tracked in the MITRE CWE Top 25. It happens when applications store or transmit passwords, tokens, financial details, or personal information without encrypting them at rest or in transit, leaving the data readable to anyone who gains access to the database, backup, log file, or network traffic. It persists because encryption is treated as a checkbox rather than a default, and because supply chain visibility into where sensitive data actually lives is weak.
What Exactly Is CWE-311 and Why Does It Keep Showing Up?
CWE-311 describes software that transmits or stores sensitive data — credentials, health records, payment information, API keys — without applying cryptographic protection. It keeps showing up because encryption is an architectural decision that has to be made correctly at multiple layers: database columns, backup snapshots, log pipelines, message queues, and network sessions. Miss any one layer and the whole chain fails. The 2017 Equifax breach is a textbook example: attackers exfiltrated 147.9 million consumers' Social Security numbers, and post-incident review found that internal encryption of data at rest was inconsistently applied across the affected systems, meaning the theft yielded directly usable data rather than ciphertext. CWE-311 has appeared in the CWE Top 25 Most Dangerous Software Weaknesses list every year since MITRE began publishing it in 2019, consistently ranking among the top 20 based on real-world CVE frequency and exploitability scoring.
How Often Does This Actually Cause Breaches?
It is one of the leading root causes cited in large-scale breach investigations, not a theoretical risk. Verizon's 2023 Data Breach Investigations Report found that "Basic Web Application Attacks" and misconfiguration-driven data exposure incidents together accounted for a substantial share of confirmed breaches, and unencrypted data at rest was repeatedly named as the factor that turned an access event into a full data-loss event. In the 2021 breach at CVS Health's vendor, a misconfigured cloud database exposed over 1 billion records, many containing unencrypted phone numbers and internal identifiers, because the database had no default encryption policy applied. Similarly, the 2020 breach affecting Estée Lauder exposed 440 million records sitting in an unsecured, unencrypted Elasticsearch database. In each case, the initial exposure vector (a misconfigured cloud service) was arguably less damaging than the fact that the underlying data was stored in plaintext.
Which CVEs Show This Pattern in Real Software?
Dozens of CVEs each year map directly to CWE-311, spanning IoT firmware, enterprise software, and cloud tooling. CVE-2020-11899, affecting Treck's embedded TCP/IP stack (part of the "Ripple20" vulnerability set), involved improper handling that allowed sensitive tunneled data to be exposed without adequate encryption in millions of connected devices from vendors including HP, Schneider Electric, and Intel. CVE-2019-11510, in Pulse Secure VPN appliances, allowed unauthenticated attackers to read arbitrary files, including ones storing plaintext credentials and session cookies that should have been encrypted at rest — this flaw was later linked to ransomware intrusions into U.S. government networks in 2020 and 2021. More recently, multiple CVEs disclosed in 2023 against open source CI/CD and secrets-management tooling described API tokens and webhook secrets stored unencrypted in configuration files or database tables, meaning any read access to the underlying storage yielded live credentials.
What Does This Look Like Inside a Modern Software Supply Chain?
It typically shows up as secrets and sensitive fields sitting unencrypted somewhere in the build and deployment pipeline, not just in the production database. Hardcoded API keys and database passwords committed to source control are the most visible form — GitGuardian's 2024 State of Secrets Sprawl report found over 12.7 million secrets exposed in public GitHub commits in 2023 alone, a 28% increase year over year, with many of those credentials granting access to systems storing customer or financial data that itself had no encryption at rest. Beyond source code, CI/CD systems frequently pass sensitive environment variables through build logs in plaintext, container images bake in unencrypted configuration files, and internal service-to-service calls within a microservices architecture often skip TLS because "it's inside the VPC." Each of these is a variant of CWE-311, and each one widens the blast radius of any single compromised component in the software supply chain.
Why Isn't This Just Fixed With a Policy Requiring Encryption?
Because policy without enforcement doesn't survive contact with delivery pressure, and most organizations lack visibility into where sensitive data actually flows across dozens or hundreds of services and third-party dependencies. A written encryption standard is easy to approve and hard to verify at scale — a developer under deadline pressure adds a new database column for "temporary" storage of a customer's tax ID, intends to encrypt it later, and it ships to production unencrypted because no automated check caught it. Compliance frameworks like PCI DSS (requirement 3.4) and HIPAA's Security Rule have mandated encryption of specific data categories for over a decade, yet breaches involving unencrypted cardholder and health data continued through 2023 and 2024, because audits happen periodically while code and infrastructure change continuously. Without continuous, automated scanning across source code, container images, and cloud configuration, missing encryption gets discovered by attackers before it's discovered by the security team.
How Do You Actually Detect Missing Encryption Before It Ships?
Detection requires combining static analysis of source code with configuration scanning of cloud resources and secrets scanning across the full software delivery pipeline. Static analysis tools can flag sensitive-looking variable names and fields (SSN, password, credit_card, api_key) that get written to disk or logged without passing through an encryption function first — a Python service that pickles a customer record straight to disk without ever calling into a data encryption in Python library like cryptography is a common, easy-to-catch instance of this pattern. Infrastructure-as-code scanning can catch cloud storage buckets, RDS instances, and Elasticsearch clusters provisioned without encryption-at-rest flags enabled — a check that would have caught the CVS Health and Estée Lauder-style exposures before data was ever loaded. Secrets scanning across every commit, pull request, and container layer catches the hardcoded-credential variant of this weakness, which GitGuardian's data shows is still growing year over year. The key requirement across all three is continuity: a one-time audit finds today's gaps, but only continuous scanning integrated into the CI/CD pipeline catches the gap introduced next Tuesday.
How Safeguard Helps
Safeguard's software supply chain security platform is built to catch exactly this pattern — sensitive data moving through a pipeline without cryptographic protection — before it reaches production. Safeguard continuously scans source repositories, build artifacts, and container images for hardcoded secrets, unencrypted credential storage, and sensitive fields that bypass encryption, mapping every finding back to the specific CWE and, where relevant, the CVE it resembles. Rather than relying on periodic manual audits, Safeguard integrates directly into CI/CD workflows so that a commit introducing an unencrypted database column, a plaintext API key, or a misconfigured storage bucket is flagged and blocked before merge, closing the gap between when a policy is written and when it's actually enforced. For teams managing dependencies across a complex supply chain, Safeguard also tracks third-party components and vendor code for known CVEs tied to missing-encryption weaknesses, giving security teams a single view of where sensitive data is exposed across their own code and everything they've pulled in from outside. The result is fewer plaintext surprises in production and a much shorter window between a mistake being introduced and it being caught.