Proyectos

Herramientas de seguridad y ML aplicado que diseñé, entregué y medí de principio a fin — de la defensa de la cadena de suministro y la detección de phishing al triaje de vulnerabilidades, el hardening móvil y la infraestructura cloud de alta disponibilidad.

SlopGuard

Guardián pre-instalación de la cadena de suministro que detecta dependencias alucinadas por IA, typosquatted y maliciosas — sin dependencias en tiempo de ejecución.

Rol: Único autor — arquitectura, motor de detección, CLI, integraciones CI y SaaS.
Context: El slopsquatting es una amenaza emergente en la cadena de suministro documentada en USENIX Security 2025: los LLMs frecuentemente recomiendan `pip install` o `npm install` de paquetes que no existen — aproximadamente el 20% de los paquetes sugeridos por IA son alucinados, con ~38% siendo near-misses de nombres de paquetes reales. Los atacantes monitorizan las salidas de los LLMs y pre-registran esos nombres alucinados con payloads maliciosos.

Problema

No existía una capa de interceptación pre-instalación que pudiera evaluar deterministamente la legitimidad de un paquete — comprobando distancia de typosquatting, antigüedad de publicación, velocidad de descargas, inteligencia de amenazas OSV y probabilidad de alucinación por LLM — antes de que cualquier código se ejecute en la máquina del desarrollador.

Enfoque

Motor de detección de 5 capas (capas 0–4) que puntúa los paquetes sin ejecutar ninguno de su código.
Núcleo agnóstico de ecosistema con adaptadores intercambiables para PyPI y npm.
Múltiples frontends que cubren cada punto de integración: CLI, pre-commit hook, GitHub Action y SaaS auto-hospedable.
Invariante anti-falso-positivo demostrable: la capa de alucinación LLM opt-in es estructuralmente incapaz de bloquear un paquete legítimo por sí sola.

Impacto

Detecta paquetes maliciosos y alucinados antes de la instalación — sin dependencias en tiempo de ejecución en entornos del consumidor.
Suite de 2687 tests recogidos (incluyendo parametrizados) garantiza la corrección en cada capa de detección con un gate de CI de ≥90% de cobertura global y ≥95% en rutas críticas.
8 contratos de arquitectura con import-linter previenen el acoplamiento entre capas a medida que crece la base de código.

0dependencias en runtime

5capas de detección

2ecosistemas (PyPI + npm)

~96%cobertura de tests

2687tests recogidos

8contratos de arquitectura

Puntuación por capas con invariante anti-falso-positivo demostrableImplementadoSeguridad
Inteligencia de amenazas OSV.dev con degradación fail-closedImplementadoSeguridad
Capa de alucinación LLM opt-in, estructuralmente incapaz de bloquear paquetes legítimosImplementadoSeguridad
Detección de typosquatting determinista sin red (Damerau-Levenshtein + Jaro-Winkler)ImplementadoSeguridad

Stack

Python 3.11+
stdlib only
mypy strict
ruff (bandit)
import-linter
pytest
GitHub Actions
CodeQL
FastAPI
Next.js
PostgreSQL
Redis

Ver repositorio

Phishing URL Detector

Detección de phishing explicable cuyo resultado principal es que el benchmark en el que todo el mundo reporta 99 %+ está roto — más una línea base honesta y TreeSHAP exacto ejecutándose en el navegador.

Rol: Único autor — auditoría de fugas, ingeniería de features, diseño de la evaluación, port de TreeSHAP a JavaScript, servicio e informe escrito.
Context: El trabajo publicado sobre clasificación de URLs de phishing reporta de forma rutinaria 99–100 % de exactitud sobre datasets públicos, y esas cifras no son reproducibles en campo. PhiUSIIL (UCI id 967, 235.795 URLs) es el dataset reciente más citado, así que es donde más vale la pena medir la brecha entre la literatura y la realidad.

Problema

Nadie había cuantificado por qué esos resultados no transfieren. Auditar el archivo crudo primero — en lugar de entrenar sobre él — era la única forma de separar lo que aprende el modelo de lo que filtra el dataset, y luego declarar una cifra que sobreviva al contacto con phishing recolectado después de los datos de entrenamiento.

Enfoque

