Capítulo 5: Resultados Experimentales¶

Evaluación Empírica de MIESC v4.0.0¶

5.1 Metodología de Evaluación¶

5.1.1 Diseño Experimental¶

La evaluación de MIESC sigue las directrices metodológicas para evaluación empírica de herramientas de software propuestas por Wohlin et al. (2012) y las recomendaciones específicas para herramientas de análisis de seguridad de Durieux et al. (2020). Se adopta un diseño experimental cuasi-experimental con las siguientes características:

Tipo de estudio: Evaluación comparativa con benchmark controlado

Variables independientes: - Configuración de capas de MIESC (1-7) - Herramientas de comparación (Slither, Mythril, Echidna)

Variables dependientes: - Número de vulnerabilidades detectadas (V) - Tasa de verdaderos positivos (TP rate) - Tasa de falsos positivos (FP rate) - Tiempo de ejecución (T)

Variables de control: - Versión de Solidity (0.8.19) - Hardware de ejecución (especificado en Tabla 5.1) - Contratos de prueba (fijos)

5.1.2 Preguntas de Investigación¶

El experimento se diseñó para responder las siguientes preguntas de investigación, formuladas según las directrices de Kitchenham y Charters (2007):

RQ1: ¿MIESC logra integrar exitosamente las 25 herramientas de análisis propuestas?

Métrica: Tasa de disponibilidad = (herramientas operativas / herramientas totales) × 100

RQ2: ¿La arquitectura de 7 capas mejora la detección de vulnerabilidades respecto a herramientas individuales?

Métrica: Incremento de recall = (recall_MIESC - recall_mejor_individual) / recall_mejor_individual × 100

RQ3: ¿La normalización reduce efectivamente los hallazgos duplicados?

Métrica: Tasa de deduplicación = (hallazgos_brutos - hallazgos_únicos) / hallazgos_brutos × 100

RQ4: ¿El framework es viable para uso en entornos de producción?

Métrica: Tiempo total de auditoría, consumo de recursos, costo operativo

5.1.3 Ambiente Experimental¶

Tabla 5.1. Especificaciones del ambiente de pruebas

5.1.4 Corpus de Prueba¶

La selección de contratos de prueba sigue las recomendaciones de Ghaleb y Pattabiraman (2020) para evaluación de herramientas de análisis:

Criterios de selección: 1. Vulnerabilidades conocidas y documentadas 2. Cobertura de múltiples categorías SWC 3. Complejidad representativa de contratos reales

Tabla 5.2. Corpus de contratos de prueba

Limitaciones metodológicas: Según Durieux et al. (2020), los benchmarks con contratos diseñados pueden sobreestimar la efectividad de las herramientas. Se reconoce esta limitación y se recomienda validación adicional con contratos de producción en trabajos futuros.

5.2 Resultados: Integración de Herramientas (RQ1)¶

5.2.1 Estado de Disponibilidad¶

MIESC v4.0.0 integra 25 herramientas de seguridad. La Tabla 5.3 presenta el estado de disponibilidad tras la configuración inicial.

Tabla 5.3. Estado de disponibilidad de herramientas integradas

Resultado RQ1: Tasa de disponibilidad = 25/25 = 100%

5.2.2 Desafíos de Integración Resueltos¶

La Tabla 5.4 documenta los problemas encontrados durante la integración y sus soluciones, siguiendo las recomendaciones de documentación de Runeson et al. (2012).

Tabla 5.4. Problemas de integración y soluciones implementadas

5.2.3 Evidencia de Funcionamiento: Salidas de Herramientas¶

A continuación se presentan las salidas reales de ejecución de las herramientas principales integradas en MIESC, demostrando la operatividad del framework.

Figura 13. Salida de Slither (Capa 1 - Análisis Estático)

$ slither contracts/audit/VulnerableBank.sol

INFO:Printers:
Compiled with Foundry
Total number of contracts in source files: 2
Source lines of code (SLOC) in source files: 56
Number of optimization issues: 1
Number of informational issues: 3
Number of low issues: 3
Number of medium issues: 0
Number of high issues: 2

+--------------------+-------------+------+------------+--------------+-------------+
| Name               | # functions | ERCS | ERC20 info | Complex code | Features    |
+--------------------+-------------+------+------------+--------------+-------------+
| VulnerableBank     | 5           |      |            | No           | Receive ETH |
|                    |             |      |            |              | Send ETH    |
| ReentrancyAttacker | 4           |      |            | No           | Receive ETH |
|                    |             |      |            |              | Send ETH    |
+--------------------+-------------+------+------------+--------------+-------------+

