Vectis

Projetos que seguem as melhores práticas abaixo podem se autocertificar voluntariamente e mostrar que alcançaram um selo de melhores práticas da Open Source Security Foundation (OpenSSF).

Não existe um conjunto de práticas que possa garantir que o software nunca terá defeitos ou vulnerabilidades; mesmo métodos formais podem falhar se as especificações ou suposições estiverem erradas. Nem existe qualquer conjunto de práticas que possa garantir que um projeto sustentará uma comunidade de desenvolvimento saudável e bem-funcionada. No entanto, seguir as melhores práticas pode ajudar a melhorar os resultados dos projetos. Por exemplo, algumas práticas permitem revisão multipessoal antes do lançamento, o que pode ajudar a encontrar vulnerabilidades técnicas difíceis de encontrar e ajudar a construir confiança e desejo de interação repetida entre desenvolvedores de diferentes empresas. Para ganhar um selo, todos os critérios DEVE e NÃO DEVE devem ser atendidos, todos os critérios DEVERIA devem ser atendidos OU não atendidos com justificativa, e todos os critérios SUGERIDO devem ser atendidos OU não atendidos (queremos que sejam considerados pelo menos). Se você quiser inserir texto de justificativa como um comentário genérico, em vez de ser uma justificativa de que a situação é aceitável, inicie o bloco de texto com '//' seguido de um espaço. Feedback é bem-vindo via site do GitHub como questões ou pull requests Há também uma lista de discussão para discussão geral.