Auditoría de fugas antes de entrenar nada: dos fugas de etiqueta independientes medidas sobre el archivo crudo. `URLSimilarityIndex` vale exactamente 100.000 en 134.850 de 134.850 filas legítimas, y la clase legítima es un artefacto de recolección — 100 % `https://www.`, 0,00 % con path, query o `@`.
Se descarta toda columna precalculada; el modelo entrena solo sobre el nombre de host canonicalizado. Un test guardián muta esquema, path, query, puerto y prefijo `www.` y verifica que el vector de features sea idéntico bit a bit — con un control negativo que planta una fuga, porque un guardián que no puede fallar no vale nada.
División agrupada por dominio registrable (eTLD+1, sección ICANN de la Public Suffix List) para que ningún dominio caiga en ambos lados. Los sufijos de hosting deliberadamente no se usan como clave de agrupación — eso premiaría memorizar un proveedor — y en su lugar se exponen como feature.
Evaluación fuera de distribución y temporal: Tranco top-1M como benigno, hosts de PhishTank enviados después del corte como phishing, y el feed vivo de OpenPhish como sonda independiente. Tres contaminaciones eliminadas y contadas, cada una de las cuales habría maquillado el resultado.
TreeSHAP exacto dependiente del camino reimplementado en JavaScript sin dependencias para que la demo explique su propio veredicto sin backend, con paridad verificada a 1e-12 contra la referencia de Python.

Impacto

La fuga queda cuantificada, no afirmada: una regla de una línea alcanza 99,67 % de exactitud, y features léxicas hechas a mano sobre la URL cruda — el rescate obvio tras tirar las columnas contaminadas — siguen dando 99,51 % sin medir nada.
La cifra honesta, contra phishing enviado dos años después de los datos de entrenamiento: ROC-AUC 0,937 y 70,5 % de recall con 1 % de falsos positivos.
Punto de operación ajustado desde la ROC en vez del 0,5 por defecto: los falsos positivos bajan de 13.453 a 999, una reducción del 92,6 %, a cambio de 18 puntos de recall. El intercambio se publica, no se esconde.
Entregado por partida doble: una demo estática de coste cero en GitHub Pages que puntúa y explica en el navegador, y un servicio FastAPI containerizado con scoring por lotes y un endpoint de introspección del modelo.

0.937ROC-AUC (OOD + temporal)

70.5%recall con 1 % de FPR

99.67%exactitud de la fuga de una línea

92.6%falsos positivos eliminados

8.9e-16delta SHAP máx. Python ↔ JS

113tests

Test guardián de fugas con control negativo de fuga plantadaImplementadoResiliencia
Split agrupado por eTLD+1 y evaluación temporal posterior al corteImplementadoResiliencia
Mapeo a MITRE ATT&CK (T1566 / T1566.002) con detection-as-codeImplementadoSeguridad
`feature_spec_sha256` se niega a puntuar si hay desviación train/serveImplementadoResiliencia
TreeSHAP exacto en el navegador — sin backend, sin telemetríaImplementadoUX
Servicio FastAPI containerizado (individual, por lotes, introspección del modelo)ImplementadoResiliencia

Stack

Python 3.12
LightGBM
scikit-learn
SHAP
FastAPI
Docker
JavaScript (zero deps)
GitHub Pages
pytest
LaTeX

Ver proyecto Ver repositorio Ver proyecto

Vulnerability Prioritisation Dashboard

¿Qué vulnerabilidad parcheas primero? CISA KEV + EPSS + NVD — y una medición que muestra que la ventaja de EPSS que todo el mundo cita es sobre todo artefacto de evaluación.

Rol: Único autor — tubería de ingesta, diseño de métricas, la evaluación prospectiva, dashboard y cinco registros de decisiones de arquitectura.
Context: Todo equipo de seguridad tiene más CVEs que capacidad de remediación, así que el orden de la cola es toda la decisión. La respuesta de la industria es EPSS, y la cifra que se cita para justificarlo es que ordenar por EPSS cubre la misma proporción de explotación real con una fracción del esfuerzo de parcheo.

Problema

Esa comparación puntúa a un pronosticador contra datos que ya vio: EPSS se entrena con señales de explotación y el catálogo KEV *es* la verdad de terreno de explotación. Nada en la presentación habitual separa la habilidad real de pronóstico de la retrospectiva, así que la cifra que dirige presupuestos reales de remediación nunca se había probado de forma prospectiva aquí.

Enfoque

