We scanned 3,000 healthcare repositories. Here's what we found in CDC, VA, NHS, and Google's code.

Satish Singh — Tue, 31 Mar 2026 06:35:53 +0000

Every year, healthcare organizations spend billions on compliance.
Auditors review policies. Security teams run vulnerability scans.
Certifications get renewed. And yet the actual code running on
production healthcare systems, the code that handles your medical
records, your Social Security Number, your vaccination history,
remains largely unexamined.

We decided to examine it.

Over the past several months, we built a static analysis engine
that reads healthcare source code the way a compliance auditor
would, mapping code patterns directly to specific HIPAA sections,
GDPR articles, SOC 2 criteria, and India's DPDPA requirements.
Then we pointed it at 3,000 public healthcare repositories spanning
9 programming languages and 4 continents.

13,427 confirmed violations. 43.6% of repositories affected.

The organizations involved are not small or obscure. They include
the US Centers for Disease Control, the US Department of Veterans
Affairs, NHS England, Google, and some of the most widely deployed
open-source healthcare platforms in the world.

The gap nobody is closing

Here is the compliance problem nobody talks about.

Security scanners like Snyk and Semgrep find known vulnerabilities,
outdated dependencies, common attack patterns, CVEs. Compliance
audits check whether policies exist, whether a Business Associate
Agreement is signed, whether an access control policy is documented.

Neither examines whether the application code actually implements
the safeguards that regulations require.

A hospital can have a perfect HIPAA policy document and a clean
Snyk scan while its billing export writes every patient's Social
Security Number to a plaintext CSV file on the server filesystem.
That is not a hypothetical. That is OpenEMR, the most widely
deployed open-source EMR with over 100,000 installations worldwide.

This is the gap. And it is systemic.

What we actually found

The VA knew and suppressed it

The US Department of Veterans Affairs notification-api handles SMS,
email, and push notifications for 9 million veterans deployed to
AWS GovCloud.

One Lambda function disables TLS certificate verification with
verify=False. Alongside it sits an explicit # nosec annotation,
a security scanner suppression comment used by developers to silence
warnings they don't want to fix.

The development team was aware this was a security issue. They
suppressed the warning and deployed to production anyway. Veteran
phone numbers and SMS content are logged in plaintext. All affected
functions deploy across dev, staging, perf, and prod environments
via GitHub Actions.

NHS England queries 58 million patient records with TLS disabled

OpenSAFELY is a secure analytics platform for NHS England
electronic health records. The cohort-extractor tool queries
patient data from approximately 58 million NHS patients.

TLS certificate verification is unconditionally disabled for its
EMIS database connection. Security warnings are globally suppressed.
A TODO comment in the code confirms the developers are aware:

# TODO remove this when certificate verification reinstated

The TODO is still there.

India's vaccination platform logged Aadhaar numbers to stdout

India's DIVOC platform powered the national COVID vaccination
certificate system used by hundreds of millions of Indian citizens.

The code serializes the entire certificate request to application
logs, Aadhaar number, name, date of birth, gender, phone number,
home address, for every single certificate created. A separate
analytics consumer prints every Kafka vaccination message to stdout
unconditionally with no feature flag, no log level gate, and no
way to disable it without modifying source code.

Production CoWIN URLs in the Kubernetes deployment configs confirm
this ran on India's national vaccination infrastructure.

We reported this to CERT-In on March 23, 2026.

OpenEMR writes patient SSNs to plaintext CSV files

OpenEMR's billing export feature writes patient Social Security
Numbers, names, dates of birth, addresses, and phone numbers to a
plaintext CSV file via fwrite(). Zero encryption. No audit trail.

When we contacted the OpenEMR security team, they confirmed this
is intended functionality, citing HIPAA's "addressable"
specification as placing the obligation on the deploying
organization.

100,000+ installations. Every one generating unencrypted files
containing the most sensitive category of patient data with no
application-level option to encrypt them.

The finding that should concern everyone most

Of everything we found, one pattern stands out as the most
forward-looking risk.

Across 3,000 repositories, our analysis detected 657 confirmed
instances of patient medical data flowing into AI and machine
learning pipelines without de-identification. This includes CSV
exports fed into model training, inference calls containing
identifiable patient records, and analytics pipelines processing
raw PHI.

Metriport, a funded healthcare API company, sends patient medical
record data to an AI model via Amazon Bedrock. No de-identification
or tokenization is visible before the API call.

This is not a niche finding. As healthcare organizations race to
adopt AI for clinical decision support, triage automation, and
population health analytics, PHI is flowing into these pipelines
at scale. Traditional security scanners were not built to detect
this pattern. Most compliance frameworks have not yet caught up
with it either.

The code is ahead of the regulations. And the data is already
moving.

Why this keeps happening

Compliance failure in our dataset does not correlate with funding,
team size, or institutional credibility. The VA has significant
engineering resources. NHS England runs one of the largest health
data platforms in the world. Google has some of the best security
engineers on the planet.

The correlation is simpler: nobody checked the code.

Not because organizations are negligent. Because the tools and
processes that exist today were not designed to check it. Security
scanners operate at the dependency and vulnerability layer.
Compliance audits operate at the policy and process layer. The
application code layer, where PHI actually moves, where encryption
actually gets implemented or skipped, where logging decisions
actually get made, sits between these two worlds largely unexamined.

That is the gap. And until it gets closed, compliance certifications
will continue to mean less than they should.

What this means for patients

You have no way of knowing whether the healthcare application
handling your data was ever checked at the code level for
compliance. Your provider may have passed a HIPAA audit. Their
software vendor may have a SOC 2 certificate. Neither guarantees
that your Social Security Number is not being written to a plaintext
file somewhere on a server filesystem.

That is not a reason for panic. It is a reason for the industry
to close a gap that has been ignored for too long.