Los desarrolladores suelen utilizar código de terceros para crear sus aplicaciones con el fin de ganar en eficiencia y ahorrar tiempo. Sin embargo, esta dependencia de componentes externos, en particular del software de código abierto (OSS), conlleva riesgos importantes, como vulnerabilidades y problemas de licencias. Según una encuesta de GitHub de 2023, el 31 % de los desarrolladores considera que detectar y corregir vulnerabilidades de seguridad es su segunda tarea más importante, justo después de escribir código (32 %).
En consecuencia, muchas organizaciones están preocupadas por su dependencia del software de código abierto, ya que este suele ser blanco de los piratas informáticos. Las organizaciones se enfrentan al reto de hacer frente a una mayor vulnerabilidad a lo largo de la cadena de suministro de software y de comprender cómo mitigar eficazmente los riesgos tras los recientes ataques de gran repercusión.
Un informe de investigación elaborado por ESG revela que el 91 % de las organizaciones ha sufrido un incidente en la cadena de suministro de software en los últimos 12 meses. Entre los incidentes más comunes se encuentran:
Vulnerabilidades destacadas como Log4J, Curl, Apache Struts y OpenSSL han provocado numerosos casos de daños operativos. Esto pone de manifiesto el grave impacto que supone para las organizaciones que se aproveche una sola vulnerabilidad dentro de la cadena de suministro de software. En respuesta a estos riesgos cada vez mayores, los organismos reguladores de todo el mundo están haciendo hincapié en la transparencia y la seguridad del software. La adopción de un Software Bill of Materials (SBOM) se está convirtiendo en una estrategia clave para gestionar los riesgos de la cadena de suministro de software.
La normativa sobre listas de materiales de seguridad (SBOM) cobra impulso
La normativa sobre las listas de materiales de software (SBOM) está cada vez más extendida. Muchos gobiernos han publicado recomendaciones sobre la implementación de las SBOM. En Estados Unidos, las recomendaciones sobre las SBOM se incluyen en varias directrices gubernamentales, entre ellas:
En 2023, la CISA publicó tres documentos clave para impulsar la adopción de las listas de componentes de software (SBOM). Estos se centraron en ampliar el uso de las SBOM, explorar nuevas tecnologías y aplicaciones, y fomentar la colaboración comunitaria.
En Europa, la Agencia de la UE para la Ciberseguridad (ENISA) ha publicado las «Directrices para la seguridad Supply Chain la Supply Chain Internet de las cosas», que ofrecen a las organizaciones información valiosa para mejorar la ciberseguridad y gestionar los riesgos de la cadena de suministro relacionados con el software.
Otros países han publicado directrices similares, entre ellos:
Recomienda a las organizaciones que utilicen las listas de materiales de software (SBOM) para evaluar los riesgos asociados a los componentes de software que utilizan, así como para identificar y subsanar las vulnerabilidades de dichos componentes.
En el «Manual de seguridad de la información: Directrices para Software », el ACSC recomienda el uso de SBOM para mejorar la transparencia de la cadena de suministro cibernética, lo que facilita la identificación y la gestión de los riesgos de seguridad relacionados con los componentes de software individuales utilizados en las aplicaciones.
En el documento «Recomendaciones para mejorar la resiliencia de Supply Chain digital de Canadá», el CSE aboga por el uso de SBOM para aumentar la transparencia y hacer frente de manera eficaz a las amenazas que se ciernen sobre la cadena de suministro de software.
Por qué la norma PCI DSS exige la generación de una SBOM
Conscientes del aumento de los riesgos para los datos de las tarjetas de pago, la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS) se ha convertido en un motor para la adopción de las SBOM. La última versión, PCI DSS 4.0, exige el uso de SBOM, lo que subraya su papel fundamental en la protección de la información confidencial. Al proporcionar un inventario detallado de los componentes de software, las SBOM permiten a las organizaciones identificar y abordar las vulnerabilidades de forma proactiva, reduciendo el riesgo de costosas filtraciones de datos y pérdidas económicas.
Establecido en 2004, el PCI DSS es un estándar de seguridad integral diseñado para proteger la información de las tarjetas de crédito. Establece un conjunto de requisitos rigurosos para las empresas que gestionan transacciones con tarjetas de crédito, adaptados al volumen de transacciones procesadas anualmente. La versión de 2022 del PCI DSS v4.0 introdujo cambios significativos, entre ellos la obligación de utilizar la SBOM, para hacer frente a las amenazas en constante evolución. El cumplimiento del PCI DSS v4.0 es obligatorio a partir de abril de 2024, y los requisitos específicos se introducirán gradualmente hasta el 31 de marzo de 2025.
Fuente: PCI DSS v. 4.0 de un vistazo
Al exigir el uso de SBOM, la norma PCI DSS permite a las organizaciones obtener una visión completa de su ecosistema de software, lo que les permite identificar y abordar las vulnerabilidades de forma proactiva. Este enfoque reduce considerablemente el riesgo de costosas filtraciones de datos y pérdidas económicas.
A mediados de 2024 se publicó una nueva versión del PCI DSS, la versión 4.0.1. Esto significa que la versión anterior, la 4.0, dejará de ser válida a partir del 31 de diciembre de 2024. Sin embargo, la nueva versión no añade ni elimina ninguna norma y no modifica los plazos. Por lo tanto, la información sobre los requisitos de la SBOM que se incluye en este blog se aplica tanto a la versión 4.0 como a la 4.0.1.
Cumplimiento del requisito 6.3.2 de la norma PCI DSS
El requisito relativo a la lista de componentes de software (SBOM) de la norma PCI DSS v4.0 forma parte de las mejoras generales introducidas en la norma PCI DSS en su última versión. Introducido como parte de los 64 nuevos requisitos añadidos en la versión 4.0, este requisito aborda específicamente la necesidad de que las organizaciones mantengan un inventario de los componentes de software, prestando especial atención al software a medida y personalizado.
Este requisito se enmarca en el Requisito 6 de la norma PCI DSS, que exige la creación y el mantenimiento de sistemas y aplicaciones seguros mediante la aplicación de medidas de seguridad sólidas y la realización periódica de evaluaciones de vulnerabilidades y actualizaciones. Este requisito es fundamental para reducir los riesgos que plantean las vulnerabilidades del software y proteger los datos de los titulares de tarjetas. La sección 6 abarca cinco áreas principales:
- 6.1 Se definen y comprenden los procesos y mecanismos para desarrollar y mantener sistemas y software seguros.
- 6.2 El software a medida y personalizado se desarrolla de forma segura.
- 6.3 Se identifican y se resuelven las vulnerabilidades de seguridad.
- 6.4 Las aplicaciones web accesibles al público están protegidas contra los ataques.
- 6.5 Las modificaciones de todos los componentes del sistema se gestionan de forma segura.
Más concretamente, el requisito 6.3.2 es una actualización importante que se derivó de varias infracciones en las que las vulnerabilidades de componentes de terceros, o las infracciones cometidas por los proveedores de dichos componentes, provocaron la filtración de los datos de los titulares de tarjetas. El requisito reza de la siguiente manera:
6.3.2.b Examinar la documentación del software, incluido el software a medida y personalizado que incorpore componentes de software de terceros, y compararla con el inventario para verificar que este incluya dicho software a medida y personalizado, así como los componentes de software de terceros.
Las organizaciones deben documentar y gestionar minuciosamente los componentes y servicios específicos que utilizan en sus aplicaciones. Aunque parte de esta información puede haberse incluido en los diagramas de flujo de datos, los nuevos requisitos exigen una documentación mucho más detallada. Llevar un control de estos detalles puede resultar complicado, ya que los componentes se actualizan y modifican constantemente. Es recomendable utilizar una plantilla estándar para recopilar esta información. Además, algunos repositorios de código fuente, como GIT, pueden ofrecer herramientas para exportar una lista de los componentes en uso. Como mínimo, su inventario debe incluir:
- Componentes de la aplicación (normalmente proyectos de repositorio)
- Lista de componentes de terceros
- Lista de dependencias de la aplicación (por ejemplo, Tomcat, JBoss, .NET, middleware)
- Lista de scripts autorizados para páginas de pago
Cómo puede OPSWAT ayudar a cumplir los requisitos de la norma PCI DSS
Las normativas exigen cada vez más el uso de SBOM para garantizar la seguridad de la cadena de suministro de software. Sin embargo, las organizaciones tienen dificultades para elaborar inventarios precisos de la composición del código de su software.
Fuente: Informe EGS 2024
Sin embargo, la elaboración de SBOM precisas y exhaustivas supone un reto considerable para las organizaciones. Estos documentos exigen un inventario minucioso de los componentes de software, lo que requiere información detallada sobre su origen, versiones e interdependencias. Sin SBOM precisas, a las organizaciones les resulta difícil identificar, evaluar y mitigar de manera eficaz los riesgos inherentes a su cadena de suministro de software.
Directrices para la generación de SBOM
OPSWAT automatiza la generación de listas de materiales de software (SBOM) tanto para código como para contenedores, lo que mejora la seguridad y facilita el cumplimiento normativo en la cadena de suministro de software.
- Identificar todos los componentes y dependencias
Identifique con precisión todos los componentes de software, incluidas las bibliotecas de código abierto y de terceros, junto con sus versiones y dependencias. Esto constituye la base para una SBOM sólida. - Evaluar los riesgos del software de código abierto
Evaluar los riesgos potenciales asociados a los componentes de OSS. Tener en cuenta factores como el cumplimiento de las licencias, las vulnerabilidades de seguridad y el estado del mantenimiento. Priorizar los componentes en función de su importancia para el software. - Detección de vulnerabilidades en el software de código abierto
Utilice herramientas de análisis de vulnerabilidades y de generación de SBOM para identificar vulnerabilidades conocidas en los componentes de OSS. Priorice las vulnerabilidades en función de su gravedad y su posible impacto en el software.
Uso de OPSWAT
OPSWAT automatiza la generación de listas de materiales de software (SBOM) tanto para código como para contenedores, lo que mejora la seguridad y facilita el cumplimiento normativo en la cadena de suministro de software.
A continuación te explicamos cómo puedes utilizar OPSWAT para generar listas de materiales de software (SBOM) de forma eficaz:
OPSWAT automatiza el proceso de generación de listas de componentes de software (SBOM), abarcando tanto las dependencias de software de código abierto (OSS) como las de terceros, así como los contenedores. Esta automatización reduce el esfuerzo manual necesario para mantener un inventario actualizado de los componentes de software.
Al proporcionar un inventario de todas las bibliotecas y componentes de código abierto utilizados en una aplicación, OPSWAT ayuda a gestionar las vulnerabilidades de las dependencias en la cadena de suministro de software, lo que permite a los usuarios identificar y corregir de manera eficiente las vulnerabilidades de las aplicaciones.
Además de identificar vulnerabilidades, OPSWAT valida las licencias asociadas a cada componente de software. Esto garantiza el cumplimiento de las condiciones de licencia y evita posibles problemas legales. Obtenga más información sobre el papel fundamental que desempeña la detección de licencias en el software de código abierto (OSS).
OPSWAT es compatible con más de 10 lenguajes de programación, entre los que se incluyen Java, JavaScript, Go, PHP y Python. Esta amplia compatibilidad garantiza vulnerability detection exhaustiva vulnerability detection diversos ecosistemas de desarrollo de software.
Sanciones por incumplimiento
Las organizaciones que no cumplan con las normas PCI DSS, incluido el requisito relativo a la lista de componentes de software (SBOM), pueden incurrir en sanciones económicas que oscilan entre los 5 000 y los 100 000 dólares al mes. Estas multas pueden ir en aumento con el tiempo si los problemas de cumplimiento siguen sin resolverse.
Además de las sanciones económicas, el incumplimiento de la norma PCI DSS puede acarrear importantes problemas legales y operativos. Las consecuencias legales pueden incluir demandas judiciales, gastos de defensa y indemnizaciones cuantiosas. Además, el incumplimiento podría dar lugar a auditorías federales por parte de organismos como la Comisión Federal de Comercio (FTC), lo que acarrearía sanciones adicionales.
Próximos pasos para el cumplimiento de la norma PCI DSS 4.0
La integración de la SBOM en el marco PCI DSS 4.0 supone un cambio fundamental hacia una cadena de suministro de software más segura. Al utilizar herramientas avanzadas como OPSWAT , las organizaciones pueden gestionar eficazmente los riesgos del código abierto, mejorar el cumplimiento normativo y protegerse contra costosas filtraciones de datos.
El uso de las listas de materiales de software (SBOM) ya no es una opción, sino una necesidad. Al adoptar medidas proactivas para comprender y gestionar las dependencias de software, las organizaciones pueden sentar unas bases de seguridad sólidas que protejan sus operaciones y fomenten la confianza de los clientes.
Mejora tu seguridad y tu postur
a con OPSWAT
Empieza ya a gestionar las dependencias de código abierto de
.
