Strigoi

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.

Si este es su proyecto, por favor muestre el estado de su insignia en la página de su proyecto. El estado de la insignia se ve así:

Aquí se explica cómo insertarla:

Puede mostrar el estado de su insignia insertando esto en su archivo markdown:

[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/11727/badge)](https://www.bestpractices.dev/projects/11727)

o insertando esto en su HTML:

<a href="https://www.bestpractices.dev/projects/11727"><img src="https://www.bestpractices.dev/projects/11727/badge"></a>

Estos son los criterios de nivel

. También puede ver los criterios de nivel

.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

Fundamentos 13/13 ●

General

¿Cuál es el nombre legible del proyecto?
Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

¿Cuál es una breve descripción del proyecto?

Find AI infrastructure vulnerabilities before attackers do. Security testing for MCP servers, AI agents, CLI AI platforms and LLM systems.

¿Cuál es la URL del proyecto (en su conjunto)?
https://github.com/macawi-ai/Strigoi

¿Cuál es la URL del repositorio de control de versiones (puede ser la misma que la URL del proyecto)?
https://github.com/macawi-ai/Strigoi

¿Bajo qué licencia(s) se publica el proyecto?
Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.

¿Qué lenguaje(s) de programación se utilizan para implementar el proyecto?
Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".

¿Cuál es el nombre Common Platform Enumeration (CPE) para el proyecto (si tiene uno)?
La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

Otros comentarios generales sobre el proyecto:
Contenido básico del sitio web del proyecto
Criterion [description_good]
Cumplido

No cumplido

?

El sitio web del proyecto DEBE describir sucintamente qué hace el software (¿qué problema resuelve?). ^{[description_good]}
Esto DEBE estar en un lenguaje que los usuarios potenciales puedan entender (por ejemplo, utiliza jerga mínima).
https://github.com/macawi-ai/strigoi/
(e.g. core capabilities -->
Core Capabilities
🛡️ Security Assessment
```
Interactive CLI - Bash-like navigation with directional reconnaissance (north/south/east/west)
17+ Detection Patterns - API keys, credentials, PII, prompt injection, SSRF, path traversal
MCP Vulnerability Scanner - Specialized scanning for Model Context Protocol servers
Multi-Layer Analysis - 7-layer protocol inspection with Russian doll unpacking
```
📡 Real-Time Monitoring
```
NATS JetStream Integration - Distributed event streaming with persistent storage
A2MCP Bridge - Monitor AI CLI tools (Claude Code, Gemini, ChatGPT) via MCP protocol
Stream Tap - Live STDIO capture with security detection and smart redaction
MetaFrame Protocol - Standardized security telemetry format
```
🏗️ Platform Features
```
Multi-Architecture - AMD64, ARM64, ARMv7 (Raspberry Pi, NanoPi, Orange Pi)
Container-Native - Podman/Docker with rootless support
Web UI Dashboard - Real-time monitoring via http://localhost:8081/
Pre-compiled Binaries - Linux, macOS (Intel/Apple Silicon), Windows
```
Criterion [interact]
Cumplido

No cumplido

?

El sitio web del proyecto DEBE proporcionar información sobre cómo: obtener, proporcionar comentarios (como informes de errores o mejoras), y contribuir al software. ^[interact]
The README provides clear information on all three requirements:
1. Obtain: Multiple installation methods documented including pre-built binaries from GitHub Releases, wget commands for Linux/macOS/Windows, and build-from-source
  via install.sh. Direct links: https://github.com/macawi-ai/strigoi/releases
2. Feedback: Bug reports and enhancement requests via GitHub Issues, linked in README: https://github.com/macawi-ai/strigoi/issues
3. Contribute: Contributing section in README links to Development Methodology guide (docs/DEVELOPMENT_METHODOLOGY.md) covering code of conduct, development process, and pull request submission.
Criterion [contribution]
Cumplido

No cumplido

?

La información sobre cómo contribuir DEBE explicar el proceso de contribución (por ejemplo, ¿se utilizan "pull requests" en el proyecto?) (URL requerida) ^{[contribution]}
Se asume que los proyectos en GitHub usan "incidencias" y "pull requests" a menos que se indique lo contrario. Esta información puede ser breve, por ejemplo, indicando que el proyecto utiliza "pull requests", un gestor de incidencias o publicaciones en una lista de correo (Indíquese cuál)

Projects on GitHub by default use issues and pull requests, as encouraged by documentation such as https://guides.github.com/activities/contributing-to-open-source/.

Criterion [contribution_requirements]
Cumplido

No cumplido

?

La información sobre cómo contribuir DEBERÍA incluir los requisitos para las contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). (URL requerida) ^{[contribution_requirements]}

https://github.com/macawi-ai/strigoi/blob/main/CONTRIBUTING.md
Licencia FLOSS
Criterion [floss_license]
Cumplido

No cumplido

?
El software producido por el proyecto DEBE ser publicado como FLOSS. ^{[floss_license]}
FLOSS es software publicado de una manera que cumple con la Definición de Código Abierto o la Definición de Software Libre. Ejemplos de tales licencias incluyen CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Para nuestros propósitos, esto significa que la licencia DEBE ser:
El software PUEDE también estar licenciado de otras maneras (por ejemplo, "GPLv2 o propietario" es aceptable).
Open Source License

This software is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).

Key AGPL-3.0 Requirements:
```
✅ Freedom to use — Use for any purpose including commercial
✅ Freedom to study — Access to source code guaranteed
✅ Freedom to modify — Make changes and improvements
✅ Freedom to distribute — Share copies and modifications
🔒 Copyleft requirement — Derivative works must be open source
🌐 Network copyleft — SaaS use requires offering source code
```
The AGPL-3.0-or-later license is approved by the Open Source Initiative (OSI).
Criterion [floss_license_osi]
Cumplido

No cumplido

?

Se SUGIERE que cualquier licencia(s) requerida(s) para el software producido por el proyecto sea aprobada por la Open Source Initiative (OSI). ^{[floss_license_osi]}
La OSI utiliza un proceso de aprobación riguroso para determinar qué licencias son OSS.

We utilize the AGPL-3.0 The AGPL-3.0-or-later license is approved by the Open Source Initiative (OSI).

Criterion [license_location]
Cumplido

No cumplido

?

