Astetik

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í:

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/15154/badge)](https://www.bestpractices.dev/projects/15154)

o insertando esto en su HTML:

<a href="https://www.bestpractices.dev/projects/15154"><img src="https://www.bestpractices.dev/projects/15154/badge"></a>

Estos son los criterios de nivel

. También puede ver los criterios de nivel

.

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

Control de cambios 1/1 ●

Versiones anteriores

Criterion [maintenance_or_update]
Cumplido

No cumplido

N/A

?

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

Migration describes retained argument mappings, breaking behavior, explicit preparation, result/export changes and preserving historical environments. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Reference/Migration.md

Análisis 2/2 ●

Análisis estático de código

Criterion [static_analysis_common_vulnerabilities]
Cumplido

No cumplido

N/A

?

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

Actual merged-master Python CodeQL run succeeded; its queries analyze security weakness classes. Required PR CodeQL is independently configured with no retained new findings. Evidence: https://github.com/autonomio/astetik/actions/runs/36969583672 https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/.github/workflows/pr_checks_codeql.yml https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/CLAUDE.md
Análisis dinámico de código

Criterion [dynamic_analysis_unsafe]
Cumplido

No cumplido

N/A

?

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.

This project owns Python/JavaScript source and does not produce memory-unsafe C/C++ modules. Third-party native scientific dependencies are separately maintained; no project-native sanitizer/fuzzer claim follows. Evidence: https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/pyproject.toml https://github.com/autonomio/astetik/blob/5db38b5fc054292a2dc3d6e592746f4815e23bf2/docs/Developer/Security-Assurance-Case.md

Puede utilizar herramientas y sistemas de IA para proponer cambios a través de una URL simple, como https://www.bestpractices.dev/es/projects/15154/choose/edit?osps_ac_01_01_status=Met&osps_ac_01_01_justification=GitHub+enforced. Consulte nuestro sistema de propuestas de automatización para saber cómo hacerlo. 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 Mikko Kotila y a los colaboradores de la insignia de Mejores Prácticas de OpenSSF.

Entrada de insignia del proyecto propiedad de: Mikko Kotila.
Entrada creada el 2026-10-02 06:55:56 UTC, última actualización el 2026-10-02 09:51:47 UTC. Última obtención de la insignia de nivel básico el 2026-10-02 09:07:57 UTC.

Astetik

Fundamentos 14/17 ●

General

Prerrequisitos

Contenido básico del sitio web del proyecto

Supervisión del proyecto

Documentación

Accesibilidad e internacionalización

Otro

Control de cambios 1/1 ●

Versiones anteriores

Informes 2/3 ●

Proceso de reporte de errores

Proceso de informe de vulnerabilidad

Calidad 19/19 ●

Estándares de codificación

Sistema de construcción funcional

Sistema de instalación

Componentes mantenidos externamente

Suite de pruebas automatizadas

Pruebas de nueva funcionalidad

Banderas de advertencia

Seguridad 11/13 ●

Conocimiento de desarrollo seguro

Use buenas prácticas criptográficas

Lanzamiento seguro

Otros problemas de seguridad

Análisis 2/2 ●

Análisis estático de código

Análisis dinámico de código