Primeros pasos
Scvltori corre siete frameworks de threat modeling sobre tu arquitectura real y convierte el resultado en un score de riesgo defendible. Esta página explica cómo está organizada la plataforma y en qué orden trabaja la mayoría de los equipos.
Qué hace realmente la plataforma
El threat modeling normalmente significa una de dos cosas: un checklist que alguien llena una vez, o una IA que inventa amenazas que suenan plausibles sin forma de verificarlas. Scvltori reemplaza ambas con un pipeline estructurado: describes tu sistema como activos y dataflows, siete frameworks lo analizan, y cada hallazgo recibe un score de riesgo residual construido con CVSS v3.1, probabilidad Bayesiana y tus controles reales — no un color.
- IDENTIFICAR AMENAZAS
- análisis de IA basado en tus propios activos y dataflows, no en una plantilla genérica.
- PRIORIZAR
- un score de riesgo residual (0–100) por amenaza, para que sepas qué arreglar primero.
- MOSTRAR EL TRABAJO
- reportes ejecutivos y técnicos, en PDF o HTML, en español o inglés.
- JUSTIFICAR INVERSIÓN
- cada control que agregas tiene un efecto medible en el score — puedes señalar exactamente qué número se movió.
- MANTENERLO VIVO
- un risk register en constante actualización, con estados de tratamiento, no un ejercicio de una sola vez.
Cómo se organiza un proyecto
Todo vive dentro de un proyecto — un sistema que estás modelando. Dentro de él:
- ASSETS
- los componentes de tu sistema y el diagrama interactivo que los conecta.
- FRAMEWORKS
- un espacio de trabajo dedicado por framework (STRIDE, MITRE ATT&CK y el resto), cada uno con su propia lista de amenazas generadas.
- THREAT INTELLIGENCE
- los hallazgos de todos los frameworks, deduplicados en una sola lista canónica — aquí es donde cambias el estado de una amenaza.
- RISK REGISTER
- el inventario completo, el más reciente primero — la vista de solo lectura de qué tan expuesto está el proyecto ahora mismo.
- CONTROLS
- tu biblioteca de controles, y la matriz que los liga a las amenazas que realmente cubren.
- REPORTS
- genera un documento ejecutivo o técnico a partir del estado actual del proyecto, cuando lo necesites.
El orden en el que trabaja la mayoría de los equipos
- Paso 1:
Crea un proyecto y describe el sistema en unas frases.
- Paso 2:
Agrega los activos — los componentes, sean los que sean.
- Paso 3:
Dibuja los dataflows entre ellos en el canvas.
- Paso 4:
Corre el análisis por framework; la mayor parte de la espera es la IA misma, típicamente unos minutos por framework, no trabajo manual.
- Paso 5:
Revisa lo que arrojó y tríalo — marca lo que es real, y lo que estás aceptando.
- Paso 6:
Construye tu biblioteca de controles y liga cada uno a las amenazas que realmente cubre.
- Paso 7:
Actualiza el estado de tratamiento en el risk register conforme los controles entran en producción.
- Paso 8:
Genera un reporte.
Cinco a ocho activos bien documentados producen resultados más precisos que veinte vagos — la especificidad es lo que usan tanto la IA como el motor de riesgo.
Trabajar en equipo
El acceso es por rol — desde un viewer de solo lectura hasta un admin del workspace — y se aplica en el API, no solo se esconde en la interfaz. Consulta Equipo y Roles para el detalle completo.
Preguntas frecuentes
- ¿PUEDO VOLVER A CORRER EL ANÁLISIS?
- Sí, las veces que quieras. Los hallazgos que ya están en tu proyecto se reconocen y se actualizan en vez de duplicarse, y lo que marcaste como mitigado, aceptado o transferido se queda intacto — tu criterio sobrevive la nueva corrida.
- ¿PUEDO AGREGAR AMENAZAS QUE LA IA NO DETECTÓ?
- No escribiéndolas a mano — hoy no existe la captura manual de amenazas. Si falta algo, agrega el activo o el dataflow del que viene y vuelve a correr; el análisis lo toma de ahí. Lo que ya se encontró siempre lo puedes reclasificar.
- ¿Y SI UNA AMENAZA NO APLICA EN NUESTRO CASO?
- Márcala como aceptada. El motor respeta esa decisión: las corridas siguientes no la reabren, y se queda visible en el registro como una decisión documentada en vez de desaparecer.