Fundamentos 13/13 ●

Geral

Qual é o nome legível do projeto?
Observe que outros projetos podem usar o mesmo nome.

Qual é uma breve descrição do projeto?

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

Qual é a URL do projeto (como um todo)?
https://github.com/macawi-ai/Strigoi

Qual é a URL do repositório de controle de versão (pode ser a mesma URL do projeto)?
https://github.com/macawi-ai/Strigoi

Sob qual(is) licença(s) o projeto é liberado?
Use o formato de expressão de licença SPDX; exemplos incluem "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" e "(BSD-2-Clause OR Ruby)". Não inclua aspas simples ou aspas duplas.

Qual(is) linguagem(ns) de programação são usadas para implementar o projeto?
Se houver mais de uma linguagem, liste-as como valores separados por vírgula (espaços opcionais) e ordene-as da mais usada para a menos usada. Se houver uma longa lista, liste pelo menos as três primeiras mais comuns. Se não houver linguagem (por exemplo, este é um projeto apenas de documentação ou apenas de teste), use o caractere único "-". Use uma capitalização convencional para cada linguagem, por exemplo, "JavaScript".

Qual é o nome Common Platform Enumeration (CPE) do projeto (se houver um)?
O Common Platform Enumeration (CPE) é um esquema de nomenclatura estruturado para sistemas de tecnologia da informação, software e pacotes. Ele é usado em vários sistemas e bancos de dados ao relatar vulnerabilidades.

Outros comentários gerais sobre o projeto:
Conteúdo básico do site do projeto
Criterion [description_good]
Atendido

Não atendido

?

O site do projeto DEVE descrever sucintamente o que o software faz (qual problema ele resolve?). ^{[description_good]}
Isso DEVE estar em linguagem que usuários potenciais possam entender (por exemplo, ele usa o mínimo de jargão).
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]
Atendido

Não atendido

?

O site do projeto DEVE fornecer informações sobre como: obter, fornecer feedback (como relatórios de bugs ou melhorias) e contribuir com o 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]
Atendido

Não atendido

?

As informações sobre como contribuir DEVEM explicar o processo de contribuição (por exemplo, pull requests são usados?) (URL obrigatória) ^{[contribution]}
Presumimos que projetos no GitHub usam issues e pull requests, a menos que indicado de outra forma. Essa informação pode ser breve, por exemplo, declarando que o projeto usa pull requests, um rastreador de issues ou postagens em uma lista de discussão (qual?)

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]
Atendido

Não atendido

?

As informações sobre como contribuir DEVERIAM incluir os requisitos para contribuições aceitáveis (por exemplo, uma referência a qualquer padrão de codificação exigido). (URL obrigatória) ^{[contribution_requirements]}

https://github.com/macawi-ai/strigoi/blob/main/CONTRIBUTING.md
Licença FLOSS
Criterion [floss_license]
Atendido

Não atendido

?
O software produzido pelo projeto DEVE ser lançado como FLOSS. ^{[floss_license]}
FLOSS é software lançado de uma forma que atende à Definição de Código Aberto ou à Definição de Software Livre. Exemplos de tais licenças incluem CC0, MIT, BSD 2-clause, BSD 3-clause revisada, Apache 2.0, Lesser GNU General Public License (LGPL) e a GNU General Public License (GPL). Para nossos propósitos, isso significa que a licença DEVE ser:
O software PODE também ser licenciado de outras formas (por exemplo, "GPLv2 ou proprietário" é aceitável).
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]
Atendido

Não atendido

?

É SUGERIDO que qualquer licença(s) exigida para o software produzido pelo projeto seja aprovada pela Open Source Initiative (OSI). ^{[floss_license_osi]}
A OSI usa um processo de aprovação rigoroso para determinar quais licenças são 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]
Atendido

Não atendido

?