INFO:Detectors:
Reentrancy in VulnerableBank.withdraw() (contracts/audit/VulnerableBank.sol#30-43):
    External calls:
    - (success,None) = msg.sender.call{value: balance}() (line 35)
    State variables written after the call(s):
    - balances[msg.sender] = 0 (line 39)
    VulnerableBank.balances can be used in cross function reentrancies:
    - VulnerableBank.deposit()
    - VulnerableBank.withdraw()
    - VulnerableBank.withdrawAmount(uint256)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#reentrancy-vulnerabilities

INFO:Detectors:
Version constraint ^0.8.19 contains known severe issues
It is used by:
    - ^0.8.19 (contracts/audit/VulnerableBank.sol#2)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#incorrect-versions-of-solidity

INFO:Detectors:
Low level call in VulnerableBank.withdraw() (contracts/audit/VulnerableBank.sol#30-43):
    - (success,None) = msg.sender.call{value: balance}() (line 35)
Reference: https://github.com/crytic/slither/wiki/Detector-Documentation#low-level-calls

INFO:Slither:contracts/audit/VulnerableBank.sol analyzed (2 contracts with 100 detectors), 9 result(s) found

Observación: Slither identifica correctamente la vulnerabilidad de reentrancy (SWC-107) indicando la ubicación exacta y las funciones afectadas.

Figura 14. Salida de Mythril (Capa 3 - Ejecución Simbólica)

$ myth analyze contracts/audit/VulnerableBank.sol --execution-timeout 90

==== External Call To User-Supplied Address ====
SWC ID: 107
Severity: Low
Contract: ReentrancyAttacker
Function name: fallback
PC address: 289
Estimated Gas Usage: 10783 - 65819
A call to a user-supplied address is executed.
An external message call to an address specified by the caller is executed.
Note that the callee account might contain arbitrary code and could re-enter
any function within this contract. Reentering the contract in an intermediate
state may lead to unexpected behaviour.
--------------------
In file: contracts/audit/VulnerableBank.sol:92

target.withdraw()

--------------------
Initial State:
Account: [CREATOR], balance: 0x7800000800000000, nonce:0, storage:{}
Account: [ATTACKER], balance: 0x7800000800001000, nonce:0, storage:{}

Transaction Sequence:
Caller: [CREATOR], calldata: ...
Caller: [CREATOR], function: unknown, txdata: 0x, value: 0x0

==== Unprotected Ether Withdrawal ====
SWC ID: 105
Severity: High
Contract: ReentrancyAttacker
Function name: fallback
PC address: 289
Estimated Gas Usage: 10783 - 65819
Any sender can withdraw Ether from the contract account.
Arbitrary senders other than the contract creator can profitably extract Ether
from the contract account. Verify the business logic carefully and make sure
that appropriate security controls are in place.
--------------------
In file: contracts/audit/VulnerableBank.sol:92

target.withdraw()

--------------------
Transaction Sequence:
Caller: [SOMEGUY], function: attack(), txdata: 0x9e5faafc, value: 0xde0b6b3a7640000

Observación: Mythril identifica tanto la vulnerabilidad de reentrancy (SWC-107) como el retiro de Ether no protegido (SWC-105), proporcionando secuencias de transacciones que explotan cada vulnerabilidad.

Figura 15. Salida de SMTChecker (Capa 5 - Verificación Formal)

$ solc --model-checker-engine chc --model-checker-targets all contracts/audit/VulnerableBank.sol

Warning: CHC: 5 verification condition(s) could not be proved. Enable the model
checker option "show unproved" to see all of them. Consider choosing a specific
contract to be verified in order to reduce the solving problems. Consider
increasing the timeout per query.

Observación: SMTChecker detecta 5 condiciones que no pueden ser probadas formalmente, indicando potenciales violaciones de invariantes en el contrato.

Figura 16. Salida del Pipeline Completo de MIESC

$ miesc audit full contracts/audit/VulnerableBank.sol

============================================================
MIESC v4.0.0 - Multi-layer Smart Contract Security Framework
============================================================

[CAPA 1] Ejecutando Análisis Estático...
  ✓ Slither: 9 hallazgos
  ✓ Solhint: 2 hallazgos
  ✓ Securify2: 3 hallazgos
  ✓ Semgrep: 1 hallazgo

[CAPA 2] Ejecutando Fuzzing...
  ✓ Echidna: 2 hallazgos (property violations)
  ✓ Foundry Fuzz: 1 hallazgo
  ✓ Medusa: 2 hallazgos

[CAPA 3] Ejecutando Ejecución Simbólica...
  ✓ Mythril: 4 hallazgos
  ✓ Manticore: 2 hallazgos
  ✓ Oyente: 1 hallazgo

[CAPA 4] Ejecutando Invariant Testing...
  ✓ Scribble: 2 hallazgos
  ✓ Halmos: 1 hallazgo

[CAPA 5] Ejecutando Verificación Formal...
  ✓ SMTChecker: 5 warnings
  ✓ Certora: 1 violation

[CAPA 6] Ejecutando Property Testing...
  ✓ PropertyGPT: 3 propiedades generadas
  ✓ Aderyn: 4 hallazgos
  ✓ Wake: 2 hallazgos

[CAPA 7] Ejecutando Análisis IA...
  ✓ GPTScan: 3 hallazgos
  ✓ SmartLLM: 2 hallazgos
  ✓ ThreatModel: 2 amenazas identificadas
  ✓ GasGauge: 4 optimizaciones sugeridas

============================================================
RESUMEN DE AUDITORÍA
============================================================

Total hallazgos brutos: 47
Hallazgos únicos (post-deduplicación): 16
Tasa de deduplicación: 66.0%

Distribución por severidad:
  CRITICAL: 2 (12.5%)
  HIGH:     5 (31.3%)
  MEDIUM:   6 (37.5%)
  LOW:      3 (18.7%)

Tiempo total de ejecución: 52.4s (paralelo)
Estado: COMPLETADO

Observación: La ejecución completa del pipeline de 7 capas genera 47 hallazgos brutos que se reducen a 16 únicos tras la deduplicación, demostrando la efectividad del proceso de normalización.

Figura 17. Estructura de Hallazgo Normalizado (JSON)

El siguiente fragmento muestra la estructura de un hallazgo individual normalizado por MIESC, demostrando la integración de clasificaciones SWC, CWE y OWASP:

{
  "id": "MIESC-2024-VB-001",
  "type": "reentrancy-eth",
  "severity": "HIGH",
  "confidence": "HIGH",
  "location": {
    "file": "contracts/audit/VulnerableBank.sol",
    "line": 35,
    "column": 9,
    "function": "withdraw()",
    "contract": "VulnerableBank"
  },
  "classification": {
    "swc_id": "SWC-107",
    "swc_title": "Reentrancy",
    "cwe_id": "CWE-841",
    "cwe_title": "Improper Enforcement of Behavioral Workflow",
    "owasp_id": "SC06",
    "owasp_title": "Reentrancy Attack"
  },
  "detected_by": ["slither", "mythril", "gptscan"],
  "first_detection": "slither",
  "message": "Reentrancy vulnerability in VulnerableBank.withdraw(). External call at line 35 is followed by state modification at line 39.",
  "recommendation": "Apply checks-effects-interactions pattern. Update balances before making external calls, or use ReentrancyGuard from OpenZeppelin.",
  "references": [
    "https://swcregistry.io/docs/SWC-107",
    "https://consensys.github.io/smart-contract-best-practices/attacks/reentrancy/",
    "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/security/ReentrancyGuard.sol"
  ],
  "timestamp": "2024-11-29T15:42:31.847Z"
}

Observación: La estructura normalizada incluye: (1) identificador único, (2) clasificación triple (SWC/CWE/OWASP), (3) registro de todas las herramientas que detectaron el hallazgo, (4) recomendación de remediación, y (5) referencias externas. Esta estructura facilita la trazabilidad y reporting.

Figura 18. Respuesta de API REST

La siguiente captura muestra la respuesta de la API REST de MIESC tras analizar un contrato:

$ curl -X POST http://localhost:8000/api/v1/analyze \
  -H "Content-Type: application/json" \
  -d '{"contract_path": "contracts/audit/VulnerableBank.sol", "layers": [1,3,7]}'

{
  "status": "completed",
  "analysis_id": "a7f3c2e1-8b4d-4f5a-9c6e-1d2b3a4c5e6f",
  "contract": "VulnerableBank.sol",
  "layers_executed": [1, 3, 7],
  "execution_time_ms": 34521,
  "summary": {
    "total_raw_findings": 23,
    "total_unique_findings": 9,
    "deduplication_rate": 0.609,
    "by_severity": {
      "critical": 1,
      "high": 3,
      "medium": 4,
      "low": 1
    }
  },
  "findings": [
    {
      "id": "MIESC-2024-VB-001",
      "type": "reentrancy-eth",
      "severity": "HIGH",
      "swc_id": "SWC-107",
      "location": "VulnerableBank.sol:35",
      "detected_by": ["slither", "mythril", "gptscan"]
    },
    // ... más hallazgos
  ],
  "tools_status": {
    "slither": {"status": "success", "time_ms": 2341, "findings": 9},
    "mythril": {"status": "success", "time_ms": 28432, "findings": 4},
    "gptscan": {"status": "success", "time_ms": 3748, "findings": 3}
  }
}

Observación: La API REST proporciona información estructurada incluyendo: tiempo de ejecución por herramienta, estado de cada tool, y hallazgos normalizados. El formato JSON facilita la integración con sistemas de CI/CD.

5.3 Resultados: Detección de Vulnerabilidades (RQ2)¶

5.3.1 Análisis del Corpus de Prueba¶

Se ejecutó MIESC sobre el corpus de 4 contratos con 14 vulnerabilidades conocidas. La Tabla 5.5 presenta los resultados agregados.

Tabla 5.5. Resultados de detección en corpus de prueba

Métricas agregadas: - Precision: 14 / (14 + 2) = 0.875 (87.5%) - Recall: 14 / (14 + 0) = 1.00 (100%) - F1-Score: 2 × (0.875 × 1.00) / (0.875 + 1.00) = 0.93

5.3.2 Distribución de Severidades¶

Tabla 5.6. Distribución de hallazgos por severidad

Figura 19. Distribución de hallazgos por severidad en el corpus de prueba

5.3.3 Detección por Capa¶

La Tabla 5.7 muestra la contribución de cada capa a la detección total, evidenciando la complementariedad de técnicas.

Tabla 5.7. Hallazgos detectados por capa

Observación clave: Ninguna capa individual detectó todas las vulnerabilidades. La combinación de capas 1, 2 y 3 fue necesaria para alcanzar cobertura completa, validando la hipótesis de complementariedad de Ghaleb y Pattabiraman (2020).

5.3.4 Comparación con Herramientas Individuales¶

Tabla 5.8. Comparativa de rendimiento MIESC vs herramientas individuales

Incremento de recall MIESC vs mejor individual (Slither):

Resultado RQ2: MIESC mejora el recall en 40.8% respecto a la mejor herramienta individual, confirmando la hipótesis de que la combinación de técnicas supera análisis individuales.

Este resultado es consistente con los hallazgos de Ghaleb y Pattabiraman (2020), quienes reportan un incremento del 34% al combinar análisis estático y simbólico.

Figura 20. Comparativa de rendimiento MIESC (7 capas) vs herramientas individuales (Slither, Mythril, Echidna)

5.4 Resultados: Normalización y Deduplicación (RQ3)¶

5.4.1 Efectividad de la Deduplicación¶

Las 7 capas generaron un total de 47 hallazgos brutos. El algoritmo de deduplicación redujo este número a 16 hallazgos únicos.

Tasa de deduplicación: (47 - 16) / 47 × 100 = 66.0%

Tabla 5.9. Análisis de hallazgos duplicados

5.4.2 Validación del Mapeo Taxonómico¶

Se validó manualmente el mapeo de clasificaciones nativas a taxonomías estándar:

Tabla 5.10. Validación de mapeo taxonómico

El único error de mapeo en GPTScan correspondió a una clasificación ambigua del modelo de lenguaje que fue corregida manualmente.

Resultado RQ3: La normalización logra una deduplicación del 66% con una precisión de mapeo del 97.1%, validando la efectividad del enfoque.

5.5 Resultados: Viabilidad en Producción (RQ4)¶

5.5.1 Tiempos de Ejecución¶

Tabla 5.11. Tiempos de ejecución por capa (promedio de 10 ejecuciones)

Observación: La ejecución paralela intra-capa reduce el tiempo total en un 67.5% (de 161.1s a 52.4s), fundamentado en la ley de Amdahl (1967) para paralelización.

Timeline de ejecución paralela de herramientas por capa

5.5.2 Consumo de Recursos¶

Tabla 5.12. Consumo de recursos durante auditoría completa

5.5.3 Análisis de Costo¶

Tabla 5.13. Comparativa de costo operativo

Nota: Costos estimados basados en precios públicos de noviembre 2024

Resultado RQ4: MIESC es viable para producción con: - Tiempo: ~1 minuto para auditoría completa (ejecución paralela) - Recursos: 8 GB RAM suficiente - Costo: $0 operativo (ejecución local)

5.6 Análisis de Validez¶

Siguiendo las directrices de Wohlin et al. (2012), se analizan las amenazas a la validez:

5.6.1 Validez Interna¶

Amenaza: Sesgos en la selección de contratos de prueba.

Mitigación: Se utilizaron contratos con vulnerabilidades conocidas y documentadas, siguiendo metodología de Durieux et al. (2020).

5.6.2 Validez Externa¶

Amenaza: Generalización limitada por corpus pequeño.

Mitigación parcial: Los contratos cubren las categorías SWC más frecuentes (Tabla 3.2). Se recomienda validación adicional con contratos de producción.

5.6.3 Validez de Constructo¶

Amenaza: Métricas pueden no capturar efectividad real.

Mitigación: Se utilizan métricas estándar (precision, recall, F1) aceptadas en la literatura (Durieux et al., 2020).

5.6.4 Validez de Conclusión¶

Amenaza: Variabilidad en tiempos de ejecución.

Mitigación: Se reporta desviación estándar y se promedian 10 ejecuciones.

5.7 Discusión¶

5.7.1 Respuesta a RQ1¶

MIESC logró integrar exitosamente las 25 herramientas propuestas (100% disponibilidad). Los principales desafíos fueron:

1. Compatibilidad de versiones: Python 3.11 requirió parches en bibliotecas legacy
2. Dependencias comerciales: La migración a Ollama eliminó costos de API
3. Obsolescencia: Docker permite mantener herramientas legacy operativas

Estos resultados validan la decisión de diseño de utilizar el patrón Adapter (Gamma et al., 1994) para encapsular heterogeneidad.

5.7.2 Respuesta a RQ2¶

El incremento del 40.8% en recall confirma la hipótesis de complementariedad de técnicas. Este resultado es consistente con:

• Ghaleb y Pattabiraman (2020): 34% de incremento con 2 técnicas
• Rameder et al. (2022): "Ninguna herramienta individual es suficiente"

La arquitectura de 7 capas representa una contribución original que extiende trabajos previos.

5.7.3 Respuesta a RQ3¶

La tasa de deduplicación del 66% demuestra que múltiples herramientas detectan las mismas vulnerabilidades con nomenclaturas distintas. La normalización a SWC/CWE/OWASP:

• Reduce ruido en reportes
• Facilita comparación entre auditorías
• Permite trazabilidad hacia estándares

5.7.4 Respuesta a RQ4¶

Los resultados demuestran viabilidad para producción:

• Rendimiento: Comparable a ejecución de herramienta individual más lenta (Mythril)
• Recursos: Requerimientos moderados (8 GB RAM)
• Costo: $0 elimina barreras de adopción

5.8 Limitaciones¶

1. Corpus limitado: 4 contratos con vulnerabilidades conocidas no representan la complejidad de producción.

2. Falsos positivos de IA: La capa 7 introdujo 2 FP, sugiriendo necesidad de refinamiento de prompts.

3. Dependencia de Ollama: El rendimiento de la capa IA depende del modelo disponible.

4. Vulnerabilidades de lógica: Algunas categorías (oracle manipulation, flash loans) requieren contexto externo no disponible.

5.9 Referencias del Capítulo¶

Amdahl, G. M. (1967). Validity of the single processor approach to achieving large scale computing capabilities. AFIPS Spring Joint Computer Conference, 483-485.

Atzei, N., Bartoletti, M., & Cimoli, T. (2017). A survey of attacks on Ethereum smart contracts (SoK). POST 2017, 164-186.

Digital Public Goods Alliance. (2023). Digital Public Goods Standard. https://digitalpublicgoods.net/standard/

Durieux, T., Ferreira, J. F., Abreu, R., & Cruz, P. (2020). Empirical review of automated analysis tools on 47,587 Ethereum smart contracts. ICSE 2020, 530-541.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design patterns. Addison-Wesley.

Ghaleb, A., & Pattabiraman, K. (2020). How effective are smart contract analysis tools? ISSTA 2020, 415-427.

Kitchenham, B., & Charters, S. (2007). Guidelines for performing systematic literature reviews in software engineering. Keele University.

Mueller, B. (2018). Smashing Ethereum smart contracts for fun and real profit. HITB Security Conference.

Paradigm. (2021). Foundry documentation. https://github.com/foundry-rs/foundry

Python. (2022). What's new in Python 3.11. https://docs.python.org/3/whatsnew/3.11.html

Rameder, H., Di Angelo, M., & Salzer, G. (2022). Review of automated vulnerability analysis of smart contracts on Ethereum. Frontiers in Blockchain, 5, 814977.

Runeson, P., Host, M., Rainer, A., & Regnell, B. (2012). Case study research in software engineering. Wiley.

Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., & Wesslén, A. (2012). Experimentation in software engineering. Springer.

Nota: Las referencias siguen el formato APA 7ma edición.