haggle

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

  • Geral

    Observe que outros projetos podem usar o mesmo nome.

    AGL Australia smart meter -> Home Assistant Energy dashboard (Claude-generated custom integration)

    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 distintivo de nível aprovado. [achieve_passing]

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

    CONTRIBUTING.md (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md) states the requirements for acceptable contributions: the mandatory dev loop (ruff lint/format, strict mypy, pytest, pre-commit) that CI re-runs and rejects failures on, enforced Conventional Commits with provenance trailers, a required PR checklist, and anonymisation rules for API fixtures. The referenced AGENTS.md carries the full coding-standard detail ("What NOT to Do", endpoint procedure).


  • Supervisão do projeto


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

    CONTRIBUTING.md contains an inbound=outbound licensing statement ("By contributing, you agree your work is licensed under the project's Apache-2.0 license") but no mechanism by which contributors assert they are legally authorized to make their contributions - there is no DCO sign-off requirement, no link to the Developer Certificate of Origin, and no CLA; commit history does not carry Signed-off-by trailers.


    Suficiente 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 governance model is documented plainly as single-maintainer: CONTRIBUTING.md (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md) states the single-maintainer model and the issue-first contribution process, .github/CODEOWNERS routes every change to the maintainer (* @naanyabiz), and SECURITY.md's risk-acceptance register states the key role explicitly: "the same person authors, triages, and accepts every exception in this project - self-acceptance is the operating model of a single-maintainer repository" (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md). AGENTS.md's "Human-approved boundary" section documents that every merge, tag, and release requires the maintainer's live decision.


    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 adopted the Contributor Covenant 2.1 as its code of conduct, posted at the standard location https://github.com/NaanyaBiz/haggle/blob/main/CODE_OF_CONDUCT.md. It states scope and enforcement and includes a private reporting contact (security@naanya.biz) with a 5-business-day acknowledgement commitment.


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

    The project publicly documents its role structure: .github/CODEOWNERS assigns ownership of everything to @naanyabiz, SECURITY.md states plainly that the same person authors, triages, releases, and accepts every exception ("self-acceptance is the operating model of a single-maintainer repository"), and AGENTS.md section Provenance enumerates every AI tool operating on the repo with its role and scope plus the human-approved boundary (merging, tagging, and releasing always require the maintainer). The committed conformance map (https://github.com/NaanyaBiz/haggle/blob/main/docs/compliance/conformance.md) records under CO-1 that all role functions collapse into the named owner, so it is unambiguous who holds which role.


    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 project documents a continuity and succession plan in SECURITY.md (section "Continuity and succession"): on the maintainer's death or permanent departure, ownership of the GitHub account/repository and the ed25519 release-signing key passes to next of kin per the maintainer's will, and a digital-legacy arrangement grants next of kin identity access to operate, wind down, or transfer the project. Risk-acceptance RA-04 records the residual (estate-administration latency; the living-incapacity gap). https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md


    Mal suficiente 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.

    The project has a bus factor of 1: a single maintainer authors, reviews, and releases everything. This is recorded openly as risk-acceptance RA-04 in SECURITY.md (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md), with the public Apache-2.0 licence, AGENTS.md as a succession document, and attested releases as the compensating controls.


  • Documentação


    Suficiente 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 documents the project's direction for roughly the next 12 months and its explicit non-goals (single-retailer AGL only; electricity and solar feed-in only; read-only Energy-dashboard import; no telemetry, device control, or portal scraping). https://github.com/NaanyaBiz/haggle/blob/main/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.

    docs/threat-model.md section 1 "System description" (https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md) documents the high-level design, including a core data-flow diagram (browser -> config flow -> AGL Auth0 -> coordinator/parser -> HA recorder -> diagnostics) and the trust boundaries between components. AGENTS.md's "Repo Map" (https://github.com/NaanyaBiz/haggle/blob/main/AGENTS.md) describes every major component (config_flow, coordinator, sensor, diagnostics, agl client/parser/pinning) with its role and relationships, and the "Energy Dashboard Contract" section documents the key statistics-interface properties.


    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.

    https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md documents what users can and cannot expect: the data handled and impact assessment, token storage (including the explicit statement that the OAuth refresh token is plaintext at rest on the HA host, with host-FDE guidance), warn-only TLS SPKI pin-mismatch behaviour, supported versions, and what is in/out of scope. The full per-boundary security requirements, data classification, and resilience targets are in the committed threat model, https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md (sections 2, 3 and 8).


    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 README's Install section (https://github.com/NaanyaBiz/haggle/blob/main/README.md) is a five-step quick start taking a new user from HACS install to a working configured integration, including the browser-based AGL login step, and is followed by an Energy-dashboard section telling users exactly which statistics to add; a full setup guide lives at docs/energy-dashboard.md.


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

    Documentation currency is enforced per-PR: AGENTS.md's "Documentation Checklist - Required on Every PR" mandates updating the CHANGELOG, repo map, API facts, and security docs with every code change (https://github.com/NaanyaBiz/haggle/blob/main/AGENTS.md). Known documentation defects are corrected when found - SECURITY.md's storage section explicitly retracts an earlier incorrect claim that HAOS encrypts data at rest, and a README version-rot defect was fixed by policy (no hardcoded version strings; a shields.io release badge instead).


    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 README (https://github.com/NaanyaBiz/haggle/blob/main/README.md) displays hyperlinked achievement badges at the top: the OpenSSF Best Practices badge (project 13582, linking to bestpractices.dev), the OpenSSF Scorecard badge (linking to the scorecard.dev viewer), and the latest-release badge. The Best Practices badge was added the same day the passing badge was earned (2026-07-12, PR #172).


  • Acessibilidade e internacionalização


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

    The project ships no user interface of its own: it is a headless Home Assistant integration whose config flow, sensors, and Energy-dashboard statistics are all rendered by Home Assistant's standard frontend (the integration contributes only strings.json/translations, no HTML/JS/frontend assets), and accessibility of that UI is owned upstream by Home Assistant. Project documentation is plain Markdown rendered by GitHub.


    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.

    User-facing text is externalized through Home Assistant's standard translation framework: custom_components/haggle/strings.json (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/strings.json) holds all config-flow, error, and entity strings, mirrored in translations/en.json - localizing to another language is a matter of adding a translations/<lang>.json file. Only English is currently provided.


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

    All project sites (repository, issue tracker, releases, security advisories) are hosted on GitHub, which handles external-user authentication and stores passwords per this criterion; the project operates no site of its own that stores passwords.


 Controle de Mudanças 1/1 ●

  • Versões anteriores


    Suficiente para um badge!

    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]

    SECURITY.md section Supported Versions states the latest tagged release on main is the only supported version, with upgrades surfaced to users automatically via HACS. The README's "Rollback / downgrade" section (https://github.com/NaanyaBiz/haggle/blob/main/README.md) documents that any prior release can be reinstalled via HACS, that config entries are downgrade-safe and statistics survive in both directions, and docs/releasing.md requires a recorded manual downgrade test with each stable release.


 Relatórios 3/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]

    The project tracks individual issues on the GitHub issue tracker at https://github.com/NaanyaBiz/haggle/issues, declared machine-readably in the integration manifest ("issue_tracker" in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/manifest.json) and in pyproject.toml project URLs. CONTRIBUTING.md requires an issue-first workflow and AGENTS.md defines a triaged label taxonomy (P1-P3 priority, sev:high/med/low, escaped) consumed by the release flow and quarterly delivery metrics.


  • Processo de relato de vulnerabilidades


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

    No vulnerability reports have been received or resolved in the last 12 months (the project is only a few months old); SECURITY.md's "Hall of Fame" section explicitly reads "(none yet - be the first.)". SECURITY.md commits to crediting reporters in release notes and the Hall of Fame unless anonymity is requested (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md). The one CVE fix in CHANGELOG (idna, dev-only lockfile) came via automated Dependabot monitoring, not an external report to this project.


    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.

    https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md documents the full response process: private reporting via GitHub Private Security Advisories or security@naanya.biz, acknowledgement within 5 business days, graduated response targets by severity (critical 72 h / high 7 days / moderate-low 30 days), a self-escalation forcing function honest about the single-maintainer bound, a coordinated-disclosure window (14 days), and the known-vulnerable-release procedure (GHSA advisory, superseding release, HACS delisting).


 Qualidade 19/19 ●

  • Padrões de codificação


    Suficiente para um badge!

    O projeto DEVE identificar os guias de estilo de codificação específicos para as linguagens primárias que utiliza, e exigir que as contribuições geralmente estejam em conformidade com eles. (URL obrigatória) [coding_standards]
    Na maioria dos casos, isso é feito referenciando algum(ns) guia(s) de estilo existente(s), possivelmente listando diferenças. Esses guias de estilo podem incluir maneiras de melhorar a legibilidade e maneiras de reduzir a probabilidade de defeitos (incluindo vulnerabilidades). Muitas linguagens de programação têm um ou mais guias de estilo amplamente utilizados. Exemplos de guias de estilo incluem guias de estilo do Google e Padrões de Codificação SEI CERT.

    CONTRIBUTING.md requires contributions to pass the documented dev loop - ruff check, ruff format, and strict mypy - before pushing (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md). The specific style configuration is committed in pyproject.toml ([tool.ruff] with 17 rule families, line-length 88, isort ordering; [tool.mypy] strict = true) (https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml), and .github/workflows/ci.yml enforces ruff check, ruff format --check, and mypy as part of a required PR status check.


    Suficiente para um badge!

    O projeto DEVE aplicar automaticamente seu(s) estilo(s) de codificação selecionado(s) se houver pelo menos uma ferramenta FLOSS que possa fazer isso na(s) linguagem(ns) selecionada(s). [coding_standards_enforced]
    Isso PODE ser implementado usando ferramenta(s) de análise estática e/ou forçando o código através de reformatadores de código. Em muitos casos, a configuração da ferramenta está incluída no repositório do projeto (já que projetos diferentes podem escolher configurações diferentes). Os projetos PODEM permitir exceções de estilo (e normalmente permitirão); onde ocorrem exceções, elas DEVEM ser raras e documentadas no código em suas localizações, para que essas exceções possam ser revisadas e para que as ferramentas possam tratá-las automaticamente no futuro. Exemplos de tais ferramentas incluem ESLint (JavaScript), Rubocop (Ruby) e devtools check (R).

    Coding style is enforced automatically by FLOSS tools: ruff lint, ruff format --check, and mypy run on every push and pull request in CI (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/ci.yml, steps at lines 41-48), and the containing 'Test (Python 3.14)' job is one of eight required status checks under the zero-bypass protect-main ruleset, so a style violation blocks merge. The selected style is committed in pyproject.toml ([tool.ruff]) and also enforced locally via pre-commit hooks.


  • Sistema de compilação funcional


    Suficiente para um badge!

    Os sistemas de compilação para binários nativos DEVEM honrar as variáveis de compilador e vinculador (ambiente) relevantes passadas para eles (por exemplo, CC, CFLAGS, CXX, CXXFLAGS e LDFLAGS) e passá-las para invocações de compilador e vinculador. Um sistema de compilação PODE estendê-las com flags adicionais; ele NÃO DEVE simplesmente substituir valores fornecidos pelos seus próprios. Se nenhum binário nativo estiver sendo gerado, selecione "não aplicável" (N/A). [build_standard_variables]
    Deve ser fácil habilitar recursos especiais de compilação como Address Sanitizer (ASAN), ou cumprir as melhores práticas de proteção de distribuição (por exemplo, ativando facilmente flags de compilador para fazê-lo).

    The project is a pure-Python Home Assistant custom integration: manifest.json declares "requirements": [] and the hatchling build backend produces no native binaries, so no compiler or linker is ever invoked and CC/CFLAGS-style variables have no referent.


    Suficiente para um badge!

    O sistema de compilação e instalação DEVERIA preservar informações de depuração se elas forem solicitadas nas flags relevantes (por exemplo, "install -s" não é usado). Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). [build_preserve_debug]
    Por exemplo, definir CFLAGS (C) ou CXXFLAGS (C++) deve criar as informações de depuração relevantes se essas linguagens forem usadas, e elas não devem ser removidas durante a instalação. Informações de depuração são necessárias para suporte e análise, e também úteis para medir a presença de recursos de proteção nos binários compilados.

    The release build (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/release.yml, "Build release artifact" step) zips the unmodified Python source of custom_components/haggle, excluding only pycache/.pyc; HACS installs that zip as-is. Nothing is stripped, minified, or compiled, so full source-level debugging information (readable source, tracebacks with line numbers) is always preserved in what users install.


    Suficiente para um badge!

    O sistema de compilação do software produzido pelo projeto NÃO DEVE compilar recursivamente subdiretórios se houver dependências cruzadas nos subdiretórios. Se não houver sistema de compilação ou instalação (por exemplo, bibliotecas JavaScript típicas), selecione "não aplicável" (N/A). [build_non_recursive]
    As informações de dependência interna do sistema de compilação do projeto precisam ser precisas, caso contrário, mudanças no projeto podem não compilar corretamente. Compilações incorretas podem levar a defeitos (incluindo vulnerabilidades). Um erro comum em sistemas de compilação grandes é usar uma "compilação recursiva" ou "make recursivo", isto é, uma hierarquia de subdiretórios contendo arquivos fonte, onde cada subdiretório é compilado independentemente. A menos que cada subdiretório seja totalmente independente, isso é um erro, porque as informações de dependência estão incorretas.

    The only build step is a single, flat packaging step in the release workflow: release.yml zips the contents of custom_components/haggle/ into haggle.zip in one command, then generates SBOMs and attestations from that artifact (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/release.yml). There are no subdirectory builds, no Makefile recursion, and no cross-directory build dependencies; the integration is pure Python with zero compiled components.


    Suficiente para um badge!

    O projeto DEVE ser capaz de repetir o processo de geração de informações a partir de arquivos fonte e obter exatamente o mesmo resultado bit a bit. 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). [build_repeatable]
    Usuários de GCC e clang podem achar útil a opção -frandom-seed; em alguns casos, isso pode ser resolvido forçando algum tipo de ordenação. Mais sugestões podem ser encontradas no site reproducible build.

    Not applicable: haggle is a pure-Python Home Assistant custom integration whose source is used directly - HACS extracts the release archive and Home Assistant imports the .py files unchanged, so there is no compilation or build step to reproduce bit-for-bit. The criterion explicitly permits N/A where source is used directly rather than compiled.


  • Sistema de instalação


    Suficiente para um badge!

    O projeto DEVE fornecer uma maneira de instalar e desinstalar facilmente o software produzido pelo projeto usando uma convenção comumente utilizada. [installation_common]
    Exemplos incluem usar um gerenciador de pacotes (no nível do sistema ou da linguagem), "make install/uninstall" (suportando DESTDIR), um contêiner em formato padrão, ou uma imagem de máquina virtual em formato padrão. O processo de instalação e desinstalação (por exemplo, seu empacotamento) PODE ser implementado por terceiros, desde que seja FLOSS.

    The integration is distributed via HACS (the Home Assistant community package manager) and is in the HACS default store; README section Install documents the install (HACS -> search Haggle -> Download -> restart) and section Removing documents uninstall via HA's Settings -> Devices & Services, including a best-effort revocation of the stored OAuth grant on removal (https://github.com/NaanyaBiz/haggle/blob/main/README.md). hacs.json configures the attested zip_release asset that HACS installs.


    Suficiente para um badge!

    O sistema de instalação para usuários finais DEVE honrar convenções padrão para selecionar o local onde os artefatos compilados são escritos no momento da instalação. Por exemplo, se instalar arquivos em um sistema POSIX, ele DEVE honrar a variável de ambiente DESTDIR. Se não houver sistema de instalação ou convenção padrão, selecione "não aplicável" (N/A). [installation_standard_variables]

    The installation system is HACS, which installs the integration into Home Assistant's standard custom_components/ location inside the user-chosen HA configuration directory - the platform's standard convention for install location (install and rollback steps documented at https://github.com/NaanyaBiz/haggle/blob/main/README.md#install). Nothing is compiled, so no DESTDIR-style build-time relocation applies to this artifact type; the install location follows the ecosystem convention exactly.


    Suficiente para um badge!

    O projeto DEVE fornecer uma maneira para desenvolvedores em potencial instalarem rapidamente todos os resultados do projeto e ambiente de suporte necessário para fazer alterações, incluindo os testes e ambiente de teste. Isso DEVE ser realizado com uma convenção comumente utilizada. [installation_development_quick]
    Isso PODE ser implementado usando um contêiner gerado e/ou script(s) de instalação. Dependências externas normalmente seriam instaladas invocando gerenciador(es) de pacotes do sistema e/ou da linguagem, conforme external_dependencies.

    CONTRIBUTING.md section Dev loop (https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md) documents a one-command setup - uv sync installs the complete dev and test environment from the hash-pinned uv.lock - followed by uv run pytest / ruff / mypy / pre-commit, matching what CI runs. A committed .devcontainer/devcontainer.json additionally provides a ready-made containerized dev environment with uv preinstalled.


  • Componentes mantidos externamente


    Suficiente para um badge!

    O projeto DEVE listar dependências externas de uma forma processável por computador. (URL obrigatória) [external_dependencies]
    Tipicamente isso é feito usando as convenções do gerenciador de pacotes e/ou sistema de compilação. Note que isso ajuda a implementar installation_development_quick.

    Runtime dependencies are declared machine-readably in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/manifest.json ("requirements": [] - the integration deliberately ships zero packages; everything it imports is vendored and pinned by Home Assistant core, as documented in SECURITY.md's supply-chain section). Development/test dependencies are declared in https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml and hash-pinned in uv.lock; Dependabot processes both the pip and github-actions ecosystems weekly.


    Suficiente para um badge!

    Os projetos DEVEM monitorar ou verificar periodicamente suas dependências externas (incluindo cópias de conveniência) para detectar vulnerabilidades conhecidas, e corrigir vulnerabilidades exploráveis ou verificá-las como não exploráveis. [dependency_monitoring]
    Isso pode ser feito usando uma ferramenta de análise de origem / ferramenta de verificação de dependências / ferramenta de análise de composição de software como OWASP's Dependency-Check, Sonatype's Nexus Auditor, Synopsys' Black Duck Software Composition Analysis e Bundler-audit (para Ruby). Alguns gerenciadores de pacotes incluem mecanismos para fazer isso. É aceitável se a vulnerabilidade dos componentes não puder ser explorada, mas esta análise é difícil e às vezes é mais fácil simplesmente atualizar ou corrigir a parte.

    Dependabot runs weekly on both the pip lockfile and github-actions ecosystems (https://github.com/NaanyaBiz/haggle/blob/main/.github/dependabot.yml), and every PR is gated by a required "Dependency review" check (actions/dependency-review-action, fail-on-severity: moderate, vulnerability-check: true) in ci.yml. SECURITY.md documents the triage ladder for alerts (critical 72 h / high 7 d / rest 30 d) and the exploitability analysis: manifest.json ships zero runtime requirements, so lockfile CVEs are dev/CI-only and are triaged on that recorded basis.


    Suficiente para um badge!

    "O projeto DEVE:
    1. facilitar a identificação e atualização de componentes mantidos externamente reutilizados; ou
    2. usar os componentes padrão fornecidos pelo sistema ou linguagem de programação.
    Então, se uma vulnerabilidade for encontrada em um componente reutilizado, será fácil atualizar esse componente." [updateable_reused_components]
    Uma maneira típica de atender a este critério é usar sistemas de gerenciamento de pacotes do sistema e da linguagem de programação. Muitos programas FLOSS são distribuídos com "bibliotecas de conveniência" que são cópias locais de bibliotecas padrão (possivelmente bifurcadas). Por si só, isso é bom. No entanto, se o programa *deve* usar essas cópias locais (bifurcadas), então atualizar as bibliotecas "padrão" como uma atualização de segurança deixará essas cópias adicionais ainda vulneráveis. Isso é especialmente um problema para sistemas baseados em nuvem; se o provedor de nuvem atualizar suas bibliotecas "padrão", mas o programa não as usar, então as atualizações na verdade não ajudam. Veja, por exemplo, "Chromium: Why it isn't in Fedora yet as a proper package" by Tom Callaway.

    The shipped integration reuses only components vendored and version-pinned by Home Assistant core - https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/manifest.json declares "requirements": [] - so users receive standard platform-provided components. Development dependencies are enumerated in pyproject.toml and hash-locked per artifact in uv.lock, and https://github.com/NaanyaBiz/haggle/blob/main/.github/dependabot.yml runs weekly grouped update PRs for both the pip and github-actions ecosystems.


    Suficiente para um badge!

    O projeto DEVERIA evitar usar funções e APIs obsoletas ou desatualizadas onde alternativas FLOSS estejam disponíveis no conjunto de tecnologia que usa (sua "pilha de tecnologia") e para uma supermaioria dos usuários que o projeto suporta (para que os usuários tenham acesso pronto à alternativa). [interfaces_current]

    Ruff's pyupgrade (UP), flake8-async (ASYNC), and bugbear (B) rule families are enabled in pyproject.toml and gate every PR, flagging obsolete Python idioms and deprecated patterns (https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml); pytest runs with filterwarnings = "error" so deprecation warnings from the project's own code fail the suite (upstream homeassistant DeprecationWarnings are the only scoped exception). A weekly compat workflow additionally runs the full suite against the latest Home Assistant releases including betas to catch upcoming upstream deprecations early (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/compat.yml).


  • Conjunto de testes automatizados


    Suficiente para um badge!

    Uma suíte de testes automatizada DEVE ser aplicada a cada check-in em um repositório compartilhado para pelo menos um branch. Esta suíte de testes DEVE produzir um relatório sobre sucesso ou falha do teste. [automated_integration_testing]
    Este requisito pode ser visto como um subconjunto de test_continuous_integration, mas focado apenas em testes, sem exigir integração contínua.

    The full automated test suite (pytest, with a combined line+branch coverage floor of 89% enforced via --cov-fail-under) runs on every push to main and every pull request via https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/ci.yml, producing a success/failure report as a GitHub check run on each commit; the check is required for merge by the protect-main ruleset.


    Suficiente para um badge!

    O projeto DEVE adicionar testes de regressão a uma suíte de testes automatizada para pelo menos 50% dos bugs corrigidos nos últimos seis meses. [regression_tests_added50]

    The committed test strategy (https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md) requires that every escaped defect gets a named, pinned regression test and lists the existing pins (e.g. test_uses_outer_consumption_quantity_not_inner_values, test_baseline_looked_up_at_earliest_fetched_hour, test_band_reachback_baseline_after_long_absence). Verified in git history: 14 of the 16 integration-code bug-fix commits in the last six months (~87%) included automated-test additions or changes in the same commit, well above the 50% threshold.


    Suficiente para um badge!

    O projeto DEVE ter suíte(s) de teste automatizada(s) FLOSS que forneçam pelo menos 80% de cobertura de instruções se houver pelo menos uma ferramenta FLOSS que possa medir este critério na linguagem selecionada. [test_statement_coverage80]
    Muitas ferramentas FLOSS estão disponíveis para medir cobertura de testes, incluindo gcov/lcov, Blanket.js, Istanbul, JCov e covr (R). Note que atender a este critério não é uma garantia de que a suíte de testes seja completa, em vez disso, falhar em atender a este critério é um forte indicador de uma suíte de testes pobre.

    The FLOSS test suite (pytest + coverage.py, ~254 tests including recorder-backed integration tests) is gated in CI at a combined line+branch coverage floor of 89% via --cov-fail-under=89 in https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/ci.yml, part of the required "Test (Python 3.14)" status check enforced by the zero-bypass protect-main ruleset. Current statement (line) coverage is 91.6% (local coverage.xml line-rate 0.9162; https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md records 90.0% combined at floor-setting time and defines the floor as an upward-only ratchet).


  • Teste de novas funcionalidades


    Suficiente para um badge!

    O projeto DEVE ter uma política escrita formal de que, à medida que uma nova funcionalidade importante é adicionada, testes para a nova funcionalidade DEVEM ser adicionados a uma suíte de testes automatizada. [test_policy_mandated]

    docs/testing.md (https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md) is the formal written test policy: its "Required depth per change type" section mandates automated tests for every functional change class (new endpoint => new fixture + parser tests; coordinator/statistics change => harness-integration tests, with real-recorder tests for sum-chain changes; every escaped defect => a named pinned regression test), enforced by the required CI check with a ratcheting coverage floor (--cov-fail-under=89). CONTRIBUTING.md and AGENTS.md's "Adding a New Endpoint" procedure repeat the tests-required rule for contributors.


    Suficiente para um badge!

    O projeto DEVE incluir, em suas instruções documentadas para propostas de mudança, a política de que testes devem ser adicionados para novas funcionalidades importantes. [tests_documented_added]
    Contudo, mesmo uma regra informal é aceitável desde que os testes estejam sendo adicionados na prática.

    https://github.com/NaanyaBiz/haggle/blob/main/CONTRIBUTING.md requires new-endpoint contributions to "Add an anonymised fixture, parser, client method, and tests", and https://github.com/NaanyaBiz/haggle/blob/main/docs/testing.md section "Required depth per change type" mandates the specific test layer for every class of change (new endpoint => new fixture + parser tests; cumulative-sum changes => recorder-backed tests in test_recorder_statistics.py; escaped defects => a named pinned regression test), enforced by CI's ratcheting 89% coverage floor.


  • Sinalizadores de aviso


    Suficiente para um badge!

    Os projetos DEVEM ser maximamente rigorosos com avisos no software produzido pelo projeto, onde for 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.

    Warnings are maximally strict and enforced in CI: mypy runs with strict = true plus warn_unreachable, warn_unused_ignores, and warn_redundant_casts; ruff enables 17 rule families including security (flake8-bandit), pylint, bugbear, and a max-complexity 12 gate; and pytest converts warnings to errors (filterwarnings = "error" with narrowly scoped upstream exceptions) - all configured in pyproject.toml (https://github.com/NaanyaBiz/haggle/blob/main/pyproject.toml) and run as part of the required "Test (Python 3.14)" PR check in .github/workflows/ci.yml.


 Segurança 13/13 ●

  • Conhecimento de desenvolvimento seguro


    Suficiente para um badge!

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

    Secure design principles are applied and documented per trust boundary in the committed threat model (https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md section 3): all untrusted AGL JSON passes allowlist parsing with numeric clamping to finite non-negative values (complete mediation / input validation, fuzz-enforced); least privilege governs OAuth scopes (read-only, with a documented re-assessment tripwire on any write scope) and CI tokens (read-only default, job-scoped writes); fail-safe defaults appear as fail-closed release gates (tag ancestry + signature verification) and a fail-closed secret-scanner self-test; secret exposure is minimised (memory-only 15-minute access token, rotate-on-use refresh token, hash-only fallback unique_id).


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

    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.

    All cryptographic mechanisms in the integration use SHA-256 or stronger: the OAuth PKCE challenge is S256 (config_flow.py), TLS pins are SHA-256 SPKI hashes (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py), diagnostics anonymisation is HMAC-SHA256 (diagnostics.py), and the fallback unique_id is a SHA-256 digest. A search of the integration code finds no MD5 or SHA-1 usage; TLS itself is provided by the host Python/aiohttp stack with modern defaults.


    Suficiente para um badge!

    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]

    All transport cryptography is delegated to the platform TLS stack (Python ssl/OpenSSL via aiohttp), which negotiates among multiple cipher suites and inherits new/updated algorithms from platform updates - the project hard-codes no protocol cryptography. The only project-level primitive is SHA-256, used for the Trust-On-First-Use SPKI pin comparison (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py) and a fallback hashed unique_id; the pin check is deliberately warn-only (SECURITY.md), so a break in that hash degrades a defence-in-depth signal without blocking traffic, and the algorithm is swappable in a single helper.


    Suficiente para um badge!

    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]

    The only credential the project processes is the user's own AGL OAuth refresh token, which is stored in Home Assistant's config-entry store (.storage/core.config_entries) - a data file entirely separate from the integration code - alongside the TOFU TLS pin hashes; SECURITY.md section Storage documents this (https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md). Credentials are replaced at any time via the standard HA Reconfigure/reauth flow with no code change (pure Python, nothing is compiled), and no credentials or keys are embedded in the source (enforced by the layered gitleaks scanning).


    Suficiente para um badge!

    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 communication is HTTPS: the only outbound endpoints are https://secure.agl.com.au and https://api.platform.agl.com.au, defined in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/const.py, with no plaintext-protocol code path. TLS is additionally hardened with Trust-On-First-Use SPKI pinning of both hosts (custom_components/haggle/agl/pinning.py; documented in SECURITY.md section Trust-On-First-Use TLS pinning).


    Suficiente para um badge!

    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]

    All upstream communication is HTTPS-only to secure.agl.com.au and api.platform.agl.com.au (const.py) via aiohttp on Python >=3.14, whose default TLS context negotiates a minimum of TLS 1.2 and supports TLS 1.3; no code in the repository lowers the TLS minimum or constructs a weakened SSL context. On top of transport TLS, both hosts are Trust-On-First-Use SPKI-pinned, with mismatches surfaced to the user (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py).


    Suficiente para um badge!

    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.

    All upstream communication is HTTPS via aiohttp, whose default TLS certificate verification is never disabled anywhere in the shipped code (no ssl=False, verify overrides, or CERT_NONE exist in custom_components/), and the integration additionally layers Trust-On-First-Use SPKI pinning of both AGL endpoints on top of standard verification (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py; behaviour documented in SECURITY.md, 'Trust-On-First-Use TLS pinning').


    Suficiente para um badge!

    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]

    All upstream endpoints are HTTPS (const.py: secure.agl.com.au, api.platform.agl.com.au) and every request goes through aiohttp with default certificate and hostname verification - no ssl=False, CERT_NONE, or check_hostname override exists anywhere in the tree - so verification completes during the TLS handshake before any HTTP headers carrying bearer tokens are sent. On top of WebPKI verification, a Trust-On-First-Use SHA-256 SPKI pin is checked on every new connection (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/pinning.py); the pin layer is warn-only by documented design, but standard certificate verification always applies.


  • Lançamento seguro


    Suficiente para um badge!

    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.

    Releases are cryptographically signed twice over: release tags are ed25519-SSH-signed by the maintainer's offline key and the release workflow refuses fail-closed any tag whose signature does not verify against the committed public key file https://github.com/NaanyaBiz/haggle/blob/main/.github/allowed_signers (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/release.yml, "Verify tag signature"); the installed artifact haggle.zip is Sigstore-attested via actions/attest-build-provenance with the .sigstore bundles and attested SPDX/CycloneDX SBOMs attached to every GitHub Release. The user verification process is documented in https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md (gh attestation verify haggle.zip --repo NaanyaBiz/haggle). No private key is on any distribution site - the tag key is held offline and Sigstore signing is keyless (ephemeral OIDC). Historical honesty: releases <= v0.4.0-beta.4 predate attestation and pre-2026-07-13 tags render Unverified, recorded as accepted risk RA-10; all releases from 2026-07 onward are signed and attested.


    Suficiente para um badge!

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

    Release tags are cryptographically signed: each v* tag is SSH-signed (ed25519) with the maintainer's release identity, whose public key is committed at .github/allowed_signers (https://github.com/NaanyaBiz/haggle/blob/main/.github/allowed_signers), and release.yml refuses fail-closed to build any tag whose signature does not verify against that file. I verified the latest tag (v0.4.0-beta.6) locally with git tag -v against the committed allowed_signers. Tags cut before 2026-07-13 predate the registered signing identity and are recorded as a historical exception (SECURITY.md RA-10).


  • Outras questões de segurança


    Suficiente para um badge!

    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.

    The untrusted input surface - AGL API JSON (attacker-influenceable, since TLS pin mismatch is warn-only by design) - is processed by allowlist-style parsers in https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/parser.py that are total over arbitrary JSON: only named fields are extracted (open-schema dict passthrough is prohibited in AGENTS.md), interval types are checked against a known set, and every numeric is clamped to a non-negative finite float via _safe_float before it can reach recorder statistics. The property is enforced by the atheris fuzz harness (tests/fuzz/fuzz_parser.py, a required PR check via fuzz.yml) and TestParserTotality in tests/test_parser.py.


    Suficiente para um badge!

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

    Multiple hardening layers make defects less likely to become vulnerabilities: both AGL endpoints are SPKI-pinned (TOFU) yet their JSON is still treated as attacker-influenceable - parsing is allowlist-style (no open-schema passthrough), numeric values are clamped through _safe_float so inf/NaN/negatives can never reach the recorder (https://github.com/NaanyaBiz/haggle/blob/main/custom_components/haggle/agl/parser.py), and the parser boundary is fuzz-tested with atheris on every PR plus a weekly deep run (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/fuzz.yml). Ruff's flake8-bandit security rules gate CI, diagnostics pass a scrub layer backed by leak tests, and upstream error bodies are stripped before exceptions propagate (docs/threat-model.md sections 2-3).


    Suficiente para um badge!

    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.

    The committed living threat model is the assurance case: it describes the system and threat model (an 18-threat STRIDE register, each threat tracked to a disposition with cited evidence), identifies five trust boundaries and the controls at each (https://github.com/NaanyaBiz/haggle/blob/main/docs/threat-model.md sections 1-5), and argues how secure design principles are applied and common implementation weaknesses countered (allowlist parsing, numeric clamping, fuzz-enforced parser totality, secret redaction backed by leak tests, plus CodeQL SAST and atheris fuzzing as required merge gates - https://github.com/NaanyaBiz/haggle/blob/main/SECURITY.md, 'Gating Policy'). The statement-level conformance map extends the argument control-by-control against the committed secure-SDLC standard (https://github.com/NaanyaBiz/haggle/blob/main/docs/compliance/conformance.md).


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

    CodeQL Python analysis runs weekly and on every PR (https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/codeql.yml) and is one of the eight required status checks enforced by the zero-bypass protect-main ruleset. CI additionally runs ruff with the flake8-bandit security rule set ("S") enabled in pyproject.toml on every PR, so two FLOSS vulnerability-oriented static analyzers gate every change.


  • 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 shipped software is written entirely in Python, a memory-safe managed language; the tree contains no C/C++/assembly and the integration declares zero compiled runtime requirements (manifest.json "requirements": []), so no memory-unsafe code exists to instrument. (Dynamic hostile-input testing runs regardless: atheris fuzzing of the parser trust boundary on every PR plus weekly deep runs, https://github.com/NaanyaBiz/haggle/blob/main/.github/workflows/fuzz.yml.)



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

Entrada de selo do projeto de propriedade de: NaanyaBiz.
Entrada criada em 2026-07-12 09:21:52 UTC, última atualização em 2026-07-14 20:21:06 UTC. Selo de aprovação alcançado pela última vez em 2026-07-12 09:34:54 UTC.