Skip to main content

Your PHI never leaves the machine that wrote the code.

Healthcare teams now merge AI-written code into systems that handle patient data, and HIPAA does not care who or what wrote the line. Your auditor will ask for evidence that the code touching PHI was reviewed for security before release. Vulkro produces that evidence on your machine, without your codebase or your findings ever leaving it.

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 prints the same mapping with the exact 45 CFR Part 164 clause numbers your auditor wants cited, and vulkro compliance-pack --framework hipaa adds a signed, audit-ready PDF. The 14-day trial and the issued license both cover the full product, including the evidence packs.

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: Health Cloud PHI mapping, Industries Clouds, Marketing Cloud, and Heroku Connect coverage is the separate Vulkro for Salesforce product (the vulkro-sf binary), not the general vulkro scanner.

The detection is structural, not regex over file contents. A FastAPI response model that returns mrn without a serializer filter is flagged with HIPAA tier 1; a Django model attribute named diagnosis serialized without a filter is 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 upload and no remote control plane; the account entitlement check carries six usage fields (product, install id, version, operating system, timestamp, and a scan counter), never code, paths, or findings, and air-gapped machines run on a license file with no network access at all. 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 scanner 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

The scanner 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)
TelemetrySix usage fields, never code or findingsMandatory, account-scoped
Network at scan timeNot required (scan is local; air-gap supported via license file)Required
Air-gap deployment for classified VA / DoD workAvailableLimited
HIPAA mapping subcommandIncludedBehind enterprise tier (commonly)
Signed evidence packIncludedEnterprise-only or external add-on
Vendor SOC 2 neededNo (no code shared)Yes
Account requiredYes, but it never sees your codeYes

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.

Deployment fit

  • Offline by architecture. The scan runs on your machine or your CI runner; nothing about your code crosses the wire.
  • Air-gapped environments (classified VA / DoD work, hospital networks with strict egress) run on a signed license file with no network access; CVE bundles arrive by sneakernet.
  • CI gating uses the standard exit-code contract (0 clean, 1 findings, 2 error) and SARIF output, so the rescan loop lives in the pipeline.
  • Evidence retention is yours: the compliance output and signed evidence packs are files on your infrastructure, kept under your own retention policy, openable on an air-gapped review machine.

Honest scope

Vulkro is a static analyzer, not a compliance certification and not a substitute for your risk analysis. It produces code-level evidence for the Security Rule's technical safeguards; it does not attest your administrative or physical safeguards, does not audit your BAA chain, and a clean scan does not make an application HIPAA-compliant on its own. It is also not a pentest: it reads code, it does not probe running systems.

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