Fornecemos com prazer as informações em vários idiomas, no entanto, se houver qualquer conflito ou inconsistência entre as traduções, a versão em inglês é a versão autoritativa.
Se este é o seu projeto, por favor mostre o status do seu selo na página do seu projeto! O status do selo se parece com isto: O nível do selo para o projeto 14194 é in_progress Aqui está como incorporá-lo:
Você pode mostrar o status do seu selo incorporando isto no seu arquivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/14194/badge)](https://www.bestpractices.dev/projects/14194)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/14194"><img src="https://www.bestpractices.dev/projects/14194/badge"></a>


Estes são os critérios de nível de Aprovação. Você também pode visualizar os critérios de nível Prata ou Ouro.

Baseline Series: Nível Básico 1 Nível Básico 2 Nível Básico 3

        

 Fundamentos 12/13 ●

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    Open-source cryptographic data protection toolkit for sensitive data workflows.

    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.
    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".
    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.

    Vectis is an experimental open source cryptographic data protection toolkit under active development. It provides profile-driven hybrid cryptography,
    format-preserving encryption, tokenization, masking, MACs, blind indexes, commitments, secret sharing, protected messaging, and verifiable audit records.

    The project emphasizes bounded input validation, signed configuration, encrypted application-level storage, explicit trust boundaries, key lifecycle
    enforcement, negative testing, property-based testing, Schemathesis, native fuzzing, dependency auditing, CodeQL, and reproducible release workflows.

    Vectis v0.8.5 completed a source-backed security self-assessment with no Critical or High severity vulnerabilities identified. This was not an
    independent external security audit, certification, or compliance assessment. Vectis should currently be used for evaluation, testing, demos, and
    design-partner proofs of concept rather than as the sole protection layer for
    production sensitive data.

    Project scope, accepted risks, and operational assumptions are documented publicly in the threat model and security documentation.

  • Conteúdo básico do site do projeto


    Suficiente para um badge!

    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).

    Vectis is an open-source advanced data protection toolkit.

    TLS protects the connection, but sensitive data keeps moving in plaintext afterward — through logs, queues, databases, and internal APIs. Vectis protects the data itself.

    Sensitive input in. Protected representation out

    Vectis protects and transforms sensitive values through a consistent HTTP API and CLI. Operator-signed profiles define the allowed operations, algorithms, keys, permissions, and lifecycle policy.


    Suficiente para um badge!

    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]

    Security: https://github.com/liesware/Vectis/blob/main/SECURITY.md
    Contributing: https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Suficiente para um badge!

    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?)

    Non-trivial contribution file in repository: https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md.


    Informações obrigatórias desconhecidas, insuficiente para um badge.

    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]

  • Licença FLOSS


    Suficiente para um badge!

    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).

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    Suficiente para um badge!

    É 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.

    The Apache-2.0 license is approved by the Open Source Initiative (OSI).


    Suficiente para um badge!

    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/liesware/Vectis/blob/main/LICENSE.


  • Documentação


    Suficiente para um badge!

    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).

    Vectis provides basic documentation in its README, including its purpose,
    current capabilities, scope, installation and Quick Start instructions,
    configuration overview, CLI and API entry points, testing, and security status.

    README:
    https://github.com/liesware/Vectis#readme

    Quick Start:
    https://github.com/liesware/Vectis#quick-start

    Detailed documentation:
    https://github.com/liesware/Vectis/tree/main/doc


    Suficiente para um badge!

    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).

    Vectis documents its external HTTP and CLI interfaces, including request and
    response fields, status codes, error behavior, command arguments, output
    formats, configuration, and environment variables.

    HTTP API reference:
    https://github.com/liesware/Vectis/blob/main/doc/API.md

    OpenAPI specification:
    https://github.com/liesware/Vectis/blob/main/doc/openapi.yaml

    CLI reference:
    https://github.com/liesware/Vectis/blob/main/doc/CLI.md

    Environment reference:
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


  • Outro


    Suficiente para um badge!

    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.


    Suficiente para um badge!

    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.


    Suficiente para um badge!

    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.

    Vectis documentation, contribution guidance, security policy, API reference,
    and source-code documentation are written in English. Bug reports, pull
    requests, and code-review comments are accepted in English through GitHub.

    Documentation:
    https://github.com/liesware/Vectis#readme

    Contribution guidance:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md

    Bug reports:
    https://github.com/liesware/Vectis/issues

    Pull requests:
    https://github.com/liesware/Vectis/pulls


    Suficiente para um badge!

    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.

    Vectis is under active development and is maintained through regular commits,
    continuous integration, dependency and security scanning, and a public issue
    tracker. The supported release series is documented in SECURITY.md, together
    with a private vulnerability-reporting process and an acknowledgment target.

    Evidence:
    https://github.com/liesware/Vectis/commits/main/
    https://github.com/liesware/Vectis/actions
    https://github.com/liesware/Vectis/issues
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Controle de Mudanças 9/9 ●

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


    Suficiente para um badge!

    O projeto DEVE ter um repositório de código-fonte controlado por versão que seja publicamente legível e tenha uma URL. [repo_public]
    A URL PODE ser a mesma que a URL do projeto. O projeto PODE usar branches privados (não públicos) em casos específicos enquanto a mudança não for lançada publicamente (por exemplo, para corrigir uma vulnerabilidade antes de ser revelada ao público).

    Repository on GitHub, which provides public git repositories with URLs.


    Suficiente para um badge!

    O repositório de código-fonte do projeto DEVE rastrear quais mudanças foram feitas, quem fez as mudanças e quando as mudanças foram feitas. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.


    Suficiente para um badge!

    Para permitir revisão colaborativa, o repositório de código-fonte do projeto DEVE incluir versões intermediárias para revisão entre lançamentos; ele NÃO DEVE incluir apenas lançamentos finais. [repo_interim]
    Os projetos PODEM optar por omitir versões intermediárias específicas de seus repositórios de código-fonte públicos (por exemplo, aquelas que corrigem vulnerabilidades de segurança não públicas específicas, podem nunca ser lançadas publicamente ou incluem material que não pode ser legalmente postado e não estão no lançamento final).

    Vectis is developed in its public Git repository. The main branch contains intermediate development commits between releases, and the complete commit
    history and proposed pull-request changes are available for review. The repository is not limited to final release snapshots or generated artifacts.

    Evidence:
    https://github.com/liesware/Vectis/commits/main/
    https://github.com/liesware/Vectis/pulls
    https://github.com/liesware/Vectis


    Suficiente para um badge!

    É SUGERIDO que software de controle de versão distribuído comum seja usado (por exemplo, git) para o repositório de código-fonte do projeto. [repo_distributed]
    O Git não é especificamente exigido e os projetos podem usar software de controle de versão centralizado (como subversion) com justificativa.

    Repository on GitHub, which uses git. git is distributed.


  • Numeração de versão única


    Suficiente para um badge!

    Os resultados do projeto DEVEM ter um identificador de versão único para cada lançamento destinado a ser usado pelos usuários. [version_unique]
    Isso PODE ser atendido de várias maneiras, incluindo IDs de commit (como git commit id ou mercurial changeset id) ou um número de versão (incluindo números de versão que usam versionamento semântico ou esquemas baseados em data como AAAAMMDD).

    Each Vectis release is assigned a unique Semantic Versioning identifier from Cargo.toml. The version is exposed by vectis version, recorded in
    CHANGELOG.md, and used in release artifact names.

    The release workflow requires the Git tag to match v${Cargo.toml.version} before publishing release artifacts, preventing a release from being published under an inconsistent version identifier.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml


    Suficiente para um badge!

    É SUGERIDO que o formato de numeração de versão Versionamento Semântico (SemVer) ou Versionamento de Calendário (CalVer) seja usado para lançamentos. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro. [version_semver]
    Os projetos geralmente devem preferir qualquer formato que seja esperado por seus usuários, por exemplo, porque é o formato normal usado por seu ecossistema. Muitos ecossistemas preferem SemVer, e SemVer é geralmente preferido para interfaces de programação de aplicações (APIs) e kits de desenvolvimento de software (SDKs). CalVer tende a ser usado por projetos que são grandes, têm um número excepcionalmente grande de dependências desenvolvidas independentemente, têm um escopo em constante mudança ou são sensíveis ao tempo. É SUGERIDO que aqueles que usam CalVer incluam um valor de nível micro, porque incluir um nível micro suporta branches mantidos simultaneamente sempre que isso se tornar necessário. Outros formatos de numeração de versão podem ser usados como números de versão, incluindo IDs de commit do git ou IDs de changeset do mercurial, desde que identifiquem exclusivamente as versões. No entanto, algumas alternativas (como IDs de commit do git) podem causar problemas como identificadores de lançamento, porque os usuários podem não ser capazes de determinar facilmente se estão atualizados. O formato do ID de versão pode não ser importante para identificar lançamentos de software se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua).

    Mal suficiente para um badge.

    É SUGERIDO que os projetos identifiquem cada lançamento dentro de seu sistema de controle de versão. Por exemplo, é SUGERIDO que aqueles que usam git identifiquem cada lançamento usando tags do git. [version_tags]

    Vectis has a release workflow that requires release tags to match v${Cargo.toml.version}, but the first public release has not yet been identified with a Git tag.


  • Notas de lançamento


    Suficiente para um badge!

    O projeto DEVE fornecer, em cada lançamento, notas de lançamento que sejam um resumo legível por humanos das principais mudanças nesse lançamento para ajudar os usuários a determinar se devem atualizar e qual será o impacto da atualização. As notas de lançamento NÃO DEVEM ser a saída bruta de um log de controle de versão (por exemplo, os resultados do comando "git log" não são notas de lançamento). Projetos cujos resultados não se destinam à reutilização em vários locais (como o software para um único site ou serviço) E empregam entrega contínua PODEM selecionar "N/A". (URL obrigatória) [release_notes]
    As notas de lançamento PODEM ser implementadas de várias maneiras. Muitos projetos as fornecem em um arquivo chamado "NEWS", "CHANGELOG" ou "ChangeLog", opcionalmente com extensões como ".txt", ".md" ou ".html". Historicamente, o termo "change log" significava um log de todas as mudanças, mas para atender a esses critérios, o que é necessário é um resumo legível por humanos. As notas de lançamento PODEM, em vez disso, ser fornecidas por mecanismos de sistema de controle de versão, como o fluxo de trabalho GitHub Releases.

    Non-trivial release notes file in repository: https://github.com/liesware/Vectis/blob/main/CHANGELOG.md.


    Suficiente para um badge!

    As notas de lançamento DEVEM identificar todas as vulnerabilidades de tempo de execução publicamente conhecidas corrigidas neste lançamento que já tinham uma atribuição CVE ou similar quando o lançamento foi criado. Este critério pode ser marcado como não aplicável (N/A) se os usuários normalmente não conseguem atualizar o software por conta própria (por exemplo, como geralmente é verdade para atualizações de kernel). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Se não houver notas de lançamento ou se não houve vulnerabilidades publicamente conhecidas, escolha N/A. [release_notes_vulns]
    Este critério ajuda os usuários a determinar se uma determinada atualização irá corrigir uma vulnerabilidade que é publicamente conhecida, para ajudar os usuários a tomar uma decisão informada sobre atualização. Se os usuários normalmente não conseguem atualizar o software por conta própria em seus computadores, mas devem depender de um ou mais intermediários para realizar a atualização (como é frequentemente o caso de um kernel e software de baixo nível que está entrelaçado com um kernel), o projeto pode escolher "não aplicável" (N/A) em vez disso, já que essa informação adicional não será útil para esses usuários. Da mesma forma, um projeto pode escolher N/A se todos os destinatários executarem apenas a versão mais recente (por exemplo, é o código para um único site ou serviço de internet que é constantemente atualizado via entrega contínua). Este critério se aplica apenas aos resultados do projeto, não às suas dependências. Listar as vulnerabilidades de todas as dependências transitivas de um projeto torna-se difícil conforme as dependências aumentam e variam, e é desnecessário já que ferramentas que examinam e rastreiam dependências podem fazer isso de uma forma mais escalável.

    N/A. At the time Vectis v0.8.5 was prepared, there were no publicly known run-time vulnerabilities in Vectis with a CVE or equivalent public identifier that were fixed by the release.

    Dependency advisories are monitored separately and are not treated as vulnerabilities in the Vectis project results for this criterion.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Relatórios 6/8 ●

  • Processo de relato de bugs


    Suficiente para um badge!

    O projeto DEVE fornecer um processo para os usuários enviarem relatórios de bugs (por exemplo, usando um rastreador de problemas ou uma lista de discussão). (URL obrigatória) [report_process]

    Non-trivial SECURITY[.md] file found file in repository: https://github.com/liesware/Vectis/blob/main/SECURITY.md. [osps_do_02_01]


    Suficiente para um badge!

    O projeto DEVERIA usar um rastreador de problemas para rastrear problemas individuais. [report_tracker]

    Vectis uses GitHub Issues as its public issue tracker. Individual bug reports,
    enhancement proposals, documentation problems, and user questions can be created, discussed, tracked, and closed there.

    Suspected unpatched vulnerabilities are handled separately through the private reporting process documented in SECURITY.md.

    Evidence:
    https://github.com/liesware/Vectis/issues
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


    Informações obrigatórias desconhecidas, insuficiente para um badge.

    O projeto DEVE reconhecer a maioria dos relatórios de bugs enviados nos últimos 2-12 meses (inclusive); a resposta não precisa incluir uma correção. [report_responses]

    Informações obrigatórias desconhecidas, insuficiente para um badge.

    O projeto DEVERIA responder a uma maioria (>50%) das solicitações de melhorias nos últimos 2-12 meses (inclusive). [enhancement_responses]
    A resposta PODE ser 'não' ou uma discussão sobre seus méritos. O objetivo é simplesmente que haja alguma resposta a algumas solicitações, o que indica que o projeto ainda está ativo. Para fins deste critério, os projetos não precisam contar solicitações falsas (por exemplo, de spammers ou sistemas automatizados). Se um projeto não estiver mais fazendo melhorias, selecione "não atendido" e inclua a URL que torna esta situação clara para os usuários. Se um projeto tende a ser sobrecarregado pelo número de solicitações de melhorias, selecione "não atendido" e explique.

    Suficiente para um badge!

    O projeto DEVE ter um arquivo publicamente disponível para relatórios e respostas para pesquisa posterior. (URL obrigatória) [report_archive]

    Vectis uses GitHub Issues as a publicly available and searchable archive for bug reports, enhancement requests, questions, and maintainer responses. Open and closed reports remain available for later review and searching.

    Public archive:
    https://github.com/liesware/Vectis/issues?q=is%3Aissue


  • Processo de relato de vulnerabilidades


    Suficiente para um badge!

    O projeto DEVE publicar o processo para relatar vulnerabilidades no site do projeto. (URL obrigatória) [vulnerability_report_process]
    Projetos hospedados no GitHub DEVERIAM considerar habilitar o relato privado de uma vulnerabilidade de segurança. Projetos no GitLab DEVERIAM considerar usar sua capacidade de relatar uma vulnerabilidade de forma privada. Projetos PODEM identificar um endereço de e-mail em https://PROJECTSITE/security, frequentemente na forma security@example.org. Este processo de relato de vulnerabilidades PODE ser o mesmo que seu processo de relato de bugs. Relatórios de vulnerabilidades PODEM ser sempre públicos, mas muitos projetos têm um mecanismo de relato de vulnerabilidades privado.

    Vectis publishes its vulnerability-reporting process in SECURITY.md. The policy defines the private reporting channel, requested report contents, supported versions, expected acknowledgment period, disclosure process, and information that reporters must not include.

    Vulnerability-reporting process:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


    Suficiente para um badge!

    Se relatórios privados de vulnerabilidades forem suportados, o projeto DEVE incluir como enviar as informações de uma forma que seja mantida privada. (URL obrigatória) [vulnerability_report_private]
    Exemplos incluem um relatório de defeito privado enviado na web usando HTTPS (TLS) ou um e-mail criptografado usando OpenPGP. Se relatórios de vulnerabilidades forem sempre públicos (portanto, nunca há relatórios privados de vulnerabilidades), escolha "não aplicável" (N/A).

    Vectis accepts private vulnerability reports through the maintainer's direct email address, using the subject specified in SECURITY.md. Reporters are instructed not to open a public issue for an unpatched vulnerability. If a more protected exchange is needed, the reporter can request an appropriate channel
    in the initial private message.

    Private reporting instructions:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md#reporting-a-vulnerability


    Suficiente para um badge!

    O tempo de resposta inicial do projeto para qualquer relatório de vulnerabilidade recebido nos últimos 6 meses DEVE ser menor ou igual a 14 dias. [vulnerability_report_response]
    Se não houve vulnerabilidades relatadas nos últimos 6 meses, escolha "não aplicável" (N/A).

    N/A. Vectis has not received any vulnerability reports during the last six months. SECURITY.md establishes a target acknowledgment period of five business
    days for future reports.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Qualidade 13/13 ●

  • Sistema de compilação funcional


    Suficiente para um badge!

    Se o software produzido pelo projeto requer construção para uso, o projeto DEVE fornecer um sistema de construção funcional que possa reconstruir automaticamente o software a partir do código-fonte. [build]
    Um sistema de construção determina quais ações precisam ocorrer para reconstruir o software (e em que ordem), e então executa essas etapas. Por exemplo, ele pode invocar um compilador para compilar o código-fonte. Se um executável é criado a partir do código-fonte, deve ser possível modificar o código-fonte do projeto e então gerar um executável atualizado com essas modificações. Se o software produzido pelo projeto depende de bibliotecas externas, o sistema de construção não precisa construir essas bibliotecas externas. Se não houver necessidade de construir nada para usar o software depois que seu código-fonte for modificado, selecione "não aplicável" (N/A).

    Vectis uses Cargo as its automated build system. The complete application can be rebuilt from source with cargo build --locked or cargo build --release --locked.

    Cargo.toml defines the package and dependencies, Cargo.lock pins dependency resolution, and rust-toolchain.toml defines the Rust toolchain. GitHub Actions
    continuously verifies that the project builds from source.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml


    Suficiente para um badge!

    É SUGERIDO que ferramentas comuns sejam usadas para construir o software. [build_common_tools]
    Por exemplo, Maven, Ant, cmake, o autotools, make, rake (Ruby) ou devtools (R).

    Vectis uses Cargo and rustup, the standard build and toolchain-management tools of the Rust ecosystem. Common Cargo commands are used for development, testing, linting, and release builds; no proprietary or project-specific build system is required.

    Typical commands include:

    cargo build --locked
    cargo test --locked
    cargo clippy --locked --all-targets --all-features -- -D warnings

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Suficiente para um badge!

    O projeto DEVERIA ser construível usando apenas ferramentas FLOSS. [build_floss_tools]

    Vectis can be built entirely with FLOSS tools. Its standard build uses the open-source Rust compiler, Cargo, LLVM-based tooling, and common GNU/Linux build
    tools.

    The container build demonstrates this path using Debian with Cargo, rustc, Clang, GCC, CMake, Make, and other open-source packages, followed by
    cargo build --release --locked. No proprietary compiler or build system is required.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/rust-toolchain.toml


  • Conjunto de testes automatizados


    Suficiente para um badge!

    O projeto DEVE usar pelo menos um conjunto de testes automatizados que seja disponibilizado publicamente como FLOSS (esse conjunto de testes pode ser mantido como um projeto FLOSS separado). O projeto DEVE mostrar ou documentar claramente como executar o(s) conjunto(s) de testes (por exemplo, por meio de um script de integração contínua (CI) ou por meio de documentação em arquivos como BUILD.md, README.md ou CONTRIBUTING.md). [test]
    O projeto PODE usar múltiplos conjuntos de testes automatizados (por exemplo, um que executa rapidamente, versus outro que é mais completo mas requer equipamento especial). Existem muitos frameworks de teste e sistemas de suporte a testes disponíveis, incluindo Selenium (automação de navegador web), Junit (JVM, Java), RUnit (R), testthat (R).

    Vectis includes publicly available automated test suites released under the project's Apache-2.0 license. The primary Rust suite runs with cargo test --locked.

    The project also includes Python HTTP integration tests, Schemathesis OpenAPI contract testing, native cargo-fuzz targets, and dedicated CLI and cryptographic integration tests. Execution instructions and the role of each suite are documented in doc/Test.md, and the standard suite runs automatically through GitHub Actions.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/tree/main/tests
    https://github.com/liesware/Vectis/tree/main/fuzz
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/LICENSE


    Suficiente para um badge!

    Um conjunto de testes DEVERIA ser invocável de forma padrão para aquela linguagem. [test_invocation]
    Por exemplo, "make check", "mvn test", ou "rake test" (Ruby).

    Vectis uses Cargo's standard Rust test interface. The primary unit and integration test suite is invoked with:

    cargo test --locked

    Targeted Rust tests can also be selected through Cargo's standard test filters. Additional Python, Schemathesis, and cargo-fuzz suites are documented separately, but they do not replace the standard Cargo test entry point.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml


    Mal suficiente para um badge.

    É SUGERIDO que o conjunto de testes cubra a maioria (ou idealmente todos) os ramos de código, campos de entrada e funcionalidade. [test_most]

    Vectis has extensive unit, integration, negative-contract, property-based, HTTP, Schemathesis, and native fuzz testing. These suites cover the primary
    cryptographic capabilities, input fields, validation boundaries, storage behavior, and public API workflows.

    However, Vectis does not yet publish or enforce a coverage result demonstrating that most code branches are executed. This suggested criterion has been
    considered but is not currently claimed as met.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Test.md
    https://github.com/liesware/Vectis/tree/main/tests
    https://github.com/liesware/Vectis/tree/main/fuzz


    Suficiente para um badge!

    É SUGERIDO que o projeto implemente integração contínua (onde código novo ou alterado é frequentemente integrado em um repositório de código central e testes automatizados são executados no resultado). [test_continuous_integration]

    Vectis uses GitHub Actions for continuous integration. The Rust workflow runs automatically for every pull request targeting main and for every push to main.

    The workflow checks formatting, runs the complete Rust test suite, runs Clippy with warnings treated as errors, validates shell scripts, audits dependencies,
    builds the binary, and then executes the Python integration tests.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/actions/workflows/Rust.yml


  • Teste de novas funcionalidades


    Suficiente para um badge!

    O projeto DEVE ter uma política geral (formal ou não) de que conforme nova funcionalidade importante seja adicionada ao software produzido pelo projeto, testes dessa funcionalidade devem ser adicionados a um conjunto de testes automatizados. [test_policy]
    Desde que haja uma política, mesmo que verbal, que diga que desenvolvedores devem adicionar testes ao conjunto de testes automatizados para novas funcionalidades importantes, selecione "Met".

    Vectis requires tests to be added alongside new behavior. Its engineering rules state that validation functions require unit tests and public contracts require
    positive and negative end-to-end tests. New endpoints are expected to add validators, limits, unit tests, and negative contract coverage as part of the
    same change.

    CONTRIBUTING.md also states that tests must not be omitted to make a change appear smaller and requires contributors to run the automated Rust suite before submitting.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md


    Suficiente para um badge!

    O projeto DEVE ter evidências de que a test_policy para adicionar testes foi seguida nas mudanças mais recentes e importantes ao software produzido pelo projeto. [tests_are_added]
    Funcionalidade importante seria tipicamente mencionada nas notas de lançamento. Perfeição não é necessária, apenas evidências de que testes estão sendo tipicamente adicionados na prática ao conjunto de testes automatizados quando nova funcionalidade importante é adicionada ao software produzido pelo projeto.

    Recent major Vectis capabilities were implemented together with automated tests:

    • SLH-DSA artifact signing added unit tests, parser validation tests, four native fuzz targets, and seed corpora.
    • One-time tokenization added SQLite transaction tests, HTTP positive and negative tests, CLI tests, and fuzz coverage.
    • Authenticated Shamir secret sharing added core and operation tests, positive and negative HTTP tests, CLI coverage, and fuzz inputs.
    • Cryptographic commitments added unit, HTTP contract, negative, CLI, and fuzz tests.

    This commit history demonstrates that the project's policy of adding tests with new functionality is followed in practice.

    Evidence:
    https://github.com/liesware/Vectis/commit/154cb816c41667d521c1f30cf25c50f6f524321d
    https://github.com/liesware/Vectis/commit/7f7f0fa4814494f7dad7fc740e1c70dd2606ba1d
    https://github.com/liesware/Vectis/commit/a337628e14e69ca4f2116a55d292fa9915a5eeca
    https://github.com/liesware/Vectis/commit/4bbf0047773cdc590da923f465a6b13cd7f02ea6


    Suficiente para um badge!

    É SUGERIDO que esta política sobre adicionar testes (veja test_policy) seja documentada nas instruções para propostas de mudanças. [tests_documented_added]
    Contudo, mesmo uma regra informal é aceitável desde que os testes estejam sendo adicionados na prática.

    Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

    The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


  • Sinalizadores de aviso


    Suficiente para um badge!

    O projeto DEVE habilitar uma ou mais flags de avisos do compilador, um modo de linguagem "seguro", ou usar uma ferramenta "linter" separada para procurar erros de qualidade de código ou erros comuns simples, se houver pelo menos uma ferramenta FLOSS que possa implementar este critério na linguagem selecionada. [warnings]
    Exemplos de flags de avisos do compilador incluem gcc/clang "-Wall". Exemplos de modo de linguagem "seguro" incluem JavaScript "use strict" e perl5 "use warnings". Uma ferramenta "linter" separada é simplesmente uma ferramenta que examina o código-fonte para procurar erros de qualidade de código ou erros comuns simples. Estes são tipicamente habilitados dentro do código-fonte ou instruções de compilação.

    Vectis documents its testing policy in the contribution instructions. Contributors must not omit tests to reduce the apparent size of a change, must document the tests performed in the pull request, and must run the automated Rust suite before submission.

    The engineering rules additionally require unit tests for validation behavior and positive and negative end-to-end tests for public contracts.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


    Suficiente para um badge!

    O projeto DEVE tratar os avisos. [warnings_fixed]
    Estes são os avisos identificados pela implementação do critério warnings. O projeto deve corrigir avisos ou marcá-los no código-fonte como falsos positivos. Idealmente não haveria avisos, mas um projeto PODE aceitar alguns avisos (tipicamente menos de 1 aviso por 100 linhas ou menos de 10 avisos).

    Vectis treats compiler and Clippy warnings as errors. The continuous integration workflow runs Clippy with -D warnings across all targets and features, so any
    new warning causes the check to fail and must be resolved before the change can be accepted.

    The project's engineering rules define zero warnings as the required state, and the same check is documented for contributors.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline
    https://github.com/liesware/Vectis/actions/workflows/Rust.yml


    Suficiente para um badge!

    É SUGERIDO que projetos sejam maximamente rigorosos com avisos no software produzido pelo projeto, onde prático. [warnings_strict]
    Alguns avisos não podem ser efetivamente habilitados em alguns projetos. O que é necessário é evidência de que o projeto está se esforçando para habilitar flags de avisos onde puder, de forma que erros sejam detectados cedo.

    Vectis applies strict warning handling across all targets and features. Clippy and compiler warnings are promoted to errors through -D warnings, so warnings
    cannot be merged while the CI check is required.

    The project uses only narrow, local lint allowances for specific cases such as intentionally unused internal helpers and configuration functions whose
    signatures reflect explicit validation hooks. It does not disable warning categories globally.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/CONTRIBUTING.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md#7-testing-and-tooling-discipline


 Segurança 15/16 ●

  • Conhecimento de desenvolvimento seguro


    Suficiente para um badge!

    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).

    Eduardo Lopez is the original author, primary developer, maintainer, release operator, and recipient of private vulnerability reports for Vectis.

    Vectis applies secure-design principles throughout its implementation and documentation: narrow scope and economy of mechanism; fail-closed sealed
    startup and authorization; centralized lifecycle and permission mediation; public design and threat-model documentation; separation of policy, keys, and
    operations; least-privilege container execution; bounded inputs and attack surface; allowlist-based validation; explicit trust boundaries; and simple,
    inspectable HTTP, CLI, JSON, and OpenAPI interfaces.

    The project's Design and Threat Model documents explain these principles, their implementation, and the security properties Vectis deliberately leaves
    to other layers.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/Design.md
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
    https://github.com/liesware/Vectis/blob/main/NOTICE


    Suficiente para um badge!

    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).

    Vectis's primary developer understands common vulnerability classes relevant to a networked cryptographic data-protection service and applies corresponding
    mitigations, including:

    • SQL injection: SQLx queries use bound parameters; dynamic SQL is limited to internally generated placeholders.
    • Missing authentication or authorization: protected endpoints use API-key authentication, signed permissions, KID scoping, peer authorization, and
      centralized lifecycle checks.
    • SSRF and destination injection: peer and final-application destinations come from signed configuration, not request-supplied addresses.
    • Invalid or malicious input: external fields are bounded and validated using allowlists, typed parsers, strict JSON contracts, and canonical structured
      contexts.
    • Cryptographic misuse: Vectis uses published algorithms through Botan and established libraries, CSPRNG-generated material, profile-controlled policy,
      context-bound AEAD, and verify-before-decrypt.
    • Timing attacks: API-key, MAC, commitment, signature-hash, and share authentication comparisons use constant-time comparison.
    • Secret disclosure: sensitive values are redacted from errors and logs, zeroized where practical, and encrypted before application-level storage.
    • Resource-exhaustion attacks: HTTP bodies, fields, batches, files, timeouts, and shutdown behavior have explicit bounds.
    • Concurrency and state races: token consumption and lifecycle changes use transactions or compare-and-swap semantics where required.
    • Memory-safety errors: Vectis is implemented in Rust and avoids manual memory management in production application logic.

    These threats and mitigations are documented and tested through unit, integration, negative-contract, property-based, and fuzz testing.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md
    https://github.com/liesware/Vectis/blob/main/src/core/validation.rs
    https://github.com/liesware/Vectis/blob/main/src/core/storage/sqlite.rs


  • 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.

    Insuficiente para um badge.

    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.

    Vectis uses publicly published and expert-reviewed cryptographic algorithms, including AES-GCM, ChaCha20-Poly1305, SHA-3, BLAKE2, HMAC, KMAC, HKDF,
    Ed25519/Ed448, X25519/X448, ML-KEM, ML-DSA, SLH-DSA, and FF1. Its transport and time protocols use established TLS, NTS, and Roughtime implementations.

    However, Vectis also defines project-specific cryptographic compositions and envelope formats for protected messages, hybrid signatures, tokenization,
    commitments, and audit checkpoints. These designs are publicly documented but have not yet completed independent expert cryptographic review. Therefore, the project does not currently claim that this strict criterion is fully met.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/README.md
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


    Suficiente para um badge!

    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]

    Vectis's primary purpose is to provide cryptographic data-protection capabilities, including encryption, signatures, FPE, tokenization, MACs,
    commitments, secret sharing, and protected messaging. Therefore, the condition for this criterion does not apply.

    Nevertheless, Vectis delegates established cryptographic primitives to specialized FLOSS implementations such as Botan, RustCrypto crates, rustls,
    and the FF1 implementation maintained in liesware/fpe. Vectis does not implement block ciphers, cryptographic hash functions, digital-signature
    algorithms, or post-quantum primitives from scratch. Project code primarily implements policy, validation, key derivation, formats, and compositions around
    those primitives.

    Evidence:
    https://github.com/liesware/Vectis#readme
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/doc/Internal.md


    Suficiente para um badge!

    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.

    All cryptography-dependent functionality in Vectis can be built and operated using FLOSS components. Vectis is licensed under Apache-2.0 and publishes its
    complete source code.

    Cryptographic primitives are provided by open-source implementations including Botan, RustCrypto crates, rustls, and the open-source Vectis FF1 fork. Vectis
    does not require proprietary cryptographic libraries, SDKs, hardware, or hosted services for its current functionality. Dependencies are declared and pinned
    through Cargo.toml and Cargo.lock, and the project can be rebuilt from source
    using the documented FLOSS toolchain.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/LICENSE
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/fpe
    https://github.com/randombit/botan
    https://github.com/rustls/rustls


    Suficiente para um badge!

    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).

    Vectis uses cryptographic profiles whose weakest supported components provide at least 128 bits of security, exceeding the 112-bit NIST minimum required
    through 2030.

    The default hybrid-performance-v1 profile uses ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other profiles use AES-128, AES-192, or
    AES-256 together with equal or stronger signature and key-establishment parameters. Internal encryption, FPE, tokenization, MAC, commitments, secret
    sharing authentication, and key derivation use 256-bit key material.

    Vectis does not expose legacy or reduced key sizes. The default VECTIS_CRYPTO_POLICY=profile-only rejects individual algorithm overrides and
    allows only the fixed, validated profiles. Even development overrides are restricted to an allowlist containing no algorithms below the required
    security strength.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md
    https://github.com/liesware/Vectis#crypto-profiles


    Suficiente para um badge!

    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.

    Vectis does not use cryptographic algorithms known to be broken, including MD4, MD5, SHA-1, DES, Triple DES, RC4, or Dual_EC_DRBG.

    The default profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Other supported profiles use SHA-3, AES-GCM,
    Ed25519 or Ed448, X25519 or X448, ML-DSA, and ML-KEM.

    Encryption uses authenticated encryption modes: ChaCha20Poly1305 or AES-GCM. Stored internal material uses AES-256/GCM, and FPE uses FF1 with AES-256 and enforces a minimum domain size. Keyed operations use HMAC or KMAC. HTTPS uses rustls and its modern TLS defaults.

    Algorithm selection is restricted through explicit allowlists. The default profile-only policy rejects request-supplied algorithm overrides, and no compatibility fallback enables broken algorithms or inappropriate cipher modes.

    Vectis currently has no interoperability requirement that requires a broken algorithm, so no exception or legacy-risk mitigation is necessary.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md


    Suficiente para um badge!

    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.

    Vectis default security mechanisms do not depend on cryptographic algorithms or modes with known serious weaknesses.

    The default cryptographic profile uses BLAKE2b(256), ChaCha20Poly1305, Ed25519, X25519, ML-DSA-44, and ML-KEM-512. Internal storage encryption uses
    AES-256/GCM. Other supported profiles use SHA-3 and AES-GCM with stronger parameter sets.

    Vectis does not use SHA-1, MD5, DES, Triple DES, RC4, ECB, unauthenticated CBC encryption, or legacy TLS cipher suites. Encryption uses authenticated
    modes with contextual AAD, while TLS is provided through rustls with modern defaults.

    FPE uses FF1 with AES-256 and validates the minimum domain size required by the current FF1 specification. The default profile-only policy also prevents
    requests from selecting arbitrary cryptographic algorithms.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/config.rs
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/fpe.rs
    https://github.com/liesware/Vectis/blob/main/Cargo.toml
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


    Mal suficiente para um badge.

    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]

    Vectis partially satisfies this criterion through TLS: HTTPS connections use rustls and modern ephemeral TLS key exchange.

    However, the protected-message protocol does not currently provide full perfect forward secrecy. Each sender generates a fresh ephemeral X25519 or
    X448 key and a fresh ML-KEM encapsulation, but both are established against the recipient's persistent operational public keys.

    The envelope retains the sender's ephemeral public key, ML-KEM ciphertext, salt, and encrypted payload. An attacker who records an envelope and later
    obtains the recipient's complete operational private key material could reconstruct both shared secrets and derive the historical message key.

    Fresh per-message key establishment prevents key and nonce reuse and isolates messages from each other, but it does not protect historical messages after
    recipient long-term key compromise.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/message.rs
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/Design.md


    Suficiente para um badge!

    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.

    Not applicable. Vectis does not provide password-based authentication and does not store passwords belonging to external users.

    HTTP authentication uses high-entropy API keys generated from a CSPRNG. The server stores a keyed HMAC verifier derived from protected init key material,
    rather than storing the API key in plaintext. Client authorization data uses the same keyed identifier model inside signed configuration.

    The unseal key, database credentials, TLS private keys, and similar operator secrets are not external-user passwords and are governed by separate storage
    and deployment controls.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/ops/apikey.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/internal_keys.rs
    https://github.com/liesware/Vectis/blob/main/src/core/permissions.rs
    https://github.com/liesware/Vectis/blob/main/doc/ThreatModel.md
    https://github.com/liesware/Vectis/blob/main/doc/ENV.md


    Suficiente para um badge!

    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.

    Vectis generates cryptographic keys, nonces, salts, tokens, commitment openings, and secret-sharing coefficients using Botan's cryptographically
    secure random number generator.

    The core crypto module centralizes random generation through RandomNumberGenerator::new(), random_bytes(), and random_bytes_with_rng(). Cryptographic operations may reuse one Botan RNG during a single operation, but they do not replace it with a non-cryptographic generator.

    This CSPRNG is used for:

    • symmetric and asymmetric operational key generation;
    • EdDSA, X25519/X448, ML-DSA, ML-KEM, and SLH-DSA material;
    • AES-GCM and ChaCha20Poly1305 nonces;
    • ML-KEM and HKDF salts;
    • reversible random tokens;
    • commitment openings;
    • Shamir secret-sharing coefficients and set identifiers;
    • API keys, unseal keys, signature serials, and audit chain identifiers.

    Non-cryptographic counters used for request correlation are not used as keys, nonces, salts, tokens, or other cryptographic material. Vectis does not use
    thread_rng, fastrand, timestamps, counters, or similar non-cryptographic sources for security-sensitive randomness.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/src/core/crypto.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/key_material.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/message.rs
    https://github.com/liesware/Vectis/blob/main/src/core/tokenization.rs
    https://github.com/liesware/Vectis/blob/main/src/core/sharing.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/commitments.rs
    https://github.com/liesware/Vectis/blob/main/src/ops/init.rs


  • Entrega protegida contra ataques man-in-the-middle (MITM)


    Suficiente para um badge!

    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.

    Distribution channels use HTTPS exclusively. [osps_br_03_02]


    Suficiente para um badge!

    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.

    Vectis does not retrieve cryptographic hashes over plain HTTP and use them for integrity decisions without signature verification.

    Source and dependency downloads use HTTPS. Cargo dependencies are resolved through Cargo.lock, which records package checksums and pins the Git-based FPEdependency to a specific commit. Container base images are referenced by immutable SHA-256 digests.

    Release SHA256SUMS are generated locally inside the trusted GitHub Actions release workflow; they are not downloaded from an untrusted HTTP source.
    Release archives also receive GitHub build-provenance attestations before publication.

    No build, installation, update, or release workflow retrieves a checksum over plain HTTP and then trusts that checksum without an authenticated mechanism.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/image/Dockerfile.tag
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml


  • Vulnerabilidades conhecidas publicamente corrigidas


    Suficiente para um badge!

    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).

    As of 2026-08-21, Vectis has no publicly known unpatched vulnerability of Medium, High, or Critical severity that has remained unresolved for more than
    60 days.

    The project runs cargo audit in CI against the committed Cargo.lock. A current scan of 362 Rust dependencies completed successfully with no vulnerabilities.
    The previously reported RUSTSEC-2026-0258 vulnerability in h2 was remediated by upgrading to h2 0.4.16.

    Container release candidates are scanned with Trivy before publication, and CodeQL analyzes the source code. Security findings and dependency updates are
    handled through the documented vulnerability-reporting process.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/Cargo.lock
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


    Suficiente para um badge!

    Os projetos DEVERIAM corrigir todas as vulnerabilidades críticas rapidamente após serem relatadas. [vulnerabilities_critical_fixed]

    No Critical severity vulnerability has been reported or publicly identified in Vectis to date, and no confirmed Critical vulnerability remains unresolved.

    Vectis accepts private vulnerability reports through its published security policy, aims to acknowledge reports within five business days, provides status
    updates during investigation, and coordinates fixes and disclosure with the reporter.

    Critical findings would receive immediate triage and an expedited tested release before coordinated public disclosure. Cargo Audit, CodeQL, Trivy,
    OpenSSF Scorecard, and security-focused testing provide continuous detection paths for vulnerabilities requiring this response.

    Because no Critical vulnerability has been reported, Vectis does not yet have a historical Critical-vulnerability remediation time to report.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/.github/workflows/Rust.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/doc/SelfAssessment.md


  • Outras questões de segurança


    Suficiente para um badge!

    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.

    Vectis public repositories do not contain valid private credentials intended to control access to private resources.

    Runtime secret files such as .env, .unseal_key, init.json, TLS private keys, databases, generated configuration, and local demo state are excluded from
    version control. Demo and integration scripts generate temporary credentials at runtime instead of embedding reusable credentials.

    GitHub Actions retrieves publishing credentials through the GitHub Secrets context. The Helm chart accepts secrets through operator-supplied values or an
    existing Kubernetes Secret and does not contain populated credentials.

    Values shown in env.dist and documentation are synthetic localhost examples. They do not grant access to any public or private service and are not production
    credentials.

    A review of tracked files and repository history found no committed private-key blocks or recognizable live access-token formats.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.gitignore
    https://github.com/liesware/Vectis/blob/main/env.dist
    https://github.com/liesware/Vectis/blob/main/charts/vectis/values.yaml
    https://github.com/liesware/Vectis/blob/main/charts/vectis/templates/secret.yaml
    https://github.com/liesware/Vectis/blob/main/.github/workflows/release-image.yml
    https://github.com/liesware/Vectis/blob/main/SECURITY.md


 Análise 8/8 ●

  • Análise estática de código


    Suficiente para um badge!

    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'.

    Vectis uses CodeQL as a static source-code analysis tool beyond compiler warnings and Rust's memory-safety guarantees.

    CodeQL analyzes both Rust source code and GitHub Actions workflows. It runs for pull requests targeting main, every push to main, on a weekly schedule, and on manual request. Proposed release commits are merged into main and reviewed through this analysis before being tagged for release.

    Cargo Clippy, Cargo Audit, Trivy, and OpenSSF Scorecard provide additional analysis, but CodeQL is the static source-code analysis mechanism used to
    satisfy this criterion.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/actions/workflows/codeql.yml
    https://github.com/liesware/Vectis/security/code-scanning


    Suficiente para um badge!

    É 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'.

    Vectis uses the CodeQL default security query suite for Rust and GitHub Actions.

    The Rust query suite includes vulnerability-focused data-flow and source-to-sink analysis mapped to common CWE categories, including:

    • SQL injection;
    • server-side request forgery;
    • path and regular-expression injection;
    • log injection and sensitive-data logging;
    • cleartext storage and transmission;
    • disabled TLS certificate verification;
    • hard-coded cryptographic values;
    • weak cryptographic algorithms;
    • uncontrolled allocation sizes;
    • invalid pointer and lifetime access.

    CodeQL also analyzes GitHub Actions workflows for security-relevant workflow issues. The analysis runs on pull requests, pushes to main, weekly, and on
    manual request.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/security/code-scanning
    https://docs.github.com/en/code-security/code-scanning/managing-your-code-scanning-configuration/rust-built-in-queries
    https://codeql.github.com/codeql-query-help/rust-cwe/


    Suficiente para um badge!

    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.

    Not applicable at present. CodeQL has not produced a confirmed exploitable Medium, High, or Critical severity vulnerability in Vectis that requires
    remediation.

    CodeQL continues to analyze Rust source code and GitHub Actions on pull requests, pushes to main, weekly, and on manual request. Any future finding is
    reviewed to distinguish an exploitable vulnerability from a false positive or non-security issue.

    A confirmed exploitable finding of Medium severity or higher will be fixed, covered by a regression test where practical, and recorded in the relevant
    release notes or security advisory.

    Evidence:
    https://github.com/liesware/Vectis/security/code-scanning
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/blob/main/SECURITY.md
    https://github.com/liesware/Vectis/blob/main/CHANGELOG.md


    Suficiente para um badge!

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

    Vectis runs static source-code analysis on every commit that is proposed for or integrated into the main branch.

    The CodeQL workflow is triggered by:

    • every push to main;
    • every pull request targeting main, including new commits pushed to that PR;
    • a weekly scheduled scan as a fallback;
    • manual workflow dispatch.

    Therefore, each commit entering the supported development and release branch is analyzed without relying solely on the scheduled scan.

    Evidence:
    https://github.com/liesware/Vectis/blob/main/.github/workflows/codeql.yml
    https://github.com/liesware/Vectis/actions/workflows/codeql.yml


  • Análise dinâmica de código


    Suficiente para um badge!

    É 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.

    Vectis applies dynamic analysis to every change proposed for or integrated into the main branch.

    The CI integration job starts a real Vectis server with generated keys and configuration, then runs project-specific HTTP mutation testing and
    OpenAPI-based property testing with Schemathesis. These tools exercise live handlers, parsers, validation, authorization, cryptographic workflows, and
    failure paths using generated and mutated inputs.

    Vectis also runs its native cargo-fuzz targets weekly with sanitizer instrumentation and accumulated corpora. This workflow can be triggered manually before a major production release.


    Suficiente para um badge!

    É 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.

    Not applicable. Vectis is implemented in Rust and does not include project-maintained production code written in a memory-unsafe language such as
    C or C++.

    Vectis interfaces with Botan through FFI, but Botan is an external dependency rather than memory-unsafe source code produced or maintained by the Vectis
    project. Native fuzzing and sanitizer-based testing are nevertheless used to exercise Vectis input-processing boundaries.


    Suficiente para um badge!

    É 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.

    Vectis runs its automated test suite using Rust's test profile. This profile enables debug assertions and integer overflow checks that are not enabled by
    default in production release builds.

    The test suite contains assertions covering validation, cryptographic round-trips, lifecycle rules, authorization, storage, audit-chain integrity,
    and HTTP contracts. Native cargo-fuzz targets add explicit semantic assertions for properties such as canonical serialization, stable encoding, sanitized
    errors, and parser round-trips.

    These assertion-enabled test and fuzz configurations are separate from the production release profile.


    Suficiente para um badge!

    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.

    Not applicable at present. Vectis has no outstanding confirmed exploitable vulnerabilities of Medium or higher severity discovered through dynamic
    analysis.

    Findings produced by fuzzing and dynamic API testing are investigated before being dismissed. Confirmed defects are fixed, added to the regression test
    suite, and preserved as readable fuzz seeds when applicable.

    A recent canonical JSON fuzzing finding was corrected with centralized input validation, unit and HTTP regression tests, and a permanent cargo-fuzz seed. It was not formally classified as a Medium-or-higher vulnerability.



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 Liesware e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: Liesware.
Entrada criada em 2026-08-21 14:40:13 UTC, última atualização em 2026-08-21 16:38:28 UTC.