DEV Community: JULIO SAMUEL CORTEZ MAMANI

Más allá del escáner: Diseño de un panel interactivo DevSecOps para análisis de seguridad móvil (SAST) con Python, Streamlit y Plotly.

JULIO SAMUEL CORTEZ MAMANI — Tue, 27 Oct 2026 03:20:15 +0000

Resumen ejecutivo: El panorama de la seguridad en aplicaciones móviles enfrenta una crisis de visibilidad. Con la adopción de arquitecturas nativas de la nube, las aplicaciones de Android (APK) a menudo ocultan credenciales codificadas de forma rígida (hardcoded secrets), configuraciones de red inseguras y vulnerabilidades criptográficas. Las herramientas tradicionales de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) como SonarCloud o Snyk generan reportes masivos en formato JSON o PDF que los equipos de desarrollo rara vez priorizan de manera efectiva.

En este artículo, explicamos cómo desarrollamos un panel interactivo de inteligencia de seguridad (DevSecOps) en Python puro utilizando Streamlit y Plotly, respaldado por más de 5,000 hallazgos de vulnerabilidades en aplicaciones móviles, una canalización automatizada de GitOps CI/CD con GitHub Actions y despliegue continuo en la nube a través de Azure Container Apps.

Enlaces del proyecto:

El desafío de la seguridad móvil: sobrecarga de alertas vs. remediación

La eficiencia de los equipos de ciberseguridad depende de su capacidad para clasificar, priorizar y mitigar riesgos antes de que el código llegue a producción. Para los ingenieros DevSecOps y los desarrolladores móviles, la gestión de vulnerabilidades presenta un problema multivariable:

¿Cómo diferenciamos un "Falso Positivo" de una vulnerabilidad crítica (CVSS > 9.0) en una base de código de 500,000 líneas?
¿Qué porcentaje de nuestra deuda técnica de seguridad proviene de dependencias de terceros (Snyk) frente a código mal estructurado (SonarCloud)?
¿Cuántos tokens de acceso a bases de datos o claves de API de AWS están expuestos en texto plano dentro de los archivos classes.dex del APK?
¿Cómo proyectamos el esfuerzo de ingeniería (en horas) necesario para remediar las vulnerabilidades de inyección SQL (CWE-89) en el próximo sprint?

Históricamente, las auditorías de seguridad móvil dependían de procesos manuales o plataformas aisladas que presentaban limitaciones:

Fatiga de alertas (Alert Fatigue): Los escáneres estáticos arrojan miles de advertencias de nivel informativo que ocultan las vulnerabilidades críticas.
Falta de contexto visual: Los archivos JSON sin procesar generados por los motores SAST no permiten a los gerentes técnicos tomar decisiones rápidas sobre qué parchear primero.
Silos entre Seguridad y Desarrollo: Los reportes estáticos no permiten simulaciones de tipo "What-If" para calcular cómo mejoraría el puntaje de riesgo global si se corrigen solo 10 dependencias clave.

Para resolver esto, diseñamos un panel web interactivo que transforma los datos crudos de ingeniería inversa y análisis estático en una herramienta de triaje visual en tiempo real.

Selección de la cadena de herramientas: el caso de Streamlit + Plotly

Marco de visualización	Fuerza primaria	Consideraciones arquitectónicas	Adecuado para este proyecto
Kibana / Grafana	Excelente para series temporales y logs de infraestructura.	Requiere montar el stack ELK o Prometheus completo. Curva de configuración alta.	Excesivo para visualizar resultados de escaneos estáticos puntuales.
Dash (Plotly)	Aplicaciones empresariales reactivas de pila completa.	Código más verboso (callbacks). Excelente para producción, pero más lento para iterar modelos de datos mutables.	Opción sólida, pero requiere más boilerplate para interfaces sencillas.
Shiny (Python)	Computación reactiva basada en R, adaptada a Python.	Ecosistema un poco más de nicho en el mundo de la ciberseguridad.	Mejor para estadística pura, menos integraciones directas con SDKs de seguridad.
Streamlit	Convierte scripts de Python en web apps al instante.	Ejecución procedural. Compatible de forma nativa con Pandas y bibliotecas de parsing de código.	Herramienta elegida: iteración rápida, fácil de dockerizar e integrar en pipelines DevSecOps.

