haggle

Los proyectos que siguen las mejores prácticas a continuación pueden autocertificarse voluntariamente y demostrar que han obtenido una insignia de mejores prácticas de Open Source Security Foundation (OpenSSF).

No existe un conjunto de prácticas que pueda garantizar que el software nunca tendrá defectos o vulnerabilidades; incluso los métodos formales pueden fallar si las especificaciones o suposiciones son incorrectas. Tampoco existe ningún conjunto de prácticas que pueda garantizar que un proyecto mantenga una comunidad de desarrollo saludable y que funcione bien. Sin embargo, seguir las mejores prácticas puede ayudar a mejorar los resultados de los proyectos. Por ejemplo, algunas prácticas permiten la revisión por parte de múltiples personas antes del lanzamiento, lo que puede ayudar a encontrar vulnerabilidades técnicas que de otro modo serían difíciles de encontrar y ayudar a generar confianza y un deseo repetido de interacción entre desarrolladores de diferentes compañías. Para obtener una insignia, se deben cumplir todos los criterios DEBE y NO DEBE, se deben cumplir, así como todos los criterios DEBERÍAN deben cumplirse o ser justificados, y todos los criterios SUGERIDOS se pueden cumplir o incumplir (queremos que se consideren al menos). Si desea añadir texto como justificación mediante un comentario genérico, en lugar de ser un razonamiento de que la situación es aceptable, comience el bloque de texto con '//' seguido de un espacio. Los comentarios son bienvenidos a través del sitio de GitHub mediante "issues" o "pull requests". También hay una lista de correo electrónico para el tema principal.

