Die HIPAA Security Rule in einem Absatz
HIPAA (der US-amerikanische Health Insurance Portability and Accountability Act) gilt für „covered entities" (Krankenversicherungen, Gesundheits-Clearingstellen, die meisten Gesundheitsdienstleister) und deren „business associates" — was jeden Softwareanbieter oder jedes Entwicklungsteam einschließt, das Systeme baut, die elektronische Protected Health Information (ePHI) berühren. Die Security Rule gliedert erforderliche Schutzmaßnahmen in drei Kategorien: Administrative (§164.308 — Richtlinien, Risikoanalyse, Schulung), Physical (§164.310 — Zugang zu Einrichtungen und Geräten) und Technical (§164.312 — die tatsächlichen Kontrollen auf Systemebene). Die meisten Implementierungsspezifikationen sind „addressable", nicht universell „required": eine Organisation muss die Schutzmaßnahme, eine gleichwertige Alternative umsetzen oder dokumentieren, warum keines von beiden für ihre Situation angemessen ist.
Die 5 Technical-Safeguards-Standards (§164.312)
Dies ist der einzige Teil der Security Rule, der Kontrollen auf Systemebene statt organisatorische Richtlinien beschreibt — zitiert aus der Verordnung und HHS-Leitfäden:
| Zitat | Standard |
|---|---|
| §164.312(a) | Access Control — technische Richtlinien, die den Zugriff auf ePHI auf autorisierte Personen und Software beschränken |
| §164.312(b) | Audit Controls — Mechanismen zur Aufzeichnung und Überprüfung von Aktivitäten in Systemen, die ePHI verarbeiten |
| §164.312(c) | Integrity — Schutz vor unbefugter Änderung oder Zerstörung von ePHI; Mechanismus zu deren Authentifizierung |
| §164.312(d) | Person or Entity Authentication — verifizieren, dass jeder, der auf ePHI zugreift, tatsächlich die behauptete Person ist |
| §164.312(e) | Transmission Security — ePHI bei der Übertragung über Netzwerke schützen |
Hervorgehobene Zeilen sind die drei Standards, für die ein Quellcode-Scan echt kontrollgefährdende Bugs aufdecken kann. Access Control und Audit Controls sind Architektur- und Prozessfragen, die ein Scanner nicht beantworten kann.
Wo StaticCodeAudit tatsächlich passt
(c) Integrity
Wenn ein kryptografischer Hash oder eine Signatur ePHI authentifizieren oder Manipulation erkennen soll, ist deren Stärke eine Code-Eigenschaft. Schwache Algorithmen oder vorhersagbarer Zufall untergraben den Mechanismus, unabhängig davon, wie gut der umgebende Prozess gestaltet ist:
weak_crypto, weak_random_java, insecure_random
(d) Person or Entity Authentication
Die größte Überschneidung. Authentifizierung wird im Code implementiert, und mehrere Regeln beziehen sich direkt auf konkrete Authentifizierungsschwächen:
missing_mfa_python/javascript/java/csharp, jwt_none_algorithm, jwt_hardcoded_secret, default_credentials, weak_password_policy
(e) Transmission Security
Ob eine Verbindung TLS tatsächlich durchsetzt und ob die Verschlüsselung selbst stark ist, sind beides direkt im Quellcode beobachtbare Eigenschaften:
http_no_tls, unencrypted_transfer, weak_crypto
Jede obige Regel löst als Teil eines Standard-Scans aus:
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-highDer SARIF-Export gibt jedem Fund eine Datei, eine Zeile, eine Regel-ID und einen Schweregrad — ein datierter, wiederholbarer Nachweis für die drei obigen Standards, keine Zertifizierung. Siehe den SARIF-Export-Leitfaden.
Was das nicht abdeckt — die ehrliche Liste
Ein Quellcode-Scanner kann für den Großteil der Security Rule keinen Nachweis erbringen, und die Lücke ist strukturell, kein Roadmap-Punkt:
- §164.312(a) Access Control — ob die richtigen Personen den richtigen Zugriff haben, ist eine Autorisierungs-/Architekturfrage, kein Syntaxmuster (wenngleich hartkodierte und Standard-Zugangsdaten als verwandtes, engeres Problem markiert werden).
- §164.312(b) Audit Controls — ob ein umfassendes, manipulationssicheres Audit-Logging tatsächlich systemweit existiert, ist eine Architekturfrage, die ein Scan nicht klären kann.
- §164.308 Administrative Safeguards (insgesamt) — Risikoanalyse, Mitarbeiterschulung, Sanktionspolitik, Notfallplanung: organisatorischer Prozess, kein Code.
- §164.310 Physical Safeguards (insgesamt) — Zugang zu Einrichtungen, Sicherheit von Arbeitsplätzen, Kontrolle von Geräten und Medien: physische Welt, ohne Bezug zum Quellcode.
Ein Input für die Security Risk Analysis
HIPAA verlangt von covered entities und business associates, eine Risk Analysis nach §164.308(a)(1) durchzuführen — „eine genaue und gründliche Bewertung der potenziellen Risiken und Schwachstellen" für Vertraulichkeit, Integrität und Verfügbarkeit von ePHI. Ein wiederholbarer, offline durchgeführter, datierter Scan des Anwendungscodes, der ePHI berührt, ist ein legitimer Input für diese breitere Bewertung — nicht die Bewertung selbst, und kein Ersatz für den organisatorischen Prozess, den §164.308 tatsächlich verlangt.
Ein separater Punkt: das Tool selbst verifizieren
Das lohnt sich, präzise zu formulieren, da es leicht mit der ePHI-Integrität oben verwechselt wird: zu verifizieren, dass die heruntergeladene StaticCodeAudit-Binary nicht manipuliert wurde (SHA-256-Hash-Vergleich), ist Sorgfaltspflicht gegenüber dem Tool als neuem Bestandteil Ihrer Software-Lieferkette — ein anderes Anliegen als die Frage, ob der ePHI-verarbeitende Code Ihrer eigenen Anwendung eine kryptografische Schwäche aufweist. Siehe die Seite für regulierte Branchen für den aktuellen Stand der Binary-Integritätsprüfung.
Häufig gestellte Fragen
Macht die Nutzung von StaticCodeAudit meine Anwendung HIPAA-konform?
Nein — und kein Software-Tool tut das. HIPAA-Konformität ist eine organisatorische Feststellung, die alle drei Schutzmaßnahmenkategorien (Administrative, Physical, Technical) abdeckt, von denen die meisten Richtlinie und Prozess sind. StaticCodeAudit erzeugt Code-Level-Nachweise für 3 der 5 Technical-Safeguards-Standards, als einen Input unter vielen, keine Zertifizierung.
Bin ich eine „covered entity" oder ein „business associate" nach HIPAA?
Das ist eine rechtliche Feststellung, die die Rechtsabteilung oder der Compliance-Beauftragte Ihrer Organisation treffen muss — sie hängt davon ab, ob Sie ePHI im Auftrag einer covered entity erstellen, empfangen, aufbewahren oder übertragen, nicht von etwas, das eine Scanner-Ausgabe beantworten kann.
Referenziert die Scan-Ausgabe HIPAA direkt?
Nein — Funde werden mit CWE und, wo ein Mapping existiert, mit OWASP-ASVS- und ISO-27001-Kennungen versehen (standardisierte, anbieterneutrale Referenzen). Die Verbindung zu einer bestimmten HIPAA-Schutzmaßnahme, wie auf dieser Seite beschrieben, zieht Ihr Compliance-Prozess — sie ist nicht in der SARIF-Datei selbst kodiert.
Sind „addressable" HIPAA-Spezifikationen optional?
Nein — „addressable" bedeutet, dass eine Organisation die Spezifikation wie geschrieben umsetzen, eine gleichwertige Alternative umsetzen oder formal dokumentieren muss, warum keines von beiden für ihre Umgebung angemessen ist, mit kompensierenden Kontrollen. Es ist ein Flexibilitätsmechanismus, keine Befreiung.
Die echten Nachweise sehen, die ein Scan erzeugt
Öffnen Sie den Live-Demo-Bericht — keine Installation, keine Anmeldung — und sehen Sie sich die Funde und den SARIF-Export direkt an.
Live-Bericht öffnen Mehr auf der Seite für regulierte Branchen