La elección de Streamlit permitió integrar directamente scripts de Python que parsean manifiestos de Android (AndroidManifest.xml) y resultados de descompilación directamente en la memoria del dashboard, complementado con la interactividad de Plotly.

La capa de datos: telemetría de vulnerabilidades (SAST & SCA)

El panel no utiliza datos sintéticos simples, sino que ingiere y normaliza resultados de motores de análisis estático (SAST) y análisis de composición de software (SCA).

Especificaciones del motor de datos

Área de estudio: Seguridad en aplicaciones móviles (Android/APK), ingeniería inversa, triaje de vulnerabilidades.
Fuentes de ingesta analizadas:
- Análisis estático (SAST): reglas personalizadas, SonarCloud.
- Detección de secretos: Gitleaks, detectores de entropía.
Volumen: +5,000 hallazgos históricos catalogados.

Parámetros clave

Parámetro	Descripción
`App_Build_ID`	Identificador de la compilación en el pipeline.
`Vulnerability_ID`	Hash único del hallazgo.
`Severity`	Crítico, Alto, Medio, Bajo.
`CVSS_Score`	Puntaje estándar de vulnerabilidad (0.0 a 10.0).
`CWE_Category`	Clasificación de debilidad (ej. CWE-79, CWE-311).
`Component_Path`	Ruta del archivo afectado en el repositorio.
`Time_to_Remediate_Hrs`	Estimación de horas de desarrollo para parchear.
`Status`	Abierto, Mitigado, Falso Positivo.

Decisión arquitectónica: caché en memoria para JSON masivos

Dado que los escaneos de seguridad generan archivos JSON de varios megabytes, utilizamos @st.cache_data para cargar los dataframes en la memoria del servidor de Streamlit solo una vez por sesión, reduciendo el tiempo de renderizado de los gráficos a milisegundos tras la carga inicial.

Dentro del motor analítico: 5 módulos principales

El sistema se divide en cinco perspectivas para facilitar el triaje de seguridad:

Matriz de Riesgo y Postura Global: Distribución de severidad y deuda técnica.
Mapa de Calor de Debilidades (CWE Treemap): Visión jerárquica de los vectores de ataque más comunes.
Radar de Secretos Expuestos: Filtro específico para credenciales hardcodeadas (claves API, tokens).
Simulador de Remediación (What-If): Deslizadores para proyectar la reducción del riesgo si el equipo dedica N horas al sprint de seguridad.
Generador de Reportes Ejecutivos: Exportación automatizada filtrada para los stakeholders.

A continuación, un extracto del código que genera el Mapa de Calor Jerárquico (Treemap) para categorizar vulnerabilidades por severidad y tipo:

`import streamlit as st
import pandas as pd
import plotly.express as px

# Ingesta en caché de resultados SAST
@st.cache_data
def load_security_scan():
    # En producción esto lee de Supabase o archivos JSON en S3
    return pd.read_parquet("data/sast_results.parquet")

df = load_security_scan()

st.subheader("Mapa de Calor de Vulnerabilidades por CWE")

# Filtros interactivos en la barra lateral
severity_filter = st.sidebar.multiselect(
    "Filtrar por Severidad",
    options=["Critical", "High", "Medium", "Low"],
    default=["Critical", "High"]
)

filtered_df = df[df["Severity"].isin(severity_filter)]

# Agrupación de datos para el Treemap
treemap_data = filtered_df.groupby(["Severity", "CWE_Category"]).size().reset_index(name="Count")

# Renderizado de Plotly Express
fig = px.treemap(
    treemap_data, 
    path=["Severity", "CWE_Category"], 
    values="Count",
    color="Severity",
    color_discrete_map={
        "Critical": "#8B0000", 
        "High": "#FF4500", 
        "Medium": "#FFA500", 
        "Low": "#2E8B57"
    },
    title="Distribución Jerárquica de Deuda Técnica de Seguridad"
)

fig.update_layout(margin=dict(t=50, l=25, r=25, b=25), template="plotly_dark")
st.plotly_chart(fig, use_container_width=True)`

