Cascavel

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 12255 es baseline-3 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/12255/baseline)](https://www.bestpractices.dev/projects/12255)
o insertando esto en su HTML:
<a href="https://www.bestpractices.dev/projects/12255"><img src="https://www.bestpractices.dev/projects/12255/baseline"></a>


Estos son los criterios de Nivel Base 1. Estos criterios son de la versión base v2025.10.10 con texto de criterios actualizado de la versión v2026.02.19. Los criterios que son nuevos en la versión v2026.02.19 están etiquetados como "futuros" y comenzarán a aplicarse a partir del 2026-06-01. Por favor, proporcione respuestas a los criterios "futuros" antes de esa fecha.

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

        

 Fundamentos

  • General

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

    Quantum Security Framework | 85 plugins | 30+ recon tools | Cinematic terminal UX | PDF/MD/JSON reports | CI/CD hardened | Red Team Intelligence Engine

    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.

 Controles 25/25 ●

  • Controles


    ¡Suficiente para una insignia!

    Cuando un usuario intenta leer o modificar un recurso sensible en el repositorio autorizado del proyecto, el sistema DEBE requerir que el usuario complete un proceso de autenticación multifactor. [OSPS-AC-01.01]
    Aplique la autenticación multifactor para el sistema de control de versiones del proyecto, requiriendo que los colaboradores proporcionen una segunda forma de autenticación al acceder a datos sensibles o modificar la configuración del repositorio. Las claves de acceso (passkeys) son aceptables para este control.

    GitHub requires 2FA for all organization members since March 2023. RET Tecnologia (rettecnologia.org), the company behind Cascavel, enforces Multi-Factor Authentication organization-wide for all contributors, including hardware key support.


    ¡Suficiente para una insignia!

    Cuando se agrega un nuevo colaborador, el sistema de control de versiones DEBE requerir asignación manual de permisos, o restringir los permisos del colaborador a los privilegios más bajos disponibles por defecto. [OSPS-AC-02.01]
    La mayoría de los sistemas de control de versiones públicos están configurados de esta manera. Asegúrese de que el sistema de control de versiones del proyecto siempre asigne los permisos más bajos disponibles a los colaboradores por defecto cuando se agreguen, otorgando permisos adicionales solo cuando sea necesario.

    GitHub assigns read-only permissions to new collaborators by default. RET Tecnologia follows the Principle of Least Privilege — elevated repository access is granted only after formal code review qualification and team lead approval.


    ¡Suficiente para una insignia!

    Cuando se intenta un commit directo en la rama principal del proyecto, un mecanismo de aplicación DEBE evitar que se aplique el cambio. [OSPS-AC-03.01]
    Si el VCS está centralizado, establezca protección de rama en la rama principal en el VCS del proyecto. Alternativamente, use un enfoque descentralizado, como el del kernel de Linux, donde los cambios se proponen primero en otro repositorio, y fusionar cambios en el repositorio principal requiere un acto separado específico.

    Branch protection rules on main require pull request reviews before merge. Direct commits blocked. GitHub Settings > Branches > Branch protection for main. https://github.com/glferreira-devsecops/Cascavel/settings/branches


    ¡Suficiente para una insignia!

    Cuando se intenta eliminar la rama principal del proyecto, el sistema de control de versiones DEBE tratar esto como una actividad sensible y requerir confirmación explícita de la intención. [OSPS-AC-03.02]
    Establezca protección de rama en la rama principal en el sistema de control de versiones del proyecto para evitar la eliminación.

    Branch protection on main prevents primary branch deletion. GitHub requires explicit admin confirmation. Force-push to main is also blocked to preserve commit history integrity.


    ¡Suficiente para una insignia!

    Cuando un pipeline de CI/CD acepta un parámetro de entrada, ese parámetro DEBE ser saneado y validado antes de usarse en el pipeline. [OSPS-BR-01.01]
    Los flujos de CI/CD deben sanear (entre comillas, escapar o salir en valores esperados) todas las entradas de metadatos que correspondan a fuentes no confiables. Esto incluye datos como nombres de ramas, mensajes de confirmación, etiquetas, títulos de solicitudes de incorporación e información del autor.

    All 5 CI/CD workflows (ci.yml, security.yml, codeql.yml, scorecard.yml, stale.yml) use pinned GitHub Actions with commit SHA hashes — never mutable tags. Top-level permissions: {} with explicit per-job permissions following OpenSSF Scorecard Token-Permissions check. https://github.com/glferreira-devsecops/Cascavel/tree/main/.github/workflows


    ¡Suficiente para una insignia!

    (Criterio futuro) Cuando un flujo de CI/CD opera sobre instantáneas de código no confiable, DEBE impedir el acceso a credenciales y activos privilegiados de CI/CD. [OSPS-BR-01.03]
    Los flujos de CI/CD deben aislar las instantáneas de código no confiable de las credenciales y activos privilegiados. En particular, los proyectos deben tener cuidado de garantizar que los flujos de trabajo que compilan o ejecutan código antes de su revisión por un colaborador no tengan acceso a las credenciales de CI/CD.

    Pull requests from forks run in isolated environments without access to repository secrets or GITHUB_TOKEN write permissions. Workflows use pull_request event (not pull_request_target) for code from external contributors.


    ¡Suficiente para una insignia!

    Cuando el proyecto lista un URI como un canal oficial del proyecto, ese URI DEBE ser entregado exclusivamente usando canales cifrados. [OSPS-BR-03.01]
    Configure los sitios web y sistemas de control de versiones del proyecto para usar canales cifrados como SSH o HTTPS para la transmisión de datos. Asegúrese de que todas las herramientas y dominios referenciados en la documentación del proyecto solo puedan accederse a través de canales cifrados.

    All project URIs use HTTPS exclusively: https://cascavel.pages.dev (project site with HSTS preload), https://github.com/glferreira-devsecops/Cascavel (repository), https://rettecnologia.org (RET Tecnologia corporate site). Zero HTTP endpoints.


    ¡Suficiente para una insignia!

    Cuando el proyecto lista una URI como un canal de distribución oficial, esa URI DEBE ser entregada exclusivamente usando canales cifrados. [OSPS-BR-03.02]
    Configure el pipeline de lanzamiento del proyecto para que solo obtenga datos de sitios web, respuestas de API y otros servicios que utilicen canales cifrados como SSH o HTTPS para la transmisión de datos.

    All distribution channels use HTTPS: GitHub releases served over HTTPS with TLS 1.3, pip install via PyPI over HTTPS, Cloudflare Pages with HSTS preload (max-age=63072000, includeSubDomains, preload). No plaintext HTTP distribution.


    ¡Suficiente para una insignia!

    El proyecto DEBE prevenir el almacenamiento no intencionado de datos sensibles no cifrados, como secretos y credenciales, en el sistema de control de versiones. [OSPS-BR-07.01]
    Configure .gitignore o equivalente para excluir archivos que puedan contener información sensible. Use hooks de pre-commit y herramientas de escaneo automatizado para detectar y prevenir la inclusión de datos sensibles en los commits.

    .gitignore excludes sensitive files (*.env, credentials, API keys, tokens, private keys). Gitleaks v8 integrated in CI/CD pipeline (security.yml) scans every commit and PR for leaked secrets using comprehensive regex rules. https://github.com/glferreira-devsecops/Cascavel/blob/main/.github/workflows/security.yml


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir guías de usuario para toda la funcionalidad básica. [OSPS-DO-01.01]
    Cree guías de usuario o documentación para toda la funcionalidad básica del proyecto, explicando cómo instalar, configurar y usar las características del proyecto. Si hay acciones peligrosas o destructivas disponibles, incluya advertencias altamente visibles.

    README.md (EN) and README.pt-BR.md (PT-BR) provide comprehensive documentation: installation guide (pip install), configuration, CLI arguments (--help), 85 plugin descriptions across 14 security categories, output formats (PDF/MD/JSON), architecture overview, and OSINT reconnaissance toolkit. Cascavel is an open-source product by RET Tecnologia — Engenharia de Software de Alta Performance. https://github.com/glferreira-devsecops/Cascavel/blob/main/README.md


    ¡Suficiente para una insignia!

    Cuando el proyecto haya realizado un lanzamiento, la documentación del proyecto DEBE incluir una guía para reportar defectos. [OSPS-DO-02.01]
    Se recomienda que los proyectos utilicen el gestor de incidencias predeterminado de su VCS. Si se utiliza una fuente externa, asegúrese de que la documentación del proyecto y la guía de contribución expliquen claramente y de manera visible cómo usar el sistema de reporte. Se recomienda que la documentación del proyecto también establezca expectativas sobre cómo se clasificarán y resolverán los defectos.

    SECURITY.md provides complete vulnerability and defect reporting procedures: private reporting via GitHub Security Advisories, email contact, coordinated disclosure timeline (90-day fix window), response SLA (48h initial response), and remediation process. https://github.com/glferreira-devsecops/Cascavel/blob/main/SECURITY.md


    ¡Suficiente para una insignia!

    Mientras esté activo, el proyecto DEBE tener uno o más mecanismos para discusiones públicas sobre cambios propuestos y obstáculos de uso. [OSPS-GV-02.01]
    Establezca uno o más mecanismos para discusiones públicas dentro del proyecto, como listas de correo, mensajería instantánea o gestores de incidencias, para facilitar la comunicación abierta y la retroalimentación.

    Multiple public communication channels: GitHub Issues (bug reports, feature requests), GitHub Discussions (usage questions, community), Pull Requests (proposed changes with code review). All publicly accessible, searchable, and indexed.


    ¡Suficiente para una insignia!

    Mientras esté activo, la documentación del proyecto DEBE incluir una explicación del proceso de contribución. [OSPS-GV-03.01]
    Cree un archivo CONTRIBUTING.md o un directorio CONTRIBUTING/ para delinear el proceso de contribución, incluyendo los pasos para enviar cambios e interactuar con los mantenedores del proyecto.

    CONTRIBUTING.md documents the full contribution process: fork workflow, branch naming conventions, commit message format, PR creation guidelines, code review requirements, CI/CD check requirements, and merge criteria. https://github.com/glferreira-devsecops/Cascavel/blob/main/CONTRIBUTING.md


    ¡Suficiente para una insignia!

    Mientras esté activo, la licencia para el código fuente DEBE cumplir con la Definición de Código Abierto de OSI o la Definición de Software Libre de FSF. [OSPS-LE-02.01]
    Agregue un archivo LICENSE al repositorio del proyecto con una licencia que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Liberar al dominio público cumple con este control si no hay otros gravámenes como patentes.

    MIT license — approved by the Open Source Initiative (OSI) and the Free Software Foundation (FSF). RET Tecnologia releases Cascavel as fully open-source software, enabling commercial and non-commercial use, modification, and distribution.


    ¡Suficiente para una insignia!

    Mientras esté activo, la licencia para los activos de software lanzados DEBE cumplir con la Definición de Código Abierto de OSI o la Definición de Software Libre de FSF. [OSPS-LE-02.02]
    Si se incluye una licencia diferente con los activos de software lanzados, asegúrese de que sea una licencia aprobada por la Open Source Initiative (OSI), o una licencia libre aprobada por la Free Software Foundation (FSF). Ejemplos de tales licencias incluyen MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), y la GNU General Public License (GPL). Tenga en cuenta que la licencia para los activos de software lanzados puede ser diferente a la del código fuente.

    All released software assets distributed under MIT license (OSI-approved). License consistent across all GitHub releases, source distributions, and repository archives. No proprietary components.


    ¡Suficiente para una insignia!

    Mientras esté activo, la licencia para el código fuente DEBE ser mantenida en el archivo LICENSE, archivo COPYING o directorio LICENSE/ del repositorio correspondiente. [OSPS-LE-03.01]
    Incluya la licencia del código fuente del proyecto en el archivo LICENSE, archivo COPYING o directorio LICENSE/ del proyecto para proporcionar visibilidad y claridad sobre los términos de licencia. El nombre de archivo PUEDE tener una extensión. Si el proyecto tiene múltiples repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

    LICENSE file maintained in repository root with complete MIT license text, including copyright holder (Gabriel Lima Ferreira / RET Tecnologia). https://github.com/glferreira-devsecops/Cascavel/blob/main/LICENSE


    ¡Suficiente para una insignia!

    Mientras esté activo, la licencia para los activos de software lanzados DEBE estar incluida en el código fuente lanzado, o en un archivo LICENSE, archivo COPYING o directorio LICENSE/ junto con los activos de lanzamiento correspondientes. [OSPS-LE-03.02]
    Incluya la licencia de los activos de software lanzados del proyecto en el código fuente lanzado, o en un archivo LICENSE, archivo COPYING o directorio LICENSE/ junto con los activos de lanzamiento correspondientes para proporcionar visibilidad y claridad sobre los términos de licencia. El nombre de archivo PUEDE tener una extensión. Si el proyecto tiene múltiples repositorios, asegúrese de que cada repositorio incluya el archivo de licencia.

    LICENSE file included in repository root and automatically part of all source code distributions. GitHub release archives (.zip, .tar.gz) include LICENSE. PyPI sdist includes LICENSE.


    ¡Suficiente para una insignia!

    Mientras esté activo, el repositorio de código fuente del proyecto DEBE ser legible públicamente en una URL estática. [OSPS-QA-01.01]
    Use un VCS común como GitHub, GitLab o Bitbucket. Asegúrese de que el repositorio sea legible públicamente. Evite la duplicación o creación de mirrors de repositorios a menos que la documentación altamente visible aclare la fuente principal. Evite cambios frecuentes en el repositorio que impactarían la URL del repositorio. Asegúrese de que el repositorio sea público.

    Public repository hosted on GitHub at stable, permanent URL: https://github.com/glferreira-devsecops/Cascavel — accessible worldwide without authentication.


    ¡Suficiente para una insignia!

    El sistema de control de versiones DEBE contener un registro legible públicamente de todos los cambios realizados, quién los realizó y cuándo se realizaron los cambios. [OSPS-QA-01.02]
    Use un VCS común como GitHub, GitLab o Bitbucket para mantener un historial de commits legible públicamente. Evite aplastar o reescribir commits de una manera que oscurecería al autor de cualquier commit.

    Full git commit history publicly readable on GitHub. All commits attributed to verified authors with GPG signatures, timestamps, and complete diff history. No force-pushes or history rewrites on main branch.


    ¡Suficiente para una insignia!

    Cuando el sistema de gestión de paquetes lo admita, el repositorio de código fuente DEBE contener una lista de dependencias que contabilice las dependencias directas del lenguaje. [OSPS-QA-02.01]
    Esto puede tomar la forma de un gestor de paquetes o un archivo de dependencias del lenguaje que enumere todas las dependencias directas como package.json, Gemfile o go.mod.

    requirements.txt contains all direct Python dependencies with pinned exact versions (e.g., requests==2.32.3, beautifulsoup4==4.12.3, reportlab==4.1.0). CI/CD validates dependency resolution on every build. https://github.com/glferreira-devsecops/Cascavel/blob/main/requirements.txt


    ¡Suficiente para una insignia!

    Mientras esté activa, la documentación del proyecto DEBE contener una lista de cualquier código base que se considere subproyecto. [OSPS-QA-04.01]
    Documente cualquier repositorio de código de subproyecto adicional producido por el proyecto y compilado en un lanzamiento. Esta documentación debe incluir el estado e intención de la respectiva base de código.

    Single-repository project. No additional codebases, subprojects, or federated components. All Cascavel source code, plugins (85), tests, CI/CD workflows, and documentation reside in one monorepo.


    ¡Suficiente para una insignia!

    Mientras esté activo, el sistema de control de versiones NO DEBE contener artefactos ejecutables generados. [OSPS-QA-05.01]
    Elimine los artefactos ejecutables generados en el sistema de control de versiones del proyecto. Se recomienda que cualquier escenario donde un artefacto ejecutable generado parezca crítico para un proceso como las pruebas, en su lugar debería generarse en el momento de la compilación o almacenarse por separado y obtenerse durante un paso de pipeline específico y bien documentado.

    No generated executable artifacts committed to VCS. .gitignore excludes compiled Python files (.pyc, .pyo, .pyd), distribution packages (dist/, build/, *.egg-info), and all build artifacts. Repository contains only source code.


    ¡Suficiente para una insignia!

    Mientras esté activo, el sistema de control de versiones NO DEBE contener artefactos binarios no revisables. [OSPS-QA-05.02]
    No agregue ningún artefacto binario no revisable al sistema de control de versiones del proyecto. Esto incluye binarios de aplicaciones ejecutables, archivos de biblioteca y artefactos similares. No incluye activos como imágenes gráficas, archivos de sonido o música y contenido similar que típicamente se almacena en formato binario.

    No unreviewable binary artifacts in repository. All content is human-reviewable: Python source code, markdown documentation, YAML CI/CD configuration, JSON test fixtures, and standard PNG images for documentation only.


    ¡Suficiente para una insignia!

    Mientras esté activa, la documentación del proyecto DEBE contener contactos de seguridad. [OSPS-VM-02.01]
    Cree un archivo security.md (o con nombre similar) que contenga contactos de seguridad para el proyecto.

    SECURITY.md contains security contacts (email + GitHub Security Advisories), detailed vulnerability reporting procedures, coordinated disclosure timeline, and response SLA. RET Tecnologia maintains a dedicated security response team. https://github.com/glferreira-devsecops/Cascavel/blob/main/SECURITY.md


    ¡Suficiente para una insignia!

    (Criterio obsoleto) Cuando un pipeline de CI/CD usa un nombre de rama en su funcionalidad, ese valor de nombre DEBE ser saneado y validado antes de usarse en el pipeline. [OSPS-BR-01.02]

    All CI/CD workflows use pinned actions with commit SHA hashes (dereferenced from annotated tags). No branch names, commit messages, PR titles, or any untrusted metadata interpolated into shell commands or workflow expressions.



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 Gabriel Lima Ferreira y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Gabriel Lima Ferreira.
Entrada creada el 2026-03-25 00:33:39 UTC, última actualización el 2026-03-25 05:06:47 UTC. Última obtención de la insignia de nivel básico el 2026-03-25 02:39:20 UTC.