O projeto DEVE publicar a(s) licença(s) de seus resultados em um local padrão em seu repositório de código-fonte. (URL obrigatória) ^{[license_location]}
Uma convenção é publicar a licença como um arquivo de nível superior chamado LICENSE ou COPYING, que PODE ser seguido por uma extensão como ".txt" ou ".md". Uma convenção alternativa é ter um diretório chamado LICENSES contendo arquivo(s) de licença; esses arquivos são tipicamente nomeados como seu identificador de licença SPDX seguido por uma extensão de arquivo apropriada, conforme descrito na Especificação REUSE. Observe que este critério é apenas um requisito no repositório de código-fonte. Você NÃO precisa incluir o arquivo de licença ao gerar algo a partir do código-fonte (como um executável, pacote ou contêiner). Por exemplo, ao gerar um pacote R para a Comprehensive R Archive Network (CRAN), siga a prática padrão do CRAN: se a licença for uma licença padrão, use a especificação de licença curta padrão (para evitar instalar outra cópia do texto) e liste o arquivo LICENSE em um arquivo de exclusão como .Rbuildignore. Da mesma forma, ao criar um pacote Debian, você pode colocar um link no arquivo de copyright para o texto da licença em /usr/share/common-licenses e excluir o arquivo de licença do pacote criado (por exemplo, deletando o arquivo após chamar dh_auto_install). Nós encorajamos a inclusão de informações de licença legíveis por máquina em formatos gerados, quando praticável.

Non-trivial license location file in repository: https://github.com/macawi-ai/Strigoi/blob/main/LICENSE.
Documentação

Criterion [documentation_basics]
Atendido

Não atendido

N/A

?

O projeto DEVE fornecer documentação básica para o software produzido pelo projeto. ^{[documentation_basics]}
Esta documentação deve estar em alguma mídia (como texto ou vídeo) que inclua: como instalá-lo, como iniciá-lo, como usá-lo (possivelmente com um tutorial usando exemplos) e como usá-lo de forma segura (por exemplo, o que fazer e o que não fazer) se esse for um tópico apropriado para o software. A documentação de segurança não precisa ser longa. O projeto PODE usar hiperlinks para material não pertencente ao projeto como documentação. Se o projeto não produz software, escolha "não aplicável" (N/A).

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

Não atendido

N/A

?