El proyecto DEBE publicar la(s) licencia(s) de sus resultados en una ubicación estándar en su repositorio de código fuente. (URL requerida) ^{[license_location]}
Una convención es publicar la licencia como un archivo de nivel superior llamado LICENSE o COPYING, que PUEDE ser seguido por una extensión como ".txt" o ".md". Una convención alternativa es tener un directorio llamado LICENSES que contenga archivo(s) de licencia; estos archivos generalmente se nombran según su identificador de licencia SPDX seguido de una extensión de archivo apropiada, como se describe en la Especificación REUSE. Tenga en cuenta que este criterio es solo un requisito para el repositorio de código fuente. NO necesita incluir el archivo de licencia al generar algo desde el código fuente (como un ejecutable, paquete o contenedor). Por ejemplo, al generar un paquete R para el Comprehensive R Archive Network (CRAN), siga la práctica estándar de CRAN: si la licencia es una licencia estándar, use la especificación de licencia corta estándar (para evitar instalar otra copia del texto) y liste el archivo LICENSE en un archivo de exclusión como .Rbuildignore. De manera similar, al crear un paquete Debian, puede poner un enlace en el archivo de derechos de autor al texto de la licencia en /usr/share/common-licenses, y excluir el archivo de licencia del paquete creado (por ejemplo, eliminando el archivo después de llamar a dh_auto_install). Alentamos a incluir información de licencia legible por máquina en formatos generados cuando sea práctico.

Non-trivial license location file in repository: https://github.com/macawi-ai/Strigoi/blob/main/LICENSE.
Documentación

Criterion [documentation_basics]
Cumplido

No cumplido

N/A

?

El proyecto DEBE proporcionar documentación básica para el software producido por el proyecto. ^{[documentation_basics]}
Esta documentación debe estar en algún medio (como texto o video) que incluya: cómo instalarlo, cómo iniciarlo, cómo usarlo (posiblemente con un tutorial usando ejemplos), y cómo usarlo de manera segura (por ejemplo, qué hacer y qué no hacer) si eso es un tema apropiado para el software. La documentación de seguridad no necesita ser larga. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. Si el proyecto no produce software, elija "no aplicable" (N/A).

Some documentation basics file contents found.
Criterion [documentation_interface]
Cumplido

No cumplido

N/A

?

El proyecto DEBE proporcionar documentación de referencia que describa la interfaz externa (tanto entrada como salida) del software producido por el proyecto. ^{[documentation_interface]}
La documentación de una interfaz externa explica a un usuario final o desarrollador cómo usarla. Esto incluiría su interfaz de programación de aplicaciones (API) si el software tiene una. Si es una biblioteca, documente las clases/tipos principales y los métodos/funciones que se pueden llamar. Si es una aplicación web, defina su interfaz URL (a menudo su interfaz REST). Si es una interfaz de línea de comandos, documente los parámetros y opciones que admite. En muchos casos es mejor si la mayor parte de esta documentación se genera automáticamente, de modo que esta documentación permanezca sincronizada con el software a medida que cambia, pero esto no es obligatorio. El proyecto PUEDE usar hipervínculos a material no relacionado con el proyecto como documentación. La documentación PUEDE generarse automáticamente (donde sea práctico, esta es a menudo la mejor manera de hacerlo). La documentación de una interfaz REST puede generarse usando Swagger/OpenAPI. La documentación de la interfaz del código PUEDE generarse usando herramientas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R), y Doxygen (muchos). Simplemente tener comentarios en el código de implementación no es suficiente para satisfacer este criterio; necesita haber una manera fácil de ver la información sin leer todo el código fuente. Si el proyecto no produce software, elija "no aplicable" (N/A).
┌────────────┬───────────────────────────────────────────┬───────────────────────────────────────────────────────────────────────────────┐
│ Interface │ Documentation │ URL │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ CLI │ USER_GUIDE.md with full command reference │ https://github.com/macawi-ai/strigoi/blob/main/USER_GUIDE.md │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ CLI │ Built-in --help flags │ strigoi --help, strigoi <cmd> --help │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ REST API │ FLEET_MANAGER_API_SPEC.md │ https://github.com/macawi-ai/strigoi/blob/main/docs/FLEET_MANAGER_API_SPEC.md │
├────────────┼───────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────┤
│ Go Package │ pkg.go.dev (auto-generated) │ https://pkg.go.dev/github.com/macawi-ai/strigoi │
└────────────┴───────────────────────────────────────────┴───────────────────────────────────────────────────────────────────────────────┘

Justification for OpenSSF:

The project provides comprehensive interface documentation:
1. CLI Interface: USER_GUIDE.md documents all commands, subcommands, flags, and usage examples. Built-in --help provides real-time command reference.
2. REST API: docs/FLEET_MANAGER_API_SPEC.md documents all API endpoints with request/response examples in JSON format.
3. Go Package API: Automatically generated documentation available at pkg.go.dev/github.com/macawi-ai/strigoi
URLs:
- https://github.com/macawi-ai/strigoi/blob/main/USER_GUIDE.md
- https://github.com/macawi-ai/strigoi/blob/main/docs/FLEET_MANAGER_API_SPEC.md
Otro

Criterion [sites_https]
Cumplido

No cumplido

?

Los sitios del proyecto (sitio web, repositorio y URLs de descarga) DEBEN admitir HTTPS usando TLS. ^{[sites_https]}
Esto requiere que la URL de la página de inicio del proyecto y la URL del repositorio de control de versiones comiencen con "https:", no "http:". Puede obtener certificados gratuitos de Let's Encrypt. Los proyectos PUEDEN implementar este criterio usando (por ejemplo) GitHub pages, GitLab pages, o SourceForge project pages. Si admite HTTP, le instamos a redirigir el tráfico HTTP a HTTPS.

Given only https: URLs.

Criterion [discussion]
Cumplido

No cumplido

?

El proyecto DEBE tener uno o más mecanismos para la discusión (incluyendo cambios propuestos y problemas) que sean buscables, permitan que los mensajes y temas sean direccionables mediante URL, permitan que nuevas personas participen en algunas de las discusiones y no requieran la instalación del lado del cliente de software propietario. ^[discussion]
Ejemplos de mecanismos aceptables incluyen listas de correo archivadas, discusiones de issues y pull requests de GitHub, Bugzilla, Mantis y Trac. Los mecanismos de discusión asíncrona (como IRC) son aceptables si cumplen con estos criterios; asegúrese de que haya un mecanismo de archivo direccionable por URL. JavaScript propietario, aunque desaconsejado, está permitido.

GitHub supports discussions on issues and pull requests.

Criterion [english]
Cumplido

No cumplido

?

