PHI is already inyour application logs.
HIPAA's audit control requirement mandates logging for every system that handles PHI - and most codebases write PHI to application logs without realizing it.
- Source: 45 CFR 164.312(b), HIPAA Security Rule Technical Safeguards (HHS, 2003, as amended).
PHI exposure at the code level, not the infrastructure level
logger.info() is a HIPAA violation waiting to surface.
HIPAA requires audit controls to record and examine PHI access activity. The most common code-level violation: patient objects serialized into application logs. HHS OCR cites audit control failures in the majority of investigated breaches.
45 CFR 164.312(b); HHS OCR Breach Portal, 2023 Annual ReportOne missing authorization check exposes every patient.
BOLA on patient APIs - returning records without validating that the requesting clinician's organization matches the patient's - is the most common code-level PHI exposure pattern. HIPAA's Minimum Necessary standard requires APIs to return only the PHI required for the stated purpose.
45 CFR 164.502(b) Minimum Necessary; OWASP API1:2023Hardcoded credentials appear in 40% of breach investigations.
HIPAA requires encryption with access-controlled key management. Hardcoded database credentials and API keys committed to source repositories are the most cited technical control failure in HHS OCR post-breach investigations.
45 CFR 164.312(a)(2)(iv); HHS OCR, Lessons Learned from HIPAA Investigations (2022)HIPAA technical safeguards at the code level, not just the policy level
PHI in logs
- Scanner patterns detect object serialization in logging calls - patient, record, encounter objects written to log sinks
- Issues execute as changes: logger calls restructured to log only identifiers, not full objects
- Continuous scanning catches the pattern every time it reappears in future code
Missing authorization checks
- Audit workflow detects API endpoints that access patient-keyed resources without visible ownership validation
- Changes enforce tenant/organization membership checks before record retrieval
- Every patient-facing API endpoint is in scope
Hardcoded credentials
- Deterministic scanner patterns catch hardcoded secrets, connection strings, and API keys in source
- Changes execute environment variable extraction before the credential is committed to history
- Continuous scanning catches the pattern every time it recurs
What HIPAA Technical Safeguards require at the code level
| Safeguard | Requirement | Hyrax |
|---|---|---|
| 164.312(a)(1) | Access control - unique user identification | Scans for shared credentials and generic usernames |
| 164.312(a)(2)(iv) | Encryption with access-controlled key management | Detects hardcoded keys; enforces environment variables |
| 164.312(b) | Audit controls - logging for all PHI access | Detects PHI serialized into logs; changes logging calls |
| 164.312(c)(1) | Integrity - PHI not improperly altered | Validates PHI modification paths require authentication |
| 164.312(e)(1) | Transmission security - PHI encrypted in transit | Detects plaintext PHI transmission patterns |
| 164.502(b) | Minimum Necessary - APIs return only required PHI | Flags generic endpoints returning full patient records |
Source: 45 CFR Part 164, HIPAA Security Rule (HHS, 2003, as amended through 2024).
Common questions
from healthtech engineering teams
Does Hyrax produce evidence for HIPAA audits?
Every issue and upgrade is logged as a PR with full attribution: issue type, code location, upgrade diff, test results, and merge timestamp. This produces a documented remediation timeline for OCR investigations.
We use a HIPAA-compliant hosting provider. Does this still matter?
Yes. BAA coverage from AWS, Azure, or GCP applies to infrastructure, not application code. OCR investigations consistently surface that breaches originate in application logic - logging, authorization, and credential management.
What's different from a penetration test?
Penetration testing is periodic and runs against deployed systems. Hyrax scans source code continuously - before deployment. The two are complementary, not substitutes.
Our EHR vendor handles the PHI. Do we still need this?
If your application exchanges data with the EHR via API, your code handles PHI in transit and in memory. Every API response that contains a patient identifier, diagnosis code, or medication name is PHI.
Does Hyrax work with FHIR APIs?
Yes. FHIR resources (Patient, Observation, MedicationRequest) are PHI. Hyrax's authorization gap detection applies to FHIR API endpoints the same as any patient-keyed resource.