O projeto DEVE fornecer documentação de referência que descreva a interface externa (tanto entrada quanto saída) do software produzido pelo projeto. ^{[documentation_interface]}
A documentação de uma interface externa explica a um usuário final ou desenvolvedor como usá-la. Isso incluiria sua interface de programação de aplicativos (API) se o software tiver uma. Se for uma biblioteca, documente as principais classes/tipos e métodos/funções que podem ser chamados. Se for uma aplicação web, defina sua interface de URL (geralmente sua interface REST). Se for uma interface de linha de comando, documente os parâmetros e opções que suporta. Em muitos casos, é melhor que a maior parte desta documentação seja gerada automaticamente, para que essa documentação permaneça sincronizada com o software conforme ele muda, mas isso não é obrigatório. O projeto PODE usar hiperlinks para material não pertencente ao projeto como documentação. A documentação PODE ser gerada automaticamente (quando praticável, esta é frequentemente a melhor forma de fazê-lo). A documentação de uma interface REST pode ser gerada usando Swagger/OpenAPI. A documentação da interface de código PODE ser gerada usando ferramentas como JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) e Doxygen (muitos). Simplesmente ter comentários no código de implementação não é suficiente para satisfazer este critério; precisa haver uma maneira fácil de ver a informação sem ler todo o código-fonte. Se o projeto não produz software, escolha "não aplicável" (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
Outro

Criterion [sites_https]
Atendido

Não atendido

?

Os sites do projeto (site, repositório e URLs de download) DEVEM suportar HTTPS usando TLS. ^{[sites_https]}
Isso requer que a URL da página inicial do projeto e a URL do repositório de controle de versão comecem com "https:", não "http:". Você pode obter certificados gratuitos do Let's Encrypt. Os projetos PODEM implementar este critério usando (por exemplo) GitHub pages, GitLab pages ou SourceForge project pages. Se você suportar HTTP, recomendamos que você redirecione o tráfego HTTP para HTTPS.

Given only https: URLs.

Criterion [discussion]
Atendido

Não atendido

?

O projeto DEVE ter um ou mais mecanismos para discussão (incluindo mudanças propostas e questões) que sejam pesquisáveis, permitam que mensagens e tópicos sejam endereçados por URL, permitam que novas pessoas participem de algumas das discussões e não exijam instalação no lado do cliente de software proprietário. ^[discussion]
Exemplos de mecanismos aceitáveis incluem lista(s) de discussão arquivadas, discussões de questões e pull requests do GitHub, Bugzilla, Mantis e Trac. Mecanismos de discussão assíncronos (como IRC) são aceitáveis se atenderem a esses critérios; certifique-se de que haja um mecanismo de arquivamento endereçável por URL. JavaScript proprietário, embora desencorajado, é permitido.

GitHub supports discussions on issues and pull requests.

Criterion [english]
Atendido

Não atendido

?

O projeto DEVERIA fornecer documentação em inglês e ser capaz de aceitar relatórios de bugs e comentários sobre código em inglês. ^[english]
O inglês é atualmente a língua franca da tecnologia de computadores; o suporte ao inglês aumenta o número de diferentes desenvolvedores e revisores em potencial em todo o mundo. Um projeto pode atender a este critério mesmo que o idioma principal de seus desenvolvedores principais não seja o inglês.

Criterion [maintained]
Atendido

Não atendido

?

O projeto DEVE ser mantido. ^[maintained]
No mínimo, o projeto deve tentar responder a relatórios significativos de problemas e vulnerabilidades. Um projeto que está buscando ativamente um badge provavelmente é mantido. Todos os projetos e pessoas têm recursos limitados, e projetos típicos devem rejeitar algumas mudanças propostas, portanto, recursos limitados e rejeições de propostas não indicam por si só um projeto não mantido.

Quando um projeto souber que não será mais mantido, ele deve definir este critério como "Não atendido" e usar o(s) mecanismo(s) apropriado(s) para indicar a outros que não está sendo mantido. Por exemplo, use "DEPRECATED" como o primeiro cabeçalho de seu README, adicione "DEPRECATED" perto do início de sua página inicial, adicione "DEPRECATED" ao início da descrição do projeto do repositório de código, adicione um badge de sem intenção de manutenção em seu README e/ou página inicial, marque-o como descontinuado em quaisquer repositórios de pacotes (por exemplo, npm deprecate), e/ou use o sistema de marcação do repositório de código para arquivá-lo (por exemplo, a configuração "archive" do GitHub, a marcação "archived" do GitLab, o status "readonly" do Gerrit ou o status de projeto "abandoned" do SourceForge). Discussão adicional pode ser encontrada aqui.

Regular maintenance evidenced on github

Segurança 16/16 ●

Conhecimento de desenvolvimento seguro
Criterion [know_secure_design]
Atendido

Não atendido

?
O projeto DEVE ter pelo menos um desenvolvedor principal que saiba como projetar software seguro. (Veja 'details' para os requisitos exatos.) ^{[know_secure_design]}
Isto requer entender os seguintes princípios de projeto, incluindo os 8 princípios de Saltzer and Schroeder:
- economia de mecanismo (mantenha o projeto tão simples e pequeno quanto prático, por exemplo, adotando simplificações amplas)
- padrões à prova de falhas (decisões de acesso devem negar por padrão, e a instalação dos projetos deve ser segura por padrão)
- mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável)
- projeto aberto (mecanismos de segurança não devem depender da ignorância do invasor sobre seu projeto, mas sim em informações mais facilmente protegidas e alteradas como chaves e senhas)
- separação de privilégios (idealmente, acesso a objetos importantes deve depender de mais de uma condição, de forma que derrotar um sistema de proteção não permita acesso completo. Por exemplo, autenticação multifator, como exigir tanto uma senha quanto um token de hardware, é mais forte que autenticação de fator único)
- menor privilégio (processos devem operar com o menor privilégio necessário)
- menor mecanismo comum (o projeto deve minimizar os mecanismos comuns a mais de um usuário e dos quais todos os usuários dependem, por exemplo, diretórios para arquivos temporários)
- aceitabilidade psicológica (a interface humana deve ser projetada para facilidade de uso - projetar para "menor surpresa" pode ajudar)
- superfície de ataque limitada (a superfície de ataque - o conjunto dos diferentes pontos onde um invasor pode tentar entrar ou extrair dados - deve ser limitada)
- validação de entrada com listas de permissões (entradas devem tipicamente ser verificadas para determinar se são válidas antes de serem aceitas; esta validação deve usar listas de permissões (que aceitam apenas valores conhecidamente bons), não listas de negação (que tentam listar valores conhecidamente ruins)).
Um "desenvolvedor principal" em um projeto é qualquer pessoa que esteja familiarizada com a base de código do projeto, esteja confortável fazendo mudanças nela, e seja reconhecida como tal pela maioria dos outros participantes no projeto. Um desenvolvedor principal tipicamente faria várias contribuições ao longo do último ano (via código, documentação ou respondendo perguntas). Desenvolvedores seriam tipicamente considerados desenvolvedores principais se iniciaram o projeto (e não deixaram o projeto há mais de três anos), têm a opção de receber informações em um canal privado de relato de vulnerabilidades (se houver um), podem aceitar commits em nome do projeto, ou realizar lançamentos finais do software do projeto. Se há apenas um desenvolvedor, esse indivíduo é o desenvolvedor principal. Muitos livros e cursos estão disponíveis para ajudá-lo a entender como desenvolver software mais seguro e discutir projeto. Por exemplo, o curso Secure Software Development Fundamentals é um conjunto gratuito de três cursos que explicam como desenvolver software mais seguro (é gratuito se você auditar; por uma taxa extra você pode obter um certificado para provar que aprendeu o 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]
Atendido

