spector

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 14829 é gold 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/14829/badge)](https://www.bestpractices.dev/projects/14829)
ou incorporando isto no seu HTML:
<a href="https://www.bestpractices.dev/projects/14829"><img src="https://www.bestpractices.dev/projects/14829/badge"></a>


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

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

        

 Fundamentos 5/5 ●

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    Memory backbone for AI agents. Four-tier store — working, episodic, semantic, procedural — with decay, consolidation, and association graphs. Fused semantic + SIMD-accelerated hybrid recall, in-process MCP, REST/gRPC, and language SDKs.

    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.

  • Pré-requisitos


    Suficiente para um badge!

    O projeto DEVE alcançar um selo de nível prata. [achieve_silver]

  • Supervisão do projeto


    Suficiente para um badge!

    O projeto DEVE ter um "fator ônibus" de 2 ou mais. (URL obrigatória) [bus_factor]
    Um "bus factor" (também conhecido como "truck factor") é o número mínimo de membros do projeto que precisam desaparecer repentinamente de um projeto ("ser atropelados por um ônibus") antes que o projeto pare devido à falta de pessoal conhecedor ou competente. A ferramenta truck-factor pode estimar isso para projetos no GitHub. Para mais informações, consulte Assessing the Bus Factor of Git Repositories de Cosentino et al.

    The project maintains a bus factor of 2 or more across its core codebase and governance hierarchy, as documented in ACKNOWLEDGMENTS.md (https://github.com/spectrayan/spector/blob/main/ACKNOWLEDGMENTS.md#open-source-contributors) and GOVERNANCE.md (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#3-the-4-tier-contributor-ladder). Technical knowledge, code review authority, and codebase maintenance are shared between Project Lead Bharat Joshi (@sbharatjoshi) and active committer Timothy Kim (@timothytkim), who has authored merged contributions across kernel documentation, provider architecture, index diagnostics, and observability, alongside functional team aliases in .github/CODEOWNERS (https://github.com/spectrayan/spector/blob/main/.github/CODEOWNERS).


    Suficiente para um badge!

    O projeto DEVE ter pelo menos dois contribuidores significativos não associados. (URL obrigatória) [contributors_unassociated]
    Os contribuidores são associados se forem pagos para trabalhar pela mesma organização (como empregado ou contratado) e a organização se beneficia dos resultados do projeto. Concessões financeiras não contam como sendo da mesma organização se passarem por outras organizações (por exemplo, concessões científicas pagas a diferentes organizações de uma fonte governamental ou ONG comum não fazem com que os contribuidores sejam associados). Alguém é um contribuidor significativo se fez contribuições não triviais para o projeto no último ano. Exemplos de bons indicadores de um contribuidor significativo são: escreveu pelo menos 1.000 linhas de código, contribuiu com 50 commits, ou contribuiu com pelo menos 20 páginas de documentação.

    The project has multiple independent, unassociated significant contributors from the open-source community who are not employed by or affiliated with Spectrayan Inc., documented in ACKNOWLEDGMENTS.md under Open Source Contributors (https://github.com/spectrayan/spector/blob/main/ACKNOWLEDGMENTS.md#open-source-contributors) and in the Git repository history. Notable unassociated contributors include Timothy Kim (@timothytkim), who has authored five merged pull requests spanning vector index diagnostics (#936), kernel documentation (#939), provider architecture (#878), and Prometheus metrics observability (#920); Kaustubh Abhinand (@KaustAbhinand), who contributed SQL agent tools (#278) and Gemini provider validation (#354); and Essosolim Joël PAKA (@paka-ops), who contributed Spring Boot starter enhancements (#420).


  • Outro


    Suficiente para um badge!

    O projeto DEVE incluir uma declaração de licença em cada arquivo-fonte. Isso PODE ser feito incluindo o seguinte dentro de um comentário perto do início de cada arquivo: SPDX-License-Identifier: [expressão de licença SPDX para o projeto]. [license_per_file]
    Isso PODE também ser feito incluindo uma declaração em linguagem natural identificando a licença. O projeto PODE também incluir uma URL estável apontando para o texto da licença, ou o texto completo da licença. Observe que o critério license_location requer que a licença do projeto esteja em um local padrão. Veja este tutorial SPDX para mais informações sobre expressões de licença SPDX. Observe a relação com copyright_per_file, cujo conteúdo normalmente precederia as informações de licença.

    The project includes the official Apache License 2.0 statement at the beginning of each source file (.java, .ts, .js, .py), documented in CONTRIBUTING.md under License Headers (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#license-headers) and codified in the template src/license/apache2-header.txt (https://github.com/spectrayan/spector/blob/main/src/license/apache2-header.txt). The header explicitly cites the Apache License 2.0 and its canonical license URL (http://www.apache.org/licenses/LICENSE-2.0). Automated verification runs on every build via the license-maven-plugin (mvn license:check), causing compilation to fail if any source file lacks a valid license header.


 Controle de Mudanças 4/4 ●

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


    Suficiente para um badge!

    O repositório de código do projeto DEVE usar um software de controle de versão distribuído comum (por exemplo, git ou mercurial). [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.


    Suficiente para um badge!

    O projeto DEVE identificar claramente pequenas tarefas que podem ser realizadas por novos colaboradores ou colaboradores casuais. (URL obrigatória) [small_tasks]
    Esta identificação é tipicamente feita marcando problemas selecionados em um rastreador de problemas com uma ou mais tags que o projeto usa para o propósito, por exemplo, up-for-grabs, first-timers-only, "Small fix", microtask ou IdealFirstBug. Essas novas tarefas não precisam envolver a adição de funcionalidade; elas podem ser melhorar a documentação, adicionar casos de teste ou qualquer outra coisa que ajude o projeto e ajude o colaborador a entender mais sobre o projeto.

    The project explicitly identifies small, accessible tasks for new and casual contributors in CONTRIBUTING.md under Good First Areas (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#good-first-areas) and in the GitHub issue tracker via the standard good first issue label (https://github.com/spectrayan/spector/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22). Documented beginner-friendly tasks include documentation and tutorial improvements, edge-case test coverage in spector-core, implementing isolated EmbeddingProvider SPI templates, CLI output ergonomics in spector-cli, and building UI widgets for spector-cortex, backed by first-time onboarding guidance in the 4-tier Contributor Ladder (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#3-the-4-tier-contributor-ladder).


    Suficiente para um badge!

    O projeto DEVE exigir autenticação de dois fatores (2FA) para desenvolvedores para alterar um repositório central ou acessar dados sensíveis (como relatórios de vulnerabilidade privados). Este mecanismo 2FA PODE usar mecanismos sem mecanismos criptográficos, como SMS, embora isso não seja recomendado. [require_2FA]

    GitHub requires 2FA as of March 2023. [osps_ac_01_01]


    Suficiente para um badge!

    A autenticação de dois fatores (2FA) do projeto DEVERIA usar mecanismos criptográficos para evitar personificação. A autenticação 2FA baseada em Short Message Service (SMS), por si só, NÃO atende a este critério, pois não é criptografada. [secure_2FA]
    Um mecanismo de 2FA que atende a este critério seria um aplicativo de Time-based One-Time Password (TOTP) que gera automaticamente um código de autenticação que muda após um determinado período de tempo. Observe que o GitHub suporta TOTP.

    The project enforces cryptographically secure two-factor authentication (2FA) across its code repository, package registries, and administrative accounts, documented in GOVERNANCE.md under Project Continuity & Redundancy (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#32-project-continuity--redundancy) and SECURITY.md (https://github.com/spectrayan/spector/blob/main/SECURITY.md). Maintainers and repository administrators authenticate using FIDO2/WebAuthn cryptographic hardware security keys and TOTP authenticator applications (RFC 6238), with SMS-based 2FA prohibited. Automated distribution pipelines (GHCR, PyPI, and npm) utilize cryptographic OpenID Connect (OIDC) token exchanges and scoped publisher tokens to eliminate static credentials and prevent impersonation attacks.


 Qualidade 7/7 ●

  • Padrões de codificação


    Suficiente para um badge!

    O projeto DEVE documentar seus requisitos de revisão de código, incluindo como a revisão de código é conduzida, o que deve ser verificado e o que é necessário para ser aceitável. (URL obrigatória) [code_review_standards]
    Veja também two_person_review e contribution_requirements.

    The project formally documents its code review requirements in CONTRIBUTING.md under Code Review Requirements (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#code-review-requirements) and GOVERNANCE.md (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#2-governance-structure--roles). Code review is conducted publicly on GitHub Pull Requests by authorized Committers and Maintainers designated in .github/CODEOWNERS (https://github.com/spectrayan/spector/blob/main/.github/CODEOWNERS). Reviewers must verify: (1) automated test coverage and regression tests; (2) security and memory safety (no hardcoded secrets, input allowlisting, Panama FFM bounded arena safety); (3) architectural invariants (zero-dependency rule in engine core); (4) performance criteria (zero allocations on SIMD hot paths, JMH benchmarks); and (5) licensing compliance (DCO 1.1 sign-off, Apache 2.0 headers). Acceptance requires passing all automated CI matrix and CodeQL checks, resolving all reviewer threads, and receiving formal approval from the assigned CODEOWNER.


    Suficiente para um badge!

    O projeto DEVE ter pelo menos 50% de todas as modificações propostas revisadas antes do lançamento por uma pessoa diferente do autor, para determinar se é uma modificação que vale a pena e livre de problemas conhecidos que argumentariam contra sua inclusão [two_person_review]

    The project enforces mandatory independent peer review on all proposed modifications prior to release, exceeding the 50% requirement. Documented in CONTRIBUTING.md under Code Review Requirements (https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#code-review-requirements) and GOVERNANCE.md (https://github.com/spectrayan/spector/blob/main/GOVERNANCE.md#4-decision-making--voting-mechanics), every pull request targeting main must be evaluated and approved by an independent committer or maintainer other than the author (governed by .github/CODEOWNERS: https://github.com/spectrayan/spector/blob/main/.github/CODEOWNERS). The full history of peer reviews, approvals, and maintainer feedback is publicly verifiable across merged pull requests in the repository (https://github.com/spectrayan/spector/pulls?q=is%3Apr+is%3Amerged).


  • Sistema de compilação funcional


    Suficiente para um badge!

    O projeto DEVE ter uma compilação reproduzível. Se nenhuma compilação ocorrer (por exemplo, linguagens de script onde o código fonte é usado diretamente em vez de ser compilado), selecione "não aplicável" (N/A). (URL obrigatória) [build_reproducible]
    Uma compilação reproduzível significa que várias partes podem refazer independentemente o processo de geração de informações a partir de arquivos fonte e obter exatamente o mesmo resultado bit a bit. Em alguns casos, isso pode ser resolvido forçando algum tipo de ordenação. Desenvolvedores JavaScript podem considerar usar npm shrinkwrap e webpack OccurrenceOrderPlugin. Usuários de GCC e clang podem achar útil a opção -frandom-seed. O ambiente de compilação (incluindo o conjunto de ferramentas) pode frequentemente ser definido para partes externas especificando o hash criptográfico de um contêiner específico ou máquina virtual que eles podem usar para recompilar. O projeto de compilações reproduzíveis tem documentação sobre como fazer isso.

    The project implements reproducible builds in accordance with reproducible-builds.org specifications via Apache Maven's build configuration in pom.xml (https://github.com/spectrayan/spector/blob/main/pom.xml#L189-L191). By declaring a fixed timestamp (<project.build.outputTimestamp>2024-01-01T00:00:00Z</project.build.outputTimestamp>), the build system normalizes file ordering, permissions, and archive entry timestamps across all generated JAR and ZIP artifacts (via maven-jar-plugin, maven-shade-plugin, and flatten-maven-plugin). Repeated compilation of the source tree in the same OpenJDK 25 environment yields bit-for-bit identical binary distributions without non-deterministic drift.


  • Conjunto de testes automatizados


    Suficiente para um badge!

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

    The test suite is invoked using standard language conventions: mvn test for the Java Maven reactor, npm test for TypeScript modules, and pytest for the Python SDK. https://github.com/spectrayan/spector/blob/main/CONTRIBUTING.md#running-the-test-suites


    Suficiente para um badge!

    O projeto DEVE implementar integração contínua, onde o código novo ou alterado é frequentemente integrado em um repositório de código central e testes automatizados são executados no resultado. (URL obrigatória) [test_continuous_integration]
    Na maioria dos casos, isso significa que cada desenvolvedor que trabalha em tempo integral no projeto integra pelo menos diariamente.

    Continuous integration is implemented using GitHub Actions (.github/workflows/ci.yml). Automated builds, multi-architecture matrix tests (x86_64 and aarch64), license checks, and property tests run on every pull request and commit to main. https://github.com/spectrayan/spector/actions


    Suficiente para um badge!

    O projeto DEVE ter conjunto(s) de testes automatizados FLOSS que fornecem pelo menos 90% de cobertura de instrução se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. [test_statement_coverage90]

    The project uses the open-source JaCoCo tool (jacoco-maven-plugin: https://github.com/spectrayan/spector/blob/main/pom.xml#L1046-L1048) in its automated CI pipeline in .github/workflows/ci.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/ci.yml#L134-L142) to measure statement and branch coverage. Automated test suites—comprising JUnit 5 unit tests, jqwik property-based generative invariant tests, and integration pathways—exercise the codebase on every check-in, achieving and maintaining over 90% statement coverage across core memory layout, decay math, SIMD vector scoring, and kernel persistence modules.


    Suficiente para um badge!

    O projeto DEVE ter conjunto(s) de testes automatizados FLOSS que fornecem pelo menos 80% de cobertura de ramos se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. [test_branch_coverage80]

    The project measures and validates branch coverage using the open-source JaCoCo framework (jacoco-maven-plugin: https://github.com/spectrayan/spector/blob/main/pom.xml#L1046-L1048), executed automatically in CI via .github/workflows/ci.yml (https://github.com/spectrayan/spector/blob/main/.github/workflows/ci.yml#L134-L142). The automated test suite combines traditional unit tests with comprehensive jqwik property-based generative testing hat systematically explores boundary inputs, bit-flip conditions, and error-handling paths, maintaining at least 80% branch coverage across the core engine and indexing modules.


 Segurança 5/5 ●

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

    Suficiente para um badge!

    O software produzido pelo projeto DEVE suportar protocolos seguros para todas as suas comunicações de rede, como SSHv2 ou posterior, TLS1.2 ou posterior (HTTPS), IPsec, SFTP e SNMPv3. Protocolos inseguros como FTP, HTTP, telnet, SSLv3 ou anterior, e SSHv1 DEVEM estar desabilitados por padrão, e apenas habilitados se o usuário configurá-lo especificamente. Se o software produzido pelo projeto não suportar comunicações de rede, selecione "não aplicável" (N/A). [crypto_used_network]

    The software supports secure network communication protocols across all network endpoints, using TLS 1.2 and TLS 1.3 for HTTPS REST APIs, gRPC services, and inter-node cluster replication, documented in docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md) and synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java (https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java). Insecure and legacy protocols (such as FTP, Telnet, SSLv2, SSLv3, and TLS 1.0/1.1) are unsupported and disabled by default by the OpenJDK 25 security provider and Netty transport layer. For remote cluster and gateway deployments, mutual TLS (mTLS) and HTTPS are enforced, while local agent communications default to secure, memory-isolated stdio process pipes.


    Suficiente para um badge!

    O software produzido pelo projeto DEVE, se suportar ou usar TLS, suportar pelo menos a versão 1.2 do TLS. Observe que o predecessor do TLS foi chamado SSL. Se o software não usar TLS, selecione "não aplicável" (N/A). [crypto_tls12]

    The software natively supports TLS 1.2 and modern TLS 1.3 for all encrypted network communications, documented in ReplicationTlsFactory.java (https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/replication/ReplicationTlsFactory.java#L46-L50) and docs/architecture/encryption-at-rest.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/encryption-at-rest.md). Cluster node replication explicitly enforces TLS 1.3 contexts (public static final String TLS_V1_3 = "TLSv1.3"), and gateway REST/gRPC endpoints support both TLS 1.2 and TLS 1.3 through the OpenJDK 25 and Netty SSL engines. All legacy protocols prior to TLS 1.2 (SSLv2, SSLv3, TLS 1.0, TLS 1.1) are permanently disabled at the runtime platform level.


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


    Suficiente para um badge!

    O site do projeto, repositório (se acessível via web) e site de download (se separado) DEVEM incluir cabeçalhos de fortalecimento chave com valores não permissivos. (URL obrigatória) [hardened_site]
    Observe que o GitHub e o GitLab são conhecidos por atender a isso. Sites como https://securityheaders.com/ podem verificar isso rapidamente. Os principais cabeçalhos de proteção são: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (como "nosniff") e X-Frame-Options. Sites web totalmente estáticos sem capacidade de fazer login por meio das páginas web poderiam omitir alguns cabeçalhos de proteção com menos risco, mas não há maneira confiável de detectar tais sites, portanto exigimos esses cabeçalhos mesmo se forem sites totalmente estáticos.

    The project repository, documentation website, and release distribution sites enforce key hardening headers with nonpermissive values. The primary code repository and release download endpoints hosted on GitHub (https://github.com/spectrayan/spector) enforce strict HTTP headers including Strict-Transport-Security: max-age=31536000; includeSubdomains; preload, X-Frame-Options: deny, X-Content-Type-Options: nosniff, and a restrictive Content-Security-Policy with frame-ancestors 'none'. The documentation website hosted on GitHub Pages (https://spectrayan.github.io/spector/) strictly enforces HTTP Strict Transport Security (Strict-Transport-Security: max-age=31556952), and the Synapse server gateway in SecurityConfig.java (https://github.com/spectrayan/spector/blob/main/synapse/spector-synapse/src/main/java/com/spectrayan/spector/synapse/config/SecurityConfig.java) activates Spring Security's default nonpermissive header suite (nosniff, frame denial, and HSTS).


  • Outras questões de segurança


    Suficiente para um badge!

    O projeto DEVE ter realizado uma revisão de segurança nos últimos 5 anos. Esta revisão DEVE considerar os requisitos de segurança e o limite de segurança. [security_review]
    Isso PODE ser feito pelos membros do projeto e/ou uma avaliação independente. Esta avaliação PODE ser apoiada por ferramentas de análise estática e dinâmica, mas também deve haver revisão humana para identificar problemas (particularmente no projeto) que as ferramentas não conseguem detectar.

    The project completed a comprehensive architectural and code security review in September 2026, documented in the formal Security Assurance Case & Threat Model (https://github.com/spectrayan/spector/blob/main/docs/architecture/security-assurance.md) and linked in SECURITY.md (https://github.com/spectrayan/spector/blob/main/SECURITY.md). The review explicitly evaluated the system's security requirements and mapped its five core security trust boundaries (network-to-gateway, agent-to-MCP, tenant-to-tenant, JVM-to-native off-heap, and host storage), verifying mitigations against memory corruption, path traversal, untrusted input injection, and timing attacks. This is augmented by automated continuous security reviews in CI via GitHub CodeQL (https://github.com/spectrayan/spector/blob/main/.github/workflows/codeql.yml) and Aqua Trivy container scanning.


    Suficiente para um badge!

    Mecanismos de proteção DEVEM ser usados no software produzido pelo projeto para que defeitos de software tenham menos probabilidade de resultar em vulnerabilidades de segurança. (URL obrigatória) [hardening]
    Os mecanismos de proteção podem incluir cabeçalhos HTTP como Content Security Policy (CSP), flags de compilador para mitigar ataques (como -fstack-protector), ou flags de compilador para eliminar comportamento indefinido. Para nossos propósitos, o privilégio mínimo não é considerado um mecanismo de proteção (privilégio mínimo é importante, mas separado).

    The project applies runtime, memory, and architectural hardening mechanisms to prevent defects from translating into security vulnerabilities, documented in SECURITY.md under Security Guarantees & Non-Guarantees (https://github.com/spectrayan/spector/blob/main/SECURITY.md#security-guarantees--non-guarantees-security-requirements) and docs/architecture/overview.md (https://github.com/spectrayan/spector/blob/main/docs/architecture/overview.md). Off-heap native memory accesses are hardened using OpenJDK 25 Project Panama bounded Arena lifecycles that enforce spatial and temporal boundary checks at the JVM level, preventing memory corruption, use-after-free, and buffer overflows. Authentication endpoints enforce constant-time string comparisons to eliminate timing side-channels, binary headers enforce hardware CRC32C integrity checksums and strict format-version gates, and container images run under restricted non-root users with pinned base image digests.


 Análise 2/2 ●

  • Análise dinâmica de código


    Suficiente para um badge!

    O projeto DEVE aplicar pelo menos uma ferramenta de análise dinâmica a qualquer lançamento de produção proposto do software produzido pelo projeto 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.

    The project applies dynamic analysis prior to release using multiple FLOSS tools: jqwik for dynamic randomized property-based testing and fuzzing of algorithmic invariants, PanamaMemoryDetector for dynamic off-heap memory leak tracking, JaCoCo for runtime bytecode coverage analysis, and automated live container smoke testing prior to release publication.


    Suficiente para um badge!

    O projeto DEVERIA incluir muitas asserções em tempo de execução no software que produz e verificar essas asserções durante a análise dinâmica. [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.

    Dynamic analysis and testing runs with JVM assertions enabled by default via the Maven Surefire test runner (-ea), executing internal invariant checks and jqwik property assertions. In production builds and container deployments, assertions are disabled by default to maintain zero-overhead performance on SIMD hot paths. https://github.com/spectrayan/spector/blob/main/pom.xml#L748-L758



Você pode usar ferramentas e sistemas de IA para propor alterações por meio de uma URL simples, como https://www.bestpractices.dev/pt-BR/projects/14829/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Veja nosso sistema de propostas de automação para saber como fazer isso. 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 Bharat Joshi e aos contribuidores do selo de melhores práticas OpenSSF.

Entrada de selo do projeto de propriedade de: Bharat Joshi.
Entrada criada em 2026-09-25 00:58:39 UTC, última atualização em 2026-09-25 04:20:39 UTC. Selo de aprovação alcançado pela última vez em 2026-09-25 01:54:45 UTC.