El proyecto DEBERÍA proporcionar documentación en inglés y ser capaz de aceptar informes de errores y comentarios sobre el código en inglés. ^[english]
El inglés es actualmente la lengua franca de la tecnología informática; el soporte del inglés aumenta el número de diferentes desarrolladores y revisores potenciales en todo el mundo. Un proyecto puede cumplir con este criterio incluso si el idioma principal de sus desarrolladores principales no es el inglés.

Criterion [maintained]
Cumplido

No cumplido

?

El proyecto DEBE ser mantenido. ^[maintained]
Como mínimo, el proyecto debe intentar responder a informes de problemas y vulnerabilidades significativos. Un proyecto que está buscando activamente una insignia probablemente esté mantenido. Todos los proyectos y personas tienen recursos limitados, y los proyectos típicos deben rechazar algunos cambios propuestos, por lo que los recursos limitados y los rechazos de propuestas no indican por sí mismos un proyecto no mantenido.

Cuando un proyecto sabe que ya no será mantenido, debe establecer este criterio como "No cumplido" y usar el o los mecanismos apropiados para indicar a otros que no está siendo mantenido. Por ejemplo, use "DEPRECATED" (OBSOLETO) como el primer encabezado de su README, agregue "DEPRECATED" cerca del comienzo de su página de inicio, agregue "DEPRECATED" al principio de la descripción del proyecto del repositorio de código, agregue una insignia no-maintenance-intended en su README y/o página de inicio, márquelo como obsoleto en cualquier repositorio de paquetes (por ejemplo, npm deprecate), y/o use el sistema de marcado del repositorio de código para archivarlo (por ejemplo, la configuración de "archive" de GitHub, el marcado "archived" de GitLab, el estado "readonly" de Gerrit, o el estado de proyecto "abandoned" de SourceForge). Se puede encontrar discusión adicional aquí.

Regular maintenance evidenced on github

Seguridad 16/16 ●

Conocimiento de desarrollo seguro
Criterion [know_secure_design]
Cumplido

No cumplido

?
El proyecto DEBE tener al menos un desarrollador principal que sepa cómo diseñar software seguro. (Ver 'detalles' para los requisitos exactos.) ^{[know_secure_design]}
Esto requiere comprender los siguientes principios de diseño, incluyendo los 8 principios de Saltzer y Schroeder:
- economía de mecanismo (mantener el diseño lo más simple y pequeño posible, por ejemplo, adoptando simplificaciones radicales)
- valores predeterminados seguros ante fallas (las decisiones de acceso deben denegar por defecto, y la instalación de los proyectos debe ser segura por defecto)
- mediación completa (cada acceso que pueda ser limitado debe ser verificado por autoridad y ser no evitable)
- diseño abierto (los mecanismos de seguridad no deben depender de la ignorancia del atacante de su diseño, sino de información más fácilmente protegida y modificable como claves y contraseñas)
- separación de privilegios (idealmente, el acceso a objetos importantes debe depender de más de una condición, de modo que vencer un sistema de protección no permita el acceso completo. Por ejemplo, la autenticación multifactor, como requerir tanto una contraseña como un token de hardware, es más fuerte que la autenticación de un solo factor)
- mínimo privilegio (los procesos deben operar con el mínimo privilegio necesario)
- mecanismo menos común (el diseño debe minimizar los mecanismos comunes a más de un usuario y de los que dependen todos los usuarios, por ejemplo, directorios para archivos temporales)
- aceptabilidad psicológica (la interfaz humana debe estar diseñada para facilitar su uso - diseñar para "menos sorpresa" puede ayudar)
- superficie de ataque limitada (la superficie de ataque - el conjunto de los diferentes puntos donde un atacante puede intentar entrar o extraer datos - debe ser limitada)
- validación de entradas con listas de permitidos (las entradas típicamente deben verificarse para determinar si son válidas antes de aceptarse; esta validación debe usar listas de permitidos (que solo aceptan valores conocidos como buenos), no listas de denegados (que intentan listar valores conocidos como malos)).
Un "desarrollador principal" en un proyecto es cualquier persona que esté familiarizada con la base de código del proyecto, se sienta cómoda haciendo cambios en él y sea reconocida como tal por la mayoría de los demás participantes en el proyecto. Un desarrollador principal típicamente haría una serie de contribuciones durante el año pasado (a través de código, documentación o respondiendo preguntas). Los desarrolladores típicamente serían considerados desarrolladores principales si iniciaron el proyecto (y no han dejado el proyecto hace más de tres años), tienen la opción de recibir información sobre un canal privado de reporte de vulnerabilidades (si existe uno), pueden aceptar commits en nombre del proyecto, o realizar versiones finales del software del proyecto. Si solo hay un desarrollador, ese individuo es el desarrollador principal. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir el diseño. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).
Primary developer Jamie Saker is a senior cybersecurity executive with 30+ years technical hands-on experience with secure networking, infrastructure and code.
Criterion [know_common_errors]
Cumplido

No cumplido

?

Al menos uno de los desarrolladores principales del proyecto DEBE conocer tipos comunes de errores que conducen a vulnerabilidades en este tipo de software, así como al menos un método para contrarrestar o mitigar cada uno de ellos. ^{[know_common_errors]}
Los ejemplos (dependiendo del tipo de software) incluyen inyección SQL, inyección de SO, desbordamiento de búfer clásico, cross-site scripting, falta de autenticación y falta de autorización. Ver el CWE/SANS top 25 o OWASP Top 10 para listas comúnmente usadas. Muchos libros y cursos están disponibles para ayudarle a comprender cómo desarrollar software más seguro y discutir errores de implementación comunes que conducen a vulnerabilidades. Por ejemplo, el curso Secure Software Development Fundamentals es un conjunto gratuito de tres cursos que explican cómo desarrollar software más seguro (es gratuito si lo audita; por una tarifa adicional puede obtener un certificado para demostrar que aprendió el material).

Use buenas prácticas criptográficas

Tenga en cuenta que algunos programas de software no necesitan usar mecanismos criptográficos. Si su proyecto produce software que (1) incluye, activa o habilita funcionalidad de cifrado, y (2) podría ser liberado desde los Estados Unidos (EE.UU.) hacia fuera de los EE.UU. o a una persona que no sea ciudadana de los EE.UU., es posible que esté legalmente obligado a tomar algunos pasos adicionales. Típicamente esto solo implica enviar un correo electrónico. Para más información, consulte la sección de cifrado de Understanding Open Source Technology & US Export Controls.

Cumplido

No cumplido

N/A

El software producido por el proyecto DEBE usar, por defecto, solo protocolos y algoritmos criptográficos que estén públicamente publicados y revisados por expertos (si se usan protocolos y algoritmos criptográficos). ^{[crypto_published]}