Não atendido

?

Pelo menos um dos desenvolvedores principais do projeto DEVE conhecer tipos comuns de erros que levam a vulnerabilidades neste tipo de software, bem como pelo menos um método para combater ou mitigar cada um deles. ^{[know_common_errors]}
Exemplos (dependendo do tipo de software) incluem injeção SQL, injeção de SO, estouro clássico de buffer, cross-site scripting, autenticação ausente e autorização ausente. Veja o CWE/SANS top 25 ou OWASP Top 10 para listas comumente usadas. Muitos livros e cursos estão disponíveis para ajudá-lo a entender como desenvolver software mais seguro e discutir erros comuns de implementação que levam a vulnerabilidades. Por exemplo, o curso Secure Software Development Fundamentals é um conjunto gratuito de três cursos que explicam como desenvolver software mais seguro (é gratuito se você auditar; por uma taxa extra você pode obter um certificado para provar que aprendeu o material).

Usar práticas criptográficas boas e básicas

Observe que alguns softwares não precisam usar mecanismos criptográficos. Se o seu projeto produzir software que (1) inclui, ativa ou habilita funcionalidade de criptografia, e (2) pode ser liberado dos Estados Unidos (EUA) para fora dos EUA ou para um não cidadão dos EUA, você pode ser legalmente obrigado a tomar algumas etapas extras. Normalmente isso envolve apenas o envio de um e-mail. Para mais informações, consulte a seção de criptografia de Understanding Open Source Technology & US Export Controls.

Atendido

Não atendido

N/A

O software produzido pelo projeto DEVE usar, por padrão, apenas protocolos criptográficos e algoritmos que são publicamente publicados e revisados por especialistas (se protocolos criptográficos e algoritmos forem usados). ^{[crypto_published]}

Esses critérios criptográficos nem sempre se aplicam porque alguns softwares não têm necessidade de usar diretamente capacidades criptográficas.

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

Atendido

Não atendido

N/A

Se o software produzido pelo projeto for uma aplicação ou biblioteca, e seu propósito principal não for implementar criptografia, então ele DEVERIA apenas chamar software especificamente projetado para implementar funções criptográficas; ele NÃO DEVERIA reimplementar o seu próprio. ^{[crypto_call]}

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

Atendido

Não atendido

N/A

Toda funcionalidade no software produzido pelo projeto que depende de criptografia DEVE ser implementável usando FLOSS. ^{[crypto_floss]}

Veja o Open Standards Requirement for Software by the Open Source Initiative.

Atendido

Não atendido

N/A

Os mecanismos de segurança dentro do software produzido pelo projeto DEVEM usar comprimentos de chave padrão que pelo menos atendam aos requisitos mínimos do NIST até o ano de 2030 (conforme declarado em 2012). DEVE ser possível configurar o software para que comprimentos de chave menores sejam completamente desabilitados. ^{[crypto_keylength]}

Esses comprimentos mínimos de bits são: chave simétrica 112, módulo de fatoração 2048, chave de logaritmo discreto 224, grupo logarítmico discreto 2048, curva elíptica 224 e hash 224 (hashing de senha não é coberto por este comprimento de bits, mais informações sobre hashing de senha podem ser encontradas no critério crypto_password_storage). Veja https://www.keylength.com para uma comparação de recomendações de comprimento de chave de várias organizações. O software PODE permitir comprimentos de chave menores em algumas configurações (idealmente não permitiria, já que isso permite ataques de downgrade, mas comprimentos de chave mais curtos são às vezes necessários para interoperabilidade).

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

Atendido

Não atendido

