BadgeApp

Controle de Mudanças 1/1 ●

Versões anteriores

Criterion [maintenance_or_update]
Atendido

Não atendido

N/A

?

O projeto DEVE manter as versões mais antigas do produto mais frequentemente usadas ou fornecer um caminho de atualização para versões mais recentes. Se o caminho de atualização for difícil, o projeto DEVE documentar como realizar a atualização (por exemplo, as interfaces que mudaram e etapas sugeridas detalhadas para ajudar na atualização). ^{[maintenance_or_update]}

Pre-1.0 project distributed via npm with a single supported line; users upgrade with npm using CHANGELOG.md and semver guidance. No widely-used older versions currently require separate maintenance.

Análise 2/2 ●

Análise estática de código

Criterion [static_analysis_common_vulnerabilities]
Atendido

Não atendido

N/A

?

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

CodeQL static analysis with the javascript-typescript and actions query suites runs on every pull request and push to main, targeting common vulnerability classes such as injection, path traversal, and unsafe deserialization (results at https://github.com/ayleen/triss-coworker/security/code-scanning). In addition, ESLint enforces security-relevant rules with a zero-warning threshold in CI, gitleaks scans for leaked credentials, and lockfile gates run in the test workflow: https://github.com/ayleen/triss-coworker/blob/main/.github/workflows/test.yml
Análise dinâmica de código

Criterion [dynamic_analysis_unsafe]
Atendido

Não atendido

N/A

?

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.

Dynamic analysis runs on every push and pull request. The CI test workflow executes the full node --test suites, including the property-based fuzz suite test/fuzz.test.js (fast-check), which generates dynamic inputs for the SSRF address classifier and its literal parsers in src/net.js and checks the implementation against an independent reference oracle. Beyond unit tests, the release pipeline builds the standalone artifact twice from independent production installs and smokes it on Ubuntu and macOS (Node 22/24), and a pnpm consumer-install smoke test exercises the packed npm tarball end to end. All of these assert expected outcomes with node:assert (assertions enabled) and fail the build on any mismatch: https://github.com/ayleen/triss-coworker/blob/main/test/fuzz.test.js and https://github.com/ayleen/triss-coworker/blob/main/.github/workflows/test.yml

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

triss-coworker

Fundamentos 17/17 ●

Geral

Pré-requisitos

Conteúdo básico do site do projeto

Supervisão do projeto

Documentação

Acessibilidade e internacionalização

Outro

Controle de Mudanças 1/1 ●

Versões anteriores

Relatórios 3/3 ●

Processo de relato de bugs

Processo de relato de vulnerabilidades

Qualidade 19/19 ●

Padrões de codificação

Sistema de compilação funcional

Sistema de instalação

Componentes mantidos externamente

Conjunto de testes automatizados

Teste de novas funcionalidades

Sinalizadores de aviso

Segurança 13/13 ●

Conhecimento de desenvolvimento seguro

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

Lançamento seguro

Outras questões de segurança

Análise 2/2 ●

Análise estática de código

Análise dinâmica de código