Estos criterios criptográficos no siempre aplican porque algunos programas de software no necesitan usar capacidades criptográficas directamente.

All cryptographic implementations use publicly published, expert-reviewed algorithms:

Key Derivation: Argon2id (RFC 9106, winner of Password Hashing Competition 2015)

Parameters: 64MB memory, 4 threads, 32-byte key output

Encryption: AES-256-GCM (NIST FIPS 197 + SP 800-38D)

Authenticated encryption with 12-byte nonce
Go's standard library crypto/aes and crypto/cipher

Random Generation: Go crypto/rand (cryptographically secure)

Timing-Safe Comparison: crypto/subtle.ConstantTimeCompare

TLS: Standard Go crypto/tls (optional, configurable)

No custom or proprietary cryptographic algorithms. See implementations:

pkg/strigoictl/crypto/keystore.go - API key encryption
pkg/session/crypto.go - Session encryption

Cumplido

No cumplido

N/A

Si el software producido por el proyecto es una aplicación o una librería, y su propósito principal no es implementar criptografía, entonces DEBE SOLAMENTE invocar un software específicamente diseñado para implementar funciones criptográficas; NO DEBERÍA volver a implementar el suyo. ^{[crypto_call]}

Software does not implement any cryptography of its own and relies on well supported public libraries for the functionality.

Cumplido

No cumplido

N/A

Toda funcionalidad en el software producido por el proyecto que dependa de criptografía DEBE ser implementable usando FLOSS. ^{[crypto_floss]}

Ver el Open Standards Requirement for Software by the Open Source Initiative.

Cumplido

No cumplido

N/A

Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN usar longitudes de clave predeterminadas que al menos cumplan con los requisitos mínimos de NIST hasta el año 2030 (como se declaró en 2012). DEBE ser posible configurar el software de modo que las longitudes de clave más pequeñas estén completamente deshabilitadas. ^{[crypto_keylength]}

Estas longitudes mínimas de bits son: clave simétrica 112, módulo de factorización 2048, clave de logaritmo discreto 224, grupo logarítmico discreto 2048, curva elíptica 224 y hash 224 (el hash de contraseñas no está cubierto por esta longitud de bits, se puede encontrar más información sobre el hash de contraseñas en el criterio crypto_password_storage). Ver https://www.keylength.com para una comparación de recomendaciones de longitud de clave de varias organizaciones. El software PUEDE permitir longitudes de clave más pequeñas en algunas configuraciones (idealmente no lo haría, ya que esto permite ataques de degradación, pero las longitudes de clave más cortas a veces son necesarias para la interoperabilidad).

All cryptographic key lengths exceed NIST 2030 minimums:

Algorithm	Our Implementation	NIST 2030 Minimum	Status
Symmetric (AES)	256-bit	112-bit	✅ 2.3x minimum
Key Derivation (Argon2id)	256-bit output	N/A (password hashing)	✅
GCM Nonce	96-bit	Standard	✅
Salt	128-256 bit	N/A	✅

Hardcoded, not configurable to weaker values:
// pkg/strigoictl/crypto/keystore.go
argon2KeyLen = 32 // AES-256 (256 bits) - hardcoded constant

// pkg/session/crypto.go
KeyLen: 32 // AES-256 - in DefaultCryptoConfig()

No downgrade path: Key lengths are defined as constants, not user-configurable. There is no option to use AES-128 or smaller keys. The only configurable parameters
are Argon2 work factors (time/memory/threads), which affect security strength, not key length.

See: pkg/strigoictl/crypto/keystore.go:40-41, pkg/session/crypto.go:24

Cumplido

No cumplido

N/A

Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBEN depender de algoritmos criptográficos rotos (por ejemplo, MD4, MD5, DES simple, RC4, Dual_EC_DRBG), o usar modos de cifrado que son inapropiados para el contexto, a menos que sean necesarios para implementar un protocolo interoperable (donde el protocolo implementado es la versión más reciente de ese estándar ampliamente soportada por el ecosistema de red, ese ecosistema requiere el uso de tal algoritmo o modo, y ese ecosistema no ofrece ninguna alternativa más segura). La documentación DEBE describir cualquier riesgo de seguridad relevante y cualquier mitigación conocida si estos algoritmos o modos rotos son necesarios para un protocolo interoperable. ^{[crypto_working]}

El modo ECB casi nunca es apropiado porque revela bloques idénticos dentro del texto cifrado como lo demuestra el ECB penguin, y el modo CTR a menudo es inapropiado porque no realiza autenticación y causa duplicados si el estado de entrada se repite. En muchos casos es mejor elegir un modo de algoritmo de cifrado de bloque diseñado para combinar secreto y autenticación, por ejemplo, Galois/Counter Mode (GCM) y EAX. Los proyectos PUEDEN permitir a los usuarios habilitar mecanismos rotos (por ejemplo, durante la configuración) cuando sea necesario para la compatibilidad, pero entonces los usuarios saben que lo están haciendo.

No broken algorithms used:

❌ MD4, MD5, DES, RC4, Dual_EC_DRBG - None used
❌ ECB mode - Not used
❌ Unauthenticated CTR mode - Not used

Only secure algorithms/modes:

✅ AES-256-GCM (authenticated encryption, as recommended)
✅ Argon2id (modern password hashing)
✅ crypto/rand (secure PRNG)

Cipher mode verification:
$ grep -E "NewGCM|NewCBC|NewECB|NewCTR" pkg/ cmd/ --include="*.go"

Only NewGCM found (4 occurrences in crypto.go and keystore.go)