N/A

Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVEM depender de algoritmos criptográficos quebrados (por exemplo, MD4, MD5, DES único, RC4, Dual_EC_DRBG), ou usar modos de cifra que são inadequados ao contexto, a menos que sejam necessários para implementar um protocolo interoperável (onde o protocolo implementado é a versão mais recente desse padrão amplamente suportado pelo ecossistema de rede, esse ecossistema requer o uso de tal algoritmo ou modo, e esse ecossistema não oferece nenhuma alternativa mais segura). A documentação DEVE descrever quaisquer riscos de segurança relevantes e quaisquer mitigações conhecidas se esses algoritmos ou modos quebrados forem necessários para um protocolo interoperável. ^{[crypto_working]}

O modo ECB é quase nunca apropriado porque revela blocos idênticos dentro do texto cifrado conforme demonstrado pelo pinguim ECB, e o modo CTR é frequentemente inadequado porque não realiza autenticação e causa duplicatas se o estado de entrada for repetido. Em muitos casos é melhor escolher um modo de algoritmo de cifra de bloco projetado para combinar sigilo e autenticação, por exemplo, Galois/Counter Mode (GCM) e EAX. Projetos PODEM permitir que usuários habilitem mecanismos quebrados (por exemplo, durante a configuração) onde necessário para compatibilidade, mas então os usuários sabem que estão fazendo isso.

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.

Atendido

Não atendido

N/A

Os mecanismos de segurança padrão dentro do software produzido pelo projeto NÃO DEVERIAM depender de algoritmos criptográficos ou modos com fraquezas sérias conhecidas (por exemplo, o algoritmo de hash criptográfico SHA-1 ou o modo CBC em SSH). ^{[crypto_weaknesses]}

Preocupações sobre o modo CBC em SSH são discutidas em 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.

Atendido

Não atendido

N/A

Os mecanismos de segurança dentro do software produzido pelo projeto DEVERIAM implementar sigilo perfeito para frente para protocolos de acordo de chave, de modo que uma chave de sessão derivada de um conjunto de chaves de longo prazo não possa ser comprometida se uma das chaves de longo prazo for comprometida no 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

Atendido

Não atendido

N/A

Se o software produzido pelo projeto causar o armazenamento de senhas para autenticação de usuários externos, as senhas DEVEM ser armazenadas como hashes iterados com um salt por usuário usando um algoritmo de extensão de chave (iterado) (por exemplo, Argon2id, Bcrypt, Scrypt ou PBKDF2). Veja também OWASP Password Storage Cheat Sheet. ^{[crypto_password_storage]}

Este critério aplica-se apenas quando o software está aplicando autenticação de usuários usando senhas para usuários externos (também conhecida como autenticação de entrada), como aplicações web do lado do servidor. Não se aplica em casos onde o software armazena senhas para autenticar em outros sistemas (também conhecida como autenticação de saída, por exemplo, o software implementa um cliente para algum outro sistema), já que pelo menos partes desse software devem ter acesso frequentemente à senha não hasheada.

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.

Atendido

Não atendido

N/A

Os mecanismos de segurança dentro do software produzido pelo projeto DEVEM gerar todas as chaves criptográficas e nonces usando um gerador de números aleatórios criptograficamente seguro, e NÃO DEVEM fazê-lo usando geradores que são criptograficamente inseguros. ^{[crypto_random]}

Um gerador de números aleatórios criptograficamente seguro pode ser um gerador de números aleatórios de hardware, ou pode ser um gerador de números pseudo-aleatórios criptograficamente seguro (CSPRNG) usando um algoritmo como Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow ou Fortuna. Exemplos de chamadas para geradores de números aleatórios seguros incluem o java.security.SecureRandom do Java e o window.crypto.getRandomValues do JavaScript. Exemplos de chamadas para geradores de números aleatórios inseguros incluem o java.util.Random do Java e o Math.random do 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 protegida contra ataques man-in-the-middle (MITM)
Criterion [delivery_mitm]
Atendido

Não atendido

?

O projeto DEVE usar um mecanismo de entrega que contraponha ataques MITM. Usar https ou ssh+scp é aceitável. ^{[delivery_mitm]}
Um mecanismo ainda mais forte é liberar o software com pacotes assinados digitalmente, já que isso mitiga ataques no sistema de distribuição, mas isso só funciona se os usuários puderem estar confiantes de que as chaves públicas para assinaturas estão corretas e se os usuários realmente verificarão a assinatura.
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]
Atendido

