Análisis estático de contratos inteligentes Solidity con infraestructura de evidencia y custodia criptográfica integrable con HSM mediante PKCS#11. Nuestra propuesta integra análisis, evidencia verificable y firma digital en una solución on-premise.
Los protocolos DeFi mueven miles de millones sobre código inmutable. Un bug no se parchea silenciosamente. Las herramientas de auditoría disponibles no han evolucionado al mismo ritmo que las amenazas.
Los scanners generan reportes sin cadena de custodia, sin firma verificable, sin sellado temporal real. Cuando un reporte llega a un tribunal, una aseguradora o un departamento de compliance, nadie puede demostrar qué artefacto produjo cada hallazgo, cuándo se generó, quién lo firmó ni si fue alterado.
Dos equipos ejecutando la misma herramienta sobre el mismo contrato obtienen resultados diferentes sin saber por qué. No hay canonicalización del manifiesto, no hay registro de la configuración utilizada.
"Valor probatorio judicial", "certidumbre matemática", "100% cobertura". Afirmaciones que destruyen credibilidad ante compradores experimentados. Ninguna herramienta SAST puede garantizar la ausencia total de vulnerabilidades.
Herramientas de seguridad que se ejecutan como root, sin SBOM propio, sin firma de releases, sin escaneo de dependencias. Pierden credibilidad inmediata ante cualquier CISO.
Cada firma de auditoría usa su propio formato, sus propios criterios de severidad, su propio nivel de detalle. No hay comparabilidad, no hay trazabilidad, no hay defensa jurídica posible.
Proxies inseguros, manipulación de oráculos, ataques flash loan, randomness predecible, pérdida de precisión aritmética. Los scanners clásicos no detectan estos vectores.
Una plataforma que combina SAST, Evidence Packs verificables y soporte de firma HSM/PKCS#11. Nuestra propuesta integra estas capacidades en una solución on-premise.
Análisis estático de contratos Solidity con siete detectores basados en Slither (análisis AST completo de Trail of Bits) y cinco detectores basados en patrones de source code para amenazas que el análisis AST no cubre. Cada hallazgo incluye severidad, confianza, ubicación precisa, descripción y referencia CWE/SWC.
Paquete ZIP autocontenido con manifiesto canónico RFC 8785, hash SHA-256, firma Ed25519/ECDSA, sellado RFC 3161, verificador independiente, SARIF 2.1.0, SBOM CycloneDX y VEX OpenVEX. Cualquier tercero puede validarlo sin tener Hyperium instalado.
Cuando se opera en modo HSM con perfiles enterprise_hsm o forensic_legal (fail closed), la firma se ejecuta dentro del hardware y la clave privada no se expone fuera del módulo de seguridad. Soporta múltiples proveedores con diferentes niveles de validación. Verificación post-firma obligatoria.
Siete detectores basados en Slither (análisis AST completo) más cinco detectores basados en source code para amenazas que los detectores clásicos no cubren.
| # | Detector | Vector de ataque | Impacto | Confianza | Tipo |
|---|---|---|---|---|---|
| 01 | Reentrancy | Llamadas recursivas antes de actualizar estado. El vector del hack de The DAO. | HIGH | HIGH | Slither |
| 02 | Access Control | selfdestruct sin modificadores restrictivos. Funciones críticas sin onlyOwner. | HIGH | HIGH | Slither |
| 03 | Overflow/Underflow | Aritmética sin validación en Solidity <0.8. Desbordamiento de enteros. | HIGH | MEDIUM | Slither |
| 04 | tx.origin | Validación de identidad con variable global manipulable vía phishing. | HIGH | HIGH | Slither |
| 05 | Delegatecall | delegatecall con destino controlable. Ejecución arbitraria en contexto del contrato. | HIGH | HIGH | Slither |
| 06 | Unchecked Return | .send() sin verificar retorno. Estado inconsistente silencioso. | HIGH | MEDIUM | Slither |
| 07 | Unprotected Init | initialize() sin onlyOwner. Inicialización maliciosa posible. | HIGH | HIGH | Slither |
| 08 | Proxy/Upgrade NUEVO | UUPS, transparent, beacon, diamond sin control de acceso en upgrade. | HIGH | MEDIUM | Source |
| 09 | Input Validation NUEVO | Zero address no verificada. Payable sin deadline ni slippage. | MEDIUM | MEDIUM | Source |
| 10 | Denial of Service NUEVO | Loops no acotados. Push payments en loops. Dependencias externas sin gas. | MEDIUM | MEDIUM | Source |
| 11 | Randomness NUEVO | block.timestamp y blockhash para decisiones económicas. Manipulable por mineros. | HIGH | HIGH | Source |
| 12 | Precision Loss NUEVO | División antes de multiplicación. Casts que pierden bits. Decimales distintos. | HIGH | MEDIUM | Source |
Cada detector reporta impacto y confianza como métricas independientes. Un hallazgo HIGH/HIGH puede bloquear un deployment; un hallazgo HIGH/MEDIUM requiere revisión humana.
No pedimos que confíes en nosotros. Entregamos un paquete autocontenido que tú, tu abogado, tu aseguradora o un perito independiente puede validar sin nuestro software.
| Rol | Responsabilidad |
|---|---|
| Auditor técnico | Ejecuta el análisis y firma los hallazgos |
| Security lead | Valida la clasificación de severidad |
| Revisor legal | Certifica la cadena de custodia documental |
Cuando se opera en modo HSM con perfiles enterprise_hsm o forensic_legal, la firma se ejecuta dentro del módulo de seguridad de hardware. La clave privada no se expone fuera del HSM. Este modo requiere configuración explícita, perfil fail-closed y un proveedor PKCS#11 validado.
El motor SAST genera el manifiesto canónico y calcula el hash SHA-256. Solo el digest viaja al HSM.
El microprocesador del HSM firma internamente. En modo fail-closed, la clave no se expone a red, OS ni RAM.
La firma se verifica contra la clave pública. Si es válida, se ensambla el Evidence Pack.
| Atributo | Valor | Propósito |
|---|---|---|
| CKA_SIGN | true | Permite operaciones de firma digital |
| CKA_SENSITIVE | true | Impide lectura en texto claro incluso por el administrador |
| CKA_EXTRACTABLE | false | Impide exportación de la clave fuera del HSM |
| CKA_TOKEN | true | La clave persiste en el token |
| CKA_PRIVATE | true | Requiere autenticación (PIN, biometría o rol) |
| Perfil | Algoritmo | Uso |
|---|---|---|
| Primario | Ed25519 (RFC 8032) | Firma EdDSA de alta velocidad |
| Corporativo | ECDSA P-256 (FIPS 186-4) | PKI corporativa existente |
| Regulatorio | ECDSA P-384 | Entornos de alta seguridad |
| Legacy | RSA-PSS 3072+ | PKI heredada |
No todos los proveedores tienen el mismo nivel de validación. Diferenciamos entre integración validada con tests automatizados, en proceso de validación y planificado.
| Proveedor | Entorno | Algoritmos | Estado |
|---|---|---|---|
| SoftHSM 2 | Desarrollo y testing | Ed25519, ECDSA P-256 | VALIDADO |
| AWS CloudHSM | Producción cloud | ECDSA P-256/P-384 | EN VALIDACIÓN |
| Azure Managed HSM | Producción cloud | ECDSA P-256/P-384 | EN VALIDACIÓN |
| YubiKey 5 (PIV) | Producción local / air-gapped | ECDSA P-256 | EN VALIDACIÓN |
| Thales Luna | Producción enterprise | ECDSA, RSA-PSS | PLANIFICADO |
| Utimaco SecurityServer | Producción enterprise | ECDSA, RSA-PSS | PLANIFICADO |
| Entrust nShield | Producción enterprise | ECDSA, RSA-PSS | PLANIFICADO |
Firma generada en HSM validado, perfil fail-closed, verificación post-firma exitosa.
Se intentó HSM pero no estaba disponible. Fallback a software con degradación documentada.
Firma Ed25519 por software. Sin HSM configurado. Garantía estándar.
| Perfil | Sin HSM | Comportamiento |
|---|---|---|
| Development | Fallback a software | Software normal, sin degradación |
| Professional | Fallback a software | Software normal, assurance = standard |
| Enterprise | Fallback con registro | Degradación documentada |
| Enterprise HSM | Fail closed | Firma rechazada. No se genera Evidence Pack. |
| Forensic Legal | Fail closed + alerta | Firma rechazada + evento de auditoría. |
Una organización regulada que opera con Enterprise HSM necesita garantía de que su evidencia fue firmada por hardware. Si el HSM falla, la política de fail closed garantiza que la firma no se produce. No hay degradación silenciosa. No hay ambigüedad en el assurance level.
Cinco perfiles progresivos de ejecución.
Feedback rápido en terminal. Sin evidencia.
SARIF en GitHub. Baseline. Fallo si CRITICAL.
PDF ejecutivo. JSON. Métricas.
Evidence Pack completo. Firma. TSA.
Multi-firma HSM. Cadena de custodia.
Nuestra propuesta integra análisis SAST, evidencia verificable y firma HSM en una solución on-premise. La siguiente tabla muestra las capacidades disponibles en cada herramienta.
| Capacidad | Slither | Mythril | Securify2 | Hyperium Smart-Audit |
|---|---|---|---|---|
| 12 detectores (AST + source) | ✗ | ✗ | ✗ | ✓ |
| Evidence Pack verificable | ✗ | ✗ | ✗ | ✓ |
| Canonicalización RFC 8785 | ✗ | ✗ | ✗ | ✓ |
| Firma Ed25519/ECDSA | ✗ | ✗ | ✗ | ✓ |
| Sellado RFC 3161 | ✗ | ✗ | ✗ | ✓ |
| Verificador independiente | ✗ | ✗ | ✗ | ✓ |
| Firma múltiple con roles | ✗ | ✗ | ✗ | ✓ |
| HSM/PKCS#11 | ✗ | ✗ | ✗ | ✓ |
| Verificación post-firma | ✗ | ✗ | ✗ | ✓ |
| Evidence Assurance | ✗ | ✗ | ✗ | ✓ |
| Política de fallback por perfil | ✗ | ✗ | ✗ | ✓ |
| SARIF 2.1.0 con fingerprints | Parcial | ✗ | ✗ | ✓ |
| SBOM CycloneDX | ✗ | ✗ | ✗ | ✓ |
| VEX OpenVEX | ✗ | ✗ | ✗ | ✓ |
| Plugin SDK | ✗ | ✗ | ✗ | ✓ |
| API REST local | ✗ | ✗ | ✗ | ✓ |
| Baseline + supresiones | ✗ | ✗ | ✗ | ✓ |
| Docker endurecido | ✗ | Parcial | ✗ | ✓ |
| Benchmark reproducible | ✗ | ✗ | ✗ | ✓ |
| 100% on-premise | ✓ | ✓ | Cloud | ✓ |
Hyperium Smart-Audit combina análisis SAST de contratos inteligentes con infraestructura de evidencia y custodia criptográfica integrable con HSM mediante PKCS#11. El cliente opera y conserva el control de las claves en su propio HSM; Hyperium orquesta operaciones de firma sin extraer las claves.
La integración HSM/PKCS#11 puede respaldar controles dentro de marcos regulatorios relevantes para el sector financiero. La aplicabilidad depende de la configuración del cliente, la infraestructura utilizada y la validación de cada marco por profesionales calificados.
Puede respaldar controles de gestión criptográfica dentro de un SGSI. La clave reside en hardware dedicado, la no exportación está garantizada por atributos PKCS#11 y las operaciones son auditable. El mapeo específico a controles debe ser validado por un auditor ISO calificado para la edición aplicable.
Puede respaldar controles de gestión de claves, segregación de funciones y trazabilidad evaluados en auditorías SOC 2. La clave requiere autenticación, nunca reside en disco del servidor y solo el digest viaja por la interfaz PKCS#11.
Claves protegidas contra acceso no autorizado. Procedimientos de gestión documentados. Operaciones criptográficas auditadas con logs que nunca contienen secretos.
Hyperium puede integrarse con HSM que cuenten con certificaciones como FIPS 140-2/140-3 o Common Criteria. La certificación del hardware no certifica automáticamente a Hyperium ni al flujo completo. La evaluación de cumplimiento debe considerar la cadena completa.
Las referencias a marcos regulatorios (ISO 27001, SOC 2, PCI DSS) indican las áreas donde Hyperium puede respaldar controles. No constituyen una declaración de cumplimiento. El cumplimiento depende de la implementación completa del cliente, la infraestructura utilizada y la evaluación de auditores o autoridades competentes. Recomendamos validar el mapeo específico con su equipo de compliance o auditoría antes de utilizarlo en contextos regulatorios formales.
| Módulo | Tests | Cobertura |
|---|---|---|
| Detectores Slither | 14 | Reentrancy, access control, overflow, tx.origin, delegatecall, unchecked return, unprotected init |
| Detectores Source | 10 | Proxy, input validation, DoS, randomness, precision |
| Evidence Pack | 8 | Generación, ZIP, manifiesto, verificación |
| Firma y gobernanza | 6 | Ed25519, PEM, metadata, secretos |
| Forensic Chain | 6 | Sellado, TSA, Merkle, integridad |
| SARIF | 5 | Formato, fingerprint, code flows |
| Baseline | 5 | Guardar, cargar, filtrar, justificación |
| Verify CLI | 7 | Hash, firma, TSA, manifiesto, veredicto |
| Políticas | 3 | Carga, firma, severidad |
| API REST | 4 | /health, /detectors, /status, 404 |
| Benchmark | 4 | Corpus, detalles, tool, detectores |
| MultiSigner | 6 | Roles, verificación, corrupción |
| Plugin SDK | 10 | Registro, ejecución, rechazo, directorios |
| SBOM + VEX | 7 | Formato, metadata, PURL, severidad |
| Reportes | 7 | JSON, PDF, SARIF, forensic seal |
| HSM/PKCS#11 | 28 | Conexión, claves, firma, verificación post-firma, fallback, fail-closed, concurrente |
| TOTAL | 159 | 0 fallidos |
La propiedad de hallazgos, código auditado y Evidence Packs siempre es del cliente.
Las ediciones Enterprise HSM y Forensic Legal están diseñadas para organizaciones que operan en entornos regulados y requieren integración con su infraestructura criptográfica existente. La disponibilidad efectiva para cada organización depende de sus requisitos específicos, la infraestructura PKCS#11 que operen y el resultado del proceso de evaluación e integración.
| Segmento | Community | Professional | Enterprise | Enterprise HSM | Forensic Legal |
|---|---|---|---|---|---|
| Desarrolladores | ✓ | ||||
| Equipos DeFi | ✓ | ||||
| Auditoras Web3 | ✓ | ✓ | |||
| Fintech reguladas | ✓ | ||||
| Exchanges regulados | ✓ | ✓ | |||
| Organizaciones financieras | ✓ | ✓ | |||
| Entidades gubernamentales | ✓ | ✓ | |||
| Estudios jurídicos | ✓ |
| Fase | Nombre | Entregables | Estado |
|---|---|---|---|
| F1 | Evidencia Verificable | Evidence Pack, RFC 8785, Ed25519, RFC 3161, verificador CLI | ✓ Completada |
| F2 | Calidad y Estándares | SARIF 2.1.0, Docker endurecido, CI multi-python, baseline | ✓ Completada |
| F3 | Alcance de Detección | 5 detectores nuevos: proxy, input, DoS, randomness, precision | ✓ Completada |
| F4 | Enterprise | Multi-firma, Plugin SDK, SBOM+VEX, API REST, benchmark | ✓ Completada |
| F5 | HSM/PKCS#11 | Integración HSM, verificación post-firma, fallback, assurance | ✓ Completada |
Solicita una demo y descubre cómo Hyperium Smart-Audit transforma la auditoría de contratos inteligentes en un proceso trazable, reproducible y defendible.