✖


Jump to content

Анализ состава программного обеспечения

Разработка программного обеспечения с использованием различных компонентов является обычной практикой разработки программного обеспечения. [1] Использование программных компонентов разделяет сложность более крупных элементов на более мелкие фрагменты кода и повышает гибкость, позволяя упростить повторное использование компонентов для удовлетворения новых требований. [2] Эта практика широко распространилась с конца 1990-х годов благодаря популяризации программного обеспечения с открытым исходным кодом (OSS), которое помогает ускорить процесс разработки программного обеспечения и сократить время выхода на рынок. [3]

Однако использование программного обеспечения с открытым исходным кодом создает множество рисков для разрабатываемых программных приложений. Эти риски можно разделить на 5 категорий: [4]

Вскоре после основания Open Source Initiative в феврале 1998 г. [5] были подняты риски, связанные с OSS [6] и организации пытались управлять этим, используя электронные таблицы и документы для отслеживания всех компонентов с открытым исходным кодом, используемых их разработчиками. [7]

Организациям, широко использующим компоненты с открытым исходным кодом, возникла необходимость помочь автоматизировать анализ и управление рисками с открытым исходным кодом. В результате появилась новая категория программных продуктов под названием «Анализ состава программного обеспечения» (SCA), которая помогает организациям управлять рисками с открытым исходным кодом.SCA стремится обнаружить все сторонние компоненты, используемые в программном приложении, чтобы снизить риски, связанные с уязвимостями безопасности, требованиями IP-лицензии и устареванием используемых компонентов.

Обзор [ править ]

Анализ состава программного обеспечения (SCA) — это практика в области информационных технологий и разработки программного обеспечения, предназначенная для анализа специально созданных программных приложений с целью обнаружения встроенного программного обеспечения с открытым исходным кодом и определения того, являются ли они актуальными, содержат ли они недостатки безопасности или имеют ли они лицензию. требования. [8]

Продукты SCA обычно работают следующим образом: [9]

  • Механизм сканирует исходный код программного обеспечения и связанные с ним артефакты, используемые для компиляции программного приложения.
  • Механизм идентифицирует компоненты OSS и их версии и обычно сохраняет эту информацию в базе данных, создавая каталог OSS, используемый в сканируемом приложении.
  • Затем этот каталог сравнивается с базами данных, в которых указаны известные уязвимости безопасности для каждого компонента, лицензионные требования для использования компонента и исторические версии компонента. [ нужна ссылка ] Для обнаружения уязвимостей безопасности это сравнение обычно проводится с известными уязвимостями безопасности (CVE), которые отслеживаются в Национальной базе данных уязвимостей (NVD). Некоторые продукты используют дополнительную собственную базу уязвимостей. Для обеспечения соответствия требованиям интеллектуальной собственности и законодательства продукты SCA извлекают и оценивают тип лицензирования, используемый для компонента OSS. [10] Версии компонентов извлекаются из популярных репозиториев с открытым исходным кодом, таких как GitHub , Maven , PyPi , NuGet и многих других.
  • Результаты затем предоставляются конечным пользователям в различных цифровых форматах. Содержание и формат зависят от продукта SCA и могут включать руководство по оценке и интерпретации риска, а также рекомендации, особенно когда это касается юридических требований к компонентам с открытым исходным кодом, таких как лицензирование с сильным или слабым авторским левом . Выходные данные также могут содержать спецификацию программного обеспечения (SBOM), в которой подробно описываются все компоненты с открытым исходным кодом и связанные атрибуты, используемые в программном приложении. [11]

Использование [ править ]

Поскольку SCA влияет на различные функции в организациях, разные команды могут использовать данные в зависимости от размера и структуры корпорации. ИТ-отдел часто использует SCA для внедрения и внедрения технологии совместно с общими заинтересованными сторонами, включая директора по информационным технологиям (CIO), главного технического директора (CTO) и главных архитекторов предприятия (EA). [12] Данные о безопасности и лицензиях часто используются такими должностями, как директора по информационной безопасности (CISO) для рисков безопасности и директор по интеллектуальной собственности/соответствию для управления рисками интеллектуальной собственности. [13]

(IDE) разработчика, В зависимости от возможностей продукта SCA он может быть реализован непосредственно в интегрированной среде разработки который использует и интегрирует компоненты OSS, или может быть реализован как отдельный этап процесса контроля качества программного обеспечения . [14] [15]

Продукты SCA, и особенно их способность генерировать SBOM, необходимы в некоторых странах, например в США, для обеспечения безопасности программного обеспечения, поставляемого поставщиком в одно из их агентств. [16]

Еще одним распространенным вариантом использования SCA является комплексная проверка технологий . Перед сделкой по слиянию и поглощению (M&A) консультационные фирмы анализируют риски, связанные с программным обеспечением целевой фирмы. [17]