Não atendido

?

Um hash criptográfico (por exemplo, um sha1sum) NÃO DEVE ser recuperado por http e usado sem verificar uma assinatura criptográfica. ^{[delivery_unsigned]}
Esses hashes podem ser modificados durante o 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 conhecidas publicamente corrigidas

Criterion [vulnerabilities_fixed_60_days]
Atendido

Não atendido

?

NÃO DEVE haver vulnerabilidades não corrigidas de severidade média ou superior que sejam publicamente conhecidas por mais de 60 dias. ^{[vulnerabilities_fixed_60_days]}
A vulnerabilidade deve ser corrigida e lançada pelo próprio projeto (as correções podem ser desenvolvidas em outro lugar). Uma vulnerabilidade se torna publicamente conhecida (para este propósito) uma vez que tem um CVE com informações lançadas publicamente sem paywall (relatadas, por exemplo, no National Vulnerability Database) ou quando o projeto foi informado e a informação foi liberada ao público (possivelmente pelo projeto). Uma vulnerabilidade é considerada de severidade média ou superior se sua pontuação qualitativa base do Common Vulnerability Scoring System (CVSS) for média ou superior. Nas versões 2.0 a 3.1 do CVSS, isso é equivalente a uma pontuação CVSS de 4.0 ou superior. Os projetos podem usar a pontuação CVSS conforme publicada em um banco de dados de vulnerabilidades amplamente usado (como o National Vulnerability Database) usando a versão mais recente do CVSS relatada nesse banco de dados. Os projetos podem, em vez disso, calcular a severidade eles mesmos usando a versão mais recente do CVSS no momento da divulgação da vulnerabilidade, se as entradas de cálculo forem publicamente reveladas uma vez que a vulnerabilidade seja publicamente conhecida. Nota: isso significa que os usuários podem ficar vulneráveis a todos os atacantes em todo o mundo por até 60 dias. Este critério é frequentemente muito mais fácil de atender do que o que o Google recomenda em Rebooting responsible disclosure, porque o Google recomenda que o período de 60 dias comece quando o projeto é notificado mesmo se o relatório não for público. Observe também que este critério de selo, como outros critérios, aplica-se ao projeto individual. Alguns projetos fazem parte de organizações guarda-chuva maiores ou projetos maiores, possivelmente em múltiplas camadas, e muitos projetos alimentam seus resultados para outras organizações e projetos como parte de uma cadeia de suprimentos potencialmente complexa. Um projeto individual geralmente não pode controlar o resto, mas um projeto individual pode trabalhar para lançar uma correção de vulnerabilidade de forma oportuna. Portanto, focamos apenas no tempo de resposta do projeto individual. Uma vez que uma correção esteja disponível do projeto individual, outros podem determinar como lidar com a correção (por exemplo, eles podem atualizar para a versão mais recente ou podem aplicar apenas a correção como uma solução cherry-picked).

Criterion [vulnerabilities_critical_fixed]
Atendido

Não atendido

?

Os projetos DEVERIAM corrigir todas as vulnerabilidades críticas rapidamente após serem relatadas. ^{[vulnerabilities_critical_fixed]}
Outras questões de segurança
Criterion [no_leaked_credentials]
Atendido

Não atendido

?

Os repositórios públicos NÃO DEVEM vazar uma credencial privada válida (por exemplo, uma senha funcionando ou chave privada) que se destina a limitar o acesso público. ^{[no_leaked_credentials]}
Um projeto PODE vazar credenciais "de amostra" para testes e bancos de dados sem importância, desde que não sejam destinadas a limitar o acesso 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álise 8/8 ●

Análise estática de código

Atendido

Não atendido

N/A

Pelo menos uma ferramenta de análise estática de código (além de avisos do compilador e modos de linguagem "seguros") DEVE ser aplicada a qualquer grande lançamento de produção proposto do software antes de seu lançamento, se houver pelo menos uma ferramenta FLOSS que implemente este critério na linguagem selecionada. ^{[static_analysis]}

