Algunos trucos para evaluar la seguridad de un proyecto de código abierto.

Existe una secta bastante progresista del mundo del desarrollo de software llamada comunidad de código abierto.

Esta comunidad cree que la mayoría de la gente sería mucho más feliz y haría mucho más trabajo si dejara de construir cosas que otra persona ya ha construido y ofrecido para su uso gratuito. Quieren que te quedes con sus cosas.

A comic I drew about using other people’s stuff, with the wheel as an example.

Además de existir sin que tengas que mover un dedo, las herramientas y el software de código abierto tienen algunas ventajas claras. Especialmente en el caso de proyectos bien establecidos, es muy probable que otra persona ya haya solucionado los errores más molestos por ti.

Gracias a la facilidad con la que los usuarios pueden ver y modificar el código base, también es más probable que un programa haya sido retocado, mejorado y asegurado a lo largo del tiempo.

Cuando muchos programadores contribuyen, aportan sus propios conocimientos y experiencias. Esto puede dar lugar a un producto mucho más sólido y capaz que el que puede crear un solo programador.

Por supuesto, al ser tan variados como las personas que los construyen, no todos los proyectos de código abierto son iguales, ni se mantienen con la misma seguridad.

Hay muchos factores que afectan a la idoneidad de un proyecto para su caso de uso. He aquí algunas consideraciones generales que constituyen el buen punto de partida a la hora de elegir un proyecto de código abierto.

Cómo elegir un proyecto de código abierto

Como requisitos fundamentales, un buen proyecto de software es confiable, fácil de entender, tiene componentes actualizados y seguridad. Hay varios indicadores que pueden ayudarte a realizar una valoración sobre si un proyecto de código abierto cumple con estos criterios.

Quiénes lo usan

Tomado en contexto, el número de personas que ya utilizan un proyecto de código abierto puede ser un indicador de su calidad.

Si un proyecto tiene cien usuarios, por ejemplo, es lógico que alguien haya intentado utilizarlo al menos cien veces antes de que tú lo encontraras. Así, según la antigua costumbre de "no sé qué hay en esa cueva, ve tú primero", es más que probable que esté bien.

Puedes sacar conclusiones sobre la base de usuarios de un proyecto mirando las estadísticas disponibles. Dependiendo de su plataforma, estas pueden incluir el número de descargas, revisiones, problemas o entradas, comentarios, contribuciones, forks o "estrellas", sean las que sean.

Evalúa las estadísticas sociales de plataformas como GitHub con un grano de sal. Pueden ayudarte a determinar la popularidad de un proyecto, pero solo de la misma manera que las aplicaciones de reseñas de restaurantes pueden ayudarte a saber si debes comer en Foo's Grill & Bar.

Dependiendo de dónde esté Foo's Grill & Bar, de cuándo haya abierto y de la probabilidad de que la gente esté cerca de él cuando le llame el inevitable antojo de carne, tener veintiséis críticas puede ser una buena señal o una terrible.

Aunque no se espera que un proyecto que aborda un caso de uso o una tecnología muy desconocida tenga cientos de usuarios, tener unos pocos usuarios activos es, en tal caso, un motivo de confianza.

La verificación externa también puede ser útil. Por ejemplo, los paquetes que se incluyen en una distribución del sistema operativo Linux (distro) deben ajustarse a normas estrictas y someterse a una verificación. Elegir un software incluido en los repositorios por defecto de una distribución puede significar que es más probable que sea seguro.

Tal vez uno de los mejores indicios para buscar es si el equipo de desarrollo de un proyecto está utilizando su propio proyecto. Busca problemas, discusiones o publicaciones en el blog que muestren que los creadores y encargados del mantenimiento del proyecto están utilizando lo que ellos mismos han construido. Lo que se conoce como "comer tu propia comida de perro" o "dogfooding", es un indicador de que el proyecto probablemente esté bien mantenido por sus desarrolladores.

Quiénes lo construyen

El principal enemigo del buen software de código abierto suele ser la falta de interés. Las partes implicadas en un proyecto de código abierto pueden marcar la diferencia entre una biblioteca de éxito inmediato y una utilidad respetada a largo plazo. Múltiples responsables comprometidos, incluso haciendo contribuciones en su tiempo libre, tienen una tasa de éxito mucho mayor para mantener un proyecto y generar interés.

Los proyectos que despiertan un gran interés suelen contar con el apoyo de una comunidad de colaboradores y usuarios, que a su vez los hace crecer.

Los nuevos colaboradores pueden ser aceptados activamente, hay guías claras que explican cómo ayudar, y los responsables del proyecto están disponibles y son accesibles cuando la gente tiene preguntas inevitables.

Algunas comunidades tienen incluso salas de chat o foros donde la gente puede interactuar al margen de las contribuciones. Las comunidades activas ayudan a mantener el interés, la relevancia y la calidad del proyecto.

De forma menos orgánica, un proyecto también puede sostenerse a través de organizaciones que lo patrocinan. Los gobiernos y las empresas con intereses financieros también son promotores del código abierto, y un proyecto que goza del uso del sector público o del respaldo financiero tiene un incentivo añadido para seguir siendo relevante y útil.

¿Qué tan vivo está?

La regularidad y la frecuencia de la actividad de un proyecto de código abierto es quizás el mejor indicador de la atención que probablemente se presta a su seguridad. Mira las publicaciones, el historial de confirmaciones, los registros de cambios o las revisiones de la documentación para determinar si un proyecto está activo. Dado que los proyectos varían en tamaño y alcance, a continuación se indican algunos aspectos generales en los que hay que fijarse.

