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

URL: https://github.com/TheAbider/RackStack/blob/master/Changelog.md

Every release maintains backwards compatibility for defaults.json and the CLI action surface. Upgrade is in-place via Update-RackStack or by replacing the EXE. The auto-updater (-Action UpdateSelf) verifies SHA-256 before swapping the binary.

Segurança 13/13 ●

Conhecimento de desenvolvimento seguro

Criterion [implement_secure_design]
Atendido

Não atendido

N/A

?

O projeto DEVE implementar princípios de projeto seguro (de "know_secure_design"), quando aplicável. Se o projeto não está produzindo software, selecione "não aplicável" (N/A). ^{[implement_secure_design]}
Por exemplo, os resultados do projeto devem ter 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). Eles também devem ter mediação completa (todo acesso que possa ser limitado deve ser verificado quanto à autoridade e não ser contornável). Note que em alguns casos os princípios entrarão em conflito, caso em que uma escolha deve ser feita (por exemplo, muitos mecanismos podem tornar as coisas mais complexas, contrariando a "economia de mecanismo" / mantenha simples).

URL: https://github.com/TheAbider/RackStack/blob/master/SECURITY.md

Secure design principles applied: least privilege (top-level permissions: read-all in CI workflows with per-job grants); defense-in-depth (PSSA + CodeQL + gitleaks + Scorecard + Pester fuzz); fail-safe defaults (Confirm-UserAction defaults to "No"; destructive ops require typing the hostname); separation of mechanism and policy (defaults.json config separate from code); complete mediation (every CLI action goes through Assert-Elevation + ValidateSet); economy of mechanism (single dispatch table for CLI actions).
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.

Criterion [crypto_weaknesses]
Atendido

Não atendido

N/A

?

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

No SHA-1, no MD5 in security-sensitive paths.

Criterion [crypto_algorithm_agility]
Atendido

Não atendido

N/A

?

O projeto DEVERIA suportar múltiplos algoritmos criptográficos, para que os usuários possam mudar rapidamente se um for quebrado. Algoritmos de chave simétrica comuns incluem AES, Twofish e Serpent. Alternativas comuns de algoritmos de hash criptográfico incluem SHA-2 (incluindo SHA-224, SHA-256, SHA-384 E SHA-512) e SHA-3. ^{[crypto_algorithm_agility]}

SHA-256 for release hashes. New-StrongPassword uses .NET BCL System.Security.Cryptography which exposes SHA-1/2/3, AES, RSA, ECC — any algorithm change is a one-line swap. Sigstore cosign uses SHA-256 + ECDSA-P256 by default; configurable.

Criterion [crypto_credential_agility]
Atendido

Não atendido

N/A

?

O projeto DEVE suportar o armazenamento de credenciais de autenticação (como senhas e tokens dinâmicos) e chaves criptográficas privadas em arquivos que são separados de outras informações (como arquivos de configuração, bancos de dados e logs), e permitir que os usuários as atualizem e substituam sem recompilação de código. Se o projeto nunca processar credenciais de autenticação e chaves criptográficas privadas, selecione "não aplicável" (N/A). ^{[crypto_credential_agility]}

URL: https://github.com/TheAbider/RackStack/blob/master/defaults.example.json

defaults.json keeps Cloudflare Access ClientId/ClientSecret, KMS host keys, and AD credentials in a file separate from code, configuration, databases, and logs. Operators can update credentials without recompiling. Empty values disable the associated feature without source changes.

Criterion [crypto_used_network]
Atendido

Não atendido

N/A

?

O software produzido pelo projeto DEVERIA 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 DEVERIAM 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]}

All network communications use HTTPS: GitHub Releases (HTTPS), PowerShell Gallery (HTTPS), Cloudflare Access file server (HTTPS only — no fallback), GitHub Actions API (HTTPS). No FTP, no HTTP, no telnet, no SSHv1 anywhere.

Criterion [crypto_tls12]
Atendido

Não atendido

N/A

?

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

URL: https://github.com/TheAbider/RackStack/blob/master/RackStack.psm1

