Hispanopedia Wiki
Articulo de referencia

Análisis de la composición del software

El análisis de composición de software (SCA) es una práctica en los campos de la tecnología de la información y la ingeniería de software para analizar aplicaciones de software ...

Hispanopedia WikiContenido en espanolLectura gratuita

El análisis de composición de software (SCA) es una práctica en los campos de la tecnología de la información y la ingeniería de software para analizar aplicaciones de software creadas a medida para detectar software de código abierto integrado y detectar si están actualizadas, contienen fallas de seguridad o tienen requisitos de licencia. [1]

Fondo

Es una práctica común en ingeniería de software desarrollar software utilizando diferentes componentes. [2] El uso de componentes de software segmenta la complejidad de elementos más grandes en fragmentos de código más pequeños y aumenta la flexibilidad al permitir una reutilización más sencilla de los componentes para abordar nuevos requisitos. [3] La práctica se ha expandido ampliamente desde fines de la década de 1990 con la popularización del software de código abierto (OSS) para ayudar a acelerar el proceso de desarrollo de software y reducir el tiempo de comercialización. [4]

Sin embargo, el uso de software de código abierto presenta numerosos riesgos para las aplicaciones de software que se están desarrollando. Estos riesgos se pueden organizar en cinco categorías: [5]

Poco después de la fundación de la Iniciativa de Código Abierto en febrero de 1998, [6] se plantearon los riesgos asociados con el OSS [7] y las organizaciones intentaron gestionarlos utilizando hojas de cálculo y documentos para rastrear todos los componentes de código abierto utilizados por sus desarrolladores. [8]

Para las organizaciones que utilizan componentes de código abierto de forma extensiva, era necesario automatizar el análisis y la gestión de los riesgos de código abierto. Esto dio lugar a una nueva categoría de productos de software denominada Análisis de composición de software (SCA), que ayuda a las organizaciones a gestionar los riesgos de código abierto. SCA se esfuerza por detectar todos los componentes de terceros que se utilizan en una aplicación de software para ayudar a reducir los riesgos asociados con las vulnerabilidades de seguridad, los requisitos de licencias de propiedad intelectual y la obsolescencia de los componentes que se utilizan.

Principio de funcionamiento

Los productos SCA normalmente funcionan de la siguiente manera: [9]

  • Un motor escanea el código fuente del software y los artefactos asociados que se utilizan para compilar una aplicación de software.
  • El motor identifica los componentes OSS y sus versiones y normalmente almacena esta información en una base de datos creando un catálogo de OSS en uso en la aplicación escaneada.
  • Este catálogo se compara luego con bases de datos que hacen referencia a vulnerabilidades de seguridad conocidas para cada componente, los requisitos de licencia para usar el componente y las versiones históricas del componente. [ cita requerida ] Para la detección de vulnerabilidades de seguridad, esta comparación generalmente se realiza con vulnerabilidades de seguridad conocidas (CVE) que se rastrean en la Base de datos nacional de vulnerabilidades (NVD). Algunos productos utilizan una base de datos patentada adicional de vulnerabilidades. Para el cumplimiento legal/de IP , los productos de SCA extraerán y evaluarán el tipo de licencia utilizada para el componente OSS. [10] Las versiones de los componentes se extraen de repositorios de código abierto populares como GitHub , Maven , PyPi , NuGet y muchos otros.
  • Los resultados se ponen a disposición de los usuarios finales en distintos formatos digitales. El contenido y el formato dependen del producto de SCA y pueden incluir una guía para evaluar e interpretar el riesgo, así como recomendaciones, especialmente en lo que respecta a los requisitos legales de los componentes de código abierto, como licencias copyleft fuertes o débiles . El resultado también puede contener una lista de materiales de software (SBOM) que detalle todos los componentes de código abierto y los atributos asociados utilizados en una aplicación de software [11].

Uso