Tubería reproducible sobre tres feeds públicos — el catálogo CISA KEV, las puntuaciones diarias de EPSS y el NVD completo tomado del mirror de fkie-cad en lugar de la API paginada, lo que convierte un rastreo de horas en una descarga de 12 segundos.
Los empates se promedian, nunca se rompen. Decenas de miles de CVEs comparten un CVSS base de exactamente 9,8, así que dejar que `sort` decida el orden dentro de ese bloque mide el orden alfabético de los identificadores CVE. Cada bloque se puntúa como su valor esperado bajo orden uniformemente aleatorio — protegido por un test que viene con control negativo.
La repetición honesta: EPSS congelado en cinco fechas pasadas, el universo rebobinado a los CVEs que existían entonces, y solo las vulnerabilidades que CISA confirmó explotadas *después* cuentan como positivos.
Incertidumbre por bootstrap sobre los positivos — 2.000 remuestreos con semilla fija — porque con 86 a 143 CVEs confirmados como explotados por corte, ese número pequeño es donde vive el ruido de muestreo, no en el universo de 300.000 filas. La línea base aleatoria siempre se grafica; sin ella las dos curvas no tienen escala.
Cuatro vistas del dashboard, cada una respondiendo la pregunta impresa en su encabezado — ningún gráfico existe por decoración — más exportación CSV de la cola, que es el artefacto que un stakeholder pide de verdad.

Impacto

Reproduce la afirmación de la industria exactamente: ordenar 359.399 CVEs vivos por CVSS exige 137.952 parches para cubrir el 80 % de la explotación confirmada, frente a 22.736 por EPSS — una ventaja de 6,1×.
Y luego disuelve la mayor parte. Con las puntuaciones congeladas, EPSS sigue ganando en la cabeza de la cola (1,2–1,8× de CVEs explotados después capturados a igual presupuesto) pero *pierde* en la cola larga, necesitando más trabajo que CVSS para llegar al 80 % de cobertura — ratio de esfuerzo 0,5–0,7×. La dirección se mantiene en los cinco cortes.
El dashboard entrega la política que defiende la medición, no el titular: explotación confirmada primero, uso por ransomware por encima del resto, luego probabilidad pronosticada, con CVSS como guardia de la cola.
Cuatro limitaciones — el sesgo propio de KEV, las puntuaciones CVSS sin congelar, los recuentos pequeños de positivos y las exclusiones posteriores al corte — se declaran en el README en vez de enterrarse, incluida la que juega en contra del hallazgo.

6.1×ventaja de EPSS, medida como se suele

0.5–0.7×la misma ventaja, medida honestamente

359,399CVEs vivos ordenados

1,665entradas KEV como verdad de terreno

2,000remuestreos bootstrap

76tests · 5 ADRs

Cola híbrida: explotación confirmada → uso por ransomware → EPSS, CVSS como guardia de colaImplementadoSeguridad
Vista de SLA de remediación BOD 22-01 con deslizador de capacidad costeado en días de retrasoImplementadoSeguridad
Métrica de esfuerzo/cobertura con empates promediados, protegida por un test con control negativoImplementadoResiliencia
Evaluación prospectiva con puntuaciones congeladas en cinco cortes con IC 95 % por bootstrapImplementadoResiliencia
Contrato de datos versionado: los tests de esquema rompen la build si un feed cambia de formaImplementadoResiliencia
Exportación CSV de la cola de parcheo para stakeholdersImplementadoUX

Stack

Python 3.12
pandas
NumPy
Streamlit
Plotly
PyArrow
pytest
Make
CISA KEV
EPSS
NVD

Ver repositorio

GOATGuard

Cliente móvil Flutter para monitoreo de red y seguridad, con 2FA TOTP completo.

Rol: Único autor — arquitectura del cliente móvil, flujos de auth/2FA, estado y servicios.
Context: Las redes pequeñas — oficinas en casa y PyMEs — carecen de una interfaz móvil accesible para visualizar activos conectados, salud del enlace y alertas de seguridad sin desplegar infraestructura NMS empresarial.

Problema

Las soluciones existentes son de nivel empresarial (costosas, complejas) o herramientas de consumo sin visibilidad de la postura de seguridad. No existía un cliente móvil ligero que combinara monitoreo de red en tiempo real con autenticación reforzada.

Enfoque

Dashboard de salud de red con inventario de dispositivos clasificados por tipo (routers, impresoras, cámaras, etc.).
Feed de alertas de seguridad con niveles de severidad, incluyendo detección de port scans.
Flujo 2FA TOTP completo: enrolamiento por QR, verificación en login, backup codes y recuperación de cuenta.
JWT almacenado en el secure storage del SO (Keystore/Keychain) con interceptor global de errores 401 para gestión de sesión.
Arquitectura WebSocket con reconexión por backoff exponencial para flujos de datos en tiempo real.

Impacto

