Proveedores, colectivos y gobiernos están contribuyendo a mejorar la seguridad del código, el software y el desarrollo de código abierto en medio del creciente uso de recursos de código abierto por parte de las organizaciones.
La seguridad del código abierto ha ocupado un lugar destacado en la agenda de este año, con una serie de iniciativas, proyectos y orientaciones lanzadas en 2022 para ayudar a mejorar la ciberresistencia del código, el software y el desarrollo de código abierto. Los proveedores, las empresas tecnológicas, los colectivos y los gobiernos han contribuido a elevar el listón de la seguridad del código abierto en medio del creciente uso y dependencia de las organizaciones de los recursos de código abierto, junto con los complejos riesgos y desafíos de seguridad que conlleva.
"El año 2022 ha intensificado la atención necesaria a los temas importantes de la seguridad del código abierto, incluida la seguridad de la cadena de suministro. También ha acelerado los esfuerzos para identificar lo que quedaba por hacer, y empezar a hacerlo. En resumen: las cosas acaban de empezar, pero se ha avanzado", explica a CSO David A. Wheeler, director de seguridad de la cadena de suministro de código abierto en la Fundación Linux.
Entonces, ¿por qué es importante mejorar la seguridad del código abierto? La respuesta es, en parte, "porque lo sustenta todo", dice Wheeler. El software realmente dirige el mundo". Los últimos estudios han demostrado que, de media, entre el 70% y el 90% de las aplicaciones son, una vez que se mira dentro, componentes de software de código abierto (OSS). Eso no es un problema en sí mismo -el OSS permite un número increíble de bienes y servicios-, pero es un problema si el OSS es vulnerable a los ataques". Para provocar cualquier cambio, las organizaciones necesitan recursos, incluidos el tiempo y el dinero de las personas, añade. "Algunas acciones no requerirán mucho, pero a menudo se necesita algo como catalizador. Algunas requerirán más recursos porque la industria del software es grande, y la cantidad de software es enorme. Para muchos desarrolladores, "hacerlo seguro" es un requisito nuevo e imprevisto".
He aquí ocho notables iniciativas de seguridad de código abierto de 2022.
1. La Casa Blanca organiza una cumbre sobre la seguridad del código abierto
En enero, la Casa Blanca convocó a las partes interesadas del gobierno y del sector privado para debatir iniciativas para mejorar la seguridad del software de código abierto y nuevos enfoques de colaboración para impulsar las mejoras. Entre los participantes en la reunión se encontraban la Viceconsejera de Seguridad Nacional para Tecnología Cibernética y Emergente, Anne Neuberger, y el Director Nacional Cibernético, Chris Inglis, junto con representantes de empresas tecnológicas como Akamai, Amazon, Apple, Cloudflare, Facebook/Meta, la Fundación Linux, la Fundación de Seguridad de Código Abierto (OpenSSF) y Microsoft.
"Los participantes mantuvieron un debate sustancial y constructivo sobre cómo marcar la diferencia en la seguridad del software de código abierto, a la vez que se comprometen con la comunidad de código abierto y la apoyan de forma efectiva", se lee en la Casa Blanca. "El debate se centró en tres temas: la prevención de defectos y vulnerabilidades de seguridad en el código y los paquetes de código abierto, la mejora del proceso para encontrar defectos y solucionarlos, y la reducción del tiempo de respuesta para distribuir e implementar las correcciones".
Todos los participantes continuarán los debates para apoyar estas iniciativas en las próximas semanas, que están abiertas a todas las partes interesadas, públicas y privadas, añadió.
Más información: https://www.whitehouse.gov/briefing-room/statements-releases/2022/01/13/readout-of-white-house-meeting-on-software-security/
2. La OpenSSF y la Fundación Linux publican el Plan de Movilización de la Seguridad del Software de Código Abierto
En mayo, la OpenSSF y la Fundación Linux publicaron el Plan de Movilización de la Seguridad del Software de Código Abierto, en el que se esboza una estrategia de 10 líneas con pasos para mejoras inmediatas y a largo plazo dentro del software de código abierto, tanto para los componentes subyacentes como para su funcionamiento. Sus tres objetivos principales de seguridad son:
Asegurar la producción de software de código abierto centrándose en la prevención de defectos y vulnerabilidades de seguridad en el código y los paquetes de código abierto.
Mejorar el descubrimiento y la corrección de vulnerabilidades mediante la mejora del proceso de búsqueda de defectos y su corrección.
Acortar los tiempos de respuesta de los parches del ecosistema acelerando la distribución e implementación de las correcciones.
"Las vulnerabilidades y debilidades en el software ampliamente desplegado presentan amenazas sistémicas a la seguridad y estabilidad de la sociedad moderna, ya que los servicios gubernamentales, los proveedores de infraestructura, las organizaciones sin fines de lucro y la gran mayoría de las empresas privadas dependen del software para funcionar", escribió la OpenSSF. Ha llegado el momento de aplicar las mejores prácticas de seguridad a todo el ecosistema del software, incluido el de código abierto, abarcando una serie más amplia de inversiones para que la seguridad pase de ser un ejercicio principalmente reactivo a un enfoque proactivo, añadió.
3. JFrog presenta el Proyecto Pyrsia para asegurar los paquetes de software de código abierto y el código binario
En mayo, JFrog anunció el lanzamiento del Proyecto Pyrsia, una red de construcción descentralizada y segura y un repositorio de paquetes de software que utiliza la tecnología blockchain para proteger los paquetes de software de código abierto de las vulnerabilidades y el código malicioso. Su objetivo es ayudar a los desarrolladores a establecer una cadena de procedencia para sus componentes de software, creando una mayor confianza y seguridad, declaró la empresa. "Con Pyrsia, los desarrolladores pueden utilizar con confianza el software de código abierto sabiendo que sus componentes no han sido comprometidos, sin necesidad de construir, mantener u operar procesos complejos para gestionar de forma segura las dependencias", dijo JFrog, afirmando que el marco ayudará a proporcionar:
- Una red de construcción independiente y segura para el software de código abierto
- Confiabilidad de los paquetes de software
- La integridad de las dependencias conocidas del software de código abierto
"En JFrog creemos que la seguridad de código abierto sólo tendrá éxito si proporcionamos a la comunidad las mismas herramientas y servicios que están disponibles para las empresas", comentó Stephen Chin, vicepresidente de relaciones con los desarrolladores de JFrog. "La combinación de un código abierto, una arquitectura personalizable y una comunidad robusta y activa hacen de Pyrsia la forma más transparente y fiable de obtener paquetes de software seguros."
Más información: https://jfrog.com/press/jfrog-ushers-in-new-era-of-open-source-software-security-launching-project-pyrsia/
4. OpenUK lanza el Verano de la Seguridad del Código Abierto
En junio, OpenUK puso en marcha el "Verano de la seguridad del código abierto", una iniciativa de dos meses de duración que incluye eventos, charlas y podcasts dedicados a la seguridad del software de código abierto y a la gestión de la cadena de suministro. Las conversaciones incluyeron la contextualización de la posición de los gobiernos y las empresas de todo el mundo con respecto a las infraestructuras críticas nacionales construidas con software de código abierto y el reconocimiento de la necesidad de tener en cuenta el mantenimiento, la seguridad y la curación del software de código abierto.
"El software de código abierto difiere en gran medida del software propietario, en parte por el modelo de derechos de autor y la exclusión de responsabilidad asociada. Esto influye directamente en la base del equilibrio de riesgos, que es muy diferente para el software de código abierto y el propietario. La contrapartida de la distribución gratuita del código abierto es la exención absoluta de responsabilidad", escribió la directora general de OpenUK, Amanda Brock.
Más información: https://openuk.uk/launching-the-openuk-summer-of-open-source-software-security/
5. GitGuardian anuncia el proyecto ggcanary para detectar los riesgos del software de código abierto
En julio, el proveedor de plataformas de seguridad de código GitGuardian anunció el lanzamiento de un proyecto de tokens canarios de código abierto para ayudar a las organizaciones a detectar entornos de desarrolladores y DevOps comprometidos. La firma dijo que el proyecto ggcanary está diseñado para ayudar a las empresas a detectar compromisos más rápidamente y está construido con las siguientes características:
- Dependencia de Terraform, que utiliza la popular herramienta de software de infraestructura como código de HashiCorp para crear y gestionar tokens canarios de AWS
Detección de intrusiones de alta sensibilidad que utiliza los registros de auditoría de AWS CloudTrail para rastrear todo tipo de acciones realizadas en los tokens canarios por los atacantes. - Escalabilidad de hasta 5.000 tokens canarios de AWS activos desplegados en el perímetro interno de una organización, en repositorios de código fuente, herramientas CI/CD, sistemas de ticketing y mensajería como Jira, Slack o Microsoft Teams
- Su propio sistema de alertas, integrado con AWS Simple Email Service (SES), Slack y SendGrid. Los usuarios también pueden ampliarlo para reenviar las alertas a SOCs, SIEMs o ITSMs.
6. Google lanza un programa de recompensas por vulnerabilidades de software de código abierto
En agosto, Google lanzó el programa de recompensas por vulnerabilidad de software de código abierto (OSS VRP) para recompensar el descubrimiento de vulnerabilidades en los proyectos de código abierto de Google. En una entrada del blog, Google escribió que su OSS VRP anima a los investigadores a informar de las vulnerabilidades con el mayor impacto real y potencial en el software de código abierto de la cartera de Google, centrándose en:
Todas las versiones actualizadas de software de código abierto (incluida la configuración de los repositorios) almacenadas en los repositorios públicos de las organizaciones de GitHub, propiedad de Google
Las dependencias de terceros de esos proyectos (siendo necesaria la notificación previa a la dependencia afectada antes de su presentación al VRP de OSS de Google)
"Los premios más importantes se destinarán a las vulnerabilidades encontradas en los proyectos más sensibles: Bazel, Angular, Golang, Protocol buffers y Fuchsia", declaró Google, añadiendo que, para centrar los esfuerzos en los descubrimientos que tienen el mayor impacto en la cadena de suministro, acepta presentaciones de:
- Vulnerabilidades que lleven a comprometer la cadena de suministro
- Problemas de diseño que provoquen vulnerabilidades en los productos
- Otros problemas de seguridad como credenciales sensibles o filtradas, contraseñas débiles o instalaciones inseguras
Las recompensas oscilan entre los 100 y los 31.337 dólares, dependiendo de la gravedad de la vulnerabilidad y de la importancia del proyecto, dijo Google.
Más información: https://security.googleblog.com/2023/08/Announcing-Googles-Open-Source-Software-Vulnerability-Rewards-Program%20.html
7. La CISA y la NSA publican una guía de seguridad para la cadena de suministro de software de código abierto
En agosto, la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA) y la Agencia de Seguridad Nacional (NSA) de EE.UU. publicaron una guía en la que se aconseja a los desarrolladores cómo proteger mejor la cadena de suministro de software de EE.UU., con un enfoque significativo en el software de código abierto.
"Las organizaciones de desarrollo deben emplear sistemas dedicados que descarguen, escaneen y realicen comprobaciones periódicas de las bibliotecas de código abierto en busca de nuevas versiones, actualizaciones y vulnerabilidades conocidas o nuevas", dice la guía. "Al igual que con todo el software, recomendamos encarecidamente educar a los desarrolladores sobre las consideraciones para el uso de software de código abierto, software de código cerrado, y la evolución de las mejores prácticas de mitigación".
El equipo de gestión también debe establecer, gestionar y aplicar los criterios de lanzamiento relacionados con el software de código abierto, añade la guía, asegurando que todo el envío de código abierto cumple con las normas de toda la empresa, incluyendo la evaluación de la vulnerabilidad de la fuente. "El equipo de gestión también debe establecer, gestionar y aplicar los criterios de publicación relativos al software de código abierto, añadió la guía, garantizando que todos los envíos de software de código abierto cumplan con las normas de toda la empresa, incluida la evaluación de la vulnerabilidad de la fuente.
Más información: https://media.defense.gov/2022/Sep/01/2003068942/-1/-1/0/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF
8. La OpenSSF publica las mejores prácticas de npm para ayudar a los desarrolladores a afrontar los riesgos de las dependencias de código abierto
En septiembre, la OpenSSF publicó la guía de mejores prácticas de npm para ayudar a los desarrolladores de JavaScript y TypeScript a reducir los riesgos de seguridad asociados al uso de dependencias de código abierto. La guía es un producto del Grupo de Trabajo de Mejores Prácticas de la OpenSSF y se centra en la gestión de dependencias y la seguridad de la cadena de suministro de npm. Cubre varias áreas, como por ejemplo cómo establecer una configuración CI segura, cómo evitar la confusión de dependencias y cómo limitar las consecuencias de una dependencia secuestrada.
En declaraciones a CSO en septiembre, Wheeler, de la Fundación Linux, dijo que el mayor riesgo de seguridad que plantea el uso de dependencias de código abierto por parte de los desarrolladores es subestimar los efectos que pueden tener las vulnerabilidades en las dependencias directas e indirectas. "Pueden surgir fallos en cualquier software, que pueden afectar significativamente a la cadena de suministro que lo utiliza si no se tiene cuidado. Con demasiada frecuencia, muchas de las dependencias son invisibles y ni los desarrolladores ni las organizaciones ven todas las capas de la pila. La solución no es dejar de reutilizar el software; la solución es reutilizar el software con prudencia y estar preparados para actualizar los componentes cuando se encuentren vulnerabilidades."
Más información: https://github.com/ossf/package-manager-best-practices/blob/main/published/npm.md
Fuente: somoslibres
