En corto.
SYNAPTIC Sentinel es un auditor de seguridad que vive dentro de
Visual Studio Code y revisa tu código, el que genera la
IA, tus dependencias y tu configuración, sin que nada salga de tu máquina. Es software libre bajo
Apache-2.0, totalmente gratuito, y queda a disposición de cualquier desarrollador: se instala
desde el Marketplace, corre en local y sólo usa tus propias
APIKeys de
IA si quieres el triaje asistido. Si escribes código con ayuda de un asistente, vale la pena instalarlo y probarlo hoy mismo. Lo que sigue en este artículo es un recorrido por la versión
0.3.22 con datos de un proyecto real.
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
SYNAPTIC 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.
SYNAPTIC 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
SYNAPTIC 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.
SYNAPTIC 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,
SYNAPTIC 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.
SYNAPTIC 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
SYNAPTIC 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 pre-clasifica 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.
La mirada de
Orsyon. En
Orsyon lo usamos en las entregas. Cada desarrollo pasa por
SYNAPTIC Sentinel antes de llegar al cliente, y el historial
append-only de
colony.db nos deja una evidencia auditable del triaje, no sólo del escaneo. Si un hallazgo cambia de veredicto entre una entrega y la siguiente, el banner lo pone a la vista con su razón y su fecha. Para quien trabaja bajo el doble cumplimiento chileno (
Ley 21.663 de ciberseguridad y Ley 21.719 de datos personales), esa trazabilidad es parte de la evidencia de control, no un extra.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
