SYNAPTIC Sentinel v0.3.22: cuando el veredicto de seguridad cambia de proveedor

Ejecutas un triaje de seguridad con un modelo de IA. Te dice: "falso positivo, confianza 95%". Cambias de proveedor, vuelves a lanzarlo, y ahora el mismo hallazgo aparece como "no concluyente, confianza 40%". ¿A cuál le crees? Peor todavía: si nadie te avisa de que la respuesta cambió, te quedas con la última que viste y sigues adelante.

Esa es exactamente la incomodidad que ataca la versión 0.3.22 de SYNAPTIC Sentinel, la herramienta Open Source (Apache-2.0) de auditoría de seguridad para código asistido por IA que GoLab mantiene en el Marketplace de VS Code. Las capturas de este artículo salen de un workspace real, SYNAPTIC_SAAS, con datos reales sobre un scan de 44 hallazgos. No hay mockups.

El scan: 44 hallazgos y de dónde salen

Un escaneo de Sentinel arranca por la capa determinista: cinco scouts corriendo en paralelo sobre el repositorio. En este caso, OpenGrep encuentra 1 hallazgo, Gitleaks 2, Trivy 45, Checkov 0 y Vibe-Detect 0. Tras la deduplicación y las supresiones conocidas quedan 44 hallazgos para triar, que el sidebar desglosa por estado: 33 true positive, 10 inconclusive, 1 false positive.

La línea que importa en v0.3.22 es la de arriba: Scan diff vs previous triage: 1 new, 9 re-classified (0 class, 9 confidence, 0 provider), 34 unchanged. Sentinel ya no se limita a decirte qué encontró: te dice qué cambió respecto del triaje anterior y por qué. De las 9 reclasificaciones, las 9 fueron por variación de confianza, ninguna por cambio de clase ni de proveedor. Antes, esos 9 hallazgos habrían contado como "sin cambios" pese a que su confianza se había movido. Ahora el resumen refleja lo que realmente pasó.

Cuando el veredicto cambia entre proveedores

Este es el corazón de la versión. Mira el hallazgo de @grpc/grpc-js 1.14.3, vulnerable a CVE-2026-48068. Está marcado como no concluyente, y sobre la tarjeta aparece un banner naranja: Verdict changed since last scan: inconclusive 0% a inconclusive 40%, con la razón Confidence changed significantly (Δ 0.40).

El banner salta solo cuando el veredicto actual difiere del anterior. La razón sigue una precedencia clara: primero mira si cambió el proveedor, luego la clase (TP/FP/INC), luego la confianza, con un umbral configurable que por defecto es 0.15. Es un aviso barato de calcular y difícil de ignorar. Antes, esa varianza entre proveedores era invisible: cambiabas de modelo, el número se movía por debajo y nadie te lo decía.

La memoria de la colonia y el historial Previously

Cada hallazgo guarda su trayectoria completa. La sección Previously es colapsable, y al abrirla ves todos los veredictos anteriores con su timestamp, su proveedor y su racional. Eso vive en la tabla verdict_history de colony.db, la base SQLite local que Sentinel mantiene en el directorio .sentinel/ del propio repo. Es append-only por diseño: el comando de re-triaje no borra el historial. Cambias de proveedor, vuelves una semana después, y la trayectoria completa sigue a un clic de distancia.

Esa misma memoria acelera los escaneos. Cuando un patrón se ha visto antes con evidencia sólida, Sentinel lo preclasifica sin gastar una llamada al LLM. En la captura, el hallazgo de protobufjs (CVE-2026-41242) sale marcado como true positive al 75% porque el patrón SCA:CVE-2026-41242 ya fue true positive en 3 hallazgos previos. Y cuando varios hallazgos comparten la misma raíz, uno actúa de representante (badge GROUPED REP) y hace la llamada real; los demás son miembros (badge GROUPED) que heredan el veredicto con una rebaja de confianza del 0.9x. Así el representante queda al 75% y el miembro al 68%, con el sufijo [group SCA:protobufjs@7.5.4:CVE-2026-41242, member 2 of 2] en el racional para que la propagación sea auditable. Alta confianza en el grupo, media en cada miembro suelto: honestidad epistémica en vez de un número inflado.

Agrupar para no quemar tokens, y un proveedor por agente

