[03/08/2022] Todo el mundo conoce la frase "el software se está comiendo el mundo" de Marc Andreessen de hace más de una década. El software impulsa y toca casi todos los aspectos de la sociedad moderna, tanto personal como profesionalmente, y es fundamental para la economía moderna y la seguridad nacional.
También puede decirse que el software de código abierto (OSS, por sus siglas en inglés) se ha comido la industria del software. La Fundación Linux y otros grupos han estimado que el software libre y de código abierto (FOSS) constituye entre el 70% y el 90% de cualquier producto de software moderno. El software moderno no solo se compone en gran medida de componentes de OSS, sino que es más probable que los responsables de TI trabajen con proveedores que también contribuyen a la comunidad de OSS.
El uso de OSS está muy extendido debido a su flexibilidad, el ahorro de costos, la innovación a través de proyectos habilitados por la comunidad y, posiblemente, una mayor seguridad debido a que hay más ojos en el código, especialmente en los grandes proyectos de OSS. Dicho esto, el OSS conlleva sus propios problemas, como las vulnerabilidades y exposiciones comunes (CVE) del código afectado.
CVE es un proyecto de MITRE que se esfuerza por "identificar, definir y catalogar las vulnerabilidades de ciberseguridad divulgadas públicamente". Sin embargo, tal y como señala el libro blanco sobre las mejores prácticas de la cadena de suministro de software de la Cloud Native Computing Foundation (CNCF), los CVE son una "métrica de seguimiento", lo que significa que enumeran las vulnerabilidades que se han divulgado públicamente. También son solo un tipo de riesgo asociado al software.
Por esta razón, las organizaciones deberían utilizar otros métodos para evaluar el estado de la seguridad de los proyectos de OSS que consumen. Uno de los más destacados es el proyecto Scorecards de la Open Source Security Foundation (OpenSSF).
¿Qué es Scorecards de OpenSSF para proyectos de código abierto?
Anunciado a finales del 2020, Scorecards pretende autogenerar una puntuación de seguridad para los proyectos de OSS con el fin de ayudar a los consumidores y a las organizaciones a tomar decisiones informadas sobre el riesgo de su consumo de OSS. Las organizaciones hacen un uso abrumador de las dependencias de OSS, pero determinar el riesgo de consumir esas dependencias sigue siendo una actividad en gran medida manual, especialmente a escala del ecosistema de software. El proyecto Scorecards pretende aliviar parte de esa carga utilizando heurística automatizada y comprobaciones de seguridad en una escala de puntuación de 0 a 10. Para ello, evalúa los proyectos de OSS en busca de problemas de seguridad que se ajusten a las mejores prácticas, como la firma o el SAST, ya defendidas por los líderes de la seguridad pública y privada.
OpenSSF Scorecards utiliza una puntuación escalonada para los niveles de gravedad de los riesgos.
El proyecto Scorecards tampoco apunta a la baja, sino que escanea el millón de proyectos de OSS más críticos basándose en las dependencias directas, y publica los resultados en un conjunto de datos públicos semanalmente. Además de aprovechar este conjunto de datos disponible públicamente, las organizaciones también pueden ejecutar Scorecards contra sus propios proyectos de GitHub utilizando acciones de GitHub. Cuando se produce un cambio en el repositorio, la acción de GitHub se ejecuta y proporciona alertas a los mantenedores de esos proyectos.
El proyecto Scorecards utiliza una escala de puntuación de crítico, alto, medio y bajo, que son niveles de gravedad con los que la mayoría de los profesionales de la seguridad están familiarizados. También utiliza una lista estándar de comprobaciones que ejecuta contra todos los proyectos a los que se dirige, ya sean proyectos públicos o, si lo utiliza de forma nativa, sus propios repositorios de GitHub.
Puede profundizar en lo que son algunas de esas comprobaciones. Incluyen prácticas de seguridad fundamentales como el uso de la protección de ramas, la firma criptográfica de las publicaciones y la presencia de vulnerabilidades no corregidas. Para detectar la presencia de vulnerabilidades no corregidas, el proyecto Scorecards utiliza la base de datos de vulnerabilidades OSV. Se trata de una base de datos de vulnerabilidad distribuida para OSS que utiliza el formato OSV de OpenSSF. OSV, en su esencia, es una agregación de otras bases de datos de vulnerabilidad que utilizan el esquema OSV, como los avisos de seguridad de GitHub y la base de datos de seguridad global, entre otros. OSC también es compatible con las API y las herramientas de la interfaz de línea de comandos (CLI) para escanear los SBOM en los formatos CycloneDX o SPDX.
El proyecto Scorecards se reúne cada dos semanas y tiene un canal de Slack activo. Está dirigido por facilitadores de empresas como Google, Datto y Cisco. Desde su creación, Scorecards ha crecido en popularidad y está catalogado con más de tres mil Stargazers, o usuarios que esencialmente han marcado el proyecto. A medida que las organizaciones continúen su impulso para madurar sus prácticas de gobierno del consumo de OSS, el proyecto crecerá inevitablemente en popularidad.
¿Cómo pueden las organizaciones utilizar las tarjetas de puntuación de OpenSSF?
La capacidad de las organizaciones para llevar a cabo la diligencia debida, la gobernanza y la gestión de riesgos de su consumo de OSS está en gran parte todavía en su infancia. Estamos viendo un gran impulso para reforzar la resistencia de la cadena de suministro de software, y madurar las prácticas de seguridad de la cadena de suministro de software de las organizaciones. Hemos tenido las Prácticas de Gestión de Riesgos de la Cadena de Suministro de Ciberseguridad del NIST para Sistemas y Organizaciones Rev.1, el Marco de Desarrollo de Software Seguro (SSDF), el Plan de Movilización de Seguridad de OSS de la OpenSSF, los Niveles de la Cadena de Suministro para Artefactos de Software (SLSA), y otras mejores prácticas y fuentes de orientación emergentes. Todas ellas se refieren a la necesidad de gobernar el consumo de OSS por parte de una organización y de garantizar que dicho consumo se ajuste a la tolerancia al riesgo de la organización.
Aunque esto pueda parecer sencillo, la idea de hacerlo en todo el sólido ecosistema de proyectos y componentes de OSS que consumen las organizaciones no es tan trivial. El proyecto Scorecards de OpenSSF ofrece una forma automatizada de obtener información sobre la seguridad y los riesgos de más de un millón de proyectos de OSS de primera línea, así como de utilizar el proyecto de forma nativa para su propio software y proyectos internos de la organización.
Las organizaciones pueden utilizar Scorecards a través de la CLI para los proyectos que no poseen, así como utilizar un gestor de paquetes para proyectos como npm, PyPi o RubyGems. Scorecards también está disponible como contenedor Docker.
Las organizaciones y los colaboradores individuales pueden participar en el proyecto, incluyendo el envío de comprobaciones de necesidades para ser consideradas para la evaluación de la puntuación. Las organizaciones también pueden personalizar su uso de Scorecards y ejecutar solo comprobaciones específicas, potencialmente alineadas con sus requisitos de seguridad organizativos o específicos del sector.
Para obtener una orientación más específica, las organizaciones pueden consultar las prácticas recomendadas por el NIST para los controles del software de código abierto, que se publicaron en respuesta a la Orden Ejecutiva de Ciberseguridad (OE) 14028, Mejora de la Ciberseguridad de la Nación. Éstas incluyen capacidades escalonadas basadas en la madurez de la organización a partir de tres niveles: fundacional, de mantenimiento y de mejora. Dentro de estos niveles se encuentran capacidades tales como el uso de revisiones de código fuente de análisis de composición de software (SCA) para identificar componentes vulnerables, priorizando el uso de lenguajes de programación con barandillas incorporadas y automatizando el proceso de recopilación, almacenamiento y escaneo de componentes OSS en repositorios internos reforzados antes de introducirlos en entornos de producción.
Basado en el artículo de Chris Hughes (CSO) y editado por CIO Perú