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 
SYNAPTIC Sentinel v0.3.22: El Auditor de Seguridad en tu Visual Studio Code. Open Source. Gratuito. BYOK.
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:
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.
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.
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.
escrito por Chema Alonso con la colaboración de Pablo González, Fran Ramírez, Amador Aparicio, Manuel S. Lemos y José Palanco en 0xWord
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.
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.
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.
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.
No hay comentarios:
Publicar un comentario