La HIPAA Security Rule en un paragraphe
HIPAA (la loi américaine Health Insurance Portability and Accountability Act) s'applique aux « covered entities » (organismes de santé, chambres de compensation santé, la plupart des prestataires de soins) et à leurs « business associates » — ce qui inclut tout éditeur logiciel ou équipe de développement construisant des systèmes qui touchent des Protected Health Information électroniques (ePHI). La Security Rule organise les mesures requises en trois catégories : Administrative (§164.308 — politiques, analyse de risque, formation), Physical (§164.310 — accès aux locaux et aux appareils), et Technical (§164.312 — les contrôles réels au niveau système). La plupart des spécifications d'implémentation sont « addressable », pas universellement « required » : une organisation doit implémenter la mesure, une alternative équivalente, ou documenter pourquoi ni l'une ni l'autre n'est raisonnable et appropriée pour sa situation.
Les 5 standards Technical Safeguards (§164.312)
C'est la seule partie de la Security Rule qui décrit des contrôles au niveau système plutôt qu'une politique organisationnelle — citée depuis le règlement et les guides HHS :
| Citation | Standard |
|---|---|
| §164.312(a) | Access Control — politiques techniques limitant l'accès aux ePHI aux personnes et logiciels autorisés |
| §164.312(b) | Audit Controls — mécanismes pour enregistrer et examiner l'activité des systèmes traitant des ePHI |
| §164.312(c) | Integrity — se prémunir contre l'altération ou la destruction non autorisée des ePHI ; mécanisme pour les authentifier |
| §164.312(d) | Person or Entity Authentication — vérifier que quiconque accède aux ePHI est bien qui il prétend être |
| §164.312(e) | Transmission Security — protéger les ePHI en transit sur les réseaux |
Les lignes en surbrillance sont les trois standards pour lesquels un scan de code source peut réellement faire remonter des bugs qui compromettent le contrôle. Access Control et Audit Controls sont des questions d'architecture et de processus qu'un scanner ne peut pas trancher.
Où StaticCodeAudit se situe réellement
(c) Integrity
Si un hash ou une signature cryptographique est censé authentifier des ePHI ou détecter une altération, sa robustesse est une propriété du code. Un algorithme faible ou un aléa prévisible compromet le mécanisme, peu importe la qualité du processus environnant :
weak_crypto, weak_random_java, insecure_random
(d) Person or Entity Authentication
Le plus grand recoupement. L'authentification est implémentée dans le code, et plusieurs règles se rattachent directement à des faiblesses d'authentification concrètes :
missing_mfa_python/javascript/java/csharp, jwt_none_algorithm, jwt_hardcoded_secret, default_credentials, weak_password_policy
(e) Transmission Security
Qu'une connexion applique réellement TLS, et que le chiffrement lui-même soit robuste, sont deux points directement observables dans le code source :
http_no_tls, unencrypted_transfer, weak_crypto
Chaque règle ci-dessus se déclenche dans le cadre d'un scan standard :
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-highL'export SARIF donne à chaque finding un fichier, une ligne, un ID de règle et une sévérité — un enregistrement daté et reproductible pour les trois standards ci-dessus, pas une certification. Voir le guide export SARIF.
Ce que cela ne couvre pas — la liste honnête
Un scanner de code source ne peut pas produire de preuve pour la majorité de la Security Rule, et l'écart est structurel, pas un point de roadmap :
- §164.312(a) Access Control — savoir si les bonnes personnes ont les bons accès est une question d'autorisation/architecture, pas un motif syntaxique (même si les identifiants en dur et par défaut sont signalés comme un problème apparenté, plus étroit).
- §164.312(b) Audit Controls — savoir si une journalisation d'audit complète et infalsifiable existe réellement sur l'ensemble d'un système est une question d'architecture qu'un scan ne peut pas trancher.
- §164.308 Administrative Safeguards (en totalité) — analyse de risque, formation du personnel, politique de sanctions, plan de continuité : processus organisationnel, pas du code.
- §164.310 Physical Safeguards (en totalité) — accès aux locaux, sécurité des postes de travail, contrôle des appareils et supports : monde physique, sans rapport avec le code source.
Une donnée d'entrée pour la Security Risk Analysis
HIPAA exige des covered entities et business associates qu'ils mènent une Risk Analysis au titre du §164.308(a)(1) — « une évaluation précise et complète des risques et vulnérabilités potentiels » pour la confidentialité, l'intégrité et la disponibilité des ePHI. Un scan reproductible, hors-ligne et daté du code applicatif qui touche des ePHI est une donnée d'entrée légitime pour cette évaluation plus large — pas l'évaluation elle-même, et pas un substitut au processus organisationnel que le §164.308 exige réellement.
Un point distinct : vérifier l'outil lui-même
Cela mérite d'être précis, car il est facile de confondre avec l'intégrité des ePHI ci-dessus : vérifier que le binaire StaticCodeAudit téléchargé n'a pas été altéré (comparaison de hash SHA-256) relève de la diligence sur l'outil en tant que nouvel élément de votre chaîne d'approvisionnement logicielle — une préoccupation différente de savoir si le code de votre propre application qui manipule des ePHI a une faiblesse cryptographique. Voir la page secteurs réglementés pour l'état actuel de la vérification d'intégrité du binaire.
Questions fréquentes
Utiliser StaticCodeAudit rend-il mon application conforme HIPAA ?
Non — et aucun outil logiciel ne le fait. La conformité HIPAA est une détermination organisationnelle couvrant les trois catégories de mesures (Administrative, Physical, Technical), dont la plupart relèvent de politiques et de processus. StaticCodeAudit produit des preuves au niveau code pour 3 des 5 standards Technical Safeguards, comme une donnée d'entrée parmi d'autres, pas une certification.
Suis-je une « covered entity » ou un « business associate » au sens HIPAA ?
C'est une détermination juridique à faire par le conseil ou le responsable conformité de votre organisation — cela dépend de si vous créez, recevez, conservez ou transmettez des ePHI pour le compte d'une covered entity, pas de quelque chose qu'une sortie de scanner peut trancher.
La sortie du scan référence-t-elle HIPAA directement ?
Non — les findings sont étiquetés CWE et, quand un mapping existe, avec des identifiants OWASP ASVS et ISO 27001 (références standards, neutres vis-à-vis des éditeurs). Le lien avec une mesure HIPAA spécifique, tel que décrit sur cette page, est établi par votre processus de conformité — il n'est pas encodé dans le fichier SARIF lui-même.
Les spécifications HIPAA « addressable » sont-elles optionnelles ?
Non — « addressable » signifie qu'une organisation doit implémenter la spécification telle qu'écrite, implémenter une alternative équivalente, ou documenter formellement pourquoi ni l'une ni l'autre n'est raisonnable et appropriée pour son environnement, avec des mesures compensatoires. C'est un mécanisme de flexibilité, pas une exemption.
Voir les preuves réelles que produit un scan
Ouvrez le rapport de démonstration en ligne — sans installation, sans inscription — et regardez directement les findings et l'export SARIF.
Ouvrir le rapport en ligne En savoir plus sur la page secteurs réglementés