Note on MD5 reference: One struct field (Checksums map[string]string // md5, sha256) exists in protocol/layers.go for optional integrity metadata from external
sources - this is not a security mechanism, just a data container. No MD5 hashing is performed by the project.

All encryption uses GCM mode which combines secrecy and authentication as recommended.

Cumplido

No cumplido

N/A

Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBERÍAN depender de algoritmos o modos criptográficos con debilidades serias conocidas (por ejemplo, el algoritmo hash criptográfico SHA-1 o el modo CBC en SSH). ^{[crypto_weaknesses]}

Las preocupaciones sobre el modo CBC en SSH se discuten en CERT: SSH CBC vulnerability.

No weak algorithms or modes used:

❌ SHA-1 - Not used anywhere
❌ CBC mode - Not used (only GCM)
❌ MD5 for security - Not used

Only strong algorithms:

✅ SHA-256 for hashing (HMAC-SHA256, integrity checks)
✅ AES-256-GCM for encryption
✅ Argon2id for password hashing

Verification:
$ grep -riE "sha1|SHA1|NewCBC" pkg/ cmd/ internal/ --include="*.go"

No results

$ grep -r "sha256" pkg/ --include="*.go" | wc -l

14 occurrences - all SHA-256

All cryptographic operations use modern, well-reviewed algorithms without known serious weaknesses.

Cumplido

No cumplido

N/A

Los mecanismos de seguridad dentro del software producido por el proyecto DEBERÍAN implementar confidencialidad directa perfecta para protocolos de acuerdo de claves de modo que una clave de sesión derivada de un conjunto de claves a largo plazo no pueda ser comprometida si una de las claves a largo plazo es comprometida en el futuro. ^[crypto_pfs]

TLS Communications: The project uses Go's standard crypto/tls library with default configuration. Go 1.17+ (project requires Go 1.25+) defaults to:

TLS 1.2 and TLS 1.3 with ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) cipher suites
All default cipher suites provide PFS via ephemeral key exchange
No custom CipherSuites configured that would disable PFS

Verification:
$ grep -r "CipherSuites" pkg/ cmd/ --include="*.go"

No custom cipher suite configuration found

Go's default TLS cipher suites (as of Go 1.25):

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ✅ PFS
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ✅ PFS
TLS_CHACHA20_POLY1305_SHA256 (TLS 1.3) ✅ PFS

Local encryption: Uses Argon2id key derivation (not a key exchange protocol, so PFS not applicable). Each encryption operation uses unique salt/nonce preventing key
reuse.

See: pkg/a2a/protocol.go, pkg/a2a/bridge.go

Cumplido

No cumplido

N/A

Si el software producido por el proyecto causa el almacenamiento de contraseñas para la autenticación de usuarios externos, las contraseñas DEBEN almacenarse como hashes iterados con un salt por usuario mediante el uso de un algoritmo de estiramiento de claves (iterado) (por ejemplo, Argon2id, Bcrypt, Scrypt o PBKDF2). Ver también OWASP Password Storage Cheat Sheet. ^{[crypto_password_storage]}

Este criterio se aplica solo cuando el software está forzando la autenticación de usuarios usando contraseñas para usuarios externos (también conocida como autenticación entrante), como aplicaciones web del lado del servidor. No se aplica en casos donde el software almacena contraseñas para autenticarse en otros sistemas (también conocida como autenticación saliente, por ejemplo, el software implementa un cliente para algún otro sistema), ya que al menos partes de ese software deben tener acceso a menudo a la contraseña sin hash.

Strigoi does not store passwords for external user authentication. The project is a security assessment CLI tool, not a multi-user web application.

Authentication model:

Agent authentication: Uses PSK (pre-shared key) and HMAC-SHA256 signatures, not passwords
API key storage: Uses Argon2id encryption for outbound authentication (storing keys to connect TO external services like OpenAI, Gemini) - this is explicitly
excluded by the criterion
Session encryption: Passphrase-derived keys using Argon2id for local file encryption

No inbound user authentication:

No user registration/login system
No user database
No password hashing for user accounts

If password storage were added in the future: The existing Argon2id infrastructure (pkg/strigoictl/crypto/keystore.go, pkg/session/crypto.go) would be used, which
already implements iterated hashing with per-user salt as required by OWASP guidelines.

Cumplido

No cumplido

N/A

Los mecanismos de seguridad dentro del software producido por el proyecto DEBEN generar todas las claves criptográficas y nonces utilizando un generador de números aleatorios criptográficamente seguro, y NO DEBEN hacerlo usando generadores que son criptográficamente inseguros. ^{[crypto_random]}

Un generador de números aleatorios criptográficamente seguro puede ser un generador de números aleatorios de hardware, o puede ser un generador de números pseudo-aleatorios criptográficamente seguro (CSPRNG) que usa un algoritmo como Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow o Fortuna. Ejemplos de llamadas a generadores de números aleatorios seguros incluyen java.security.SecureRandom de Java y window.crypto.getRandomValues de JavaScript. Ejemplos de llamadas a generadores de números aleatorios inseguros incluyen java.util.Random de Java y Math.random de JavaScript.

All cryptographic key and nonce generation uses Go's crypto/rand (CSPRNG):

Security-critical code uses crypto/rand exclusively:
// pkg/strigoictl/crypto/keystore.go
import "crypto/rand"
rand.Read(salt) // Salt generation
rand.Read(nonce) // Nonce generation

// pkg/session/crypto.go
io.ReadFull(rand.Reader, salt)
io.ReadFull(rand.Reader, nonce)

// pkg/a2a/auth.go
ed25519.GenerateKey(rand.Reader) // Key pair generation
rand.Read(psk) // PSK generation

// pkg/security/auth.go
rand.Read(pskBytes) // Authentication key generation

math/rand usage is non-security only:

pkg/logging/txcontext.go - Transaction IDs for log tracing
cmd/traffic-simulator/ - Test traffic generation
cmd/test.go - Test files

Go's crypto/rand uses the operating system's CSPRNG (getrandom() on Linux, CryptGenRandom on Windows) which meets NIST SP 800-90A requirements.

Entrega garantizada contra ataques de hombre en el medio (MITM)
Criterion [delivery_mitm]
Cumplido

No cumplido

?

El proyecto DEBE usar un mecanismo de entrega que contrarreste los ataques MITM. Usar https o ssh+scp es aceptable. ^{[delivery_mitm]}
Un mecanismo aún más fuerte es publicar el software con paquetes firmados digitalmente, ya que eso mitiga los ataques en el sistema de distribución, pero esto solo funciona si los usuarios pueden estar seguros de que las claves públicas para las firmas son correctas y si los usuarios realmente verificarán la firma.
Primary delivery via HTTPS:
- GitHub Releases: https://github.com/macawi-ai/strigoi/releases (TLS 1.3)
- Source clone: git clone https://github.com/macawi-ai/strigoi.git
- Container images: ghcr.io/macawi-ai/ (HTTPS registry)
Integrity verification provided:
- SHA256 checksums published with each release (checksums.txt)
- Git commit signatures available
- Container image digests via GHCR
The irony:
Strigoi is literally a security assessment platform that detects MITM attacks, credential exposure, and TLS misconfigurations in AI/LLM systems. The tool includes:
- TLS verification scanning (pkg/security/mcp_scanner.go)
- Credential leak detection (17+ patterns)
- Stream Tap for real-time STDIO security monitoring
We practice what we preach. Be curious if anyone reads this deep - if so, reach out to jamie.saker@macawi.ai and I'll even offer a free tool walkthru if interested :)
Criterion [delivery_unsigned]
Cumplido