🏛️ System Architecture & GitOps Pipeline

+-----------------------------------------------------------------------------------------+
|                                    1. DATA LAYER                                        |
|  [ data/sast_results.parquet ]                             [ CI/CD Artifacts (JSON) ]   |
|  (5,000+ Normalized Vulnerability Findings)                (SonarCloud / Snyk outputs)  |
+-----------------------------------------------------------------------------------------+
                                      │
                                      ▼ (Data Ingestion)
+-----------------------------------------------------------------------------------------+
|                       2. APPLICATION CORE & CACHING LAYER                               |
|  • @st.cache_data(ttl=3600) Fast In-Memory Parsing of Security Artifacts                |
|  • Pandas Filtering Engine (By Component, Severity, CVSS Score, CWE Type)               |
|  • Automated Risk Scoring Algorithms                                                    |
+-----------------------------------------------------------------------------------------+
                                      │
                                      ▼ (Reactive Dataframes)
+-----------------------------------------------------------------------------------------+
|                         3. ANALYTICAL MODULES & SEC ENGINES                             |
|  ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────────────────┐  |
|  | Module 1: Risk Matrix | | Module 2: CWE Heatmap | | Module 3: Secrets Radar       |  |
|  | • CVSS Distributions  | | • Plotly Treemap      | | • Hardcoded Token Alerts      |  |
|  | • Tech Debt (Hours)   | | • Dependency Trees    | | • Entropy Analysis Viewer     |  |
|  └───────────────────────┘ └───────────────────────┘ └───────────────────────────────┘  |
|  ┌─────────────────────────────────────────────────┐ ┌───────────────────────────────┐  |
|  | Module 4: What-If Mitigation Simulator          | | Module 5: Audit Export        |  |
|  | • Adjust Sprint Hours for Security              | | • Dynamic DataTable           |  |
|  | • Calculate Projected Risk Reduction            | | • Generate Compliance CSV/PDF |  |
|  └─────────────────────────────────────────────────┘ └───────────────────────────────┘  |
+-----------------------------------------------------------------------------------------+
                                      │
                                      ▼ (git push origin main)
+-----------------------------------------------------------------------------------------+
|                             4. DEVSECOPS & CI/CD PIPELINE                               |
|  [ GitHub Repository ] ──► [ GitHub Actions Runner ] ──► [ Azure Container Apps ]       |
|  • Version Control         • Terraform Provisioning      • Docker Image Build           |
|  • Branch: main            • Snyk Container Scan         • Managed Cloud Run (SaaS)     |
|                            • Flake8/Bandit Linting       • Secure HTTPS Endpoint        |
+-----------------------------------------------------------------------------------------+

Mastering Production Reliability: Practical Observability with OpenTelemetry, Prometheus, and GitHub Actions

JULIO SAMUEL CORTEZ MAMANI — Sun, 05 Jul 2026 01:26:16 +0000

In modern software engineering, traditional monitoring — simply knowing if a system is up or down — is no longer enough. High-velocity engineering teams require Observability: the ability to infer the internal states of a system based solely on its external outputs.

When a critical microservice misbehaves under high traffic, engineering teams cannot afford to guess. We need contextualized telemetry data that points directly to the root cause. This article provides a comprehensive guide to implementing production-grade observability practices using OpenTelemetry (the vendor-neutral industry standard) alongside Prometheus and Grafana, backed by an automated CI/CD validation workflow.

The Practical Implementation: Multi-Dimensional Metrics

Below is a complete, production-ready Node.js microservice. It showcases how to instrument a checkout endpoint to track both throughput (volume/status) and latency distribution using high-cardinality attributes.

const express = require('express');
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { PrometheusExporter } = require('@opentelemetry/exporter-prometheus');
const { PeriodicExportingMetricReader } = require('@opentelemetry/sdk-metrics');
const opentelemetry = require('@opentelemetry/api');

// 1. Initialize the Prometheus Exporter (Exposes metrics on port 9464)
const exporter = new PrometheusExporter({}, () => {
  console.log('OpenTelemetry metrics exporter running at http://localhost:9464/metrics');
});

