Skip to main content

Your PHI never leaves the machine that wrote the code.

Healthcare engineering teams (EHR vendors, telehealth platforms, medical-billing SaaS, HIPAA business associates) have an awkward choice when they pick a SAST tool. The static analyzer reads the code that handles patient data. The code references your schemas (Patient, Encounter, MedicalRecord), your access-control logic, and the dataflow that produces 837 / 835 / CCDA exchanges. A cloud SAST vendor that ingests that code is, in a literal HIPAA sense, processing data that describes how PHI moves through your application.

Vulkro is the offline option. A single static binary that runs on your laptop or your CI runner, never phones home, and emits the HIPAA Security Rule mapping your auditor wants on paper.

What HIPAA asks your codebase to prove

The Security Rule auditor will look at your application code for the same patterns a security engineer would, but framed in the language of "administrative" and "technical" safeguards. The short list of code-level questions:

  • Access control on PHI. Can a logged-in but unauthorised user read another patient's record by walking the URL or swapping an ID? Vulkro's auth-dataflow and IDOR / BOLA detectors catch the unguarded handler.
  • Auth on PHI-touching endpoints. Does every route that loads a Patient, Encounter, or Claim shape pass through an authentication and authorisation gate? Vulkro maps this per-endpoint.
  • Audit-log coverage on PHI reads. Every PHI read path needs a corresponding audit-log write at the same call site. Vulkro flags the gap.
  • Encryption at rest and in transit. MD5, SHA-1, DES, or RC4 used anywhere on a PHI path is a finding. TLS configurations without forward secrecy or accepting TLS 1.0 / 1.1 are findings.
  • Hardcoded credentials for upstream integrations. Clearinghouse, pharmacy benefit manager, labs APIs. Anything in source or git history.
  • Unsafe deserialisation on partner-supplied data. Pickled payloads, yaml.load, JSON deserialised straight into a model without validation.
  • PHI shapes in logs, errors, and responses. Patient identifiers, medical record numbers, date-of-birth-plus-name combinations leaking into a place they should not be.

Concrete detector → control mapping:

Vulkro detector familyWhat it catchesHIPAA safeguard family
auth_dataflowEndpoints reaching PHI shapes without an auth check at handler entryAccess control + authentication
idor / BOLACode that loads a Patient / Encounter by id without an ownership checkAccess control
crypto_weaknessMD5 / SHA-1 / DES on PHI fields; non-PFS TLS configurationsEncryption (at rest, in transit)
secretsHardcoded API keys for clearinghouse, pharmacy benefit manager, or labs integrationsWorkforce security + access management
audit_log_gapPHI read paths missing the audit-log write at the same call siteAudit controls
unsafe_deserializePickled / YAML.load on data sourced from a partner integrationIntegrity + risk management
pii (PHI shapes)Patient identifiers, MRNs, DOB+name combinations leaking into logs / error messages / responsesPHI minimum necessary

vulkro compliance --profile hipaa (Free) prints the same mapping with the exact 45 CFR Part 164 clause numbers your auditor wants cited. The Pro vulkro compliance-pack --framework hipaa adds a signed, audit-ready PDF.

PHI detection across the stack you actually use

The naming and pattern catalog covers the standard PHI shapes across the languages and frameworks healthcare teams write in:

  • Python: Django and FastAPI model attributes named patient, mrn, dob, ssn, diagnosis, npi. SQLAlchemy table columns with the same shapes. FastAPI response models that serialize PHI without filtering.
  • JavaScript / TypeScript: Node / Express / Nest / Next.js handlers and React component prop types. JSON serialization paths that include patient, mrn, dob, medications.
  • Go: Struct fields tagged for JSON marshalling with PHI shapes; gorm models with the same shapes.
  • Salesforce (Pro): The sf_pii_map module recognises the standard Salesforce SObjects (Account, Contact, Lead, Case, User) that Health Cloud and ISV apps extend. PHI tagging flows through to the AppExchange Security Review report.
  • Salesforce Health Cloud (Pro): The Industries Clouds detector pack walks HealthCloudGA__* and vlocity_* SObjects, catches PHI cross-component leakage via @AuraEnabled returns, and flags the FSC AccountShare = Edit/All pattern reachable from a request-context method. Six rules (IND-001..006), High severity on the PHI-leak shapes.
  • Salesforce Marketing Cloud (Pro): The Marketing Cloud detector pack flags AMPscript injection and SSJS server-side eval on patient-segment Cloud Pages and templates that touch PHI fields.
  • Heroku Connect for healthcare on Heroku (Pro): The Heroku Connect detector pack catches PHI fields (SSN__c, DateOfBirth, Patient_MRN__c) replicated to Heroku Postgres without a redaction transform, and SQL schemas that read the mapped column with no pgcrypto column-level encryption.