Como la SCA afecta a distintas funciones de las organizaciones, distintos equipos pueden utilizar los datos según el tamaño y la estructura de la corporación. El departamento de TI suele utilizar la SCA para implementar y poner en funcionamiento la tecnología con partes interesadas comunes, como el director de información (CIO), el director de tecnología (CTO) y los arquitectos empresariales jefe (EA). [12] Los datos de seguridad y licencias suelen ser utilizados por funciones como los directores de seguridad de la información (CISO) para los riesgos de seguridad y los directores de propiedad intelectual/cumplimiento para la gestión de riesgos de propiedad intelectual. [13]

Dependiendo de las capacidades del producto SCA, se puede implementar directamente dentro del entorno de desarrollo integrado (IDE) de un desarrollador que utiliza e integra componentes OSS, o se puede implementar como un paso dedicado en el proceso de control de calidad del software . [14] [15]

Los productos SCA, y en particular su capacidad para generar un SBOM, son necesarios en algunos países como Estados Unidos para reforzar la seguridad del software entregado a una de sus agencias por un proveedor. [16]

Otro caso de uso común de la SCA es la debida diligencia tecnológica . Antes de una transacción de fusión y adquisición (M&A), las empresas de asesoramiento revisan los riesgos asociados con el software de la empresa objetivo. [17]

Fortalezas

La naturaleza automática de los productos SCA es su principal fortaleza. Los desarrolladores no tienen que hacer un trabajo adicional de forma manual al usar e integrar componentes OSS. [18] La automatización también se aplica a las referencias indirectas a otros componentes OSS dentro del código y los artefactos. [19]

Debilidades

Por el contrario, algunas debilidades clave de los productos SCA actuales pueden incluir:

  • Implementación compleja y que requiere mucho trabajo y que puede llevar meses hasta que esté completamente operativa [20]
  • Cada producto utiliza su propia base de datos patentada de componentes OSS que pueden variar drásticamente en términos de tamaño y cobertura [21].
  • Limitar los datos de vulnerabilidad a informar únicamente sobre las vulnerabilidades notificadas oficialmente en el NVD (que pueden ser meses después de que se descubrió originalmente la vulnerabilidad) [22]
  • Falta de orientación automatizada sobre las medidas a tomar en función de los informes y datos de la SCA [23]
  • Se detecta falta de orientación sobre los requisitos legales de las licencias de OSS [24]

Véase también