SCA стороны Сильные ​

Автоматический характер продуктов SCA является их основным преимуществом. Разработчикам не нужно вручную выполнять дополнительную работу при использовании и интеграции компонентов OSS. [18] Автоматизация также применяется к косвенным ссылкам на другие компоненты OSS в коде и артефактах. [19]

SCA стороны Слабые ​

И наоборот, некоторые ключевые недостатки текущих продуктов SCA могут включать в себя:

  • Сложное и трудоемкое развертывание, полное введение которого в эксплуатацию может занять месяцы. [20]
  • Каждый продукт использует собственную базу данных компонентов OSS, которые могут существенно различаться по размеру и охвату. [21]
  • Ограничение данных об уязвимостях отчетами только об уязвимостях, официально зарегистрированных в NVD (это может быть через несколько месяцев после первоначального обнаружения уязвимости). [22]
  • Отсутствие автоматизированных указаний о действиях, которые необходимо предпринять на основе отчетов и данных SCA. [23]
  • Отсутствие указаний о юридических требованиях к обнаруженным лицензиям OSS. [24]

См. также [ править ]

Ссылки [ править ]

  1. ^ Ньерстраз, Оскар; Мейлер, Тео Дирк (1995). «Направления исследований в области композиции программного обеспечения» . Обзоры вычислительной техники ACM . 27 (2). АКМ: 262–264. дои : 10.1145/210376.210389 . S2CID   17612128 .
  2. ^ Ньерстраз, Оскар; Дами, Лоран (январь 1995 г.). Объектно-ориентированная композиция программного обеспечения . Prentice Hall International (UK) Ltd., стр. 3–28. CiteSeerX   10.1.1.90.8174 .
  3. ^ Де Хун, Мишель Дж.Л.; Имото, Сейя; Нолан, Джон; Мияно, Сатору (февраль 2004 г.). «Программное обеспечение для кластеризации с открытым исходным кодом». Биоинформатика . Издательство Оксфордского университета: 1453–1454. CiteSeerX   10.1.1.114.3335 .
  4. ^ Дык Линь, Нгуен; Дуй Хунг, Фан; Дипе, Ву Ту (2019). «Управление рисками в проектах на основе открытого программного обеспечения» . Материалы 8-й Международной конференции по программному обеспечению и компьютерным приложениям 2019 года . стр. 178–183. дои : 10.1145/3316615.3316648 . ISBN  9781450365734 . S2CID   153314145 .
  5. ^ «История ОСИ» . Opensource.org. 19 сентября 2006 г.
  6. ^ Пейн, Кристиан (2002). «О безопасности программного обеспечения с открытым исходным кодом» (PDF) . Журнал информационных систем . 12 : 61–78. дои : 10.1046/j.1365-2575.2002.00118.x . S2CID   8123076 .
  7. ^ Каур, Сумандип (апрель 2020 г.). «Проблемы безопасности в программном обеспечении с открытым исходным кодом» (PDF) . Международный журнал компьютерных наук и коммуникаций : 47–51.
  8. ^ Прана, Геде Артха Азриади; Шарма, Абхишек; Шар, Львин Кхин; Фу, Дариус; Сантоса, Эндрю Э; Шарма, Асанхая; Ло, Дэвид (июль 2021 г.). «С глаз долой, из головы? Как уязвимые зависимости влияют на проекты с открытым исходным кодом» . Эмпирическая программная инженерия . 26 (4). Спрингер: 1–34. дои : 10.1007/s10664-021-09959-3 . S2CID   197679660 .
  9. ^ Омбреданн, Филипп (октябрь 2020 г.). «Соответствие лицензии на бесплатное и открытое программное обеспечение: инструменты для анализа состава программного обеспечения» . Компьютер . 53 (10). ИИЭР: 262–264. дои : 10.1109/MC.2020.3011082 . S2CID   222232127 .
  10. ^ Дуань, Руян; Биджлани, Ашиш; Сюй, Мэн; Ким, Тэсу; Ли, Венке (2017). «Выявление нарушений лицензии на ПО с открытым исходным кодом и однодневных угроз безопасности в больших масштабах» . Материалы конференции ACM SIGSAC 2017 по компьютерной и коммуникационной безопасности . АКМ. стр. 2169–2185. дои : 10.1145/3133956.3134048 . ISBN  9781450349468 . S2CID   7402387 .
  11. ^ Арора, Аруши; Райт, Вирджиния; Гарман, Кристина (2022). «Усиление безопасности эксплуатационных технологий: понимание современной спецификации материалов» (PDF) . JCIP, Журнал политики критической инфраструктуры : 111.
  12. ^ Бейли, Т.; Грейс, Дж.; Уоттерс, М.; Велле, Дж. (19 сентября 2022 г.). «Спецификация программного обеспечения: Управление рисками кибербезопасности программного обеспечения» . МакКинси и компания . Проверено 6 января 2024 г.
  13. ^ Попп, Карл Майкл (30 октября 2019 г.). Лучшие практики коммерческого использования программного обеспечения с открытым исходным кодом . Совет директоров – Книги по запросу, 2019. с. 10. ISBN  9783750403093 .
  14. ^ Имтиаз, Насиф; Торн, Сивер; Уильямс, Лори (октябрь 2021 г.). «Сравнительное исследование отчетов об уязвимостях с помощью инструментов анализа состава программного обеспечения» . Материалы 15-го Международного симпозиума ACM / IEEE по эмпирической разработке программного обеспечения и измерениям (ESEM) . АКМ. стр. 1–11. arXiv : 2108.12078 . дои : 10.1145/3475716.3475769 . ISBN  9781450386654 . S2CID   237346987 .
  15. ^ Сунь, Сяохань; Ченг, Юньчан; Цюй, Сяоцзе; Ли, Ханг (июнь 2021 г.). «Проектирование и реализация конвейера тестирования безопасности на основе DevSecOps» . 2021 г. 4-я конференция IEEE по расширенному управлению информацией, коммуникациям, электронному и автоматическому управлению (IMCEC) . Том. 4. ИИЭР. стр. 532–535. дои : 10.1109/IMCEC51613.2021.9482270 . ISBN  978-1-7281-8535-4 . S2CID   236193144 .
  16. ^ «Элементы и соображения спецификации программного обеспечения» . Федеральный реестр . 6 февраля 2021 г. Проверено 6 января 2024 г.
  17. ^ Серафини, Даниэле; Закчироли, Стефано (сентябрь 2022 г.). «Эффективная идентификация предыдущих публикаций открытого исходного кода» . 18-й Международный симпозиум по открытому сотрудничеству . Том. 4. АКМ. стр. 1–8. arXiv : 2207.11057 . дои : 10.1145/3555051.3555068 . ISBN  9781450398459 . S2CID   251018650 .
  18. ^ Чен, Ян; Сантоса, Эндрю Э; Шарма, Асанхая; Ло, Дэвид (сентябрь 2020 г.). «Автоматическая идентификация библиотек по данным об уязвимостях» . Материалы 42-й Международной конференции ACM/IEEE по программной инженерии: программная инженерия на практике . стр. 90–99. дои : 10.1145/3377813.3381360 . ISBN  9781450371230 . S2CID   211167417 .
  19. ^ Кенго Ока, Деннис (2021). «Анализ состава программного обеспечения в автомобильной промышленности» . Создание безопасных автомобилей: обеспечение жизненного цикла разработки автомобильного программного обеспечения . Уайли: 91–110. дои : 10.1002/9781119710783 . ISBN  9781119710783 . S2CID   233582862 .
  20. ^ Раджапаксе, Рошан Намаль; Захеди, Мансура; Бабар, Мухаммед Али (2021). «Эмпирический анализ взглядов практиков на интеграцию инструментов безопасности в DevOps» . Материалы 15-го Международного симпозиума ACM / IEEE по эмпирической разработке программного обеспечения и измерениям (ESEM) . стр. 1–12. arXiv : 2107.02096 . дои : 10.1145/3475716.3475776 . ISBN  9781450386654 . S2CID   235731939 .
  21. ^ Имтиаз, Насиф; Торн, Сивер; Уильямс, Лори (2021). «Сравнительное исследование отчетов об уязвимостях с помощью инструментов анализа состава программного обеспечения» . Материалы 15-го Международного симпозиума ACM / IEEE по эмпирической разработке программного обеспечения и измерениям (ESEM) . стр. 1–11. arXiv : 2108.12078 . дои : 10.1145/3475716.3475769 . ISBN  9781450386654 . S2CID   237346987 .
  22. ^ «Компонентный анализ» . owasp.org .
  23. ^ Фу, Дариус; Чуа, Хенди; Да, Джейсон; Анг, Мин Йи; Шарма, Асанхая (2018). «Эффективная статическая проверка обновлений библиотеки» . Материалы 26-й совместной встречи ACM по Европейской конференции по разработке программного обеспечения и симпозиума по основам программной инженерии в 2018 году . стр. 791–796. дои : 10.1145/3236024.3275535 . ISBN  9781450355735 . S2CID   53079466 .
  24. ^ Миллар, Стюарт (ноябрь 2017 г.). «Обнаружение уязвимостей в программном обеспечении с открытым исходным кодом: лечение и причина» (PDF) . Королевский университет Белфаста .
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_composition_analysis&oldid=1222325781"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: e200f3daf324c0bfaaa21de9715cff55__1714892880
URL1:https://arc.ask3.ru/arc/aa/e2/55/e200f3daf324c0bfaaa21de9715cff55.html
Заголовок, (Title) документа по адресу, URL1:
Software composition analysis - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)