Uma ferramenta de análise estática de código examina o código de software (como código-fonte, código intermediário ou executável) sem executá-lo com entradas específicas. Para fins deste critério, avisos do compilador e modos de linguagem "seguros" não contam como ferramentas de análise estática de código (estes tipicamente evitam análise profunda porque a velocidade é vital). Algumas ferramentas de análise estática focam na detecção de defeitos genéricos, outras focam em encontrar tipos específicos de defeitos (como vulnerabilidades), e algumas fazem uma combinação. Exemplos de tais ferramentas de análise estática de código incluem cppcheck (C, C++), clang static analyzer (C, C++), SpotBugs (Java), FindBugs (Java) (incluindo FindSecurityBugs), PMD (Java), Brakeman (Ruby on Rails), lintr (R), goodpractice (R), Coverity Quality Analyzer, SonarQube, Codacy e HP Enterprise Fortify Static Code Analyzer. Listas maiores de ferramentas podem ser encontradas em lugares como a lista da Wikipedia de ferramentas para análise estática de código, informações da OWASP sobre análise estática de código, lista do NIST de analisadores de segurança de código-fonte e lista de ferramentas de análise estática de Wheeler. Se não houver ferramentas de análise estática FLOSS disponíveis para a(s) linguagem(ns) de implementação usada(s), você pode selecionar '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

Atendido

Não atendido

N/A

É SUGERIDO que pelo menos uma das ferramentas de análise estática usadas para o critério static_analysis inclua regras ou abordagens para procurar vulnerabilidades comuns na linguagem ou ambiente analisado. ^{[static_analysis_common_vulnerabilities]}

Ferramentas de análise estática que são especificamente projetadas para procurar vulnerabilidades comuns são mais propensas a encontrá-las. Dito isso, usar quaisquer ferramentas estáticas normalmente ajudará a encontrar alguns problemas, então estamos sugerindo mas não exigindo isso para o nível de selo '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

Atendido

Não atendido

N/A

Todas as vulnerabilidades exploráveis de severidade média e superior descobertas com análise estática de código DEVEM ser corrigidas de forma oportuna após serem confirmadas. ^{[static_analysis_fixed]}

Uma vulnerabilidade é considerada de severidade média ou superior se sua pontuação qualitativa base do Common Vulnerability Scoring System (CVSS) for média ou superior. Nas versões 2.0 a 3.1 do CVSS, isso é equivalente a uma pontuação CVSS de 4.0 ou superior. Os projetos podem usar a pontuação CVSS conforme publicada em um banco de dados de vulnerabilidades amplamente usado (como o National Vulnerability Database) usando a versão mais recente do CVSS relatada nesse banco de dados. Os projetos podem, em vez disso, calcular a severidade eles mesmos usando a versão mais recente do CVSS no momento da divulgação da vulnerabilidade, se as entradas de cálculo forem publicamente reveladas uma vez que a vulnerabilidade seja publicamente conhecida. Observe que o critério vulnerabilities_fixed_60_days exige que todas essas vulnerabilidades sejam corrigidas dentro de 60 dias de se tornarem 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.

Atendido

Não atendido

N/A

É SUGERIDO que a análise estática de código-fonte ocorra em cada commit ou pelo menos diariamente. ^{[static_analysis_often]}

Análise dinâmica de código
Criterion [dynamic_analysis]
Atendido

Não atendido

?

É SUGERIDO que pelo menos uma ferramenta de análise dinâmica seja aplicada a qualquer grande lançamento de produção proposto do software antes de seu lançamento. ^{[dynamic_analysis]}
Uma ferramenta de análise dinâmica examina o software executando-o com entradas específicas. Por exemplo, o projeto PODE usar uma ferramenta de fuzzing (por exemplo, American Fuzzy Lop) ou um scanner de aplicação web (por exemplo, OWASP ZAP ou w3af). Em alguns casos, o projeto OSS-Fuzz pode estar disposto a aplicar testes de fuzzing ao seu projeto. Para fins deste critério, a ferramenta de análise dinâmica precisa variar as entradas de alguma forma para procurar vários tipos de problemas ou ser um conjunto de testes automatizado com pelo menos 80% de cobertura de ramificação. A página da Wikipedia sobre análise dinâmica e a página da OWASP sobre fuzzing identificam algumas ferramentas de análise dinâmica. A(s) ferramenta(s) de análise PODEM estar focadas em procurar vulnerabilidades de segurança, mas isso não é obrigatório.
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]
Atendido

Não atendido

N/A

?