Referencias

  1. ^ Prana, Gede Artha Azriadi; Sharma, Abhishek; Shar, Lwin Khin; Foo, Darius; Santosa, Andrew E; Sharma, Asankhaya; Lo, David (julio de 2021). "¿Ojos que no ven, corazón que no siente? Cómo las dependencias vulnerables afectan a los proyectos de código abierto". Ingeniería de software empírica . 26 (4). Springer: 1– 34. doi :10.1007/s10664-021-09959-3. S2CID  197679660.
  2. ^ Nierstrasz, Oscar; Meijler, Theo Dirk (1995). "Direcciones de investigación en la composición de software". Encuestas de informática de la ACM . 27 (2). ACM: 262– 264. doi : 10.1145/210376.210389 . S2CID  17612128.
  3. ^ Nierstrasz, Oscar; Dami, Laurent (enero de 1995). Composición de software orientada a objetos . Prentice Hall International. pp.  3– 28. CiteSeerX 10.1.1.90.8174 .  
  4. ^ De Hoon, Michiel JL; Imoto, Seiya; Nolan, Juan; Miyano, Satoru (febrero de 2004). "Software de agrupación en clústeres de código abierto". Bioinformática . 20 (9): 1453– 1454. Bibcode : 2004Bioin..20.1453D. CiteSeerX 10.1.1.114.3335 . doi : 10.1093/bioinformática/bth078.  
  5. ^ Duc Linh, Nguyen; Duy Hung, Phan; Dipe, Vu Thu (2019). "Gestión de riesgos en proyectos basados ​​en software de código abierto". Actas de la 8.ª Conferencia internacional sobre software y aplicaciones informáticas de 2019. págs.  178– 183. doi :10.1145/3316615.3316648. ISBN  9781450365734.S2CID153314145  .​
  6. ^ "Historia de la OSI". Opensource.org. 19 de septiembre de 2006.
  7. ^ Payne, Christian (2002). "Sobre la seguridad del software de código abierto" (PDF) . Revista de sistemas de información . 12 : 61–78 . doi :10.1046/j.1365-2575.2002.00118.x. S2CID  8123076.
  8. ^ Kaur, Sumandeep (abril de 2020). "Cuestiones de seguridad en el software de código abierto" (PDF) . Revista internacional de informática y comunicación : 47– 51.
  9. ^ Ombredanne, Philippe (octubre de 2020). «Cumplimiento de licencias de software libre y de código abierto: herramientas para el análisis de la composición de software». Computer . 53 (10): 262– 264. doi : 10.1109/MC.2020.3011082 . S2CID  222232127.
  10. ^ Duan, Ruian; Bijlani, Ashish; Xu, Meng; Kim, Taesoo; Lee, Wenke (2017). "Identificación de violaciones de licencias de código abierto y riesgo de seguridad de un día a gran escala". Actas de la Conferencia ACM SIGSAC de 2017 sobre seguridad informática y de las comunicaciones . ACM. págs.  2169– 2185. doi :10.1145/3133956.3134048. ISBN .  9781450349468.S2CID 7402387  .
  11. ^ Arora, Arushi; Wright, Virginia; Garman, Christina (2022). "Fortalecimiento de la seguridad de la tecnología operativa: comprensión de la lista de materiales contemporánea" (PDF) . Revista de políticas de infraestructura crítica . 3 : 111– 135. doi :10.18278/jcip.3.1.8.
  12. ^ Bailey, T.; Greis, J.; Watters, M.; Welle, J. (19 de septiembre de 2022). "Lista de materiales de software: gestión de los riesgos de ciberseguridad del software". McKinsey & Company . Consultado el 6 de enero de 2024 .
  13. ^ Popp, Karl Michael (30 de octubre de 2019). Mejores prácticas para el uso comercial de software de código abierto. BoD – Books on Demand, 2019. p. 10. ISBN 9783750403093.
  14. ^ Imtiaz, Nasif; Thorn, Seaver; Williams, Laurie (octubre de 2021). "Un estudio comparativo de informes de vulnerabilidad mediante herramientas de análisis de composición de software". Actas del 15.º Simposio internacional ACM/IEEE sobre ingeniería y medición de software empírico (ESEM) . ACM. págs.  1– 11. arXiv : 2108.12078 . doi :10.1145/3475716.3475769. ISBN .  9781450386654.S2CID237346987  .​
  15. ^ Sun, Xiaohan; Cheng, Yunchang; Qu, Xiaojie; Li, Hang (junio de 2021). "Diseño e implementación de un canal de pruebas de seguridad basado en DevSecOps". 2021 IEEE 4th Advanced Information Management, Communicates, Electronic and Automation Control Conference (IMCEC) . Vol. 4. IEEE. págs.  532– 535. doi :10.1109/IMCEC51613.2021.9482270. ISBN  978-1-7281-8535-4. Número de identificación del sujeto  236193144.
  16. ^ "Elementos y consideraciones de la lista de materiales de software". Registro Federal . 6 de febrero de 2021 . Consultado el 6 de enero de 2024 .
  17. ^ Serafini, Daniele; Zacchiroli, Stefano (septiembre de 2022). "Identificación eficiente de publicaciones previas para código fuente abierto". El 18.º Simposio Internacional sobre Colaboración Abierta . Vol. 4. ACM. págs.  1– 8. arXiv : 2207.11057 . doi :10.1145/3555051.3555068. ISBN .  9781450398459. Número de identificación del sujeto  251018650.
  18. ^ Chen, Yang; Santosa, Andrew E; Sharma, Asankhaya; Lo, David (septiembre de 2020). "Identificación automatizada de bibliotecas a partir de datos de vulnerabilidad". Actas de la 42.ª Conferencia internacional sobre ingeniería de software de la ACM/IEEE: Ingeniería de software en la práctica. págs.  90-99 . doi :10.1145/3377813.3381360. ISBN  9781450371230.S2CID211167417  .​
  19. ^ Kengo Oka, Dennis (2021). "Análisis de la composición del software en la industria automotriz". Building Secure Cars (Construcción de automóviles seguros). Wiley. págs.  91– 110. doi :10.1002/9781119710783.ch6. ISBN  9781119710783. Número de identificación del sujeto  233582862.
  20. ^ Rajapakse, Roshan Namal; Zahedi, Mansooreh; Babar, Muhammad Ali (2021). "Un análisis empírico de las perspectivas de los profesionales sobre la integración de herramientas de seguridad en DevOps". Actas del 15.º Simposio internacional ACM/IEEE sobre ingeniería y medición de software empírico (ESEM) . pp.  1– 12. arXiv : 2107.02096 . doi :10.1145/3475716.3475776. ISBN .  9781450386654. Número de identificación del sujeto  235731939.
  21. ^ Imtiaz, Nasif; Thorn, Seaver; Williams, Laurie (2021). "Un estudio comparativo de informes de vulnerabilidad mediante herramientas de análisis de composición de software". Actas del 15.º Simposio internacional ACM/IEEE sobre ingeniería y medición de software empírico (ESEM) . pp.  1– 11. arXiv : 2108.12078 . doi :10.1145/3475716.3475769. ISBN .  9781450386654.S2CID237346987  .​
  22. ^ "Análisis de componentes". owasp.org .
  23. ^ Foo, Darius; Chua, Hendy; Yeo, Jason; Ang, Ming Yi; Sharma, Asankhaya (2018). "Comprobación estática eficiente de actualizaciones de bibliotecas". Actas de la 26.ª reunión conjunta de la ACM de 2018 sobre la conferencia y el simposio sobre los fundamentos de la ingeniería de software europea . págs.  791– 796. doi :10.1145/3236024.3275535. ISBN .  9781450355735.S2CID 53079466  .
  24. ^ Millar, Stuart (noviembre de 2017). "Detección de vulnerabilidades en software de código abierto: la cura y la causa" (PDF) . Queen's University Belfast.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Análisis_de_composición_de_software&oldid=1265201206"