Con mucho gusto proporcionaríamos la información en varios idiomas, sin embargo, si hay algún conflicto o inconsistencia entre las traducciones, la versión en inglés es la versión autorizada.
Si este es su proyecto, por favor muestre el estado de su insignia en la página de su proyecto. El estado de la insignia se ve así: El nivel de insignia para el proyecto 13582 es silver Aquí se explica cómo insertarla:
Puede mostrar el estado de su insignia insertando esto en su archivo markdown:
[![OpenSSF Best Practices](https://www.bestpractices.dev/projects/13582/badge)](https://www.bestpractices.dev/projects/13582)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/13582"><img src="https://www.bestpractices.dev/projects/13582/badge"></a>


Estos son los criterios de nivel Plata. También puede ver los criterios de nivel Básico o Oro.

Baseline Series: Nivel Base 1 Nivel Base 2 Nivel Base 3

        

 Fundamentos 17/17 ●

  • General

    Tenga en cuenta que otros proyectos pueden usar el mismo nombre.

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

    Por favor use formato de expresión de licencia SPDX; los ejemplos incluyen "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" y "(BSD-2-Clause OR Ruby)". No incluya comillas simples o comillas dobles.
    Si hay más de un lenguaje, enumérelos como valores separados por comas (los espacios son opcionales) y ordénelos de más a menos usado. Si hay una lista larga, por favor enumere al menos los tres primeros más comunes. Si no hay lenguaje (por ejemplo, este es un proyecto solo de documentación o solo de pruebas), use el carácter único "-". Por favor use una capitalización convencional para cada lenguaje, por ejemplo, "JavaScript".
    La Common Platform Enumeration (CPE) es un esquema de nomenclatura estructurado para sistemas de tecnología de la información, software y paquetes. Se utiliza en varios sistemas y bases de datos al reportar vulnerabilidades.

  • Prerrequisitos


    ¡Suficiente para una insignia!

    El proyecto DEBE lograr una insignia de nivel aprobado. [achieve_passing]

  • Contenido básico del sitio web del proyecto


    ¡Suficiente para una insignia!

    La información sobre cómo contribuir DEBE incluir los requisitos para contribuciones aceptables (por ejemplo, una referencia a cualquier estándar de codificación requerido). (URL requerida) [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).


  • Supervisión del proyecto


    Apenas suficiente para una insignia.

    El proyecto DEBERÍA tener un mecanismo legal donde todos los desarrolladores de cantidades no triviales de software del proyecto afirmen que están legalmente autorizados para hacer estas contribuciones. El enfoque más común y fácilmente implementado para hacer esto es usando un Certificado de Origen del Desarrollador (DCO), donde los usuarios agregan "signed-off-by" en sus commits y el proyecto enlaza al sitio web DCO. Sin embargo, esto PUEDE implementarse como un Acuerdo de Licencia de Contribuidor (CLA), u otro mecanismo legal. (URL requerida) [dco]
    El DCO es el mecanismo recomendado porque es fácil de implementar, se rastrea en el código fuente, y git soporta directamente una función "signed-off" usando "commit -s". Para ser más efectivo, es mejor si la documentación del proyecto explica qué significa "signed-off" para ese proyecto. Un CLA es un acuerdo legal que define los términos bajo los cuales las obras intelectuales han sido licenciadas a una organización o proyecto. Un acuerdo de asignación de contribuidor (CAA) es un acuerdo legal que transfiere derechos en una obra intelectual a otra parte; no se requiere que los proyectos tengan CAAs, ya que tener CAA aumenta el riesgo de que los contribuidores potenciales no contribuyan, especialmente si el receptor es una organización con fines de lucro. Los CLAs de Apache Software Foundation (la licencia de contribuidor individual y el CLA corporativo) son ejemplos de CLAs, para proyectos que determinan que los riesgos de estos tipos de CLAs para el proyecto son menores que sus beneficios.

    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 una insignia!

    El proyecto DEBE definir y documentar claramente su modelo de gobernanza del proyecto (la forma en que toma decisiones, incluyendo roles clave). (URL requerida) [governance]
    Necesita haber alguna forma bien establecida y documentada de tomar decisiones y resolver disputas. En proyectos pequeños, esto puede ser tan simple como "el propietario del proyecto y líder toma todas las decisiones finales". Hay varios modelos de gobernanza, incluyendo dictador benevolente y meritocracia formal; para más detalles, ver Modelos de gobernanza. Tanto los enfoques centralizados (por ejemplo, un solo mantenedor) como los descentralizados (por ejemplo, grupo de mantenedores) se han utilizado con éxito en proyectos. La información de gobernanza no necesita documentar la posibilidad de crear un fork del proyecto, ya que eso siempre es posible para proyectos 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 una insignia!

    El proyecto DEBE adoptar un código de conducta y publicarlo en una ubicación estándar. (URL requerida) [code_of_conduct]
    Los proyectos pueden ser capaces de mejorar la civilidad de su comunidad y establecer expectativas sobre la conducta aceptable adoptando un código de conducta. Esto puede ayudar a evitar problemas antes de que ocurran y hacer que el proyecto sea un lugar más acogedor para fomentar contribuciones. Esto debe enfocarse solo en el comportamiento dentro de la comunidad/lugar de trabajo del proyecto. Ejemplos de códigos de conducta son el código de conducta del kernel de Linux, el Código de Conducta del Pacto del Contribuidor, el Código de Conducta de Debian, el Código de Conducta de Ubuntu, el Código de Conducta de Fedora, el Código de Conducta de GNOME, el Código de Conducta de la Comunidad KDE, el Código de Conducta de la Comunidad Python, La Guía de Conducta de la Comunidad Ruby, y El Código de Conducta de 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 una insignia!

    El proyecto DEBE definir y documentar públicamente claramente los roles clave en el proyecto y sus responsabilidades, incluyendo cualquier tarea que esos roles deban realizar. DEBE quedar claro quién tiene qué rol(es), aunque esto podría no estar documentado de la misma manera. (URL requerida) [roles_responsibilities]
    La documentación para gobernanza y roles y responsabilidades puede estar en un solo 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 una insignia!

    El proyecto DEBE poder continuar con una interrupción mínima si cualquier persona muere, queda incapacitada o de otro modo no puede o no está dispuesta a continuar el soporte del proyecto. En particular, el proyecto DEBE poder crear y cerrar issues, aceptar cambios propuestos y lanzar versiones de software, dentro de una semana de confirmación de la pérdida de soporte de cualquier individuo. Esto PUEDE hacerse asegurando que alguien más tenga las claves, contraseñas y derechos legales necesarios para continuar el proyecto. Los individuos que ejecutan un proyecto FLOSS PUEDEN hacer esto proporcionando claves en una caja de seguridad y un testamento que proporcione los derechos legales necesarios (por ejemplo, para nombres DNS). (URL requerida) [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


    Apenas suficiente para una insignia.

    El proyecto DEBERÍA tener un "factor de autobús" de 2 o más. (URL requerida) [bus_factor]
    Un "factor de autobús" (también conocido como "factor de camión") es el número mínimo de miembros del proyecto que tienen que desaparecer repentinamente de un proyecto ("ser atropellados por un autobús") antes de que el proyecto se paralice debido a la falta de personal conocedor o competente. La herramienta truck-factor puede estimar esto para proyectos en GitHub. Para más información, ver 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.


  • Documentación


    ¡Suficiente para una insignia!

    El proyecto DEBE tener una hoja de ruta documentada que describa lo que el proyecto tiene la intención de hacer y no hacer durante al menos el próximo año. (URL requerida) [documentation_roadmap]
    Es posible que el proyecto no logre la hoja de ruta, y eso está bien; el propósito de la hoja de ruta es ayudar a los posibles usuarios y colaboradores a comprender la dirección prevista del proyecto. No necesita ser detallada.

    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 una insignia!

    El proyecto DEBE incluir documentación de la arquitectura (también conocida como diseño de alto nivel) del software producido por el proyecto. Si el proyecto no produce software, seleccione "no aplicable" (N/A). (URL requerida) [documentation_architecture]
    Una arquitectura de software explica las estructuras fundamentales de un programa, es decir, los componentes principales del programa, las relaciones entre ellos y las propiedades clave de estos componentes y relaciones.

    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 una insignia!

    El proyecto DEBE documentar lo que el usuario puede y no puede esperar en términos de seguridad del software producido por el proyecto (sus "requisitos de seguridad"). (URL requerida) [documentation_security]
    Estos son los requisitos de seguridad que el software tiene la intención de cumplir.

    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 una insignia!

    El proyecto DEBE proporcionar una guía de "inicio rápido" para nuevos usuarios para ayudarles a hacer algo rápidamente con el software. (URL requerida) [documentation_quick_start]
    La idea es mostrar a los usuarios cómo comenzar y hacer que el software haga algo. Esto es de importancia crítica para que los posibles usuarios puedan comenzar.

    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 una insignia!

    El proyecto DEBE hacer un esfuerzo para mantener la documentación consistente con la versión actual de los resultados del proyecto (incluido el software producido por el proyecto). Cualquier defecto de documentación conocido que lo haga inconsistente DEBE ser corregido. Si la documentación es generalmente actual, pero incluye erróneamente alguna información antigua que ya no es verdadera, simplemente trátelo como un defecto, luego rastree y corrija como de costumbre. [documentation_current]
    La documentación PUEDE incluir información sobre diferencias o cambios entre versiones del software y/o enlaces a versiones anteriores de la documentación. La intención de este criterio es que se haga un esfuerzo por mantener la documentación consistente, no que la documentación deba ser perfecta.

    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 una insignia!

    La página frontal del repositorio del proyecto y/o el sitio web DEBEN identificar e hipervincular cualquier logro, incluida esta insignia de mejores prácticas, dentro de las 48 horas del reconocimiento público de que el logro ha sido alcanzado. (URL requerida) [documentation_achievements]
    Un logro es cualquier conjunto de criterios externos que el proyecto ha trabajado específicamente para cumplir, incluidas algunas insignias. Esta información no necesita estar en la página frontal del sitio web del proyecto. Un proyecto que utiliza GitHub puede colocar los logros en la página frontal del repositorio agregándolos al archivo 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).


  • Accesibilidad e internacionalización


    ¡Suficiente para una insignia!

    El proyecto (tanto los sitios del proyecto como los resultados del proyecto) DEBERÍA seguir las mejores prácticas de accesibilidad para que las personas con discapacidades puedan participar en el proyecto y utilizar los resultados del proyecto cuando sea razonable hacerlo. [accessibility_best_practices]
    Para aplicaciones web, consulte las Pautas de Accesibilidad para el Contenido Web (WCAG 2.0) y su documento de apoyo Understanding WCAG 2.0; vea también información de accesibilidad de W3C. Para aplicaciones GUI, considere usar las pautas de accesibilidad específicas del entorno (como Gnome, KDE, XFCE, Android, iOS, Mac, y Windows). Algunas aplicaciones TUI (por ejemplo, programas `ncurses`) pueden hacer ciertas cosas para hacerse más accesibles (como la configuración `force-arrow-cursor` de `alpine`). La mayoría de las aplicaciones de línea de comandos son bastante accesibles tal como están. Este criterio es a menudo N/A, por ejemplo, para bibliotecas de programas. Aquí hay algunos ejemplos de acciones a tomar o problemas a considerar:
    • Proporcione alternativas de texto para cualquier contenido que no sea texto para que pueda transformarse en otras formas que las personas necesiten, como letra grande, braille, voz, símbolos o lenguaje más simple (pauta 1.1 de WCAG 2.0)
    • El color no se utiliza como el único medio visual de transmitir información, indicar una acción, solicitar una respuesta o distinguir un elemento visual. (pauta 1.4.1 de WCAG 2.0)
    • La presentación visual de texto e imágenes de texto tiene una relación de contraste de al menos 4.5:1, excepto para texto grande, texto incidental y logotipos (pauta 1.4.3 de WCAG 2.0)
    • Haga que toda la funcionalidad esté disponible desde un teclado (pauta 2.1 de WCAG)
    • Un proyecto basado en GUI o web DEBERÍA probar con al menos un lector de pantalla en las plataformas de destino (por ejemplo, NVDA, Jaws o WindowEyes en Windows; VoiceOver en Mac e iOS; Orca en Linux/BSD; TalkBack en Android). Los programas TUI PUEDEN trabajar para reducir el sobredibujo para evitar la lectura redundante por parte de los lectores de pantalla.

    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 una insignia!

    El software producido por el proyecto DEBERÍA estar internacionalizado para permitir una fácil localización para la cultura, región o idioma de la audiencia objetivo. Si la internacionalización (i18n) no aplica (por ejemplo, el software no genera texto destinado a usuarios finales y no ordena texto legible por humanos), seleccione "no aplicable" (N/A). [internationalization]
    La localización "se refiere a la adaptación de un producto, aplicación o contenido de documento para satisfacer los requisitos de idioma, cultura y otros de un mercado objetivo específico (una configuración regional)". La internacionalización es el "diseño y desarrollo de un producto, aplicación o contenido de documento que permite una fácil localización para audiencias objetivo que varían en cultura, región o idioma". (Vea "Localization vs. Internationalization" de W3C.) El software cumple con este criterio simplemente estando internacionalizado. No se requiere localización para otro idioma específico, ya que una vez que el software ha sido internacionalizado, es posible que otros trabajen en la localización.

    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.


  • Otro


    ¡Suficiente para una insignia!

    Si los sitios del proyecto (sitio web, repositorio y URLs de descarga) almacenan contraseñas para la autenticación de usuarios externos, las contraseñas DEBEN almacenarse como hashes iterados con un salt por usuario mediante el uso de un algoritmo de estiramiento de claves (iterado) (por ejemplo, Argon2id, Bcrypt, Scrypt o PBKDF2). Si los sitios del proyecto no almacenan contraseñas para este propósito, seleccione "no aplicable" (N/A). [sites_password_security]
    Tenga en cuenta que el uso de GitHub cumple con este criterio. Este criterio solo se aplica a las contraseñas utilizadas para la autenticación de usuarios externos en los sitios del proyecto (también conocida como autenticación entrante). Si los sitios del proyecto deben iniciar sesión en otros sitios (también conocida como autenticación saliente), es posible que necesiten almacenar tokens de autorización para ese propósito de manera diferente (ya que almacenar un hash sería inútil). Esto aplica el criterio crypto_password_storage a los sitios del proyecto, similar 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.


 Control de cambios 1/1 ●

  • Versiones anteriores


    ¡Suficiente para una insignia!

    El proyecto DEBE mantener las versiones antiguas más utilizadas del producto o proporcionar una ruta de actualización a versiones más nuevas. Si la ruta de actualización es difícil, el proyecto DEBE documentar cómo realizar la actualización (por ejemplo, las interfaces que han cambiado y los pasos detallados sugeridos para ayudar con la actualización). [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.


 Informes 3/3 ●

  • Proceso de reporte de errores


    ¡Suficiente para una insignia!

    El proyecto DEBE usar un sistema de seguimiento de incidencias para rastrear problemas individuales. [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.


  • Proceso de informe de vulnerabilidad


    ¡Suficiente para una insignia!

    El proyecto DEBE dar crédito al o a los reportadores de todos los informes de vulnerabilidades resueltos en los últimos 12 meses, excepto a los reportadores que soliciten anonimato. Si no ha habido vulnerabilidades resueltas en los últimos 12 meses, seleccione "no aplicable" (N/A). (URL requerida) [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 una insignia!

    El proyecto DEBE tener un proceso documentado para responder a los informes de vulnerabilidades. (URL requerida) [vulnerability_response_process]
    Esto está fuertemente relacionado con vulnerability_report_process, que requiere que haya una forma documentada de reportar vulnerabilidades. También está relacionado con vulnerability_report_response, que requiere respuesta a los informes de vulnerabilidades dentro de un cierto marco de tiempo.

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


 Calidad 19/19 ●

  • Estándares de codificación


    ¡Suficiente para una insignia!

    El proyecto DEBE identificar las guías de estilo de codificación específicas para los lenguajes principales que utiliza, y requerir que las contribuciones generalmente cumplan con ellas. (URL requerida) [coding_standards]
    En la mayoría de los casos esto se hace haciendo referencia a alguna o algunas guías de estilo existentes, posiblemente enumerando las diferencias. Estas guías de estilo pueden incluir formas de mejorar la legibilidad y formas de reducir la probabilidad de defectos (incluyendo vulnerabilidades). Muchos lenguajes de programación tienen una o más guías de estilo ampliamente utilizadas. Ejemplos de guías de estilo incluyen las guías de estilo de Google y SEI CERT Coding Standards.

    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 una insignia!

    El proyecto DEBE hacer cumplir automáticamente su o sus estilos de codificación seleccionados si existe al menos una herramienta FLOSS que pueda hacerlo en el o los lenguajes seleccionados. [coding_standards_enforced]
    Esto PUEDE implementarse usando herramientas de análisis estático y/o forzando el código a través de reformateadores de código. En muchos casos, la configuración de la herramienta está incluida en el repositorio del proyecto (ya que diferentes proyectos pueden elegir diferentes configuraciones). Los proyectos PUEDEN permitir excepciones de estilo (y típicamente lo harán); donde ocurran excepciones, DEBEN ser raras y documentadas en el código en sus ubicaciones, de modo que estas excepciones puedan ser revisadas y de modo que las herramientas puedan manejarlas automáticamente en el futuro. Ejemplos de tales herramientas incluyen ESLint (JavaScript), Rubocop (Ruby), y 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 construcción funcional


    ¡Suficiente para una insignia!

    Los sistemas de construcción para binarios nativos DEBEN honrar las variables (de entorno) del compilador y enlazador relevantes que se les pasen (por ejemplo, CC, CFLAGS, CXX, CXXFLAGS y LDFLAGS) y pasarlas a las invocaciones del compilador y enlazador. Un sistema de construcción PUEDE extenderlas con banderas adicionales; NO DEBE simplemente reemplazar los valores proporcionados con los suyos. Si no se están generando binarios nativos, seleccione "no aplicable" (N/A). [build_standard_variables]
    Debería ser fácil habilitar características especiales de construcción como Address Sanitizer (ASAN), o para cumplir con las mejores prácticas de fortificación de distribución (por ejemplo, activando fácilmente banderas del compilador para hacerlo).

    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 una insignia!

    El sistema de construcción e instalación DEBERÍA preservar la información de depuración si se solicita en las banderas relevantes (por ejemplo, no se usa "install -s"). Si no hay sistema de construcción o instalación (por ejemplo, bibliotecas JavaScript típicas), seleccione "no aplicable" (N/A). [build_preserve_debug]
    Por ejemplo, establecer CFLAGS (C) o CXXFLAGS (C++) debería crear la información de depuración relevante si se utilizan esos lenguajes, y no deberían eliminarse durante la instalación. La información de depuración es necesaria para soporte y análisis, y también es útil para medir la presencia de características de fortificación en los binarios 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 una insignia!

    El sistema de construcción para el software producido por el proyecto NO DEBE construir recursivamente subdirectorios si hay dependencias cruzadas en los subdirectorios. Si no hay sistema de construcción o instalación (por ejemplo, bibliotecas JavaScript típicas), seleccione "no aplicable" (N/A). [build_non_recursive]
    La información de dependencias internas del sistema de construcción del proyecto debe ser precisa, de lo contrario, los cambios en el proyecto pueden no construirse correctamente. Las construcciones incorrectas pueden conducir a defectos (incluyendo vulnerabilidades). Un error común en sistemas de construcción grandes es usar una "construcción recursiva" o "make recursivo", es decir, una jerarquía de subdirectorios que contienen archivos fuente, donde cada subdirectorio se construye independientemente. A menos que cada subdirectorio sea completamente independiente, esto es un error, porque la información de dependencias es incorrecta.

    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 una insignia!

    El proyecto DEBE poder repetir el proceso de generar información desde archivos fuente y obtener exactamente el mismo resultado bit por bit. Si no ocurre construcción (por ejemplo, lenguajes de scripting donde el código fuente se usa directamente en lugar de compilarse), seleccione "no aplicable" (N/A). [build_repeatable]
    Los usuarios de GCC y clang pueden encontrar útil la opción -frandom-seed; en algunos casos, esto puede resolverse forzando algún tipo de orden. Se pueden encontrar más sugerencias en el sitio de construcciones reproducibles.

    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 instalación


    ¡Suficiente para una insignia!

    El proyecto DEBE proporcionar una forma de instalar y desinstalar fácilmente el software producido por el proyecto usando una convención comúnmente utilizada. [installation_common]
    Los ejemplos incluyen usar un administrador de paquetes (a nivel del sistema o del lenguaje), "make install/uninstall" (soportando DESTDIR), un contenedor en un formato estándar, o una imagen de máquina virtual en un formato estándar. El proceso de instalación y desinstalación (por ejemplo, su empaquetado) PUEDE ser implementado por un tercero siempre que sea 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 una insignia!

    El sistema de instalación para usuarios finales DEBE honrar las convenciones estándar para seleccionar la ubicación donde se escriben los artefactos construidos en el momento de la instalación. Por ejemplo, si instala archivos en un sistema POSIX, DEBE honrar la variable de entorno DESTDIR. Si no hay sistema de instalación o no hay convención estándar, seleccione "no aplicable" (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 una insignia!

    El proyecto DEBE proporcionar una forma para que los potenciales desarrolladores instalen rápidamente todos los resultados del proyecto y el entorno de soporte necesario para realizar cambios, incluidas las pruebas y el entorno de pruebas. Esto DEBE realizarse utilizando una convención de uso común. [installation_development_quick]
    Esto PUEDE implementarse mediante un contenedor generado y/o script(s) de instalación. Las dependencias externas normalmente se instalarían invocando el/los gestor(es) de paquetes del sistema y/o del lenguaje, según 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 mantenidos externamente


    ¡Suficiente para una insignia!

    El proyecto DEBE enumerar las dependencias externas de manera procesable por computadora. (URL requerida) [external_dependencies]
    Normalmente esto se hace utilizando las convenciones del gestor de paquetes y/o sistema de construcción. Tenga en cuenta que esto ayuda 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 una insignia!

    Los proyectos DEBEN monitorear o verificar periódicamente sus dependencias externas (incluidas las copias de conveniencia) para detectar vulnerabilidades conocidas, y corregir las vulnerabilidades explotables o verificarlas como no explotables. [dependency_monitoring]
    Esto se puede hacer utilizando una herramienta de análisis de origen / verificación de dependencias / análisis de composición de software como Dependency-Check de OWASP, Nexus Auditor de Sonatype, Black Duck Software Composition Analysis de Synopsys, y Bundler-audit (para Ruby). Algunos gestores de paquetes incluyen mecanismos para hacer esto. Es aceptable si la vulnerabilidad de los componentes no puede ser explotada, pero este análisis es difícil y a veces es más fácil simplemente actualizar o corregir la 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 una insignia!

    El proyecto DEBE:
    1. facilitar la identificación y actualización de componentes reutilizados mantenidos externamente; o
    2. utilizar los componentes estándar proporcionados por el sistema o lenguaje de programación.
    Entonces, si se encuentra una vulnerabilidad en un componente reutilizado, será fácil actualizar ese componente. [updateable_reused_components]
    Una forma típica de cumplir este criterio es utilizar sistemas de gestión de paquetes del sistema y del lenguaje de programación. Muchos programas FLOSS se distribuyen con "bibliotecas de conveniencia" que son copias locales de bibliotecas estándar (posiblemente bifurcadas). En sí, eso está bien. Sin embargo, si el programa *debe* usar estas copias locales (bifurcadas), entonces actualizar las bibliotecas "estándar" como una actualización de seguridad dejará estas copias adicionales aún vulnerables. Esto es especialmente un problema para sistemas basados en la nube; si el proveedor de la nube actualiza sus bibliotecas "estándar" pero el programa no las usa, entonces las actualizaciones en realidad no ayudan. Vea, por ejemplo, "Chromium: Why it isn't in Fedora yet as a proper package" de 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 una insignia!

    El proyecto DEBERÍA evitar el uso de funciones y APIs obsoletas o en desuso cuando estén disponibles alternativas FLOSS en el conjunto de tecnología que utiliza (su "pila tecnológica") y para una supermayoría de los usuarios que el proyecto admite (para que los usuarios tengan acceso directo a la 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).


  • Suite de pruebas automatizadas


    ¡Suficiente para una insignia!

    Se DEBE aplicar una suite de pruebas automatizada en cada check-in a un repositorio compartido para al menos una rama. Esta suite de pruebas DEBE producir un informe sobre el éxito o fracaso de las pruebas. [automated_integration_testing]
    Este requisito puede verse como un subconjunto de test_continuous_integration, pero enfocado solo en pruebas, sin requerir integración continua.

    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 una insignia!

    El proyecto DEBE agregar pruebas de regresión a una suite de pruebas automatizada para al menos el 50% de los errores corregidos en los ú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 una insignia!

    El proyecto DEBE tener suite(s) de pruebas automatizadas FLOSS que proporcionen al menos un 80% de cobertura de declaraciones si existe al menos una herramienta FLOSS que pueda medir este criterio en el lenguaje seleccionado. [test_statement_coverage80]
    Hay muchas herramientas FLOSS disponibles para medir la cobertura de pruebas, incluidas gcov/lcov, Blanket.js, Istanbul, JCov y covr (R). Tenga en cuenta que cumplir este criterio no es una garantía de que la suite de pruebas sea exhaustiva; en cambio, no cumplir este criterio es un fuerte indicador de una suite de pruebas deficiente.

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


  • Pruebas de nueva funcionalidad


    ¡Suficiente para una insignia!

    El proyecto DEBE tener una política formal por escrito que establezca que cuando se agregue nueva funcionalidad importante, se DEBEN agregar pruebas para la nueva funcionalidad a una suite de pruebas 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 una insignia!

    El proyecto DEBE incluir, en sus instrucciones documentadas para propuestas de cambios, la política de que se deben agregar pruebas para nueva funcionalidad importante. [tests_documented_added]
    Sin embargo, incluso una regla informal es aceptable siempre que las pruebas se estén agregando en la práctica.

    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.


  • Banderas de advertencia


    ¡Suficiente para una insignia!

    Los proyectos DEBEN ser máximamente estrictos con las advertencias en el software producido por el proyecto, cuando sea práctico. [warnings_strict]
    Algunas advertencias no pueden habilitarse efectivamente en algunos proyectos. Lo que se necesita es evidencia de que el proyecto está esforzándose por habilitar marcas de advertencia donde pueda, de modo que los errores se detecten temprano.

    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.


 Seguridad 13/13 ●

  • Conocimiento de desarrollo seguro


    ¡Suficiente para una insignia!

    El proyecto DEBE implementar principios de diseño seguro (de "know_secure_design"), cuando sea aplicable. Si el proyecto no está produciendo software, seleccione "no aplicable" (N/A). [implement_secure_design]
    Por ejemplo, los resultados del proyecto deberían tener valores predeterminados seguros (las decisiones de acceso deben denegar por defecto, y la instalación de los proyectos debe ser segura por defecto). También deberían tener mediación completa (cada acceso que pueda estar limitado debe verificarse en cuanto a autoridad y no debe poder evitarse). Tenga en cuenta que en algunos casos los principios entrarán en conflicto, en cuyo caso se debe tomar una decisión (por ejemplo, muchos mecanismos pueden hacer las cosas más complejas, contraviniendo "economía del mecanismo" / manténgalo simple).

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


  • Use buenas prácticas criptográficas

    Tenga en cuenta que algunos programas de software no necesitan usar mecanismos criptográficos. Si su proyecto produce software que (1) incluye, activa o habilita funcionalidad de cifrado, y (2) podría ser liberado desde los Estados Unidos (EE.UU.) hacia fuera de los EE.UU. o a una persona que no sea ciudadana de los EE.UU., es posible que esté legalmente obligado a tomar algunos pasos adicionales. Típicamente esto solo implica enviar un correo electrónico. Para más información, consulte la sección de cifrado de Understanding Open Source Technology & US Export Controls.

    ¡Suficiente para una insignia!

    Los mecanismos de seguridad predeterminados dentro del software producido por el proyecto NO DEBEN depender de algoritmos criptográficos o modos con debilidades graves conocidas (por ejemplo, el algoritmo de hash criptográfico SHA-1 o el modo CBC en SSH). [crypto_weaknesses]
    Las preocupaciones sobre el modo CBC en SSH se discuten en 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 una insignia!

    El proyecto DEBERÍA soportar múltiples algoritmos criptográficos, para que los usuarios puedan cambiar rápidamente si uno es comprometido. Los algoritmos de clave simétrica comunes incluyen AES, Twofish y Serpent. Las alternativas de algoritmos criptográficos hash comunes incluyen SHA-2 (incluyendo SHA-224, SHA-256, SHA-384 y SHA-512) y 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 una insignia!

    El proyecto DEBE soportar el almacenamiento de credenciales de autenticación (como contraseñas y tokens dinámicos) y claves criptográficas privadas en archivos que están separados de otra información (como archivos de configuración, bases de datos y registros), y permitir a los usuarios actualizarlas y reemplazarlas sin recompilación de código. Si el proyecto nunca procesa credenciales de autenticación y claves criptográficas privadas, seleccione "no aplicable" (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 una insignia!

    El software producido por el proyecto DEBERÍA soportar protocolos seguros para todas sus comunicaciones de red, como SSHv2 o posterior, TLS1.2 o posterior (HTTPS), IPsec, SFTP y SNMPv3. Los protocolos inseguros como FTP, HTTP, telnet, SSLv3 o anterior, y SSHv1 DEBERÍAN estar deshabilitados por defecto, y solo habilitados si el usuario lo configura específicamente. Si el software producido por el proyecto no soporta comunicaciones de red, seleccione "no aplicable" (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 una insignia!

    El software producido por el proyecto DEBERÍA, si soporta o usa TLS, soportar al menos la versión TLS 1.2. Tenga en cuenta que el predecesor de TLS se llamaba SSL. Si el software no usa TLS, seleccione "no aplicable" (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 una insignia!

    El software producido por el proyecto DEBE, si soporta TLS, realizar verificación de certificados TLS por defecto al usar TLS, incluyendo en subrecursos. Si el software no usa TLS, seleccione "no aplicable" (N/A). [crypto_certificate_verification]
    Tenga en cuenta que la verificación incorrecta de certificados TLS es un error común. Para más información, consulte "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" por Martin Georgiev et al. y "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 una insignia!

    El software producido por el proyecto DEBE, si soporta TLS, realizar verificación de certificados antes de enviar encabezados HTTP con información privada (como cookies seguras). Si el software no usa TLS, seleccione "no aplicable" (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.


  • Lanzamiento seguro


    ¡Suficiente para una insignia!

    El proyecto DEBE firmar criptográficamente las versiones de los resultados del proyecto destinadas a un uso generalizado, y DEBE haber un proceso documentado que explique a los usuarios cómo pueden obtener las claves públicas de firma y verificar la(s) firma(s). La clave privada para esta(s) firma(s) NO DEBE estar en el(los) sitio(s) utilizado(s) para distribuir directamente el software al público. Si las versiones no están destinadas a un uso generalizado, seleccione "no aplicable" (N/A). [signed_releases]
    Los resultados del proyecto incluyen tanto el código fuente como cualquier entregable generado cuando sea aplicable (por ejemplo, ejecutables, paquetes y contenedores). Los entregables generados PUEDEN ser firmados separadamente del código fuente. Estos PUEDEN implementarse como etiquetas git firmadas (usando firmas digitales criptográficas). Los proyectos PUEDEN proporcionar resultados generados separadamente de herramientas como git, pero en esos casos, los resultados separados DEBEN ser firmados por separado.

    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 una insignia!

    Se SUGIERE que en el sistema de control de versiones, cada etiqueta de versión importante (una etiqueta que es parte de una versión mayor, versión menor, o corrige vulnerabilidades notificadas públicamente) sea firmada criptográficamente y verificable como se describe en 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).


  • Otros problemas de seguridad


    ¡Suficiente para una insignia!

    Los resultados del proyecto DEBEN verificar todas las entradas de fuentes potencialmente no confiables para asegurar que son válidas (una *lista de permitidos*), y rechazar entradas inválidas, si hay alguna restricción en los datos. [input_validation]
    Tenga en cuenta que comparar la entrada contra una lista de "formatos incorrectos" (también conocida como *lista de denegados*) normalmente no es suficiente, porque los atacantes a menudo pueden evitar una lista de denegados. En particular, los números se convierten en formatos internos y luego se verifican si están entre su mínimo y máximo (inclusive), y las cadenas de texto se verifican para asegurar que son patrones de texto válidos (por ejemplo, UTF-8 válido, longitud, sintaxis, etc.). Algunos datos pueden necesitar ser "cualquier cosa en absoluto" (por ejemplo, un cargador de archivos), pero estos típicamente serían 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 una insignia!

    Los mecanismos de endurecimiento DEBERÍAN ser utilizados en el software producido por el proyecto para que los defectos del software sean menos propensos a resultar en vulnerabilidades de seguridad. [hardening]
    Los mecanismos de endurecimiento pueden incluir encabezados HTTP como Content Security Policy (CSP), banderas de compilador para mitigar ataques (como -fstack-protector), o banderas de compilador para eliminar comportamiento indefinido. Para nuestros propósitos, el menor privilegio no se considera un mecanismo de endurecimiento (el menor privilegio es importante, pero 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 una insignia!

    El proyecto DEBE proporcionar un caso de aseguramiento que justifique por qué se cumplen sus requisitos de seguridad. El caso de aseguramiento DEBE incluir: una descripción del modelo de amenazas, una identificación clara de los límites de confianza, un argumento de que se han aplicado principios de diseño seguro, y un argumento de que se han contrarrestado las debilidades de seguridad de implementación comunes. (URL requerida) [assurance_case]
    Un caso de aseguramiento es "un cuerpo documentado de evidencia que proporciona un argumento convincente y válido de que un conjunto especificado de afirmaciones críticas con respecto a las propiedades de un sistema están adecuadamente justificadas para una aplicación dada en un entorno dado" ("Software Assurance Using Structured Assurance Case Models", Thomas Rhodes et al, NIST Interagency Report 7608). Los límites de confianza son límites donde los datos o la ejecución cambian su nivel de confianza, por ejemplo, los límites de un servidor en una aplicación web típica. Es común enumerar principios de diseño seguro (como Saltzer y Schroeder) y debilidades de seguridad de implementación comunes (como el top 10 de OWASP o el top 25 de CWE/SANS), y mostrar cómo se contrarresta cada uno. El caso de aseguramiento de BadgeApp puede ser un ejemplo útil. Esto está relacionado con 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álisis 2/2 ●

  • Análisis estático de código


    ¡Suficiente para una insignia!

    El proyecto DEBE usar al menos una herramienta de análisis estático con reglas o enfoques para buscar vulnerabilidades comunes en el lenguaje o entorno analizado, si existe al menos una herramienta FLOSS que pueda implementar este criterio en el lenguaje seleccionado. [static_analysis_common_vulnerabilities]
    Las herramientas de análisis estático que están diseñadas específicamente para buscar vulnerabilidades comunes tienen más probabilidades de encontrarlas. Dicho esto, usar cualquier herramienta estática típicamente ayudará a encontrar algunos problemas, por lo que estamos sugiriendo pero no requiriendo esto para el nivel de insignia '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álisis dinámico de código


    ¡Suficiente para una insignia!

    Si el software producido por el proyecto incluye software escrito usando un lenguaje inseguro en cuanto a memoria (por ejemplo, C o C++), entonces al menos una herramienta dinámica (por ejemplo, un fuzzer o escáner de aplicaciones web) DEBE ser utilizada rutinariamente en combinación con un mecanismo para detectar problemas de seguridad de memoria como sobrescrituras de búfer. Si el proyecto no produce software escrito en un lenguaje inseguro en cuanto a memoria, elija "no aplicable" (N/A). [dynamic_analysis_unsafe]
    Ejemplos de mecanismos para detectar problemas de seguridad de memoria incluyen Address Sanitizer (ASAN) (disponible en GCC y LLVM), Memory Sanitizer, y valgrind. Otras herramientas potencialmente utilizadas incluyen thread sanitizer y undefined behavior sanitizer. También funcionarían aserciones generalizadas.

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



Estos datos están disponibles bajo el Acuerdo de Licencia de Datos de la Comunidad – Permisivo, Versión 2.0 (CDLA-Permissive-2.0). Esto significa que un Destinatario de Datos puede compartir los Datos, con o sin modificaciones, siempre que el Destinatario de Datos ponga a disposición el texto de este acuerdo con los Datos compartidos. Por favor, acredite a NaanyaBiz y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: NaanyaBiz.
Entrada creada el 2026-07-12 09:21:52 UTC, última actualización el 2026-07-14 20:21:06 UTC. Última obtención de la insignia de nivel básico el 2026-07-12 09:34:54 UTC.