t3x-nr-llm

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


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

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

        

 Fundamentos 10/17 ●

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    The shared AI foundation for TYPO3 — one LLM setup for every extension on your site

    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


    Insuficiente para um badge.

    O projeto DEVE alcançar um distintivo de nível aprovado. [achieve_passing]

    This completed self-assessment still has unresolved or unmet passing requirements; it does not currently claim a passing badge. The badge service calculates the achievement from the saved answers. Evidence: https://www.bestpractices.dev/en/projects/11697


  • Conteúdo básico do site do projeto


    Suficiente para um badge!

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

    Contribution instructions specify acceptance expectations, development/check commands or commit requirements. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/CONTRIBUTING.md


  • Supervisão do projeto


    Suficiente para um badge!

    O projeto DEVERIA ter um mecanismo legal onde todos os desenvolvedores de quantidades não triviais de software do projeto afirmem que estão legalmente autorizados a fazer essas contribuições. A abordagem mais comum e facilmente implementada para fazer isso é usando um Developer Certificate of Origin (DCO), onde os usuários adicionam "signed-off-by" em seus commits e o projeto faz link para o site do DCO. No entanto, isso PODE ser implementado como um Contributor License Agreement (CLA) ou outro mecanismo legal. (URL obrigatória) [dco]
    O DCO é o mecanismo recomendado porque é fácil de implementar, rastreado no código-fonte e o git suporta diretamente um recurso "signed-off" usando "commit -s". Para ser mais eficaz, é melhor que a documentação do projeto explique o que "signed-off" significa para aquele projeto. Um CLA é um acordo legal que define os termos sob os quais obras intelectuais foram licenciadas para uma organização ou projeto. Um contributor assignment agreement (CAA) é um acordo legal que transfere direitos em uma obra intelectual para outra parte; os projetos não são obrigados a ter CAAs, já que ter CAA aumenta o risco de que contribuidores potenciais não contribuam, especialmente se o receptor for uma organização com fins lucrativos. Os CLAs da Apache Software Foundation (a licença de contribuidor individual e o CLA corporativo) são exemplos de CLAs, para projetos que determinam que os riscos desses tipos de CLAs para o projeto são menores do que seus benefícios.

    Contribution instructions require a Developer Certificate of Origin sign-off on contributions. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/CONTRIBUTING.md


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

    O projeto DEVE definir e documentar claramente seu modelo de governança do projeto (a forma como toma decisões, incluindo papéis-chave). (URL obrigatória) [governance]
    É necessário haver alguma forma bem estabelecida e documentada de tomar decisões e resolver disputas. Em projetos pequenos, isso pode ser tão simples quanto "o proprietário do projeto e líder toma todas as decisões finais". Existem vários modelos de governança, incluindo ditador benevolente e meritocracia formal; para mais detalhes, consulte Modelos de governança. Tanto abordagens centralizadas (por exemplo, mantenedor único) quanto descentralizadas (por exemplo, grupo de mantenedores) foram usadas com sucesso em projetos. As informações de governança não precisam documentar a possibilidade de criar um fork do projeto, já que isso é sempre possível para projetos FLOSS.

    The documented contribution and agent workflows do not by themselves establish the project's governance model. The reviewed CONTRIBUTING.md and AGENTS.md describe development and review expectations, but this review did not establish a clear public statement identifying final decision authority, the key governance roles and how disputes are resolved. A short project-specific governance statement is needed, or an existing authoritative statement should be linked. The former local pr-quality.yml link has also been superseded by checks.yml. See https://github.com/netresearch/t3x-nr-llm/blob/main/CONTRIBUTING.md, https://github.com/netresearch/t3x-nr-llm/blob/main/AGENTS.md and https://www.bestpractices.dev/en/projects/11697/1#governance. Current repository self-assessment: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/.bestpractices.json


    Suficiente para um badge!

    O projeto DEVE adotar um código de conduta e publicá-lo em um local padrão. (URL obrigatória) [code_of_conduct]
    Os projetos podem ser capazes de melhorar a civilidade de sua comunidade e estabelecer expectativas sobre conduta aceitável adotando um código de conduta. Isso pode ajudar a evitar problemas antes que ocorram e tornar o projeto um lugar mais acolhedor para encorajar contribuições. Isso deve se concentrar apenas no comportamento dentro da comunidade/local de trabalho do projeto. Exemplos de códigos de conduta são o código de conduta do kernel Linux, o Contributor Covenant Code of Conduct, o Código de Conduta Debian, o Código de Conduta Ubuntu, o Código de Conduta Fedora, o Código de Conduta GNOME, o Código de Conduta da Comunidade KDE, o Código de Conduta da Comunidade Python, A Diretriz de Conduta da Comunidade Ruby e O Código de Conduta do Rust.

    The project has a code of conduct via its repository file. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/CODE_OF_CONDUCT.md


    Insuficiente para um badge.

    O projeto DEVE definir e documentar publicamente de forma clara os papéis-chave no projeto e suas responsabilidades, incluindo quaisquer tarefas que esses papéis devem executar. DEVE estar claro quem tem qual(is) papel(is), embora isso possa não ser documentado da mesma forma. (URL obrigatória) [roles_responsibilities]
    A documentação para governança e papéis e responsabilidades pode estar em um único lugar.

    Public author names and CODEOWNERS do not provide a complete documented roster of sensitive-resource access together with the required project roles and responsibilities. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/CONTRIBUTING.md https://github.com/netresearch/t3x-nr-llm/tree/31fb1ef86a00a5071b132f5faefc686a3accf08f/.github/


    Suficiente para um badge!

    O projeto DEVE ser capaz de continuar com interrupção mínima se qualquer pessoa morrer, ficar incapacitada ou, de outra forma, não puder ou não quiser continuar o suporte do projeto. Em particular, o projeto DEVE ser capaz de criar e fechar issues, aceitar mudanças propostas e lançar versões do software, dentro de uma semana após a confirmação da perda de suporte de qualquer indivíduo. Isso PODE ser feito garantindo que outra pessoa tenha quaisquer chaves, senhas e direitos legais necessários para continuar o projeto. Indivíduos que executam um projeto FLOSS PODEM fazer isso fornecendo chaves em um cofre e um testamento fornecendo quaisquer direitos legais necessários (por exemplo, para nomes DNS). (URL obrigatória) [access_continuity]

    The existing maintainer attests to organization backup access. Authenticated organization metadata confirms three organization owners; repositories and automated release workflows are organization-controlled, supporting continued issue, change and release management if one person becomes unavailable. Evidence: https://www.bestpractices.dev/en/projects/11697 https://github.com/orgs/netresearch/people https://github.com/netresearch/t3x-nr-llm/actions


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

    O projeto DEVERIA ter um "bus factor" 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.

    A bus factor of at least two has not been established by the available evidence. Organization-level backup access addresses access continuity but does not by itself establish that a second person has sufficient project knowledge to sustain maintenance. The current project document describes a solo-maintainer model. The former Dependabot reviewer assignment is no longer evidence because .github/dependabot.yml was removed. This answer does not infer personnel competence from commit counts. See https://github.com/netresearch/t3x-nr-llm/blob/21d17f3a29d6b99192535876376dc3e1d6bdc1b3/.github/SECURITY_CONTROLS.md#succession-planning and https://github.com/netresearch/t3x-nr-llm/pull/939. Current repository self-assessment: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/.bestpractices.json


  • Documentação


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

    O projeto DEVE ter um roadmap documentado que descreva o que o projeto pretende fazer e não fazer por pelo menos o próximo ano. (URL obrigatória) [documentation_roadmap]
    O projeto pode não alcançar o roadmap, e isso é aceitável; o objetivo do roadmap é ajudar usuários e contribuidores potenciais a entender a direção pretendida do projeto. Não precisa ser detalhado.

    ROADMAP.md is present, but the documented commitments and exclusions have not been established to cover at least the next full year. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/ROADMAP.md


    Suficiente para um badge!

    O projeto DEVE incluir documentação da arquitetura (também conhecida como design de alto nível) do software produzido pelo projeto. Se o projeto não produz software, selecione "não aplicável" (N/A). (URL obrigatória) [documentation_architecture]
    Uma arquitetura de software explica as estruturas fundamentais de um programa, ou seja, os principais componentes do programa, os relacionamentos entre eles e as principais propriedades desses componentes e relacionamentos.

    High-level architecture and component responsibilities are documented. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Documentation/Adr/Adr002FeatureServicesArchitecture.rst https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Documentation/Adr/Adr010ToolFunctionCallingDesign.rst https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Documentation/Adr/Adr013ThreeLevelConfigurationArchitecture.rst


    Suficiente para um badge!

    O projeto DEVE documentar o que o usuário pode e não pode esperar em termos de segurança do software produzido pelo projeto (seus "requisitos de segurança"). (URL obrigatória) [documentation_security]
    Estes são os requisitos de segurança que o software deve atender.

    SECURITY.md documents private vulnerability reporting, the response process and user security guidance. SECURITY_AUDIT.md documents current security boundaries, test-backed controls, limitations and scoped review outcomes; it explicitly separates the archived January 2026 self-audit from current assurance. See https://github.com/netresearch/t3x-nr-llm/blob/main/SECURITY.md and https://github.com/netresearch/t3x-nr-llm/blob/main/SECURITY_AUDIT.md. Current repository self-assessment: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/.bestpractices.json


    Suficiente para um badge!

    O projeto DEVE fornecer um guia de "início rápido" para novos usuários para ajudá-los a fazer algo rapidamente com o software. (URL obrigatória) [documentation_quick_start]
    A ideia é mostrar aos usuários como começar e fazer o software fazer qualquer coisa. Isso é extremamente importante para que potenciais usuários comecem.

    The overview and installation/usage instructions show how to obtain, configure and use the project. Project-specific security expectations are assessed separately. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/README.md https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Configuration/AGENTS.md https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Configuration/CLAUDE.md


    Insuficiente para um badge.

    O projeto DEVE fazer um esforço para manter a documentação consistente com a versão atual dos resultados do projeto (incluindo software produzido pelo projeto). Quaisquer defeitos de documentação conhecidos que a tornem inconsistente DEVEM ser corrigidos. Se a documentação estiver geralmente atualizada, mas erroneamente incluir algumas informações antigas que não são mais verdadeiras, trate isso apenas como um defeito, então rastreie e corrija como de costume. [documentation_current]
    A documentação PODE incluir informações sobre diferenças ou mudanças entre versões do software e/ou link para versões antigas da documentação. A intenção deste critério é que um esforço seja feito para manter a documentação consistente, não que a documentação deva ser perfeita.

    SECURITY.md still identifies 0.13.x as supported while the current published release is v0.38.0. The public support/EOL policy is inconsistent with the current release and needs correction. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/SECURITY.md https://github.com/netresearch/t3x-nr-llm/releases/tag/v0.38.0


    Suficiente para um badge!

    A página inicial do repositório do projeto e/ou site DEVE identificar e criar hiperlinks para quaisquer conquistas, incluindo este selo de melhores práticas, dentro de 48 horas do reconhecimento público de que a conquista foi alcançada. (URL obrigatória) [documentation_achievements]
    Uma conquista é qualquer conjunto de critérios externos que o projeto trabalhou especificamente para atender, incluindo alguns selos. Esta informação não precisa estar na página inicial do site do projeto. Um projeto usando o GitHub pode colocar conquistas na página inicial do repositório adicionando-as ao arquivo README.

    The repository front page hyperlinks its OpenSSF badge achievement/status. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/README.md


  • Acessibilidade e internacionalização


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

    O projeto (tanto os sites do projeto quanto os resultados do projeto) DEVERIA seguir as melhores práticas de acessibilidade para que pessoas com deficiências ainda possam participar do projeto e usar os resultados do projeto quando for razoável fazê-lo. [accessibility_best_practices]
    Para aplicações web, veja as Diretrizes de Acessibilidade para Conteúdo Web (WCAG 2.0) e seu documento de apoio Understanding WCAG 2.0; veja também informações de acessibilidade do W3C. Para aplicações GUI, considere usar as diretrizes de acessibilidade específicas do ambiente (como Gnome, KDE, XFCE, Android, iOS, Mac e Windows). Algumas aplicações TUI (por exemplo, programas `ncurses`) podem fazer certas coisas para se tornarem mais acessíveis (como a configuração `force-arrow-cursor` do `alpine`). A maioria das aplicações de linha de comando são bastante acessíveis como estão. Este critério é frequentemente N/A, por exemplo, para bibliotecas de programas. Aqui estão alguns exemplos de ações a tomar ou questões a considerar:
    • Forneça alternativas de texto para qualquer conteúdo não textual para que possa ser transformado em outras formas que as pessoas precisam, como letras grandes, braille, fala, símbolos ou linguagem mais simples (diretriz WCAG 2.0 1.1)
    • A cor não é usada como o único meio visual de transmitir informações, indicar uma ação, solicitar uma resposta ou distinguir um elemento visual. (diretriz WCAG 2.0 1.4.1)
    • A apresentação visual de texto e imagens de texto tem uma razão de contraste de pelo menos 4.5:1, exceto para texto grande, texto incidental e logotipos (diretriz WCAG 2.0 1.4.3)
    • Torne toda a funcionalidade disponível a partir de um teclado (diretriz WCAG 2.1)
    • Um projeto GUI ou baseado na web DEVERIA testar com pelo menos um leitor de tela nas plataformas de destino (por exemplo, NVDA, Jaws ou WindowEyes no Windows; VoiceOver no Mac & iOS; Orca no Linux/BSD; TalkBack no Android). Programas TUI PODEM trabalhar para reduzir o redesenho para evitar leitura redundante por leitores de tela.

    Documentation and use of the TYPO3 UI do not establish accessibility of all project sites and delivered features; no complete current accessibility assessment was verified. Evidence: https://github.com/netresearch/t3x-nr-llm


    Suficiente para um badge!

    O software produzido pelo projeto DEVERIA ser internacionalizado para permitir fácil localização para a cultura, região ou idioma do público-alvo. Se a internacionalização (i18n) não se aplicar (por exemplo, o software não gera texto destinado a usuários finais e não classifica texto legível por humanos), selecione "não aplicável" (N/A). [internationalization]
    Localização "refere-se à adaptação de um produto, aplicação ou conteúdo de documento para atender aos requisitos de idioma, cultura e outros de um mercado-alvo específico (um locale)". Internacionalização é o "projeto e desenvolvimento de um produto, aplicação ou conteúdo de documento que permite fácil localização para públicos-alvo que variam em cultura, região ou idioma". (Veja "Localization vs. Internationalization" do W3C.) O software atende a este critério simplesmente sendo internacionalizado. Nenhuma localização para outro idioma específico é necessária, pois uma vez que o software foi internacionalizado, é possível para outros trabalharem na localização.

    End-user labels are externalized into TYPO3 XLIFF language resources, allowing translation/localization through the framework. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Resources/Private/Language/de.locallang.xlf https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Resources/Private/Language/de.locallang_dashboard.xlf https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/Resources/Private/Language/de.locallang_mod.xlf


  • Outro


    Suficiente para um badge!

    Se os sites do projeto (site, repositório e URLs de download) armazenam 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). Se os sites do projeto não armazenam senhas para este propósito, selecione "não aplicável" (N/A). [sites_password_security]
    Observe que o uso do GitHub atende a este critério. Este critério aplica-se apenas a senhas usadas para autenticação de usuários externos nos sites do projeto (também conhecida como autenticação de entrada). Se os sites do projeto precisam fazer login em outros sites (também conhecida como autenticação de saída), eles podem precisar armazenar tokens de autorização para esse propósito de forma diferente (já que armazenar um hash seria inútil). Isso aplica o critério crypto_password_storage aos sites do projeto, semelhante a sites_https.

    Repository and release hosting use GitHub, explicitly recognized by this criterion as meeting password-storage requirements. Project documentation pages do not implement their own user-password login. Evidence: https://github.com/netresearch/t3x-nr-llm https://www.bestpractices.dev/en/criteria/1#sites_password_security


 Controle de Mudanças 1/1 ●

 Relatórios 2/3 ●

  • Processo de relato de bugs


    Suficiente para um badge!

    O projeto DEVE usar um rastreador de questões para rastrear questões individuais. [report_tracker]

    Public GitHub issues and pull requests provide an addressable, searchable discussion and bug-report archive. Private security reports use a separate channel. Evidence: https://github.com/netresearch/t3x-nr-llm/issues https://github.com/netresearch/t3x-nr-llm/pulls


  • Processo de relato de vulnerabilidades


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

    O projeto DEVE dar crédito ao(s) relator(es) de todos os relatórios de vulnerabilidade resolvidos nos últimos 12 meses, exceto para o(s) relator(es) que solicitarem anonimato. Se não houve vulnerabilidades resolvidas nos últimos 12 meses, selecione "não aplicável" (N/A). (URL obrigatória) [vulnerability_report_credit]

    The disclosure policy does not establish credit for every resolved vulnerability report in the last twelve months; the private report history is unavailable. Evidence: https://github.com/netresearch/t3x-nr-llm


    Suficiente para um badge!

    O projeto DEVE ter um processo documentado para responder a relatos de vulnerabilidades. (URL obrigatória) [vulnerability_response_process]
    Isso está fortemente relacionado a vulnerability_report_process, que exige que haja uma forma documentada de relatar vulnerabilidades. Também está relacionado a vulnerability_report_response, que exige resposta a relatos de vulnerabilidades dentro de um determinado prazo.

    The published policy describes coordinated reporting/handling and an initial response/assessment timeframe. Actual historical response performance is assessed separately. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/SECURITY.md


 Qualidade 19/19 ●

 Segurança 10/13 ●

 Análise 2/2 ●

  • Análise estática de código


    Suficiente para um badge!

    O projeto DEVE usar pelo menos uma ferramenta de análise estática com regras ou abordagens para procurar vulnerabilidades comuns na linguagem ou ambiente analisado, se houver pelo menos uma ferramenta FLOSS que possa implementar este critério na linguagem selecionada. [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'.

    PHP security analysis uses Opengrep through the shared security workflow invoked by checks.yml. PHPStan level 10 provides additional PHP type and architecture analysis. CodeQL analyzes GitHub Actions and JavaScript/TypeScript, not PHP. The current security-assurance document identifies the applicable checks and their required gate. This answer does not claim that Psalm, Trivy or every historical scanner is currently enforced. See https://github.com/netresearch/t3x-nr-llm/blob/main/.github/workflows/checks.yml, https://github.com/netresearch/t3x-nr-llm/blob/main/SECURITY_AUDIT.md and https://github.com/netresearch/t3x-nr-llm/blob/main/Build/phpstan/phpstan.neon. Evidence: https://github.com/netresearch/t3x-nr-llm/blob/31fb1ef86a00a5071b132f5faefc686a3accf08f/.bestpractices.json


  • Análise dinâmica de código


    Suficiente para um badge!

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

    The project itself contains PHP/JavaScript/TypeScript/shell/configuration source, not project-owned C/C++ or another memory-unsafe native implementation. Runtime dependencies do not change the language of project source. Evidence: https://github.com/netresearch/t3x-nr-llm/tree/31fb1ef86a00a5071b132f5faefc686a3accf08f/



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

Entrada de selo do projeto de propriedade de: Sebastian Mendel.
Entrada criada em 2026-01-05 22:00:46 UTC, última atualização em 2026-09-29 15:16:54 UTC. Selo de aprovação perdido pela última vez em 2026-09-29 15:16:54 UTC. Selo de aprovação alcançado pela última vez em 2026-01-08 20:13:05 UTC.