// 2. Configure and bootstrap the OpenTelemetry SDK
const sdk = new NodeSDK({
  metricReader: new PeriodicExportingMetricReader({ exporter: exporter }),
});
sdk.start();

const app = express();
app.use(express.json());

// 3. Acquire a Meter from the Global Meter Provider
const meter = opentelemetry.metrics.getMeter('payment-gateway', '1.0.0');

// 4. Define Strategic Metrics: Counters and Histograms
const totalPaymentsCounter = meter.createCounter('payment_requests_total', {
  description: 'Total number of execution checkout requests',
});

const paymentLatencyHistogram = meter.createHistogram('payment_processing_duration_ms', {
  description: 'Latencies associated with external banking handshakes',
  unit: 'ms',
});

// API Route Core Logic
app.post('/api/v1/checkout', async (req, res) => {
  const startTime = Date.now();
  const { paymentMethod, amount } = req.body; // Expected values: 'credit_card', 'crypto', 'paypal'

  try {
    // Simulating external network latency and random payment failure (15% rate)
    const isSuccess = Math.random() > 0.15;
    await new Promise((resolve) => setTimeout(resolve, Math.random() * 350 + 50));

    if (!isSuccess) {
      throw new Error('External banking gateway rejected the transaction.');
    }

    // --- BEST PRACTICE: Increment counter injecting success dimension ---
    totalPaymentsCounter.add(1, {
      method: paymentMethod || 'fallback',
      status: 'success'
    });

    res.status(200).json({ status: 'approved', transactionId: 'tx_live_abc123' });

  } catch (error) {
    // --- BEST PRACTICE: Increment same counter injecting failure dimension ---
    totalPaymentsCounter.add(1, {
      method: paymentMethod || 'fallback',
      status: 'failed'
    });

    // Structured logging supporting telemetry aggregation
    console.error(JSON.stringify({
      timestamp: new Date().toISOString(),
      level: 'ERROR',
      message: error.message,
      metadata: { transactionAmount: amount }
    }));

    res.status(500).json({ error: 'Transaction declined' });
  } finally {
    // --- BEST PRACTICE: Record exact execution boundaries into a Histogram ---
    const totalDuration = Date.now() - startTime;
    paymentLatencyHistogram.record(totalDuration, { method: paymentMethod || 'fallback' });
  }
});

const PORT = 3000;
app.listen(PORT, () => {
  console.log(`Production payment microservice listening on port ${PORT}`);
});

Core Observability Architecture Breakdown

1. Eliminating Vendor Lock-in via OpenTelemetry

By avoiding proprietary agents (e.g., native Datadog or New Relic hardcoded libraries) and writing directly against the OpenTelemetry API, the source code remains completely agnostic. If infrastructure changes require switching backend platforms, only the instantiation layer (PrometheusExporter) is swapped out, saving months of engineering refactoring.

2. Multi-Dimensional Metrics vs. Flat Strings

Instead of spawning decoupled metrics like payments_paypal_failed_total, we deploy a single structured metric (payment_requests_total) attached to structured attributes (method, status). This allows complex PromQL querying structures inside Grafana dashboards, such as:

sum(rate(payment_requests_total{status="failed"}[5m])) by (method)

3. Histograms Over Averages

Averages hide outliers. This implementation tracks duration inside an OpenTelemetry Histogram. When visualized via Grafana, this allows the calculation of percentiles (p95, p99), ensuring engineers observe exactly how the slowest 5% or 1% of real-world clients are experiencing the application performance.

Repository Source Code & CI/CD Automation

The entire code layout, infrastructure manifests (Prometheus/Grafana docker-compose configurations), and local test suites are hosted publicly.

To satisfy automated delivery tracking, continuous quality checks, and deployment guarantees, the repository includes a strict automation workflow driven by GitHub Actions.

Code Repository: https://github.com/open-telemetry/opentelemetry-js

Ejemplo:
https://github.com/open-telemetry/opentelemetry-demo

Automation Blueprint (.github/workflows/ci.yml):

name: Observability Service CI/CD Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  validate-and-test:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout Source Code
      uses: actions/checkout@v4

    - name: Setup Node.js Environment
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'

    - name: Install Production Dependencies
      run: npm ci

    - name: Execute Linter & Code Style Checks
      run: npm run lint

    - name: Run Automated Telemetry Unit Tests
      run: npm test

