Clasificación de bibliotecas que requieren una verificación de seguridad especial

Fondo formado por la organización Linux Foundation Iniciativa de Infraestructura Básica, en el marco de la cual las principales corporaciones unieron esfuerzos para apoyar proyectos abiertos involucrados en áreas clave de la industria informática, realizó el segundo estudio en el marco del programa Censo, destinado a identificar proyectos abiertos que requieren auditoría de seguridad prioritaria.

El segundo estudio se centra en el análisis del código abierto de uso compartido, implícitamente utilizado en varios proyectos corporativos en forma de dependencias descargadas de repositorios externos. Las vulnerabilidades y la compromisión de los desarrolladores de componentes de terceros involucrados en el trabajo de aplicaciones (supply chain) pueden anular todos los esfuerzos por mejorar la seguridad del producto principal. Como resultado de la investigación, se han determinado 10 de los paquetes más utilizados en JavaScript y Java, cuya seguridad y actividad de mantenimiento requieren especial atención.

Bibliotecas de JavaScript del repositorio npm:

• async (196 mil líneas de código, 11 autores, 7 committers, 11 problemas abiertos);
• inherits (3.8 mil líneas de código, 3 autores, 1 committer, 3 problemas abiertos);
• isarray (317 líneas de código, 3 autores, 3 committers, 4 problemas abiertos);
• kind-of (2 mil líneas de código, 11 autores, 11 committers, 3 problemas abiertos);
• lodash (42 mil líneas de código, 28 autores, 2 committers, 30 problemas abiertos);
• minimist (1.2 mil líneas de código, 14 autores, 6 committers, 38 problemas abiertos);
• natives (3 mil líneas de código, 2 autores, 1 committer, sin problemas abiertos);
• qs (5.4 mil líneas de código, 5 autores, 2 committers, 41 problemas abiertos);
• readable-stream (28 mil líneas de código, 10 autores, 3 committers, 21 problemas abiertos);
• string_decoder (4.2 mil líneas de código, 4 autores, 3 committers, 2 problemas abiertos).

Bibliotecas de Java de los repositorios Maven:

• jackson-core (74 mil líneas de código, 7 autores, 6 committers, 40 problemas abiertos);
• jackson-databind (74 mil líneas de código, 23 autores, 2 committers, 363 problemas abiertos);
• guava.git, bibliotecas de Google para Java (1 millón de líneas de código, 83 autores, 3 committers, 620 problemas abiertos);
• commons-codec (51 mil líneas de código, 3 autores, 3 committers, 29 problemas abiertos);
• commons-io (73 mil líneas de código, 10 autores, 6 committers, 148 problemas abiertos);
• httpcomponents-client (121 mil líneas de código, 16 autores, 8 committers, 47 problemas abiertos);
• httpcomponents-core (131 mil líneas de código, 15 autores, 4 committers, 7 problemas abiertos);
• logback (154 mil líneas de código, 1 autor, 2 committers, 799 problemas abiertos);
• commons-lang (168 mil líneas de código, 28 autores, 17 committers, 163 problemas abiertos);
• slf4j (38 mil líneas de código, 4 autores, 4 committers, 189 problemas abiertos);

El informe también aborda cuestiones de estandarización de la nomenclatura de componentes externos, la protección de las cuentas de los desarrolladores y el mantenimiento de versiones obsoletas tras la creación de nuevas versiones significativas. Además, la organización Linux Foundation ha publicado entre los censores de internet en los últimos años. Ahora, sin embargo, están consolidados en un acuerdo internacional. El documento aún no ha sido publicado, pero ya se pueden entender qué medidas proponen ambos países para implementar en el marco de la armonización de enfoques para regular el entorno digital, según el documento publicado en septiembre de 2019 por la Administración del Ciberespacio de China. En el proyecto de ley, que refleja un enfoque puramente chino-ruso sobre la “Gestión de internet”, hay una lista bastante amplia de nuevas bases para limitar el acceso a la información. Además de las prohibiciones recomendaciones prácticas para la organización de un proceso de desarrollo seguro de proyectos de código abierto.

El documento examina cuestiones sobre la distribución de roles en el proyecto, la creación de equipos responsables de la seguridad, la definición de políticas de seguridad, el seguimiento de los privilegios que tienen los participantes en el proyecto, el uso adecuado de Git al corregir vulnerabilidades para evitar filtraciones antes de que se publique la corrección, la definición de procesos de respuesta a informes de problemas de seguridad, la implementación de sistemas de pruebas de seguridad, la aplicación de procedimientos de revisión de código, y la consideración de criterios relacionados con la seguridad al formar versiones.

Fuente: opennet.ru