Lecturas relacionadas
6 articulos
Ingeniería de software basada en componentesIngeniería de software basada en componentesLa ingeniería de software basada en componentes ( CBSE ), también llamada desarrollo basado en componentes ( CBD ), es un estilo de ingeniería de s...Software de código abiertoUna captura de pantalla de Manjaro ejecutando el entorno de escritorio Cinnamon , Firefox accediendo a Wikipedia que utiliza MediaWiki , LibreOffic...Vulnerabilidades y exposiciones comunesVulnerabilidades y exposiciones comunesEl sistema de Vulnerabilidades y Exposiciones Comunes ( CVE ), originalmente Enumeración de Vulnerabilidades Comunes , [ 1 ] proporciona un método ...Propiedad intelectualPropiedad intelectualLa propiedad intelectual ( PI ) es una categoría de propiedad que incluye creaciones intangibles del intelecto humano. [1] [2] Existen muchos tipos...ObsolescenciaObsolescenciaLa obsolescencia es el proceso de volverse anticuado, obsoleto, pasado de moda, fuera de uso general o inservible, o la condición de estar en tal e...Una gran "C" verde girada 90 grados en el sentido de las agujas del reloj para formar una especie de ojo de cerradura marcado con una pequeña "R" en un círculo que indica una marca registrada y las palabras "código abierto" debajo.Iniciativa de código abiertoLa Iniciativa de Código Abierto ( OSI ) es el administrador de la Definición de Código Abierto , el estándar más utilizado para el software de códi...