Conclusion

Implementing robust observability is not a luxury for modern engineering teams; it is a fundamental requirement to guarantee system reliability and operational excellence under scale. By shifting from a reactive "monitoring" mindset to a proactive "observability" framework, organizations can drastically reduce Mean Time to Resolution (MTTR) and uncover hidden system bottlenecks.

Vanna AI (El estándar de la industria para Text-to-SQL)

JULIO SAMUEL CORTEZ MAMANI — Fri, 03 Jul 2026 23:40:49 +0000

Idea central

Vanna es uno de los frameworks de código abierto más utilizados hoy en día para crear asistentes de SQL con IA. Funciona en dos pasos:

Entrenas un modelo de IA (o un índice vectorial) con tu esquema, documentación y consultas SQL reales pasadas.
El modelo genera código con una precisión quirúrgica. ### Ventajas

Se conecta nativamente a Snowflake, BigQuery, PostgreSQL y MySQL.
Incluye interfaces gráficas listas para usar en Slack o aplicaciones web.

Novedades de la versión 2.0
Atención al usuario en cada nivel: las consultas se filtran automáticamente según los permisos del usuario.
Interfaz web moderna <vanna-chat>: un componente prediseñado de gran belleza.
Respuestas en tiempo real: tablas, gráficos y actualizaciones de progreso en tiempo real.
Seguridad empresarial: seguridad a nivel de fila (RLS), registros de auditoría y rate limiting.
Listo para producción: integración con FastAPI, observabilidad y lifecycle hooks.

¿Cómo funciona? (conceptos clave)

User Resolver: define cómo extraer la identidad del usuario de las solicitudes (cookies, JWT, etc.).
Herramientas con reconocimiento de usuario: comprueban automáticamente los permisos según los grupos del usuario.
Componentes de transmisión: el backend transmite componentes de UI estructurados (tablas, gráficos) al frontend en tiempo real.
Interfaz web integrada: el componente <vanna-chat> lo renderiza todo automáticamente. ## Ejemplo de código: configuración de producción con autorización

1. Backend (Python + FastAPI)

from fastapi import FastAPI
from vanna import Agent
from vanna.servers.fastapi.routes import register_chat_routes
from vanna.servers.base import ChatHandler
from vanna.core.user import UserResolver, User, RequestContext
from vanna.integrations.anthropic import AnthropicLlmService
from vanna.tools import RunSqlTool
from vanna.integrations.sqlite import SqliteRunner
from vanna.core.registry import ToolRegistry

# App de FastAPI existente
app = FastAPI()

# 1. Define tu user resolver (usando tu propio sistema de auth)
class MyUserResolver(UserResolver):
    async def resolve_user(self, request_context: RequestContext) -> User:
        # Extraer desde cookies, JWTs o sesión
        token = request_context.get_header('Authorization')
        user_data = self.decode_jwt(token)  # Tu lógica existente

        return User(
            id=user_data['id'],
            email=user_data['email'],
            group_memberships=user_data['groups']  # Usado para permisos
        )

# 2. Configurar el agente con herramientas
llm = AnthropicLlmService(model="claude-3-5-sonnet")
tools = ToolRegistry()
tools.register(RunSqlTool(sql_runner=SqliteRunner("./data.db")))

agent = Agent(
    llm_service=llm,
    tool_registry=tools,
    user_resolver=MyUserResolver()
)

# 3. Añadir las rutas de Vanna a tu aplicación
chat_handler = ChatHandler(agent)
register_chat_routes(app, chat_handler)

# Endpoint listo: POST /api/vanna/v2/chat_sse (streaming)

2. Frontend (componente web)

Agrega esta etiqueta HTML en tu página. Funciona con React, Vue o HTML simple, y utiliza tus cookies/JWT existentes:

<script src="https://img.vanna.ai/vanna-components.js"></script>

<vanna-chat
  sse-endpoint="/api/vanna/v2/chat_sse"
  theme="dark">
</vanna-chat>

Al hacer una pregunta en lenguaje natural, el componente frontend recibe por streaming:

Actualizaciones del progreso de la transmisión.
Bloque de código SQL (por defecto, solo visible para usuarios admin).
Tabla de datos interactiva.
Gráficos (visualizaciones de Plotly).
Resumen en lenguaje natural. ### 3. Herramientas personalizadas

Puedes extender Vanna con herramientas específicas para tu caso de uso de negocio, por ejemplo, enviar un correo automático con los resultados:

from vanna.core.tool import Tool, ToolContext, ToolResult
from pydantic import BaseModel, Field
from typing import Type

class EmailArgs(BaseModel):
    recipient: str = Field(description="Email recipient")
    subject: str = Field(description="Email subject")

class EmailTool(Tool[EmailArgs]):
    @property
    def name(self) -> str:
        return "send_email"

    @property
    def access_groups(self) -> list[str]:
        return ["send_email"]  # Verificación de permisos

    def get_args_schema(self) -> Type[EmailArgs]:
        return EmailArgs

    async def execute(self, context: ToolContext, args: EmailArgs) -> ToolResult:
        user = context.user  # Inyectado automáticamente por Vanna

        # Tu lógica de negocio
        await self.email_service.send(
            from_email=user.email,
            to=args.recipient,
            subject=args.subject
        )

        return ToolResult(success=True, result_for_llm=f"Email sent to {args.recipient}")

# Registrar tu herramienta personalizada
tools.register(EmailTool())

Características avanzadas y casos de uso

Vanna 2.0 incluye potentes funciones empresariales para producción:

Lifecycle Hooks: agrega comprobación de cuotas, registro personalizado y filtrado de contenido.
Middlewares de LLM: implementa caching, ingeniería de prompts o seguimiento de costos.
Almacenamiento de conversaciones: guarda y recupera el historial por usuario.

¿Para qué casos es ideal?
Aplicaciones de análisis de datos con interfaces de lenguaje natural.
SaaS multiusuario que requiere permisos con reconocimiento de usuario (RLS).
Aplicaciones empresariales con requisitos estrictos de seguridad y auditoría.

Flujo de arquitectura

El siguiente flujo detalla el ciclo de vida de una solicitud en Vanna 2.0, desde que el usuario hace la pregunta hasta que se renderizan los componentes visuales:

El usuario escribe una pregunta como "Show Q4 sales" en el componente <vanna-chat>.
El frontend envía un POST al endpoint /api/vanna/v2/chat_sse de tu servidor FastAPI, adjuntando las credenciales de autenticación.
Tu servidor resuelve la identidad del usuario (ej. Alice) y sus grupos de acceso (read_sales), y se los pasa al Agente.
El Agente invoca la herramienta de ejecución de SQL (User-Aware Tool).
La herramienta aplica automáticamente las reglas de seguridad a nivel de fila (RLS) según el grupo del usuario.
La base de datos retorna únicamente los resultados filtrados y autorizados al Agente.
El Agente transmite (streams) la respuesta en bloques estructurados (Tabla → Gráfico → Resumen) de vuelta al componente web. ## Comparativa rápida de enfoques

Enfoque	Complejidad	Mejor para	Herramientas clave
LLM + Python puro	Baja	Prototipos rápidos, scripts internos	API de OpenAI, sqlite3
Agentes (`smolagents`)	Media-Alta	Consultas complejas, autocorrección	Hugging Face, smolagents
Streamlit + HF	Media	Paneles para usuarios no técnicos	Streamlit, transformers
RAG Dinámico	Alta	Entornos enterprise con cientos de tablas	BD vectoriales, DB-GPT
Vanna AI	Media-Alta	Producción escalable, UI web lista y segura	Vanna, FastAPI

Conclusiones y buenas prácticas

Nunca ejecutes SQL generado por IA sin validarlo. Usa listas de operaciones permitidas (SELECT solamente) y usuarios de base de datos de solo lectura.
El contexto del esquema es clave. Cuanto más claro y completo sea el esquema que le das al modelo, mejor será el SQL generado.
Los agentes brillan en tareas multipaso, pero cuestan más tokens y latencia que una llamada simple.
Streamlit es la vía más rápida para llevar un prototipo a manos de usuarios no técnicos.