Aplicación móvil de 14 pantallas con arquitectura de 5 tabs que ofrece una experiencia completa de gestión de seguridad de red.
Seguridad de cuenta con 3 factores (TOTP + backup codes + recovery) respaldada por almacenamiento seguro a nivel de SO.

6.6Klíneas de Dart

3factores de seguridad de cuenta

20+endpoints REST

14pantallas (arq. 5 tabs)

2FA TOTP: enrolamiento QR, verificación en login, backup y recovery codesImplementadoSeguridad
JWT en secure storage del SO (Keystore/Keychain) + interceptor global 401ImplementadoSeguridad
Arquitectura de dashboard en tiempo real (REST + WebSocket)Demo / listo para backendResiliencia
Reconexión WebSocket con backoff exponencialImplementadoResiliencia
Gráficas de series de tiempoDatos simuladosUX
Notificaciones pushDatos simuladosUX

Stack

Flutter
Dart
Provider
Dio
web_socket_channel
flutter_secure_storage
qr_flutter
fl_chart

Ver repositorio

AWS High-Availability Infrastructure

Arquitectura de tres capas repartida en dos zonas de disponibilidad, íntegramente codificada en Terraform y desplegada por un pipeline que nunca ejecuta Terraform en la ruta caliente.

Rol: Único autor — arquitectura, módulos de Terraform, servicio de aplicación, pipeline CI/CD, pruebas de carga y el registro escrito de decisiones.
Context: Evaluación final de Diseño y Gestión de Infraestructura Tecnológica (UPB) con un entregable concreto en vez de un diagrama: un servicio en marcha que sigue respondiendo cuando se pierde una zona de disponibilidad, reproducible desde el código en un sandbox de AWS Academy cuyas credenciales caducan cada cuatro horas.

Problema

La alta disponibilidad es fácil de dibujar y difícil de demostrar. La arquitectura tenía que sobrevivir de forma visible a la caída de una AZ, mantener la base de datos inalcanzable tanto desde internet como desde el balanceador, y redesplegarse en cada push sin que nadie sostenga el estado de Terraform — todo dentro de una cuenta que prohíbe crear roles IAM.

Enfoque

VPC repartida en dos zonas de disponibilidad con subredes públicas y privadas separadas por rol: el balanceador y el NAT gateway viven en subredes públicas, las instancias de aplicación y la base de datos en privadas.
Auto Scaling Group fijado a un mínimo de dos instancias, una por AZ, con el health check HTTP del ALB — no el status check de EC2 — como fuente de verdad de la salud aplicativa.
Security groups de mínimo privilegio en cadena estricta: el ALB acepta internet, la capa de aplicación acepta solo al ALB, y la base de datos acepta solo a la capa de aplicación y no tiene egress alguno.
RDS PostgreSQL Multi-AZ con almacenamiento gp3 cifrado, acceso público deshabilitado y credenciales generadas con `random_password` y marcadas como sensibles para que nunca lleguen al repositorio.
Despliegue sin Terraform en la ruta caliente: GitHub Actions pasa linters y tests, construye la imagen y la sube a ECR, y luego dispara un instance refresh del ASG. Terraform aprovisiona; el pipeline solo rota instancias.
Pruebas de carga con k6 leídas contra CloudWatch — conteo de peticiones, tiempo de respuesta del target, hosts sanos y tasa de 5XX — para que la afirmación sobre balanceo se mida en vez de afirmarse.

Impacto

Toda la infraestructura — VPC, internet y NAT gateways, ALB, Auto Scaling Group, ECR, RDS Multi-AZ, security groups, dashboard y alarma de CloudWatch — se reproduce con un solo `terraform apply`.
Trade-offs documentados con su coste en vez de presentarse como buenas prácticas: un solo NAT gateway en lugar de uno por AZ (~32 USD/mes cada uno, con el modo de fallo escrito), EC2 + ASG en vez de Fargate porque perder una instancia se sobrevive de forma visible, y Multi-AZ en vez de una réplica de lectura porque el failover importaba más que la capacidad de lectura.
Tres flujos independientes mantienen honesto el repositorio: CI sobre la aplicación, CD hacia ECR y el ASG, y un plan de Terraform que corre en los pull requests.

2zonas de disponibilidad

3capas (web / app / datos)

3flujos CI/CD

0puertos de base de datos abiertos a internet