No cumplido

?

Un hash criptográfico (por ejemplo, un sha1sum) NO DEBE recuperarse a través de http y usarse sin verificar una firma criptográfica. ^{[delivery_unsigned]}
Estos "hash" se pueden modificar en tránsito.
All checksums delivered via HTTPS:
- checksums.txt is published on GitHub Releases at https://github.com/macawi-ai/strigoi/releases
- GitHub enforces TLS 1.2+ for all connections
- No HTTP endpoints exist for checksum retrieval
Verification instructions in README use HTTPS:
wget https://github.com/macawi-ai/strigoi/releases/download/v1.0.0/checksums.txt
sha256sum -c checksums.txt

Additional integrity mechanisms:
- Git tags are used for releases (cryptographically linked to commit history)
- Container images use content-addressable digests via GHCR
- GitHub's infrastructure provides additional transport security guarantees
No retrieval of cryptographic hashes over unencrypted HTTP.
Vulnerabilidades públicamente conocidas corregidas

Criterion [vulnerabilities_fixed_60_days]
Cumplido

No cumplido

?

NO DEBE haber vulnerabilidades sin parchar de severidad media o superior que hayan sido conocidas públicamente durante más de 60 días. ^{[vulnerabilities_fixed_60_days]}
La vulnerabilidad debe ser parcheada y publicada por el proyecto mismo (los parches pueden desarrollarse en otro lugar). Una vulnerabilidad se convierte en conocida públicamente (para este propósito) una vez que tiene un CVE con información publicada públicamente sin muro de pago (reportada, por ejemplo, en la National Vulnerability Database) o cuando el proyecto ha sido informado y la información ha sido publicada al público (posiblemente por el proyecto). Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente. Nota: esto significa que los usuarios podrían quedar vulnerables a todos los atacantes en todo el mundo durante hasta 60 días. Este criterio es a menudo mucho más fácil de cumplir que lo que Google recomienda en Rebooting responsible disclosure, porque Google recomienda que el período de 60 días comience cuando se notifica al proyecto incluso si el informe no es público. También tenga en cuenta que este criterio de insignia, como otros criterios, se aplica al proyecto individual. Algunos proyectos son parte de organizaciones paraguas más grandes o proyectos más grandes, posiblemente en múltiples capas, y muchos proyectos alimentan sus resultados a otras organizaciones y proyectos como parte de una cadena de suministro potencialmente compleja. Un proyecto individual a menudo no puede controlar el resto, pero un proyecto individual puede trabajar para publicar un parche de vulnerabilidad de manera oportuna. Por lo tanto, nos enfocamos únicamente en el tiempo de respuesta del proyecto individual. Una vez que un parche está disponible del proyecto individual, otros pueden determinar cómo lidiar con el parche (por ejemplo, pueden actualizar a la versión más nueva o pueden aplicar solo el parche como una solución seleccionada).

Criterion [vulnerabilities_critical_fixed]
Cumplido

No cumplido

?

Los proyectos DEBERÍAN corregir todas las vulnerabilidades críticas rápidamente después de que se reporten. ^{[vulnerabilities_critical_fixed]}
Otros problemas de seguridad
Criterion [no_leaked_credentials]
Cumplido

No cumplido

?

Los repositorios públicos NO DEBEN filtrar una credencial privada válida (por ejemplo, una contraseña funcional o una clave privada) que esté destinada a limitar el acceso público. ^{[no_leaked_credentials]}
Un proyecto PUEDE filtrar credenciales de "muestra" para pruebas y bases de datos sin importancia, siempre que no estén destinadas a limitar el acceso público.
No valid private credentials in repository:

Scanned and verified clean:
- No AWS keys (AKIA...), GitHub tokens (ghp_), OpenAI keys (sk-...)
- No private keys (RSA, EC, SSH, OPENSSH)
- No hardcoded passwords for production systems
What exists (all safe):
- Detection patterns in modules/probe/ - regex patterns for finding credentials (the scanner's job)
- Key generation scripts - openssl rand -hex 16 generates new random keys at deploy time
- Local dev paths - .env contains only DATABASE_URL=./sqlite.db
Intentional test fixtures (permitted):
- examples/insecure-mcps/ contains intentionally vulnerable MCPs for testing
- Clearly documented as test targets, not production credentials
- Criterion explicitly allows "sample credentials for testing"
Preventive measures:
- .gitignore excludes: .env, .env.local, nkeys/*.txt
- Keystore encrypts API keys with Argon2id before storage
- gosec linter enabled to detect credential patterns

Análisis 8/8 ●

Análisis estático de código

Cumplido

No cumplido

N/A

Al menos una herramienta de análisis de código estático (más allá de las advertencias del compilador y los modos de lenguaje "seguros") DEBE aplicarse a cualquier lanzamiento de producción importante propuesto del software antes de su lanzamiento, si hay al menos una herramienta FLOSS que implemente este criterio en el lenguaje seleccionado. ^{[static_analysis]}

Una herramienta de análisis de código estático examina el código de software (como código fuente, código intermedio o ejecutable) sin ejecutarlo con entradas específicas. Para los propósitos de este criterio, las advertencias del compilador y los modos de lenguaje "seguros" no cuentan como herramientas de análisis de código estático (estos típicamente evitan el análisis profundo porque la velocidad es vital). Algunas herramientas de análisis estático se centran en detectar defectos genéricos, otras se centran en encontrar tipos específicos de defectos (como vulnerabilidades), y algunas hacen una combinación. Ejemplos de tales herramientas de análisis de código estático incluyen cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (incluyendo FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy, y HP Enterprise Fortify Static Code Analyzer. Se pueden encontrar listas más grandes de herramientas en lugares como la lista de Wikipedia de herramientas para análisis de código estático, información de OWASP sobre análisis de código estático, lista de NIST de analizadores de seguridad de código fuente, y lista de Wheeler de herramientas de análisis estático. Si no hay herramientas de análisis estático FLOSS disponibles para el(los) lenguaje(s) de implementación utilizado(s), puede seleccionar 'N/A'.

Multiple static analysis tools applied before every release:

golangci-lint (meta-linter with 11+ analyzers):

staticcheck - advanced static analysis
gosec - security vulnerability detection
govet - Go vet checks
ineffassign, unused, typecheck, etc.
Run via make lint and in CI

gosec (dedicated security scanner):

Standalone run via make security
Separate CI step using securego/gosec@master action
Checks for: SQL injection, command injection, hardcoded credentials, weak crypto, etc.

Release process requires static analysis:
release: clean lint security test build # All must pass
ci: deps lint security test-coverage test-race build

CI enforcement:

GitHub Actions runs golangci-lint and gosec on every push/PR
Builds blocked if static analysis fails
Results logged for review

See: .github/workflows/strigoi-v1rc1-ci.yml, Makefile, .golangci.yml

Cumplido

No cumplido

N/A

Se SUGIERE que al menos una de las herramientas de análisis estático utilizadas para el criterio static_analysis incluya reglas o enfoques para buscar vulnerabilidades comunes en el lenguaje o entorno analizado. ^{[static_analysis_common_vulnerabilities]}

Las herramientas de análisis estático que están diseñadas específicamente para buscar vulnerabilidades comunes tienen más probabilidades de encontrarlas. Dicho esto, usar cualquier herramienta estática típicamente ayudará a encontrar algunos problemas, por lo que estamos sugiriendo pero no requiriendo esto para el nivel de insignia 'passing'.

gosec is specifically designed to detect common vulnerabilities:

Vulnerability categories checked:

G101: Hardcoded credentials
G102: Bind to all interfaces
G103: Unsafe block usage
G104: Unhandled errors
G107: SSRF via variable URL
G108: Profiling endpoint exposure
G201-G203: SQL injection
G301-G307: File permission issues
G401-G404: Weak cryptography
G501-G505: Blocklisted imports
G601: Implicit memory aliasing

Mapped to common vulnerability standards:

OWASP Top 10 coverage
CWE (Common Weakness Enumeration) mappings
SANS Top 25 alignment

Integration:

.github/workflows/strigoi-v1rc1-ci.yml

uses: securego/gosec@master
with:
args: '-no-fail -fmt json -out gosec-results.json ./...'

Additionally, golangci-lint includes staticcheck which detects correctness issues that could lead to vulnerabilities.

See: https://github.com/securego/gosec

Cumplido

No cumplido

N/A

Todas las vulnerabilidades explotables de severidad media y superior descubiertas con el análisis de código estático DEBEN corregirse de manera oportuna después de que se confirmen. ^{[static_analysis_fixed]}

Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente. Tenga en cuenta que el criterio vulnerabilities_fixed_60_days requiere que todas esas vulnerabilidades se corrijan dentro de los 60 días de hacerse públicas.

Current status: All confirmed exploitable medium+ vulnerabilities addressed.

Current gosec findings (62 medium+) are documented exclusions or false positives:

Rule	Count	Status
G115 (integer overflow)	41	Excluded - Go type conversions for array/slice lengths
G304 (file path taint)	9	Intentional - security scanner must read user-specified files
G204 (subprocess variable)	4	Intentional - scanner executes commands by design
G302/G301 (permissions)	7	Non-exploitable - internal config directories
G404 (weak random)	1	Excluded - used in non-security logging context

Evidence of timely fixes (git history):
8586a44 fix: resolve all gosec, unused, and code quality issues
5797609 fix: resolve all 10 golangci-lint issues for clean CI
f533dd1 fix: resolve all remaining linting issues for Go 1.25 compliance

Exclusions documented in .golangci.yml:
gosec:
excludes: [G104, G115, G402, G404] # With justification comments

No CVEs: Zero CVE-assigned vulnerabilities in project history.

Cumplido

No cumplido

N/A

Se SUGIERE que el análisis de código fuente estático ocurra en cada commit o al menos diariamente. ^{[static_analysis_often]}

Análisis dinámico de código
Criterion [dynamic_analysis]
Cumplido

No cumplido

?

Se SUGIERE que al menos una herramienta de análisis dinámico se aplique a cualquier lanzamiento de producción importante propuesto del software antes de su lanzamiento. ^{[dynamic_analysis]}
Una herramienta de análisis dinámico examina el software ejecutándolo con entradas específicas. Por ejemplo, el proyecto PUEDE usar una herramienta de fuzzing (por ejemplo, American Fuzzy Lop) o un escáner de aplicaciones web (por ejemplo, OWASP ZAP o w3af). En algunos casos, el proyecto OSS-Fuzz puede estar dispuesto a aplicar pruebas de fuzzing a su proyecto. Para los propósitos de este criterio, la herramienta de análisis dinámico necesita variar las entradas de alguna manera para buscar varios tipos de problemas o ser una suite de pruebas automatizada con al menos 80% de cobertura de ramas. La página de Wikipedia sobre análisis dinámico y la página de OWASP sobre fuzzing identifican algunas herramientas de análisis dinámico. La(s) herramienta(s) de análisis PUEDEN estar enfocadas en buscar vulnerabilidades de seguridad, pero esto no es obligatorio.
Dynamic analysis tools applied before releases:
1. Go Race Detector (ThreadSanitizer-based):
- Instruments code at runtime to detect data races
- Run via go test -race in CI on every push/PR
- Applied to all packages: ./cmd/... ./pkg/... ./internal/...
CI workflow

run: go test -v -race -short -timeout=10m -coverprofile=coverage.out ./...
1. Automated Test Suite with Coverage:
- Unit and integration tests executed on every build
- Coverage tracked and reported via Codecov
- make test-coverage generates HTML coverage reports
- CI enforces minimum coverage threshold
1. Release gate (make ci):
  ci: deps lint security test-coverage test-race build
  All dynamic analysis must pass before builds succeed.
Evidence of effectiveness:
a25b207 Phase 3.1 Complete: ZERO Race Conditions Found! 🎉
a3ed353 Fix CrossSessionChecker deadlock with read-lock optimization
2ee9653 fix: Add comprehensive mutex protection to SessionManager

Race detector has caught and helped fix real concurrency bugs.
Criterion [dynamic_analysis_unsafe]
Cumplido

No cumplido

N/A

?

Se SUGIERE que si el software producido por el proyecto incluye software escrito usando un lenguaje no seguro en memoria (por ejemplo, C o C++), entonces se use rutinariamente al menos una herramienta dinámica (por ejemplo, un fuzzer o escáner de aplicaciones web) en combinación con un mecanismo para detectar problemas de seguridad de memoria como desbordamientos de búfer. Si el proyecto no produce software escrito en un lenguaje no seguro en memoria, elija "no aplicable" (N/A). ^{[dynamic_analysis_unsafe]}
Ejemplos de mecanismos para detectar problemas de seguridad de memoria incluyen Address Sanitizer (ASAN) (disponible en GCC y LLVM), Memory Sanitizer, y valgrind. Otras herramientas potencialmente utilizadas incluyen thread sanitizer y undefined behavior sanitizer. También funcionarían aserciones generalizadas.
Primary language: Go
- Garbage collected
- Bounds-checked array/slice access
- No pointer arithmetic
- No manual memory allocation/deallocation
- No buffer overflow vulnerabilities by design
Supporting languages (also memory-safe):
- Python (A2MCP agents)
- Shell scripts (deployment/build)
- YAML/JSON (configuration)
No C/C++ code in the project.

Go's memory safety is why we chose it - eliminates entire vulnerability classes (CWE-119, CWE-120, CWE-122, CWE-125, CWE-787) that plague C/C++ security tools.

Note: Go's race detector (used in CI) provides similar runtime instrumentation benefits for concurrency safety.
Criterion [dynamic_analysis_enable_assertions]
Cumplido

No cumplido

?

Se SUGIERE que el proyecto use una configuración para al menos algún análisis dinámico (como pruebas o fuzzing) que habilite muchas aserciones. En muchos casos estas aserciones no deberían estar habilitadas en compilaciones de producción. ^{[dynamic_analysis_enable_assertions]}
Este criterio no sugiere habilitar aserciones durante la producción; eso depende completamente del proyecto y sus usuarios decidir. El enfoque de este criterio es en cambio mejorar la detección de fallas durante el análisis dinámico antes del despliegue. Habilitar aserciones en el uso de producción es completamente diferente de habilitar aserciones durante el análisis dinámico (como las pruebas). En algunos casos, habilitar aserciones en el uso de producción es extremadamente imprudente (especialmente en componentes de alta integridad). Hay muchos argumentos contra habilitar aserciones en producción, por ejemplo, las bibliotecas no deberían bloquear a los llamadores, su presencia puede causar rechazo por las tiendas de aplicaciones, y/o activar una aserción en producción puede exponer datos privados como claves privadas. Tenga en cuenta que en muchas distribuciones de Linux NDEBUG no está definido, por lo que assert() de C/C++ estará habilitado por defecto para producción en esos entornos. Puede ser importante usar un mecanismo de aserción diferente o definir NDEBUG para producción en esos entornos.
Race detector enabled during dynamic analysis (testing), disabled in production:

Makefile - test mode with assertions

test-race:
go test -short -race ./cmd/strigoi ./pkg/... ./internal/...

CI runs with race detector

run: go test -v -race -short -timeout=10m ./...

Go's race detector acts as runtime assertions:
- Instruments memory access patterns at runtime
- Detects data races, deadlocks, and synchronization bugs
- Panics (asserts) on any detected race condition
- Only enabled via -race flag during testing
- Not included in production binaries
Test assertions used throughout:
- t.Fatal(err) - Stops test on invariant violation
- t.Error() - Records assertion failure
- t.Errorf() - Records formatted assertion failure
- Bounds checking panics in test scenarios
Production builds:
build:
go build -o strigoi ./cmd/strigoi # No -race flag

This follows the criterion's recommendation: assertions enabled during analysis, disabled in production.
Criterion [dynamic_analysis_fixed]
Cumplido

No cumplido

N/A

?

Todas las vulnerabilidades explotables de severidad media y superior descubiertas con análisis de código dinámico DEBEN ser corregidas de manera oportuna después de que sean confirmadas. ^{[dynamic_analysis_fixed]}
Si no está ejecutando análisis de código dinámico y por lo tanto no ha encontrado ninguna vulnerabilidad de esta manera, elija "no aplicable" (N/A). Una vulnerabilidad se considera de severidad media o superior si su puntuación cualitativa base del Sistema de Puntuación de Vulnerabilidades Comunes (CVSS) es media o superior. En las versiones 2.0 a 3.1 de CVSS, esto es equivalente a una puntuación CVSS de 4.0 o superior. Los proyectos pueden usar la puntuación CVSS como se publica en una base de datos de vulnerabilidades ampliamente utilizada (como la National Vulnerability Database) usando la versión más reciente de CVSS reportada en esa base de datos. Los proyectos pueden en cambio calcular la severidad ellos mismos usando la última versión de CVSS en el momento de la divulgación de la vulnerabilidad, si las entradas de cálculo se revelan públicamente una vez que la vulnerabilidad es conocida públicamente.
Dynamic analysis IS performed, and all discovered issues have been fixed:

Race detector findings - all fixed:
a3ed353 Fix CrossSessionChecker deadlock with read-lock optimization
2ee9653 fix: Add comprehensive mutex protection to SessionManager
99183df fix(concurrency): Eliminate race conditions in coordinator and load tester
a25b207 Phase 3.1 Complete: ZERO Race Conditions Found! 🎉

Current status:
- Race detector runs on every CI build
- Zero race conditions currently detected
- All historically detected races were fixed within days of discovery
No CVE-assigned vulnerabilities discovered through dynamic analysis.

If N/A is selected, context:
While dynamic analysis (race detector, test suite) is actively used, no exploitable security vulnerabilities with CVSS 4.0+ have been discovered through these
methods. The race conditions found were correctness/reliability issues, not security vulnerabilities with CVSS scores. Therefore N/A is technically accurate - no
medium+ security vulnerabilities to fix.

Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a Macawi AI y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Macawi AI.
Entrada creada el 2026-01-12 01:24:54 UTC, última actualización el 2026-01-12 02:24:30 UTC. Última obtención de la insignia de nivel básico el 2026-01-12 02:24:30 UTC.

Strigoi

Fundamentos 13/13 ●

General

Contenido básico del sitio web del proyecto

Licencia FLOSS

Documentación

Otro

Control de cambios 9/9 ●

Repositorio público para el control de versiones de código fuente

Numeración única de versión

Notas de lanzamiento

Informes 8/8 ●

Proceso de reporte de errores

Proceso de informe de vulnerabilidad

Calidad 13/13 ●

Sistema de construcción funcional

Suite de pruebas automatizadas

Pruebas de nueva funcionalidad

Banderas de advertencia

Seguridad 16/16 ●

Conocimiento de desarrollo seguro

Use buenas prácticas criptográficas

Only NewGCM found (4 occurrences in crypto.go and keystore.go)

No results

14 occurrences - all SHA-256

No custom cipher suite configuration found

Entrega garantizada contra ataques de hombre en el medio (MITM)

Vulnerabilidades públicamente conocidas corregidas

Otros problemas de seguridad

Análisis 8/8 ●

Análisis estático de código

.github/workflows/strigoi-v1rc1-ci.yml

Análisis dinámico de código

CI workflow

Makefile - test mode with assertions

CI runs with race detector