HIPAA Security Rule Source Code Compliance

HIPAA risk analysis evidence from the code behind your ePHI systems

The Security Rule asks you to identify the vulnerabilities in the systems that handle ePHI, reduce them to a reasonable level, and keep the documentation. Codacy analyzes every code change and records the result.

HIPAA — Health Insurance Portability & Accountability Act

Trusted by 15,000+ organizations and 200,000+ developers worldwide

Virta Zalando Delivery Hero Bamboo Health Genesys Evolv NASA Fathom Napier LIXIL

How Codacy supports
your HIPAA Security Rule evidence

Requirement
What it asks for
Codacy’s coverage
164.308(a)(1)(ii)(A) Risk analysis

An accurate and thorough assessment of the potential risks and vulnerabilities to the ePHI you hold

Codacy surfaces supported weaknesses in code, dependencies, infrastructure-as-code files and secrets across your connected repositories.

164.308(a)(1)(ii)(B) Risk management

Security measures to reduce risks and vulnerabilities to an appropriate level

Severity levels and configurable remediation deadlines, with overdue status, so reduction is tracked against deadlines you set.

164.308(a)(1)(ii)(D) Information system activity review

Procedures to regularly review records of information system activity

Audit logs record selected changes to Codacy settings, members and tokens, so a change to what gets analyzed is itself a reviewable record.

164.308(a)(5)(ii)(B) Protection from malicious software

Procedures for guarding against, detecting and reporting malicious software

Dependency scanning checks your manifest files daily against the OpenSSF Malicious Packages database for known malware, and against public CVE and advisory data for known-vulnerable components.

164.308(a)(8) Evaluation

Periodic evaluation of changes affecting ePHI security

Analysis runs on every pull request and commit, so a technical check follows each change. Usage reporting shows which repositories are analyzed and which are not.

164.312(c)(1) Integrity

Policies and procedures to protect ePHI from improper alteration or destruction

Code analysis flags injection, input validation and mass assignment patterns. Infrastructure-as-code checks catch datastores defined without backup retention, versioning or deletion protection. Secrets detection catches credentials that would allow either.

164.316(b)(1) Documentation

Policies, procedures, actions, activities and assessments maintained in writing, and kept for six years

Codacy gives you findings, analysis history and CSV export as a written record of the activity. Audit logs are saved for one year.

“Codacy has improved communication between security and development teams, and it’s continuing to raise the bar for compliance.”

David Morton Manager of Security Operations at Genesys

90%accuracy rate in security findings
1,200security issues closed vs a “few hundred” before
900+repositories and 1,400 developers scaled to
David Morton, Manager of Security Operations at Genesys

HIPAA Security Rule evidence
for engineering leaders

Connect your Git organization in two clicks. First evidence report the same day.

Evaluation

A recorded check on every change

Set the security thresholds you want a pull request to meet. Codacy evaluates each change against them and posts the result as a status check: a dated record of what was tested on the code that handles ePHI. 164.308(a)(8) asks for periodic evaluation and re-evaluation when things change; a check on every pull request gives you dated evidence for both.

A pull request showing three successful checks and a passed Codacy quality gate
Risk analysis

Every finding in one view

Code scanning, infrastructure-as-code and exposed secrets report into a single findings view, alongside open-source dependency and application scanning findings, with severity and overdue status. Export it as CSV for the risk analysis and the risk management plan behind it.

Security findings dashboard showing open, critical, overdue and prevented issues
Known vulnerabilities

Component inventory, rescanned daily

See which open-source components the applications that handle ePHI depend on, at which versions, and which repositories use an affected version — the software half of the inventory 164.308(a)(1)(ii)(A) asks your risk analysis to cover. Rescanned daily, so a newly disclosed vulnerability surfaces at the next daily rescan rather than at the next code change.

Dependency inventory listing packages, how many repositories use each, and severity-ranked findings

SAST on every commit

Injection and input validation patterns that let data be altered improperly (164.312(c)(1)), authentication and authorization weaknesses in the code behind access control (164.312(a)(1), 164.312(d)), and weak cryptographic and insecure transport patterns (164.312(e)(1)) — all identified before merge.

Malicious package detection

Manifest files are checked against the OpenSSF Malicious Packages database, so a typosquat or a hijacked dependency is flagged on the pull request that introduces it — the supply-chain side of 164.308(a)(5)(ii)(B).

Secrets caught before commit

Supported secret patterns detected in analyzed code and in the IDE, so credentials to the systems holding ePHI are not sitting in a repository — the code side of 164.312(a)(1).

Deadlines and overdue status

Set a remediation deadline per severity, and every finding shows as on track, due soon or overdue. Those deadlines become your documented definition 164.308(a)(1)(ii)(B) asks for.

Repository coverage report

164.308(a)(8) evaluation is scoped to the systems that handle ePHI. Report which repositories are analyzed and which are not, so the gap is visible to you before it is visible to an assessor, with CSV and JSON export.

CSV findings export

Export severity-ranked findings and remediation records into your own evidence store, where the six-year record lives.

Frequently asked questions

Does the Security Rule require static analysis or code review?

45 CFR Part 164 Subpart C requires an accurate and thorough risk analysis, measures sufficient to reduce what that analysis finds, periodic technical evaluation, and six years of documentation. Under 164.306(b) the method is yours. For an organization that writes the software handling ePHI, code analysis is a defensible answer to those obligations, not a named requirement.

Does this apply if we are pursuing HITRUST?

Mostly, yes. Healthcare organizations commonly use HITRUST certification as the evidence vehicle for their HIPAA program, and the same dated analysis records serve both. Certification attaches to your organization for an assessed scope, so a tool contributes evidence to a control rather than satisfying one. HITRUST itself says an assessment should not be submitted alone to demonstrate Security Rule compliance: OCR expects a narrative response and a valid risk analysis alongside it — the first row of the table above. Ask us for the Category 10 detail on the call.

Do our developers have to change how they work?

Analysis runs on pull requests in the Git provider they already use, results post as a status check, nothing new to open.

What do we actually hand an assessor?

A CSV export of findings with severity and remediation status, the analysis history for each repository, the status check recorded on every pull request, and a coverage report showing which repositories were in scope.

Risk analysis refresh or
security questionnaire coming up?

See your first evidence report today. Bring your current risk analysis or the questionnaire a covered entity has sent you. Talk to our team about:

  • The repositories and languages that handle ePHI.
  • The severities and deadlines your risk management plan commits to.
  • The records you need to keep for six years.