É SUGERIDO que se o software produzido pelo projeto incluir software escrito usando uma linguagem insegura em memória (por exemplo, C ou C++), então pelo menos uma ferramenta dinâmica (por exemplo, um fuzzer ou scanner de aplicação web) seja rotineiramente usada em combinação com um mecanismo para detectar problemas de segurança de memória, como estouros de buffer. Se o projeto não produzir software escrito em uma linguagem insegura em memória, escolha "não aplicável" (N/A). ^{[dynamic_analysis_unsafe]}
Exemplos de mecanismos para detectar problemas de segurança de memória incluem Address Sanitizer (ASAN) (disponível no GCC e LLVM), Memory Sanitizer e valgrind. Outras ferramentas potencialmente usadas incluem thread sanitizer e undefined behavior sanitizer. Assertivas generalizadas também funcionariam.
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]
Atendido

Não atendido

?

É SUGERIDO que o projeto use uma configuração para pelo menos alguma análise dinâmica (como testes ou fuzzing) que habilite muitas asserções. Em muitos casos, essas asserções não devem ser habilitadas em builds de produção. ^{[dynamic_analysis_enable_assertions]}
Este critério não sugere habilitar asserções durante a produção; isso é inteiramente decisão do projeto e de seus usuários. O foco deste critério é, em vez disso, melhorar a detecção de falhas durante a análise dinâmica antes da implantação. Habilitar asserções no uso em produção é completamente diferente de habilitar asserções durante a análise dinâmica (como testes). Em alguns casos, habilitar asserções no uso em produção é extremamente imprudente (especialmente em componentes de alta integridade). Existem muitos argumentos contra habilitar asserções em produção, por exemplo, bibliotecas não devem travar chamadores, sua presença pode causar rejeição por lojas de aplicativos e/ou ativar uma asserção em produção pode expor dados privados, como chaves privadas. Observe que em muitas distribuições Linux NDEBUG não é definido, então assert() em C/C++ será habilitado por padrão para produção nesses ambientes. Pode ser importante usar um mecanismo de asserção diferente ou definir NDEBUG para produção nesses ambientes.
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]
Atendido

Não atendido

N/A

?

Todas as vulnerabilidades exploráveis de severidade média e superior descobertas com análise dinâmica de código DEVEM ser corrigidas em tempo hábil após serem confirmadas. ^{[dynamic_analysis_fixed]}
Se você não está executando análise dinâmica de código e, portanto, não encontrou nenhuma vulnerabilidade dessa forma, escolha "não aplicável" (N/A). Uma vulnerabilidade é considerada de severidade média ou superior se sua pontuação qualitativa base do Common Vulnerability Scoring System (CVSS) for média ou superior. Nas versões 2.0 a 3.1 do CVSS, isso é equivalente a uma pontuação CVSS de 4.0 ou superior. Os projetos podem usar a pontuação CVSS conforme publicada em um banco de dados de vulnerabilidades amplamente utilizado (como o National Vulnerability Database) usando a versão mais recente do CVSS relatada nesse banco de dados. Os projetos podem, em vez disso, calcular a severidade por conta própria usando a versão mais recente do CVSS no momento da divulgação da vulnerabilidade, se as entradas de cálculo forem reveladas publicamente assim que a vulnerabilidade for conhecida publicamente.
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.

Estes dados estão disponíveis sob o Community Data License Agreement – Permissive, Version 2.0 (CDLA-Permissive-2.0). Isso significa que um Destinatário de Dados pode compartilhar os Dados, com ou sem modificações, desde que o Destinatário de Dados disponibilize o texto deste acordo com os Dados compartilhados. Por favor, dê crédito a Macawi AI e aos contribuidores do selo de melhores práticas OpenSSF.

Strigoi

Fundamentos 13/13 ●

Geral

Conteúdo básico do site do projeto

Licença FLOSS

Documentação

Outro

Controle de Mudanças 9/9 ●

Repositório de código-fonte público controlado por versão

Numeração de versão única

Notas de lançamento

Relatórios 8/8 ●

Processo de relato de bugs

Processo de relato de vulnerabilidades

Qualidade 13/13 ●

Sistema de compilação funcional

Conjunto de testes automatizados

Teste de novas funcionalidades

Sinalizadores de aviso

Segurança 16/16 ●

Conhecimento de desenvolvimento seguro

Usar práticas criptográficas boas e básicas

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 protegida contra ataques man-in-the-middle (MITM)

Vulnerabilidades conhecidas publicamente corrigidas

Outras questões de segurança

Análise 8/8 ●

Análise estática de código

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

Análise dinâmica de código

CI workflow

Makefile - test mode with assertions

CI runs with race detector