The detection is structural, not regex over file contents. A SOQL select that pulls a Contact's birthdate into an Apex controller flagged with HIPAA tier 1; a FastAPI response model that returns mrn without a serializer filter flagged the same way.

Business Associate Agreements: what changes

A Business Associate Agreement (BAA) is the contract a covered entity signs with any vendor that may receive, transmit, or store PHI on their behalf. The Security Rule explicitly extends BAA obligations to subcontractors.

A cloud SAST vendor that ingests your application code is, by the plain reading of HIPAA, a potential business associate. The code references PHI shapes, the dataflow between them, and the access-control logic that protects them. Vendors disagree on whether their static analyzer "really" receives PHI (the source code is not the data itself), but the conservative reading from most healthcare general counsels is: if the vendor reasonably could reconstruct PHI dataflow from what they receive, list them.

Vulkro receives no source code. Ever. The binary runs on your machine, reads files on your filesystem, writes a report. No account, no telemetry, no upload, no remote control plane. The manifesto covers the architectural commitment in full.

The downstream consequence: Vulkro does not require a BAA because there is no business-associate relationship to govern. Your security and compliance team can adopt the scanner without the 8-to-12-week vendor-onboarding cycle a new BAA implies.

vulkro compliance --profile hipaa

The Free tier ships the HIPAA mapping subcommand. Output is a control-by-control breakdown showing which findings touch which Security Rule citation:

vulkro compliance --profile hipaa

Sample row (truncated):

164.312(a)(1) Access control
PASS No auth-bypass findings on PHI-tagged endpoints.
FAIL 3 findings (high severity) on /api/v1/patient/{id} family.
See findings: AUTH-0042, IDOR-0017, IDOR-0019.

The command writes to stdout by default, JSON via --format json, or HTML via --format html for handing to a non-engineering auditor. Run vulkro compliance --help for the live list of supported profiles (HIPAA, SOC 2, ISO 27001, PCI DSS, GDPR, NIST 800-53, others).

vulkro compliance-pack --framework hipaa (Pro)

The Pro tier ships the signed evidence-pack output. This is the artefact you hand to the auditor: a control-by-control HIPAA report, with findings cross-referenced, signed so the auditor can verify the report was generated against a specific commit:

vulkro compliance-pack --framework hipaa --output hipaa.pdf

The pack includes:

  • An executive summary with finding counts by severity and by control family.
  • A control-by-control narrative: for each Security Rule citation Vulkro maps to, what was checked and what was found.
  • A cryptographic signature over the report body, the commit hash, and a timestamp. The signature verifies offline with vulkro compliance-pack verify.

The PDF and HTML outputs are self-contained (no external CSS, no fonts loaded over the network, no JavaScript) so the auditor can open them on an air-gapped review machine if their compliance process requires it.

At a glance: Vulkro vs typical cloud SAST

VulkroTypical cloud SAST
Code uploaded for scanningNeverYes
BAA requiredNoOften (varies by vendor)
TelemetryNoneMandatory, account-scoped
Network at scan timeOptional (CVE bundle download or air-gap)Required
Air-gap deployment for classified VA / DoD workAvailableLimited
HIPAA mapping subcommandFreeBehind enterprise tier (commonly)
Signed evidence packPro (Pro Monthly $19, Pro Annual $149)Enterprise-only or external add-on
Vendor SOC 2 neededNo (no data shared)Yes
Account requiredNoneYes

The "no BAA" property is the load-bearing one. It is also the property a cloud-first competitor cannot match without architectural surgery.

Use cases we hear from

  • EHR vendors and platform startups. Multi-tenant access control, audit-log completeness, and the SCIM / FHIR integration boundary.
  • Telehealth platforms. Auth on video-session join paths, rate-limit + replay protection on appointment APIs, PHI in webhook payloads to insurance verifiers.
  • Medical billing and revenue-cycle SaaS. 837 / 835 parsing safety, callout-credential audit for clearinghouses, PHI logging gaps.
  • HIPAA business associates. Any team contractually required to demonstrate Security Rule compliance to a covered-entity customer.
  • Hospital and health-system internal engineering. Same needs, with the additional constraint that internal counsel often forbids cloud SAST entirely.

Talk to us

If you are evaluating Vulkro for a HIPAA-regulated workload and want to walk through the mapping, the evidence-pack format, or the air-gap deployment recipe, email [email protected].

Read the manifesto for the architectural commitment. See the compliance docs for the full HIPAA control mapping. See the benchmark for reproducible detection numbers.