Llegamos a ustedes gracias a:



Reportajes y análisis

Qué es la OSPO

La primera línea para la gobernanza segura

[19/11/2022] Organizaciones de todas las formas, tamaños y sectores han adoptado el software de código abierto (OSS, por sus siglas en inglés). Industrias como la financiera, médica y manufacturera, e incluso la seguridad nacional ahora usan OSS para sus aplicaciones y actividades más críticas. Sin embargo, esta adopción generalizada conlleva dificultades: un aumento correspondiente de casi el 800% en los ataques a la cadena de abastecimiento de software, según el State of the Software Supply Chain de Sonatype.

Con el rápido crecimiento de la adopción de OSS, las organizaciones han comenzado a crear Open Source Program Offices (OSPO) para ayudar a codificar estrategias en torno al uso y la contribución de OSS y fomentar la colaboración, en general, con la comunidad de OSS. Estos OSPO a menudo tienen responsabilidades clave, como cultivar una estrategia de OSS, liderar su ejecución y facilitar el uso de productos y servicios de OSS en toda la empresa.

[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]

La OSPO como elemento estratégico y clave de la seguridad

En la dirección de la gestión y la estrategia de OSS, la posición única de la OSPO la convierte en un actor clave en el enfoque de una organización hacia la seguridad y en la gobernanza de OSS, un rol cada vez más crítico.

El OSS requiere una gestión cuidadosa. Los estudios muestran que las aplicaciones modernas incluyen más de 500 componentes OSS. Con un uso tan generalizado, es importante reconocer algunas estadísticas alarmantes sobre los componentes del OSS. Según una encuesta de Synopsis del 2022, el 81% incluye al menos una vulnerabilidad, el 88% no ha tenido nuevos desarrollos en los últimos dos años, y el 88% de los utilizados no eran la última versión. Todas estas métricas culminan en una realidad alarmante: las organizaciones están haciendo un amplio uso de componentes obsoletos e inseguros. Esto significa que tenemos una enorme superficie de ataque en los ambientes empresariales modernos que son pobres en gobernanza y ricos en vías para los actores maliciosos.

A estas alturas, todos están familiarizados con la US Cybersecurity Executive Order (EO) de Estados Unidos, incluyendo la Sección 4, "Mejorar la seguridad de la cadena de abastecimiento de software. Como resultado de la EO, el National Institute of Standards and Technology (NIST) ha producido una guía integral para la cadena de abastecimiento de software, que incluye controles para el software de código abierto, que discutiremos aquí, así como la manera en que las OSPO pueden abogar por su implementación.

El NIST presenta su conjunto de controles para el OSS en tres niveles de madurez: capacidades fundamentales, de mantenimiento y de mejora. Entre esos controles se encuentran cosas como el uso de aspectos del Secure Software Development Framework (SSDF) del NIST y garantizar que los componentes del OSS se adquieran a través de canales seguros de fuentes confiables. La realidad del ambiente empresarial moderno es que la mayoría de las organizaciones no tienen una visibilidad y un control completos del uso del OSS de su organización, y mucho menos un control continuo de las vulnerabilidades asociadas con él.

La OSPO como evangelista del uso eficaz y seguro del OSS

Este es un ejemplo perfecto de dónde brilla OSPO: como evangelista del uso efectivo de productos y servicios comerciales de OSS, abogando por la vigilancia de las vulnerabilidades asociadas con el OSS, y asegurando que estas prácticas de seguridad estén codificadas en políticas y procesos organizacionales.

Los controles de seguridad del OSS, recomendados por el NIST, también incluyen el establecimiento de repositorios internos de componentes del OSS conocidos y examinados, y que los desarrolladores pueden usar para reducir el riesgo organizacional. En lugar de permitir un ambiente en el que los desarrolladores tengan la libertad de extraer y usar todos y cada uno de los componentes del OSS, sin conocer sus vulnerabilidades y riesgos, los repositorios internos crean una biblioteca sólida de componentes del OSS que permiten aumentar la velocidad del desarrollador y, al mismo tiempo, reducen el riesgo organizativo debido al uso de componentes vulnerables del OSS.

