La HIPAA Security Rule en un párrafo
HIPAA (la ley estadounidense Health Insurance Portability and Accountability Act) se aplica a "covered entities" (planes de salud, cámaras de compensación sanitaria, la mayoría de proveedores de atención médica) y a sus "business associates" — lo que incluye a cualquier proveedor de software o equipo de desarrollo que construya sistemas que manejen Protected Health Information electrónica (ePHI). La Security Rule organiza las medidas requeridas en tres categorías: Administrative (§164.308 — políticas, análisis de riesgo, formación), Physical (§164.310 — acceso a instalaciones y dispositivos), y Technical (§164.312 — los controles reales a nivel de sistema). La mayoría de las especificaciones de implementación son "addressable", no universalmente "required": una organización debe implementar la medida, una alternativa equivalente, o documentar por qué ninguna de las dos es razonable y apropiada para su situación.
Los 5 estándares de Technical Safeguards (§164.312)
Esta es la única parte de la Security Rule que describe controles a nivel de sistema en lugar de política organizativa — citada del reglamento y guías de HHS:
| Cita | Estándar |
|---|---|
| §164.312(a) | Access Control — políticas técnicas que limitan el acceso a ePHI a personas y software autorizados |
| §164.312(b) | Audit Controls — mecanismos para registrar y examinar la actividad en sistemas que manejan ePHI |
| §164.312(c) | Integrity — protegerse contra la alteración o destrucción indebida de ePHI; mecanismo para autenticarla |
| §164.312(d) | Person or Entity Authentication — verificar que quien accede a ePHI es quien dice ser |
| §164.312(e) | Transmission Security — proteger las ePHI en tránsito por redes |
Las filas resaltadas son los tres estándares para los que un escaneo de código fuente puede realmente sacar a la luz bugs que anulan el control. Access Control y Audit Controls son cuestiones de arquitectura y proceso que un escáner no puede responder.
Dónde encaja realmente StaticCodeAudit
(c) Integrity
Si un hash o firma criptográfica está destinado a autenticar ePHI o detectar manipulación, su solidez es una propiedad a nivel de código. Algoritmos débiles o aleatoriedad predecible socavan el mecanismo sin importar cuán bien diseñado esté el proceso circundante:
weak_crypto, weak_random_java, insecure_random
(d) Person or Entity Authentication
El mayor solapamiento. La autenticación se implementa en código, y varias reglas se vinculan directamente a debilidades de autenticación concretas:
missing_mfa_python/javascript/java/csharp, jwt_none_algorithm, jwt_hardcoded_secret, default_credentials, weak_password_policy
(e) Transmission Security
Si una conexión realmente aplica TLS, y si el cifrado en sí es robusto, son ambos directamente observables en el código fuente:
http_no_tls, unencrypted_transfer, weak_crypto
Cada regla anterior se dispara como parte de un escaneo estándar:
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-highLa exportación SARIF da a cada hallazgo un archivo, una línea, un ID de regla y una severidad — un registro fechado y repetible para los tres estándares anteriores, no una certificación. Vea la guía de exportación SARIF.
Qué no cubre esto — la lista honesta
Un escáner de código fuente no puede producir evidencia para la mayor parte de la Security Rule, y la brecha es estructural, no un punto de roadmap:
- §164.312(a) Access Control — si las personas correctas tienen el acceso correcto es una cuestión de autorización/arquitectura, no un patrón sintáctico (aunque las credenciales hardcoded y por defecto se marcan como un problema relacionado, más acotado).
- §164.312(b) Audit Controls — si realmente existe un registro de auditoría completo e infalsificable en todo un sistema es una cuestión de arquitectura que un escaneo no puede resolver.
- §164.308 Administrative Safeguards (en su totalidad) — análisis de riesgo, formación del personal, política de sanciones, plan de contingencia: proceso organizativo, no código.
- §164.310 Physical Safeguards (en su totalidad) — acceso a instalaciones, seguridad de estaciones de trabajo, control de dispositivos y medios: mundo físico, sin relación con el código fuente.
Una entrada más para el Security Risk Analysis
HIPAA exige a covered entities y business associates realizar un Risk Analysis bajo el §164.308(a)(1) — "una evaluación precisa y completa de los riesgos y vulnerabilidades potenciales" para la confidencialidad, integridad y disponibilidad de las ePHI. Un escaneo repetible, sin conexión y fechado del código de la aplicación que maneja ePHI es una entrada legítima para esa evaluación más amplia — no la evaluación en sí, y no un sustituto del proceso organizativo que el §164.308 realmente exige.
Un punto aparte: verificar la propia herramienta
Vale la pena ser precisos aquí, porque es fácil confundirlo con la integridad de las ePHI mencionada arriba: verificar que el binario de StaticCodeAudit que descarga no ha sido alterado (comparación de hash SHA-256) es diligencia debida sobre la herramienta como una nueva pieza de su cadena de suministro de software — una preocupación distinta de si el código de su propia aplicación que maneja ePHI tiene una debilidad criptográfica. Vea la página de sectores regulados para el estado actual de la verificación de integridad del binario.
Preguntas frecuentes
¿Usar StaticCodeAudit hace que mi aplicación cumpla con HIPAA?
No — y ninguna herramienta de software lo hace. El cumplimiento de HIPAA es una determinación organizativa que cubre las tres categorías de medidas (Administrative, Physical, Technical), la mayoría de las cuales son política y proceso. StaticCodeAudit produce evidencia a nivel de código para 3 de los 5 estándares de Technical Safeguards, como una entrada más entre muchas, no una certificación.
¿Soy una "covered entity" o un "business associate" bajo HIPAA?
Esa es una determinación legal que debe hacer el consejo o el responsable de cumplimiento de su organización — depende de si usted crea, recibe, mantiene o transmite ePHI en nombre de una covered entity, no de algo que la salida de un escáner pueda responder.
¿La salida del escaneo referencia HIPAA directamente?
No — los hallazgos se etiquetan con CWE y, donde existe mapeo, con identificadores OWASP ASVS e ISO 27001 (referencias estándar, neutrales respecto a proveedores). La conexión con una medida HIPAA específica, tal como se describe en esta página, la establece su proceso de cumplimiento — no está codificada en el propio archivo SARIF.
¿Son opcionales las especificaciones HIPAA "addressable"?
No — "addressable" significa que una organización debe implementar la especificación tal como está escrita, implementar una alternativa equivalente, o documentar formalmente por qué ninguna de las dos es razonable y apropiada para su entorno, con controles compensatorios. Es un mecanismo de flexibilidad, no una exención.
Vea la evidencia real que produce un escaneo
Abra el informe de demostración en vivo — sin instalación, sin registro — y observe directamente los hallazgos y la exportación SARIF.
Abrir el informe en vivo Más información en la página de sectores regulados