Cadena de security groups de mínimo privilegio; la base de datos no tiene egress ni acceso públicoImplementadoSeguridad
Cifrado en reposo en RDS; contraseñas generadas en Terraform y marcadas como sensiblesImplementadoSeguridad
Failover Multi-AZ con el health check del ALB como fuente de verdadImplementadoResiliencia
Redespliegue sin intervención vía push a ECR + instance refresh del ASGImplementadoResiliencia
Escaneo al subir en ECR y política de ciclo de vida que limita las imágenes guardadasImplementadoSeguridad
Dashboard de CloudWatch y alarma de 5XX, ejercitados bajo carga con k6ImplementadoResiliencia

Stack

Terraform 1.6+
AWS VPC / ALB / ASG / EC2
RDS PostgreSQL 15 Multi-AZ
Amazon ECR
CloudWatch
FastAPI
SQLAlchemy 2.0
Docker
GitHub Actions
k6

Ver repositorio

Autonomous Market Intelligence System

Tubería de mercado dirigida por eventos donde la ingeniería interesante es la capa de gobernanza capaz de negarse a operar — y que ahora mismo se niega.

Rol: Único autor — motor de gobernanza, tubería de ML, ejecución dirigida por eventos y suite de tests. Repositorio privado; recorrido disponible a petición.
Context: Un sistema de larga ejecución que ingiere datos de mercado, noticias y presentaciones ante la SEC, forma una opinión con un ensemble de machine learning y una mesa de analistas multiagente, y puede colocar órdenes bracket en la cuenta de paper trading de Alpaca. Acciones y cripto, con un calendario diario fijo más streaming continuo.

Problema

Cualquier cosa capaz de enviar una orden de forma autónoma es tan segura como aquello que puede detenerla. La parte difícil nunca fue el modelo — fue construir una capa que rechaza señales que no puede justificar, escala las ambiguas a una persona, y mantiene todo el sistema lejos del dinero real hasta que las cifras se lo ganen.

Enfoque

Un motor de gobernanza con siete comprobaciones de riesgo y un cortacircuitos por drawdown de cartera se interpone entre cada señal y el bróker: la confianza alta ejecuta, la media pasa a un teclado en línea de Telegram y expira sin respuesta a los 30 minutos, y la baja se rechaza sin más.
Validación walk-forward con ventana expansiva y un hueco purgado de 21 días; un ensemble de XGBoost, RandomForest y LogisticRegression con calibración de Platt — la isotónica se reemplazó porque colapsaba las probabilidades — y ajuste con Optuna cada tres folds.
Cuarenta features construidas que abarcan acción del precio, volatilidad, régimen de mercado y sentimiento de noticias con FinBERT, con selección dinámica de features por encima de un piso de importancia.
Ejecución dirigida por eventos: un bus pub/sub de asyncio sobre trece tipos de evento, tres flujos WebSocket con reconexión por backoff exponencial y búferes circulares de ticks, y un planificador con ocho trabajos.
Una puerta GO/NO-GO que debe superarse antes de considerar capital real: al menos 30 operaciones en 90 días, 55 % de aciertos, Sharpe ≥ 1,0, drawdown máximo ≤ 15 % y exactitud del modelo ≥ 55 %.

Impacto

505 tests automatizados en diecisiete suites, cargados hacia las partes que pueden perder dinero: gobernanza, ejecución, calibración, reconciliación y la capa de streaming.
El estado actual se reporta en vez de maquillarse: el ensemble está en 52,9 % de exactitud frente a una puerta del 55 %, así que el sistema deliberadamente no está autorizado para capital real y opera solo en papel.
Cada predicción se guarda y se valida contra lo que ocurrió de verdad, de modo que la exactitud del modelo es una serie medida y no una afirmación del momento de entrenamiento.

505tests en 17 suites

7comprobaciones de riesgo antes de cada orden

40features de ML construidas

52.9%exactitud del modelo

13tipos de evento en el bus

3flujos WebSocket

Motor de gobernanza: 7 comprobaciones de riesgo más un cortacircuitos por drawdown de carteraImplementadoSeguridad
Aprobación humana en el bucle vía Telegram, con expiración a los 30 minutosImplementadoSeguridad
Puerta GO/NO-GO que bloquea el capital real hasta que las métricas se cumplanImplementadoSeguridad
Validación walk-forward con hueco purgado y calibración de PlattImplementadoResiliencia
Streaming WebSocket con reconexión por backoff exponencial y proveedor de respaldoImplementadoResiliencia
Operativa en vivo con capital realDatos simuladosSeguridad

Stack

Python 3.14
XGBoost
scikit-learn
Optuna
FinBERT
CrewAI
DuckDB
ChromaDB
aiohttp
APScheduler
Alpaca API
Telegram Bot API
Streamlit