El mantenimiento de la seguridad es un esfuerzo continuo que requiere un seguimiento y actualizaciones regulares, especialmente para los proyectos con componentes de terceros. Estos pueden ser bibliotecas o cualquier parte del proyecto que dependa de algo externo a él, como la integración de una pasarela de pago.

Es más probable que un proyecto inactivo tenga código obsoleto o utilice versiones obsoletas de componentes. Para una determinación más concreta, puedes investigar los componentes de terceros de un proyecto y comparar sus parches o actualizaciones más recientes con las últimas actualizaciones del proyecto.

Los proyectos sin componentes de terceros pueden no tener actualizaciones externas que aplicar. En estos casos, puedes utilizar la actividad reciente y las notas de publicación para determinar el grado de compromiso de los responsables de un proyecto.

Por lo general, los proyectos activos deberían mostrar actualizaciones en los últimos meses, con un lanzamiento notable en el último año. Esto puede ser una buena indicación de si el proyecto está utilizando una versión actualizada de su lenguaje o framework.

También se puede juzgar el grado de actividad de un proyecto observando a los propios encargados de su mantenimiento. Los encargados del mantenimiento activo responden rápidamente a los comentarios o a los nuevos problemas, aunque solo sea para decir: "Estamos en ello".

Si el proyecto tiene una comunidad, sus responsables forman parte de ella. Puede que tengan un sitio web dedicado o que escriban blogs con regularidad. Pueden ofrecer formas de contactar con ellos directamente y en privado, especialmente para plantear problemas de seguridad.

¿Puedes entenderlo?

Disponer de documentación es un requisito básico para un proyecto que está destinado a ser utilizado por cualquier persona, además de su creador. Los buenos proyectos de código abierto tienen una documentación fácil de seguir, honesta y completa.

Disponer de una documentación bien redactada es una de las formas en que un proyecto puede destacarse y demostrar la consideración y dedicación de sus responsables.

Una sección de "Primeros pasos" puede detallar todos los requisitos y la configuración inicial para ejecutar el proyecto. Una lista precisa de temas en la documentación permite a los usuarios encontrar rápidamente la información que necesitan. Una definición clara de la licencia no deja lugar a dudas sobre cómo se puede utilizar el proyecto y para qué fines.

Son aspectos característicos de la documentación que está al servicio de sus usuarios.

Un proyecto que sigue buenas prácticas de codificación probablemente tenga un código tan legible como su documentación. El código que es fácil de leer se presta a ser entendido. Por lo general, tiene funciones y variables claramente definidas y con nombres adecuados, un flujo lógico y un propósito aparente. El código legible es más fácil de corregir, asegurar y construir.

¿Qué tan compatible es?

Algunos factores determinarán la compatibilidad de un proyecto con tus objetivos. Se trata de cualidades objetivas, que pueden determinarse mirando los archivos del repositorio de un proyecto. Entre ellos están:

  • Código del lenguaje
  • Tecnologías o frameworks específicos
  • Compatibilidad de la licencia

La compatibilidad no significa necesariamente una coincidencia directa. Diferentes lenguajes de programación pueden relacionarse entre sí, al igual que diversas tecnologías y frameworks. Debes leer detenidamente la licencia de un proyecto para saber si permite su uso para tu objetivo, o si es compatible con una licencia que te gustaría utilizar.

Finalmente, un proyecto que satisface todos estos criterios puede no adaptarse a su caso de uso. Sin embargo, parte de la belleza del software de código abierto es que puedes beneficiarte de él haciendo modificaciones que se adapten mejor a tu uso. Si esas modificaciones hacen que el proyecto sea mejor para todos, puedes pagarle y pagarle contribuyendo con tu trabajo al proyecto.

Cuidado y alimentación adecuada para un proyecto de código abierto

Una vez que se adopta un proyecto de código abierto, es necesario prestar un poco de atención para asegurarse de que sigue siendo una ayuda para sus objetivos.

Aunque sus responsables se ocuparán de los archivos del proyecto, usted es el único responsable de su propia copia. Como todo el software, tu proyecto de código abierto debe estar bien mantenido para que siga siendo lo más seguro y útil posible.

Disponga de un sistema que le proporcione notificaciones cuando las actualizaciones de su software estén disponibles. Actualice el software con tiempo, tratando cada parche como si fuera vital para la seguridad, ya que puede serlo.

Tenga en cuenta que los creadores y encargados de mantener los proyectos de código abierto actúan, en la mayoría de los casos, sólo por la bondad de su propio corazón. Si tienes uno particularmente impresionante, es posible que sus desarrolladores pongan a disposición actualizaciones y parches de seguridad de forma regular. Depende de ti estar al tanto de las actualizaciones y aplicarlas rápidamente.

Como con la mayoría de las cosas en el software, mantener sus actualizaciones de código abierto regulares puede ser útil. Puedes utilizar submódulos, ramas o entornos de git para aislar tus modificaciones. Esto puede facilitar la aplicación de actualizaciones o la localización del origen de cualquier error que surja.

Así que, aunque un proyecto de código abierto no cueste dinero, caveat emptor, es decir, "Jimmy, si te regalamos un cachorro, es tu responsabilidad cuidarlo".

Traducido del artículo de Victoria Drake - How to Choose and Care for a Secure Open Source Project