PowerShell module sets [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12 before any HTTPS call to avoid older defaults on Windows PowerShell 5.1.

Criterion [crypto_certificate_verification]
Atendido

Não atendido

N/A

?

O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado TLS por padrão ao usar TLS, incluindo em sub-recursos. Se o software não usar TLS, selecione "não aplicável" (N/A). ^{[crypto_certificate_verification]}
Observe que a verificação incorreta de certificado TLS é um erro comum. Para mais informações, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. e "Do you trust this application?" por Michael Catanzaro.

Default Invoke-RestMethod / Invoke-WebRequest verifies certificates. The codebase contains zero usages of -SkipCertificateCheck (audited).

Criterion [crypto_verification_private]
Atendido

Não atendido

N/A

?

O software produzido pelo projeto DEVE, se suportar TLS, realizar a verificação de certificado antes de enviar cabeçalhos HTTP com informações privadas (como cookies seguros). Se o software não usar TLS, selecione "não aplicável" (N/A). ^{[crypto_verification_private]}

Same — no certificate-skip flag anywhere. All HTTPS calls perform full verification before transmitting any auth header.
Lançamento seguro
Criterion [signed_releases]
Atendido

Não atendido

N/A

?

O projeto DEVE assinar criptograficamente os lançamentos dos resultados do projeto destinados ao uso generalizado, e DEVE haver um processo documentado explicando aos usuários como eles podem obter as chaves públicas de assinatura e verificar a(s) assinatura(s). A chave privada para essa(s) assinatura(s) NÃO DEVE estar em site(s) usado(s) para distribuir diretamente o software ao público. Se os lançamentos não forem destinados ao uso generalizado, selecione "não aplicável" (N/A). ^{[signed_releases]}
Os resultados do projeto incluem tanto o código-fonte quanto quaisquer entregáveis gerados quando aplicável (por exemplo, executáveis, pacotes e contêineres). Os entregáveis gerados PODEM ser assinados separadamente do código-fonte. Estes PODEM ser implementados como tags git assinadas (usando assinaturas digitais criptográficas). Os projetos PODEM fornecer resultados gerados separadamente de ferramentas como git, mas nesses casos, os resultados separados DEVEM ser assinados separadamente.
URL: https://github.com/TheAbider/RackStack/releases/latest
Every release artifact (RackStack.exe, monolithic .ps1, release-hashes.txt) is signed via Sigstore cosign keyless OIDC. The matching .sig (signature) and .pem (Fulcio-issued cert) files are attached to the release. Verification command documented in the release notes:

cosign verify-blob \ --certificate RackStack.exe.pem \ --signature RackStack.exe.sig \ --certificate-identity-regexp "^https://github.com/TheAbider/RackStack/.github/workflows/ci.yml@refs/heads/master$" \ --certificate-oidc-issuer https://token.actions.githubusercontent.com \ RackStack.exe

The private signing key is the GitHub Actions OIDC identity for this exact workflow run; Fulcio issues a short-lived cert valid only for that run. Rekor's public transparency log records every signature. Once SignPath
Criterion [version_tags_signed]
Atendido

Não atendido

?

É SUGERIDO que no sistema de controle de versão, cada tag de versão importante (uma tag que faz parte de um lançamento principal, lançamento menor ou corrige vulnerabilidades publicamente observadas) seja criptograficamente assinada e verificável conforme descrito em signed_releases. ^{[version_tags_signed]}

Currently tags are unsigned. The maintainer plans to enable GPG-signed commits and tags via git config --global commit.gpgsign true and git config --global tag.gpgsign true, with the GPG public key registered at https://github.com/TheAbider.gpg. This criterion will flip to Met within the same release as the GPG configuration.
Outras questões de segurança

Criterion [input_validation]
Atendido

Não atendido

N/A

?

Os resultados do projeto DEVEM verificar todas as entradas de fontes potencialmente não confiáveis para garantir que sejam válidas (uma *lista de permissões*), e rejeitar entradas inválidas, se houver quaisquer restrições sobre os dados. ^{[input_validation]}
Observe que comparar a entrada com uma lista de "formatos inválidos" (também conhecida como *lista de negação*) normalmente não é suficiente, porque os atacantes muitas vezes podem contornar uma lista de negação. Em particular, os números são convertidos em formatos internos e então verificados se estão entre o mínimo e o máximo (inclusive), e as strings de texto são verificadas para garantir que sejam padrões de texto válidos (por exemplo, UTF-8 válido, comprimento, sintaxe, etc.). Alguns dados podem precisar ser "qualquer coisa" (por exemplo, um carregador de arquivos), mas estes normalmente seriam raros.

URL: https://github.com/TheAbider/RackStack/blob/master/Modules/03-InputValidation.ps1

All operator-controlled input flows through allowlist validators: Test-ValidHostname (regex-based ASCII allowlist with NetBIOS length cap and null-byte rejection), Test-ValidIPAddress (parse + octet range), Test-ValidVLANId (integer range), Test-PasswordComplexity (per-class allowlist). CLI parameter validation uses [ValidateSet] for enums (Action, Tier, OutputFormat) and [ValidatePattern] for structured codes (RS-NNNN error codes). Configuration values are validated by Test-BatchConfig before any action runs.

Criterion [hardening]
Atendido

Não atendido

N/A

?

Mecanismos de proteção DEVERIAM ser usados no software produzido pelo projeto para que defeitos de software tenham menos probabilidade de resultar em vulnerabilidades de segurança. ^[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).

URL: https://github.com/TheAbider/RackStack/blob/master/PSScriptAnalyzerSettings.psd1

Same evidence as Silver: PSScriptAnalyzer ruleset, strict mode in tests, Test-Path -LiteralPath everywhere, atomic write-then-rename for operator-visible files, SLSA L3 + Sigstore cosign on every release, branch protection with required status checks.

Criterion [assurance_case]
Atendido

Não atendido

?

O projeto DEVE fornecer um caso de garantia que justifique por que seus requisitos de segurança são atendidos. O caso de garantia DEVE incluir: uma descrição do modelo de ameaças, identificação clara dos limites de confiança, um argumento de que os princípios de projeto seguro foram aplicados e um argumento de que fraquezas comuns de segurança na implementação foram combatidas. (URL obrigatória) ^{[assurance_case]}
Um caso de garantia é "um corpo documentado de evidências que fornece um argumento convincente e válido de que um conjunto específico de reivindicações críticas sobre as propriedades de um sistema são adequadamente justificadas para uma dada aplicação em um dado ambiente" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Limites de confiança são fronteiras onde os dados ou a execução muda seu nível de confiança, por exemplo, os limites de um servidor em uma aplicação web típica. É comum listar princípios de projeto seguro (como Saltzer e Schroeer) e fraquezas comuns de segurança na implementação (como o OWASP top 10 ou CWE/SANS top 25), e mostrar como cada um é combatido. O caso de garantia do BadgeApp pode ser um exemplo útil. Isso está relacionado a documentation_security, documentation_architecture e implement_secure_design.

URL: https://github.com/TheAbider/RackStack/blob/master/docs/ASSURANCE_CASE.md

ASSURANCE_CASE.md documents: (1) threat model — local-admin operator on a Windows Server, untrusted file-server downloads, network-attached SAN, multi-tenant Hyper-V VM trust boundaries; (2) trust boundaries — operator vs admin vs SYSTEM, EXE vs registry vs file-server; (3) secure-design principles applied (least privilege, defense-in-depth, fail-safe defaults, complete mediation, economy of mechanism); (4) common implementation weaknesses countered (command injection via metachar guards, path traversal via Test-Path -LiteralPath, TOCTOU via atomic operations, credential leaks via SecureString + BSTR cleanup + structured-log redaction).

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

PSSA covers PowerShell-specific issues; CodeQL with security-extended queries covers the JS embedded in github-script steps and the GitHub Actions workflows themselves.
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.

PowerShell is a memory-safe managed language running on .NET CLR. The project ships no C/C++ source; the only native dependency is ps2exe for compilation, which itself is managed code. Memory-safety dynamic analysis is not applicable.

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

RackStack

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