Why Your Security Scanner Isn’t a Compliance Scanner

One Line of Code. Zero Vulnerabilities. One Serious Violation.

Here’s a line of code that exists in almost every healthcare application we’ve scanned:

logger.info(f"Patient lookup: {patient.first_name}, DOB: {patient.dob}, MRN: {patient.mrn}")

Run it through Snyk. Zero findings. Run it through SonarQube. Clean. Semgrep. Nothing. HCL AppScan. Pass.

Now run it through a compliance scanner.

One line of code. Zero security vulnerabilities. One serious compliance violation.

This is the gap between security scanning and compliance scanning. And in healthcare, this gap is where audit failures, regulatory violations, and seven-figure fines live.

This Isn’t a Theoretical Example

Across the hundreds of healthcare repositories we’ve analyzed so far - EHR integrations, FHIR implementations, telehealth platforms, HL7 pipelines - PHI in application logs is the single most common violation we find. It appears in the majority of healthcare codebases we analyze.

And it makes sense. Developers log data to debug problems. During development, you want to see what’s flowing through the system. The patient name in the log helps you trace an issue. Nobody thinks of it as a compliance violation.

But it is. And it’s invisible to every general-purpose security scanner on the market.

This is just one example. The pattern repeats across the entire application:

• Patient data in URL parameters - a security scanner flags it as “information exposure” with low severity. A compliance scanner flags it as a HIPAA §164.312(e)(1) violation because ePHI is being transmitted in a way that can be cached, logged by proxies, and stored in browser history.
• Missing access control on a patient data endpoint - a security scanner doesn’t flag it at all. A missing authorization check isn’t a “vulnerability” in the traditional sense. But it’s a HIPAA §164.312(d) violation: failure to verify that a person seeking access to ePHI is who they claim to be.
• Unencrypted internal API calls carrying patient records - the frontend uses HTTPS. The perimeter scan passes. But inside the network, microservices transmit ePHI over plain HTTP. A compliance scanner traces the data flow and catches it.

In every case, the security scanner either misses the finding entirely or downgrades its severity because it doesn’t understand the regulatory context. A compliance scanner maps each finding to the specific regulation it violates, traces the data flow from source to sink, and assigns severity based on regulatory impact - not just exploitability.

Security Scanning vs. Compliance Scanning: The Core Difference

A security scanner asks: “Does this code have vulnerabilities?”

A compliance scanner asks: “Does this code handle regulated data the way the law requires?”

These sound similar. They are fundamentally different questions.

A security scanner looks for patterns that an attacker could exploit: injection flaws, authentication bypasses, insecure cryptography, known CVEs in dependencies. The output is a vulnerability report organized by severity (Critical, High, Medium, Low).

A compliance scanner does all of that, but adds a layer that changes everything:

It maps every finding to a regulation. Not just “this is a High severity finding” but “this violates HIPAA §164.312(a)(2)(iv) - encryption and decryption standard” or “this violates DPDPA Section 8(4) - reasonable security safeguards.”

It traces data flows, not just code patterns. A security scanner looks at each file in isolation. A compliance scanner follows patient data from where it enters the application (an API endpoint, a form input, a FHIR interface) through every function call, storage operation, and external transmission - and identifies where protection breaks down.

Side-by-Side: Same Codebase, Different Results

Here’s what this looks like from a real scan we ran on an anonymized healthcare application:

The security scanner found 2 issues. The compliance scanner found 6 violations and produced a complete map of how patient data moves through the application.

Same codebase. Completely different picture.

The Missing Piece: Where Does Patient Data Actually Go?

Even if a security scanner caught every vulnerability, it still wouldn’t answer the most fundamental compliance question: where does patient data flow through your application?

The proposed HIPAA Security Rule modification requires regulated entities to create and maintain a technology asset inventory and a network map that illustrates the movement of ePHI throughout their electronic information systems. India’s DPDPA requires organizations to implement and document security safeguards for personal data flows. GDPR requires data processing records and data flow documentation.

At the application layer, this means you need to know:

• Entry points: Where does patient data enter? API endpoints, form inputs, file uploads, HL7/FHIR interfaces, webhook receivers.
• Processing nodes: How does it move? Function calls, data transformations, service-to-service communication.
• Storage locations: Where does it rest? Databases, caches, temporary files, log files, session stores.
• External transmissions: Where does it leave? Third-party APIs, email services, PDF generators, analytics platforms.

No security scanner produces this map. This gap is where the ePHI Data Flow Analysis Report comes in.

Using AST-based taint analysis and control flow graph traversal, it follows patient data from entry point to exit point through your codebase. It identifies every storage location, processing node, and external transmission, and flags where protection breaks down.

From a recent scan of an anonymized healthcare application:

• 14 ePHI entry points identified across REST API endpoints
• 7 storage locations mapped: 3 database tables, 2 cache layers, 1 log file, 1 temp file
• 4 external transmission points: 2 third-party API integrations, 1 email service, 1 PDF generation service
• 3 unprotected flows where patient data moved from entry to storage without encryption

This application had passed a security scan with zero critical findings. It had a SOC 2 certification from an infrastructure audit. And yet it had three unprotected ePHI flows that would fail a HIPAA audit.

Infrastructure compliance tools like Vanta and Drata audit your cloud configuration. Security scanners audit your code for vulnerabilities.

Why This Matters Right Now

Three regulatory forces are converging:

The Proposed HIPAA Security Rule Update

Will require regulated entities to document ePHI movement through their systems. You’ll need evidence that patient data is protected at every step - not just at the infrastructure level, but inside your application.

India’s DPDPA Enforcement Begins May 2027

Healthcare companies handling Indian citizens’ personal data must demonstrate code-level security safeguards and data flow documentation. The compliance deadline is 14 months away.

Healthcare Breach Costs at Record Highs

The average cost of a healthcare data breach exceeded $7.4 million in 2025. Regulators are increasing enforcement. They’re looking beyond policies and infrastructure and asking: did your application code actually protect patient data?

We’re Putting This to the Test at Scale

We’re currently analyzing over 1,000 public healthcare repositories on GitHub across the United States, Europe, and India to build the first Healthcare Code Security Index - a comprehensive baseline of how healthcare application code actually performs against HIPAA, GDPR, SOC 2, DPDPA, Singapore MGF, and PCI DSS compliance requirements.

The early results confirm what we’ve seen in individual scans: the majority of healthcare applications have compliance violations that no general-purpose security scanner would catch. PHI in logs. Unencrypted data flows. Missing access controls on patient endpoints. Hardcoded credentials. Weak cryptographic implementations.

We’ll publish the full findings later this month.