La agrupación no es solo higiene visual: ahorra dinero. En esta sesión, Grouping: 12 group(s) covering 24 findings; 20 solitary. LLM calls saved by grouping: 12. Doce llamadas al modelo que no se hicieron porque el veredicto se propagó dentro del grupo.

Sentinel además deja elegir un proveedor distinto por agente. En el agents.yaml de esta sesión: triage=OpenAiCompatible, context=Anthropic, remediation=Anthropic. La idea es mezclar por coste, calidad y privacidad, con las llaves siempre bajo modelo BYOK (Bring Your Own Key), leídas del entorno y nunca escritas en el repo.

Y aquí viene el detalle que más me gusta: cuando algo falla, Sentinel lo enseña. En el terminal se ven los 404 de los agentes de contexto y remediación porque el modelo configurado (deepseek-v4-pro) no existía bajo el proveedor apuntado. En lugar de tragarse el error y devolver un veredicto vacío como si nada, la herramienta lo escupe a la vista. Un fallo de configuración se vuelve visible en vez de silencioso, que es justo lo que quieres en una herramienta de seguridad.

Remediación honesta: cuando el bump no basta

Un aviso de "actualiza la dependencia" es fácil de dar y muchas veces está mal. Sentinel agrupa las remediaciones de SCA y, cuando la cosa no es tan simple, lo dice. En el caso de prismjs, el panel no se limita a "sube a 1.30.0": avisa Top-level bump alone will NOT fix this (npm) y entrega el override exacto que hay que aplicar, con botón de copiar, porque una dependencia transitiva está fijando una versión vulnerable anidada.

Lo mismo con protobufjs, que arrastra 22 hallazgos vía @google-cloud/firestore: el fix es heterogéneo entre major tracks, y subir a una sola versión puede dejar otros CVE abiertos, así que hay que aplicar los máximos por track. Es el tipo de matiz que un escáner que solo lista CVEs nunca te da.

Falsos positivos que no vuelven

El taint analysis de Sentinel marca, por ejemplo, un sentinel-js-taint-sql-injection en src/api/routes/agent.ts:62: datos controlados por el usuario que fluyen a un sink SQL dentro de un string. Si tras revisarlo es un falso positivo, el quick fix Mark as false positive lo añade a fp_known en colony.db y deja de aparecer en escaneos posteriores. No se pierde del historial, simplemente deja de hacer ruido. Y como el patrón queda en la memoria de colonia, la próxima vez que aparezca uno igual se preclasifica solo, con la nota was false_positive in 3 prior findings.

Para CI/CD y con el coste a la vista

Todo esto también corre fuera del editor. El comando synaptic-sentinel diff --json devuelve la reclasificación en JSON estructurado, con la razón y los deltas exactos de cada cambio, listo para alimentar un dashboard o para filtrar con jq en un pipeline. La bandera --fail-on convierte el scan en un gate por severidad. Y al final de cada sesión tienes el coste real: en el ejemplo, el agente de triaje con DeepSeek v4-pro consumió 0,0046 USD en 8 llamadas. Sabes lo que te costó el scan antes de que llegue la factura del proveedor. Los conteos de tokens son estimaciones (chars/4, con un margen del 15-20%) y aparecen marcados como tales, sin vender una precisión que no se tiene.

Por qué esto importa

La promesa de v0.3.22 es sencilla: la confianza en un veredicto de seguridad no debería evaporarse al cambiar de proveedor ni al pasar una semana. El banner de veredicto cambiado, el historial append-only en colony.db y el desglose de reclasificaciones convierten la varianza entre modelos en algo visible y auditable, en vez de un número que se mueve a tus espaldas. Súmale la agrupación que ahorra llamadas, la remediación que admite cuándo un bump no basta y los errores mostrados sin maquillaje, y tienes una herramienta que prefiere decirte la verdad incómoda antes que un resultado bonito.

Todo bajo Apache-2.0, sin tier premium y con BYOK sobre el proveedor que elijas. La v0.3.22 se distribuye como release en GitHub con su .vsix, y el código está abierto para que lo audites tú mismo.

Enlaces

• Marketplace de VS Code
• Sitio del producto (GoLab)
• Releases en GitHub
• Documentación técnica (DeepWiki)

Licencia: Apache-2.0. Parte de la familia SYNAPTIC de GoLab.