Otra recomendación clave del SSDF del NIST es implementar cadenas de herramientas de apoyo, incluyendo la especificación de qué herramientas deben incluirse en los pipelines de CI/CD para mitigar los riesgos. Los ejemplos podrían incluir la integración de cosas como el análisis de composición de software (SCA, por sus siglas en inglés) y las herramientas de lista de materiales de software (SBOM, por sus siglas en inglés) en las cadenas de herramientas modernas de CI/CD para garantizar que la empresa tenga una visibilidad completa de los componentes vulnerables del OSS, los cuales se mueven a través de las cadenas de herramientas y en los ambientes de producción.

Esto también facilita el impulso para "mover la seguridad hacia la izquierda, asegurando que los escaneos de seguridad se realicen antes en el ciclo de vida del desarrollo del software, y que las vulnerabilidades se identifiquen y corrijan antes de introducirlas en producción, donde pueden ser explotadas por actores maliciosos. Las políticas y los procesos que las OSPO pueden evangelizar y codificar en esta área incluyen no solo el escaneo de vulnerabilidades y SBOM, sino también la habilitación de capacidades de firma que ayudan a crear registros inmutables y logs para soportar tanto la integridad como la capacidad de auditoría de las actividades de desarrollo de software.

Pasar al nivel más maduro establecido por el NIST -capacidades mejoradas- incluye priorizar el uso de lenguajes de programación seguros y, en última instancia, automatizar la recopilación, el almacenamiento y el escaneo de los componentes del OSS en los repositorios internos reforzados mencionados anteriormente. Este es quizás el paso más crítico para ayudar a reducir el riesgo y, al mismo tiempo, no obstaculizar la velocidad de los equipos de desarrollo, los cuales, si se obstaculizan, sin duda evitarían las políticas y los procesos de la organización para cumplir con sus tareas.

Roles de la OSPO: Relaciones con los desarrolladores, promoción y evangelización

Entre los roles comúnmente ocupados en una OSPO se encuentran las relaciones con los desarrolladores, la defensa y la evangelización. Si bien estos grupos a menudo generan entusiasmo e interés entre los equipos de desarrollo de la empresa, también suelen forjar relaciones críticas. Esas relaciones se pueden aprovechar para fomentar la aceptación de las mejores prácticas de seguridad emergentes para el OSS, que muchas organizaciones simplemente no han implementado aún a pesar del amplio uso del OSS en sus aplicaciones, software y productos. Esto crea muchos beneficios, como garantizar que la organización minimice el uso de dependencias inseguras y produzca aplicaciones más seguras, ya sea para fines internos o externos.

Otra cosa, que vale la pena mencionar, es que el gobierno federal de los Estados Unidos publicó recientemente un memorando que requerirá que todos los proveedores de software de terceros, que vendan software al gobierno, puedan ratificar que están alineados con el SSDF del NIST y otras guías para la cadena de abastecimiento de software del NIST. Muchas de las actividades y prácticas descritas en el SSDF giran, naturalmente, en torno al equipo de desarrollo como parte del proceso de desarrollo de software. La OSPO puede usar las relaciones con los desarrolladores para garantizar que el cambio -por parte de los proveedores que trabajan con el gobierno y adoptan este requisito- no sea demasiado disruptivo.

Investigaciones, como la realizada por Chinmayi Sharma, también sugiere que los proveedores de software sean los beneficiarios primarios del OSS y, en consecuencia, se encuentren en la mejor posición para ayudar a abordar el riesgo de la cadena de abastecimiento del OSS. Esto coloca a los proveedores de software en una excelente posición para involucrarse más en las comunidades de OSS, buscar vulnerabilidades y contribuir a los proyectos del OSS para mitigarlas. Esto sería un cambio del modelo actual, en el que la comunidad de OSS principalmente soporta esta carga con una falta de participación y contribución equitativa de la comunidad de proveedores de software.

Esto coloca a las OSPO en una posición perfecta para liderar un cambio de paradigma y, en última instancia, reforzar la seguridad de la cadena de abastecimiento del OSS más amplia. El OSS ha llevado a innovaciones y capacidades en casi todas las industrias. Las OSPO ahora están posicionadas para liderar la carga de esas industrias, y organizaciones asociadas, que se involucran más en la comunidad de OSS. Simultáneamente, las OSPO abordan el riesgo del sistema actual, planteado por el OSS, debido a la participación e inversión desarticuladas.

Puede ver también: