What the HIPAA Security Rule is, in one paragraph
HIPAA (the US Health Insurance Portability and Accountability Act) applies to "covered entities" (health plans, healthcare clearinghouses, most healthcare providers) and their "business associates" — which includes any software vendor or development team building systems that touch electronic Protected Health Information (ePHI). The Security Rule organises required safeguards into three categories: Administrative (§164.308 — policies, risk analysis, training), Physical (§164.310 — facility and device access), and Technical (§164.312 — the actual system-level controls). Most implementation specifications are "addressable," not universally "required": an organisation must implement the safeguard, an equivalent alternative, or document why neither is reasonable and appropriate for its situation.
The 5 Technical Safeguards standards (§164.312)
These are the only part of the Security Rule that describes system-level controls rather than organisational policy — quoted from the regulation and HHS guidance:
| Citation | Standard |
|---|---|
| §164.312(a) | Access Control — technical policies limiting access to ePHI to authorized persons and software |
| §164.312(b) | Audit Controls — mechanisms to record and examine activity in systems that handle ePHI |
| §164.312(c) | Integrity — guard against improper alteration or destruction of ePHI; mechanism to authenticate it |
| §164.312(d) | Person or Entity Authentication — verify that whoever accesses ePHI is who they claim to be |
| §164.312(e) | Transmission Security — protect ePHI in transit over networks |
Highlighted rows are the three standards a source-code scan can genuinely surface control-defeating bugs for. Access Control and Audit Controls are architecture and process questions a scanner cannot answer.
Where StaticCodeAudit actually fits
(c) Integrity
If a cryptographic hash or signature is meant to authenticate ePHI or detect tampering, its strength is a code-level property. Weak algorithms or predictable randomness undermine the mechanism regardless of how well the surrounding process is designed:
weak_crypto, weak_random_java, insecure_random
(d) Person or Entity Authentication
The largest overlap. Authentication is implemented in code, and several rules map directly to concrete authentication weaknesses:
missing_mfa_python/javascript/java/csharp, jwt_none_algorithm, jwt_hardcoded_secret, default_credentials, weak_password_policy
(e) Transmission Security
Whether a connection actually enforces TLS, and whether the encryption itself is strong, are both directly observable in source code:
http_no_tls, unencrypted_transfer, weak_crypto
Every rule above fires as part of a standard scan:
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-highThe SARIF export gives each finding a file, a line, a rule ID and a severity — a dated, repeatable record for the three standards above, not a certification. See the SARIF export guide.
What this doesn't cover — the honest list
A source-code scanner cannot produce evidence for most of the Security Rule, and the gap is structural, not a roadmap item:
- §164.312(a) Access Control — whether the right people have the right access is an authorization/architecture question, not a syntax pattern (though hardcoded credentials and default credentials are flagged as a related, narrower issue).
- §164.312(b) Audit Controls — whether comprehensive, tamper-evident audit logging actually exists across a system is an architecture question a scan cannot confirm one way or the other.
- §164.308 Administrative Safeguards (all of it) — risk analysis, workforce training, sanction policy, contingency planning: organisational process, not code.
- §164.310 Physical Safeguards (all of it) — facility access, workstation security, device and media controls: physical world, unrelated to source code.
One input to the Security Risk Analysis
HIPAA requires covered entities and business associates to conduct a Risk Analysis under §164.308(a)(1) — "an accurate and thorough assessment of the potential risks and vulnerabilities" to ePHI confidentiality, integrity and availability. A repeatable, offline, dated scan of the application code that touches ePHI is one legitimate input to that broader assessment — not the assessment itself, and not a substitute for the organisational process §164.308 actually requires.
A separate point: verifying the tool itself
This is worth being precise about, since it's easy to conflate with ePHI integrity above: verifying that the StaticCodeAudit binary you download hasn't been tampered with (SHA-256 hash comparison) is due diligence on the tool as a new piece of your software supply chain — a different concern from whether your own application's ePHI-handling code has a cryptographic weakness. See the regulated industries page for the current state of binary integrity verification.
Frequently asked questions
Does using StaticCodeAudit make my application HIPAA compliant?
No — and no software tool does. HIPAA compliance is an organisational determination covering all three safeguard categories (Administrative, Physical, Technical), most of which are policy and process. StaticCodeAudit produces code-level evidence for 3 of the 5 Technical Safeguards standards, as one input among many, not a certification.
Am I a "covered entity" or "business associate" under HIPAA?
That is a legal determination for your organisation's counsel or compliance officer — it depends on whether you create, receive, maintain or transmit ePHI on behalf of a covered entity, not on anything a scanner output can answer.
Does the scan output reference HIPAA directly?
No — findings are tagged with CWE and, where mapped, OWASP ASVS and ISO 27001 identifiers (standard, vendor-neutral references). The connection to a specific HIPAA safeguard, as described on this page, is something your compliance process draws — it is not encoded in the SARIF file itself.
Are "addressable" HIPAA specifications optional?
No — "addressable" means an organisation must implement the specification as written, implement an equivalent alternative, or formally document why neither is reasonable and appropriate for its environment, with compensating controls. It is a flexibility mechanism, not an exemption.
See the real evidence a scan produces
Open the live demo report — no install, no signup — and look at the findings and SARIF export directly.
Open the live report Read more on the regulated industries page