Libellus Potionis

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 base en la página de su proyecto. El estado de la insignia base se ve así: El nivel de insignia base para el proyecto 13480 es baseline-2 Aquí se explica cómo insertar la insignia base:
Puede mostrar el estado de su insignia base insertando esto en su archivo markdown:
[![OpenSSF Baseline](https://www.bestpractices.dev/projects/13480/baseline)](https://www.bestpractices.dev/projects/13480)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/13480"><img src="https://www.bestpractices.dev/projects/13480/baseline"></a>


Estos son los criterios de Nivel Base 3. Estos son los criterios de la versión v2026.02.19.

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

        

 Fundamentos

  • General

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

    Libellus Potionis is a privacy-first, free, open-source, ad-free alcohol-consumption tracker that helps users monitor, pace, and manage their drinking habits entirely offline. It needs no invasive device permissions — no camera, microphone, or location access — and works completely without network connectivity.

    Key features

    • Intelligent logging: predefine custom beverages or use internationally common presets, and log drinks instantly or retroactively with precise timestamp corrections.
    • Concurrent limit tracking: set three simultaneous boundaries — a daily limit (grams of pure alcohol), a rolling 7-day weekly limit (grams), and a maximum number of drinking days per week — with visual progress bars in real time.
    • Blood-alcohol (BAC) estimation: enter your body weight for a live BAC approximation based on the established Widmark formula.
    • Addiction-counseling reports: generate a clear, well-organized two-page PDF report designed for consultations and counseling appointments.
    • Data portability: export your complete dataset as a standard CSV file for external processing (e.g. in LibreOffice Calc), or create secure JSON backups to migrate data between devices.
    • Granular adjustments: customize your "day start" time so late-night drinks count toward the correct evening, and define custom evaluation start dates for clean restarts.

    A comprehensive User's Guide is fully accessible in-app. The app is available on F-Droid.

    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.

    Libellus Potionis is a privacy-first, offline, ad-free Android app for tracking, pacing, and managing alcohol consumption. It requests no network permission and no camera/microphone/location access; all data stays on the device in the app's private, sandboxed storage, encrypted at rest (AES-256-GCM via the Android Keystore), with an optional biometric lock. It is Free Software under GPL-3.0-or-later, developed openly on Codeberg and distributed through F-Droid. The project is deliberately maintained as a teaching-quality codebase: every source file carries a license header and KDoc, and a release gate (tools/release-check.sh) enforces documentation, version consistency, English-only source, and translation completeness. Quality is guarded by a broad automated test suite (JVM unit tests plus instrumented Room-migration, Compose-UI, and locale tests) and by Android Lint and Kotlin compiler warnings promoted to build-breaking errors.

 Controles 18/21 ●

  • Controles


    ¡Suficiente para una insignia!

    Cuando se asigna permisos a un trabajo en un pipeline de CI/CD, el código fuente o configuración DEBE asignar solo los privilegios mínimos necesarios para la actividad correspondiente. [OSPS-AC-04.02]
    Configure los pipelines de CI/CD del proyecto para asignar los permisos más bajos disponibles a usuarios y servicios por defecto, elevando los permisos solo cuando sea necesario para tareas específicas. En algunos sistemas de control de versiones, esto puede ser posible a nivel organizacional o de repositorio. Si no es posible, establezca los permisos en el nivel superior del pipeline.

    This control is conditional on the project operating a CI/CD pipeline in which jobs are assigned permissions, and the project operates none. No CI/CD system or pipeline is configured in the repository (no Woodpecker, Forgejo Actions, GitHub Actions, GitLab CI, or other automation), so there are no pipeline jobs that could be granted more than the minimum privileges; the precondition never occurs. Releases are built and published manually with Fastlane, run locally by the sole maintainer on a trusted checkout. Should a CI/CD pipeline be introduced later, it will be configured to assign the lowest available permissions by default and elevate only where a specific task requires it — tracked in the project roadmap, alongside the related OSPS-AC-04.01 and OSPS-BR-01.04.


    ¡Suficiente para una insignia!

    Los flujos de CI/CD que aceptan entradas de colaboradores de confianza DEBEN sanear y validar dichas entradas antes de utilizarlas en el flujo. [OSPS-BR-01.04]
    Los flujos de CI/CD deben sanear (entre comillas, escapar o salir en valores esperados) todas las entradas de colaboradores en ejecuciones explícitas de flujos de trabajo. Aunque los colaboradores son generalmente de confianza, las entradas manuales a un flujo de trabajo no pueden revisarse y podrían ser abusadas por una toma de control de cuenta o una amenaza interna.

    This control is conditional on the project operating CI/CD pipelines that accept trusted-collaborator input, and the project operates no CI/CD pipelines at all. No CI/CD system or pipeline is configured in the repository (no Woodpecker, Forgejo Actions, GitHub Actions, GitLab CI, or other automation), so there is no pipeline — and in particular none accepting manual collaborator/workflow input — whose input could require sanitizing or validation; the precondition never occurs. Releases are built and published manually with Fastlane, run locally by the sole maintainer on a trusted checkout. Should a CI/CD pipeline be introduced later, any collaborator or workflow inputs it accepts will be sanitized and validated before use, consistent with the related OSPS-BR-01.01/OSPS-BR-01.03 and OSPS-AC-04.01/OSPS-AC-04.02 (tracked in the project roadmap).


    ¡Suficiente para una insignia!

    Cuando se crea un lanzamiento oficial, todos los activos dentro de ese lanzamiento DEBEN estar claramente asociados con el identificador del lanzamiento u otro identificador único para el activo. [OSPS-BR-02.02]
    Asigne un identificador de versión único a cada activo de software producido por el proyecto, siguiendo una convención de nomenclatura o esquema de numeración consistente. Ejemplos incluyen SemVer, CalVer, o git commit id.

    Every user-facing release has a unique version identifier. The app carries a three-part versionName (MAJOR.MINOR.PATCH) and a strictly increasing integer versionCode, both defined in android/app/build.gradle.kts. CONTRIBUTING.md requires that the versionName, the top CHANGELOG.md entry, the README title, and the proguard-rules.pro header all carry the same version string and that versionCode increases by at least 1 each release; the tools/release-check.sh release gate enforces this consistency automatically. See https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#7-versioning--release-checklist


    ¡Suficiente para una insignia!

    El proyecto DEBE definir una política para gestionar secretos y credenciales utilizados por el proyecto. La política debe incluir directrices para almacenar, acceder y rotar secretos y credenciales. [OSPS-BR-07.02]
    Documente cómo se gestionan y utilizan los secretos y credenciales dentro del proyecto. Esto debe incluir detalles sobre cómo se almacenan los secretos (por ejemplo, utilizando una herramienta de gestión de secretos), cómo se controla el acceso y cómo se rotan o actualizan los secretos. Asegúrese de que la información sensible no esté codificada directamente en el código fuente ni almacenada en sistemas de control de versiones.

    SECURITY.md defines a "Secrets and credentials" policy — https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#secrets-and-credentials — enumerating the secrets used (release signing keystore, Google Play upload credentials, and the maintainer's OpenPGP signing key) with guidelines for storing them (never hard-coded or committed; git-ignored with structure-only templates; environment-variable injection), accessing them (held solely by the single maintainer on trusted machines, not shared), and rotating them (Play credential/tokens rotated at will; OpenPGP key rotated by publishing a new key; the long-lived Android app-signing key rotated only on suspected compromise via the distribution channel's key-rotation process; any exposed secret revoked and replaced before the next release).


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la integridad y autenticidad de los activos del lanzamiento. [OSPS-DO-03.01]
    Las instrucciones en el proyecto deben contener información sobre la tecnología utilizada, los comandos a ejecutar y la salida esperada. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    Releases are cryptographically signed with the maintainer's own Android app-signing key via reproducible builds; the private key is held only by the maintainer and is never stored on Codeberg, F-Droid, or any other distribution site. SECURITY.md ("Verifying releases") documents how users obtain the public key and verify a release: the F-Droid client verifies the signature automatically and the project's F-Droid metadata pins the allowed signing key; users can also compare the APK signing certificate SHA-256 fingerprint (7506f17184b31a2d67621305d190a73e497806b39f7d64463ff5dbc0afd8317b) via apksigner verify --print-certs, or reproduce the build and compare. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#verifying-releases


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE contener instrucciones para verificar la identidad esperada de la persona o proceso que crea el lanzamiento del software. [OSPS-DO-03.02]
    La identidad esperada puede estar en forma de IDs de clave utilizados para firmar, emisor e identidad de un certificado sigstore, u otras formas similares. Cuando sea posible, evite almacenar esta documentación en la misma ubicación que el pipeline de compilación y lanzamiento para evitar que una sola violación comprometa tanto el software como la documentación para verificar la integridad del software.

    Releases are cryptographically signed with the maintainer's own Android app-signing key via reproducible builds; the private key is held only by the maintainer and is never stored on Codeberg, F-Droid, or any other distribution site. SECURITY.md ("Verifying releases") documents how users obtain the public key and verify a release: the F-Droid client verifies the signature automatically and the project's F-Droid metadata pins the allowed signing key; users can also compare the APK signing certificate SHA-256 fingerprint (7506f17184b31a2d67621305d190a73e497806b39f7d64463ff5dbc0afd8317b) via apksigner verify --print-certs, or reproduce the build and compare. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#verifying-releases


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una declaración descriptiva sobre el alcance y la duración del soporte para cada lanzamiento. [OSPS-DO-04.01]
    Para comunicar el alcance y la duración del soporte para los activos de software lanzados del proyecto, el proyecto debe tener un archivo SUPPORT.md, una sección "Soporte" en SECURITY.md, u otra documentación que explique el ciclo de vida del soporte, incluyendo la duración esperada del soporte para cada lanzamiento, los tipos de soporte proporcionados (por ejemplo, corrección de errores, actualizaciones de seguridad), y cualquier política o procedimiento relevante para obtener soporte.

    SECURITY.md includes a "Support" section describing the scope and duration of support for each release — https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#support . The project is a single-maintainer rolling release in which only the latest version is supported; support consists of best-effort bug fixes and security updates shipped in new releases via F-Droid, with no back-porting; each release is supported until the next supersedes it; and support is obtained through the Codeberg issue tracker (or the vulnerability-reporting process for security issues).


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE proporcionar una declaración descriptiva sobre cuándo los lanzamientos o versiones ya no recibirán actualizaciones de seguridad. [OSPS-DO-05.01]
    Para comunicar el alcance y la duración del soporte para correcciones de seguridad, el proyecto debe tener un SUPPORT.md u otra documentación que explique la política del proyecto para actualizaciones de seguridad.

    The "Support" section of SECURITY.md states when versions stop receiving security updates — https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#support . A given version stops receiving security updates as soon as a newer release supersedes it, because security fixes are shipped in new releases rather than back-ported; if the project is discontinued this will be announced in the repository, after which no further security updates are provided.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE tener una política que establezca que los colaboradores de código sean revisados antes de otorgarles permisos elevados a recursos sensibles. [OSPS-GV-04.01]
    Publique una política exigible en la documentación del proyecto que requiera que los colaboradores de código sean revisados y aprobados antes de otorgarles permisos elevados a recursos sensibles, como aprobación de fusiones o acceso a secretos. Se recomienda que la verificación incluya establecer un linaje justificable de identidad, como confirmar la asociación del colaborador con una organización confiable conocida.

    docs/GOVERNANCE.md documents an enforceable policy that code collaborators are reviewed before being granted escalated permissions to sensitive resources — https://codeberg.org/godisch/potillus/src/branch/main/docs/GOVERNANCE.md#repository-access-and-account-security . Write/merge access to the canonical repository and access to release secrets or credentials are granted only after the maintainer has reviewed and approved the individual, considering their track record of contributions reviewed through the normal pull-request process, a justifiable lineage of identity, and the mandatory 2FA. Permissions are granted at the lowest level needed and escalated only as further need is demonstrated; until such a grant, all contributions go through pull requests merged only by the maintainer, so no contributor holds escalated permissions without this review.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, todos los activos de software compilados lanzados DEBEN ser entregados con una lista de materiales de software. [OSPS-QA-02.02]
    Se recomienda generar automáticamente SBOMs en el momento de la compilación utilizando una herramienta que haya sido verificada para precisión. Esto permite a los usuarios ingerir estos datos en un enfoque estandarizado junto con otros proyectos en su entorno.

    Every released version is delivered with a CycloneDX software bill of materials, one per platform. The Android build generates its SBOM alongside the release artifact — make release-android/make bundle run the cyclonedxDirectBom Gradle task, producing android/app/build/outputs/sbom/libellus-potionis-sbom.json, normalized to be byte-stable and staged as <id>_<code>android_sbom.json — and the iOS build generates an equivalent CycloneDX 1.6 SBOM from ios/PotillusKit/Package.resolved via tools/gen-ios-sbom.py, normalized by the same tools/sbom-normalize.py and staged as <id><code>_ios_sbom.json (make ios-sbom / make release-ios). Each published release on Codeberg is accompanied by the platform SBOM(s) as downloadable release assets: https://codeberg.org/godisch/potillus/releases . Attaching the SBOM is a documented step in the release checklist: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#7-versioning--release-checklist . Users can thus obtain a standardized, auto-generated SBOM for each release of either app.


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento que comprenda múltiples repositorios de código fuente, todos los subproyectos DEBEN aplicar requisitos de seguridad que sean tan estrictos o más estrictos que la base de código principal. [OSPS-QA-04.02]
    Cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento debe aplicar requisitos de seguridad según sea aplicable al estado e intención de la base de código respectiva. Además de seguir los requisitos correspondientes de la Línea Base OSPS, esto puede incluir requerir una revisión de seguridad, asegurar que esté libre de vulnerabilidades y asegurar que esté libre de problemas de seguridad conocidos.

    This control applies only to a release comprising multiple source code repositories, and Libellus Potionis is a single-repository project. The entire application is built from one canonical repository (https://codeberg.org/godisch/potillus), with no submodules, subprojects, or additional source repositories compiled into the release, so there are no subprojects that could need to enforce security requirements as strict as the primary codebase; the precondition never occurs. This is consistent with the single-repository answer given for the related OSPS-QA-04.01.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE documentar claramente cuándo y cómo se ejecutan las pruebas. [OSPS-QA-06.02]
    Agregue una sección a la documentación de contribución que explique cómo ejecutar las pruebas localmente y cómo ejecutar las pruebas en el pipeline de CI/CD. La documentación debe explicar qué están probando las pruebas y cómo interpretar los resultados.

    The project ships a substantial automated test suite, released as FLOSS under GPL-3.0-or-later in the same repository: JVM unit tests in android/app/src/test/ (domain, data, l10n, util, and ViewModel layers, plus LocaleSyncTest) and instrumented tests in android/app/src/androidTest/ (Room migration validation, Compose UI components, on-device locale formatting), using FLOSS test frameworks (JUnit, AndroidX/Compose testing). How to run the tests is documented in CONTRIBUTING.md §5 "Testing strategy" (./gradlew :app:test for unit tests, ./gradlew :app:connectedAndroidTest for instrumented tests) and §7. See https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#5-testing-strategy


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política que establezca que todos los cambios importantes al software producido por el proyecto deben agregar o actualizar las pruebas de la funcionalidad en una suite de pruebas automatizada. [OSPS-QA-06.03]
    Agregue una sección a la documentación de contribución que explique la política para agregar o actualizar pruebas. La política debe explicar qué constituye un cambio importante y qué pruebas deben agregarse o actualizarse.

    The project has a formal written policy mandating tests for new functionality. CONTRIBUTING.md §5 ("Test policy (mandatory)") states that as major new functionality is added, automated tests covering it MUST be added to the project's automated test suite as part of the same change, and that a change introducing significant new behavior without accompanying tests will not be merged. This is reinforced by the domain-layer coverage-floor rules in the same section. URL: https://codeberg.org/godisch/potillus/src/branch/main/CONTRIBUTING.md#5-testing-strategy


    No es suficiente para una insignia.

    Cuando se realiza un commit a la rama principal, el sistema de control de versiones del proyecto DEBE requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos. [OSPS-QA-07.01]
    Configure el sistema de control de versiones del proyecto para requerir al menos una aprobación humana no autora de los cambios antes de fusionarlos en la rama de lanzamiento o principal. Esto se puede lograr requiriendo que un pull request sea revisado y aprobado por al menos otro colaborador antes de que pueda fusionarse.

    The project currently has a single maintainer who authors and reviews all changes, so fewer than 50% of modifications are reviewed by a person other than the author. The review process and checklist are documented (CONTRIBUTING.md, "Code review requirements"); satisfying this criterion requires a second, independent reviewer. Tracked in docs/ROADMAP.md ("Working toward the OpenSSF gold badge").


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, el proyecto DEBE realizar un modelado de amenazas y análisis de superficie de ataque para comprender y protegerse contra ataques en rutas de código críticas, funciones e interacciones dentro del sistema. [OSPS-SA-03.02]
    El modelado de amenazas es una actividad donde el proyecto examina la base de código, procesos asociados e infraestructura, interfaces, componentes clave y "piensa como un hacker" y hace una lluvia de ideas sobre cómo el sistema puede ser vulnerado o comprometido. Cada amenaza identificada se enumera para que el proyecto pueda pensar en cómo evitar proactivamente o cerrar cualquier brecha/vulnerabilidad que pueda surgir. Asegúrese de que esto se actualice para nuevas características o cambios importantes.

    The project provides a security assurance case in docs/ASSURANCE_CASE.md (linked from SECURITY.md). It states the security requirements, describes the threat model (assets, in-scope adversaries/attacks, and explicit out-of-scope residual risks), identifies the trust boundaries (app sandbox, hardware-backed Keystore, FLAG_SECURE screen boundary, device/biometric authentication, the export boundary, and the absence of a network boundary), argues that secure design principles were applied (least privilege, secure defaults, economy of mechanism, defense in depth, fail-safe), and maps common implementation weakness classes to their countermeasures (injection, insecure storage, cryptography, input validation, network exposure, memory safety, tampering, and upgrade data integrity). URL: https://codeberg.org/godisch/potillus/src/branch/main/docs/ASSURANCE_CASE.md [assurance_case]


    No es suficiente para una insignia.

    Mientras esté activo, cualquier vulnerabilidad en los componentes de software que no afecte al proyecto DEBE ser contabilizada en un documento VEX, aumentando el informe de vulnerabilidad con detalles de no explotabilidad. [OSPS-VM-04.02]
    Establezca un feed VEX comunicando el estado de explotabilidad de vulnerabilidades conocidas, incluyendo detalles de evaluación o cualquier mitigación implementada que impida que el código vulnerable sea ejecutado.

    The project scans its dependencies with osv-scanner against the CycloneDX SBOM and triages findings — exploitable issues are fixed, and issues that do not affect this app are recorded as non-exploitable (SECURITY.md, "Dependency monitoring") — but this triage is not published as a VEX document. The project does not currently produce a VEX (Vulnerability Exploitability eXchange) feed communicating the exploitability status and non-exploitability justifications of known vulnerabilities in a standardized, machine-readable form, as this control requires.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política que defina un umbral para la remediación de hallazgos de SCA relacionados con vulnerabilidades y licencias. [OSPS-VM-05.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Análisis de Composición de Software (SCA) relacionados con vulnerabilidades y licencias. Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    The project applies a documented approach to remediating software-composition-analysis (SCA) findings for both vulnerabilities and licenses. Vulnerabilities: dependencies are scanned before each release with osv-scanner against the CycloneDX SBOM and triaged so that exploitable vulnerabilities are remediated (upgraded or mitigated) before release and non-exploitable ones are recorded — https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#dependency-monitoring . Licenses: every third-party dependency is verified to be under a license compatible with the project's GPL-3.0-or-later distribution and documented as such, so a dependency with an incompatible license is not shipped — https://codeberg.org/godisch/potillus/src/branch/main/COPYING.md . Together these define the remediation threshold for SCA findings.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política para abordar violaciones de SCA antes de cualquier lanzamiento. [OSPS-VM-05.02]
    Documente una política en el proyecto para abordar los resultados aplicables del Análisis de Composición de Software antes de cualquier lanzamiento, y agregue verificaciones de estado que comprueben el cumplimiento de esa política antes del lanzamiento.

    The project periodically checks its external dependencies for known vulnerabilities. As documented in SECURITY.md ("Dependency monitoring") and enforced by the CONTRIBUTING.md §7 release checklist, dependencies are scanned before each release with osv-scanner (a FLOSS scanner querying the OSV database) against the CycloneDX SBOM the build generates. Reported issues are triaged: exploitable vulnerabilities are fixed by upgrading or mitigating the affected dependency; non-exploitable ones are recorded as such. URL: https://codeberg.org/godisch/potillus/src/branch/main/SECURITY.md#dependency-monitoring


    No es suficiente para una insignia.

    Mientras esté activo, todos los cambios en la base de código del proyecto DEBEN ser automáticamente evaluados contra una política documentada para dependencias maliciosas y vulnerabilidades conocidas en dependencias, y luego bloqueados en caso de violaciones, excepto cuando se declaren y supriman como no explotables. [OSPS-VM-05.03]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Análisis de Composición de Software en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    This control requires all changes to be automatically evaluated against a documented policy for malicious and vulnerable dependencies and blocked on violation. The project scans dependencies with osv-scanner against the CycloneDX SBOM before each release and triages findings (SECURITY.md, "Dependency monitoring"), but that check is a manual pre-release step, not an automated per-change gate that blocks changes on violation. Without a CI pipeline enforcing it, changes are not automatically evaluated and blocked, so this control is not met. (Tracked in the project roadmap alongside the CI-based automated-blocking work.)


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una política que defina un umbral para la remediación de hallazgos de SAST. [OSPS-VM-06.01]
    Documente una política en el proyecto que defina un umbral para la remediación de hallazgos de Pruebas de Seguridad de Aplicaciones Estáticas (SAST). Incluya el proceso para identificar, priorizar y remediar estos hallazgos.

    Findings from static analysis cannot reach a release: Android Lint runs as a release gate with abortOnError = true and warningsAsErrors = true, so any reported issue breaks the build and must be fixed (or made an explicit, reviewable exception) before a release can be produced. Timely remediation is thus enforced by construction, and no exploitable medium-or-higher findings are currently outstanding. See https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts


    ¡Suficiente para una insignia!

    Mientras esté activo, todos los cambios en la base de código del proyecto DEBEN ser automáticamente evaluados contra una política documentada para debilidades de seguridad y bloqueados en caso de violaciones excepto cuando se declaren y supriman como no explotables. [OSPS-VM-06.02]
    Cree una verificación de estado en el sistema de control de versiones del proyecto que ejecute una herramienta de Pruebas de Seguridad de Aplicaciones Estáticas (SAST) en todos los cambios en la base de código. Requiera que la verificación de estado pase antes de que los cambios puedan fusionarse.

    Android Lint, a FLOSS static analysis tool that goes well beyond compiler warnings and safe-language modes (it analyzes code, resources, the manifest, API usage, correctness, performance, and security across hundreds of rules), is applied to every release as a build gate: android/app/build.gradle.kts configures lint { abortOnError = true; warningsAsErrors = true } and the release process runs ./gradlew lintDebug, so a release cannot be produced while Lint reports any issue. See https://codeberg.org/godisch/potillus/src/branch/main/android/app/build.gradle.kts



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 Martin A. Godisch y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Martin A. Godisch.
Entrada creada el 2026-07-04 04:21:04 UTC, última actualización el 2026-07-14 19:16:17 UTC. Última obtención de la insignia de nivel básico el 2026-07-04 08:45:54 UTC.