Про Профстандарты РосМинТруда Модель качества программного обеспечения согласно ISO 9126
Стандарт ISO/ IEC 9126 был выпущен 19 декабря 1991 года, 15 июня 2001 года ISO/IEC 9126:1991 был расширен в систему из четырёх взаимосвязанных стандартов: ISO/ IEC 9126: 2001:
Функциональность — «Набор атрибутов, которые влияют на существование набора функций и их заданных свойств. Функции — это характеристики ПО, которые удовлетворяют заявленные или подразумеваемые потребности».
Надёжность — «Набор атрибутов, которые влияют на способность программного обеспечения поддерживать свой уровень производительности при указанных условиях в течение указанного периода времени».
Юзабилити — «Набор атрибутов, которые влияют на усилия, необходимые для использования, и на индивидуальную оценку такого использования заявленным или подразумеваемым набором пользователей».
Эффективность — «Набор атрибутов, которые влияют на взаимосвязь между уровнем производительности программного обеспечения и количеством используемых ресурсов при указанных условиях».
Ремонтопригодность — «Набор атрибутов, влияющих на усилия, необходимые для внесения определённых изменений».
Каждая субхарактеристика качества (например, адаптивность) далее делится на атрибуты. Атрибут — это свойство, которое можно проверить или измерить в программном продукте. Атрибуты не определены в стандарте, поскольку они различаются для разных программных продуктов.
Программный продукт определяется в широком смысле: он включает в себя исполняемые файлы, исходный код, описания архитектуры и так далее. В результате понятие пользователя распространяется на операторов, а также на программистов, которые являются пользователями таких компонентов, как библиотеки программного обеспечения.
Стандарт предоставляет организациям основу для определения модели качества программного продукта. Однако при этом каждая организация оставляет за собой задачу точно определить свою собственную модель. Это может быть сделано, например, путем определения целевых значений для показателей качества, которые оценивают степень присутствия атрибутов качества.
Управление проектами — это сложная и ответственная задача, требующая от проектных менеджеров, команд, групп и персонала высокого уровня компетентности, навыков и опыта. Чтобы с успехом реализовывать проекты различной сложности и масштаба, необходимо применять эффективные методы, инструменты и практики. Но как выбрать самые подходящие и актуальные подходы к менеджменту в разных ситуациях? Как обеспечить единообразие и согласованность действий внутри компании или между разными компаниями? Как повысить продуктивность и результативность управления проектами и добиваться лучших итоговых результатов?
На эти и многие другие вопросы помогают ответить стандарты управления проектами. Они представляют собой документы, содержащие набор правил, рекомендаций и требований по менеджменту. Стандарты разрабатываются различными компаниями, бизнесами и институтами, занятыми развитием специализации менеджера. Они дают возможность сформировать общий язык и понимание, повышают квалификацию и компетентность персонала.
В статье рассмотрим главные виды стандартов управления проектами, существующие в мире и в нашей стране, а также расскажем о том, как выбирать различные виды стандартов на основании целей и задач проекта.
Что представляют собой стандарты управления проектами?
Стандарты управления проектами — это документы, определяющие понятия, термины, методологии, фазы, роли, обязанности и компетентность в сфере проектного менеджмента. Они представляют собой совокупность знаний и опыта работы, проверенных практически и признанных авторитетными источниками. Они служат для того, чтобы:
Стандарты управления проектами не являются жесткими инструкциями или рецептами, которым нужно следовать безотказно. Они предоставляют общие рекомендации и руководства, которые нужно адаптировать и применять, ориентируясь на особенности конкретного проекта, организации, отрасли или региона. Они постоянно обновляются и совершенствуются в соответствии с изменениями в среде, технологиях, требованиях и ожиданиях заинтересованных сторон.
Основные задачи стандартизации управления проектами
Стандартизация управления проектами — это процесс разработки, принятия, распространения и применения стандартов. Этот процесс выполняет следующие основные задачи:
Виды стандартов
Существует множество различных стандартов менеджмента, которые разрабатываются и публикуются разными компаниями. Можно выделить следующие виды:
PMI
PMI — это крупнейшая в мире некоммерческая организация, занимающаяся обеспечением развития и продвижения профессии управленца. PMI разрабатывает и публикует различные стандарты по управлению программами, рисками, требованиями и другими аспектами деятельности. Самый известный и распространенный из них — это PMBOK, свод знаний, содержащий описание основных понятий, терминов, фаз, систем и их элементов, процессов и сфер знаний по управлению проектами. PMBOK является базисом для присвоения сотрудникам сертификатов по программе PMP. Кроме PMBOK, PMI также издает другие стандарты:
Стандарты PMI отличаются высоким уровнем детализации, формализации и универсальности. Так, они подходят для управления проектами различной сложности и масштаба в любой отрасли. Являются базисом для системы сертификации профессиональных управленцев по разным уровням и направлениям. Доступны на разных языках, в том числе на русском.
IPMA
IPMA — это ассоциация по управлению проектами, объединяющая более 70 национальных организаций в разных уголках мира. Самый известный и распространенный стандарт IPMA — это ICB, базовый стандарт компетенций управленца, содержащий описание 29 компетенций, требующихся для эффективного управления проектами. Компетенции можно разделить на три категории: технические, связанные с поведением и контекстные. ICB является базисом для сертификации сотрудников по программе IPMA 4-L-C (IPMA Four Level Certification System). Кроме ICB, IPMA издает другие стандарты:
Стандарты IPMA отличаются высочайшим уровнем гибкости, адаптивности и ориентации на человеческий фактор. Так, они подходят для управления проектами разной сложности и масштаба в любой отрасли. Являются основой для сертификации профессиональных управленцев по разным уровням и направлениям. Данные доступны на разных языках, включая русский.
OGC
OGC (Office of Government Commerce) — это бывшее подразделение правительства Великобритании, занимавшееся разработкой и публикацией элементов системы различных стандартов и методологий по управлению проектами, программами, портфелями, услугами и другими аспектами бизнеса. Самый известный и распространенный стандарт OGC — это PRINCE2, методология, содержащая описание основных понятий, терминов, тем. PRINCE2 выполняет роль основы для сертификации профессиональных сотрудников по программе PRINCE2 Foundation и PRINCE2 Practitioner. Кроме PRINCE2, OGC также издавало другие методологии, такие как:
Стандарты OGC отличаются высоким уровнем структурированности, интеграции и адаптации к специфике государственного сектора. Так, они подходят для управления проектами различной сложности и масштаба в государственных или частных компаниях.
APM
APM (Association for Project Management) — это крупнейшая в Европе профессиональная ассоциация по управлению проектами, основанная в 1972 году в Великобритании и объединяющая более 30 тысяч членов в более чем 40 государствах мира.
Самый известный и распространенный стандарт APM — это APM Body of Knowledge — свод знаний, содержащий описание 69 областей знаний (включает цели, принципы, темы, техники и инструменты работ). APM также издает другие стандарты:
Стандарты APM отличаются высоким уровнем практичности, актуальности и ориентации на результат работ.
PMAJ
PMAJ (Project Management Association of Japan) — это японская ассоциация, объединяющая более 10 тысяч участников в Японии и других азиатских государствах. Самый известный стандарт PMAJ, связанный с методологией по управлению проектами, ориентированной на развитие инноваций и поощрение новых открытий в организациях.
ISO
ISO — это объединение по стандартизации, объединившее национальные органы по стандартизации из 160 государств мира. Разрабатывает и публикует стандарты по разным сферам деятельности, связанным с управлением проектами. Самый известный и распространенный стандарт ISO по управлению проектами — это ISO 21500:2012, гайд по управлению проектами, содержащий описание основных понятий, терминов, принципов.
Российские стандарты управления проектами
В России существуют различные стандарты по управлению проектами, которые разрабатываются и принимаются разными организациями и органами власти. Некоторые из них являются адаптациями международных, другие являются оригинальными разработками, учитывающими специфику российского рынка и культуры. Некоторые из наиболее известных и распространенных стандартов по управлению проектами, разработанных в России, это:
Стандарты по управлению проектами, созданные в России, отличаются высоким уровнем соответствия международным требованиям и тенденциям, учетом специфики российского рынка и культуры. Подходят для управления проектами различной сложности и масштаба в любой отрасли. Являются основой для национальной сертификации систем качества в организациях.
Организационная зрелость в сфере проектного менеджмента
Организационная зрелость — это степень, в которой компания способна эффективно и последовательно управлять своими проектами, программами и портфелями. Организационная зрелость зависит от многих факторов:
Оценка организационной зрелости выполняется с помощью различных моделей и методик, позволяющих определить сильные и слабые стороны организации, выявить пути улучшения, развития, повышения уровня работы. Некоторые из наиболее известных и распространенных моделей и методик оценки зрелости — это:
Организационная зрелость имеет большое значение для повышения показателей эффективности менеджмента и для достижения стратегических целей и конкурентных преимуществ организации. Этот показатель требует постоянного измерения, анализа, улучшения и развития.
Как выбирать и применять разные виды стандартов?
В заключение мы хотели бы поделиться с вами несколькими советами по выбору и использованию стандартов по управлению проектами:
Обучение проводится в дистанционном формате с использованием современных технологий обучения. Курсовая программа включает теоретические лекции, практические задания, тесты и кейс-стади.
Мы предлагаем доступ к учебным материалам навсегда по исключительно выгодной стоимости. Внести оплату можно частями, воспользовавшись услугой внутренней рассрочки без участия банка.
Ждем вас в НИПКЭФ!
Что такое обеспечение качества программного обеспечения?
Обеспечение качества программного обеспечения (Software Quality Assurance, SQA) — это комплекс мероприятий, который гарантирует, что все процессы и методы разработки ПО контролируются и соответствуют установленным стандартам. К этим стандартам относятся, например, ISO 9000, модель CMMI и ISO 15504.
SQA включает в себя все процессы разработки программного обеспечения, от формирования техзадания до разработки программы (включая написание кода) и вплоть до выпуска готового продукта. Главная цель — обеспечить качество.
План контроля качества ПО (по-английски сокращается как SQAP, от Software Quality Assurance Plan) включает в себя методы и средства, позволяющие убедиться, что продукт или услуга отвечают установленным для него требованиям спецификации (в англоязычных источниках SRS, Software Requirement Specification).
В этом плане определяются обязанности команды по обеспечению качества ПО и перечисляются пункты, которые должны быть проверены. Также в нем указывается, к какому результату должен привести весь процесс обеспечения качества.
Документ с планом контроля качества состоит из следующих разделов
В первую очередь, необходимо составить четкий план того, как именно в вашем проекте будет осуществляться управление качеством.
В зависимости от того, какого подхода вы собираетесь придерживаться и какие технологии планируется задействовать будут проводиться, план также может включать контроль за подбором экспертов в вашей команде.
Установка контрольных точек
Команда устанавливает ряд контрольных точек, в соответствии с которыми она оценивает качество проектной деятельности на каждом этапе проекта. Это обеспечивает регулярную проверку качества и работу в соответствии с графиком.
Участие в сборе требований для группы разработчиков
Для достижения высокого качества продукта необходимо совмещать тестирование с процессом его разработки. Для сбора необходимой информации разработчик может использовать такие методы, как интервью или метод быстрого анализа решений (Functional Analysis System Technique, FAST).
Позже, основываясь на собранной информации, разработчик может вычислить оценку временных затрат на реализацию проекта, используя такие метрики, как иерархическая структура работ (Work Breakdown Structure,WBS), количество строк коды (Source Lines of Code, SLOC) и метод функциональных точек (Function Points, FP).
Проведение технического анализа
Технический анализ (Formal Technical Review, FTR) проводится для оценки качества и дизайна прототипа ПО.
В этом процессе проводится встреча с разработчиками и другими техническими экспертами для обсуждения фактических требований к качеству программного обеспечения и качества его прототипа. Эта работа помогает обнаружить ошибки на ранней стадии жизненного цикла ПО и сократить усилия на его переработку на последующих этапах.
Работа над стратегией мультитестирования
Под стратегией мультитестирования подразумевается, что не следует полагаться только на какой-либо единственный подход к тестированию. Вместо этого необходимо проводить несколько разных видов тестирования для достижения лучшего качества.
Контроль за соблюдением технологических процессов
Этот вид деятельности обеспечивает соблюдение технологических процессов в ходе разработки ПО. Процесс разработки должен происходить в соответствии с установленными требованиями.
Данный этап можно условно разделить на две составляющие:
(i) Оценка продукта
Подтверждает, что программный продукт соответствует заданным требованиям, и что стандарты соблюдены.
(ii) Мониторинг процессов
Периодический контроль за разного рода метриками позволяет отследить, налажена ли работа по разработке ПО должным образом.
Управление изменениями
Позволяет убедиться, что все изменения контролируемы и вносятся с нашего ведома. Контроль изменений осуществляется вручную или с помощью инструментов автоматизации.
Подтверждая запросы на изменения, оценивая их характер и контролируя последствия, мы обеспечиваем поддержание качества программного обеспечения на этапах разработки и поддержки продукта.
Отслеживание зависимостей
Команда активно участвует в оценки влияния изменений, внесённых в результате устранения ошибок или существенных нововведений. Этот этап необходим, чтобы избежать нежелательных эффектов.
Для этого используются метрики качества программного обеспечения, которые позволяют руководителям проекта и самим разработчикам наблюдать за ходом разработки и предлагаемыми изменениями в течение всего жизненного цикла ПО и вносить коррективы там, где это необходимо.
Аудит системы обеспечения качества
Аудит позволяет проверить все фактические процессы жизненного цикла ПО и сравнить их с установленными требованиями.
Он также позволяет выяснить, было ли на самом деле выполнено то, о чем команда сообщала в своих отчетах. Эта деятельность также выявляет любые неожиданные проблемы.
Ведение записей и протоколов тестирования
Очень важно хранить необходимую документацию, связанную с обеспечением качества, и делиться требуемой информацией о процессах с заинтересованными сторонами. Результаты тестирования, аудита, отчеты о проверках, документация по запросам на изменения и тому подобное, должны храниться как для анализа, так и на будущее.
Работа с коллективом
Сильная команда разработчиков — та, в которой есть гармония между разными отделами. В самом деле, очень важно поддерживать хорошие отношения между отделом контроля качества и отделом разработки.
Известно, что тестировщики (испытатели) и разработчики ПО часто чувствуют превосходство друг над другом. Подобного рода взаимоотношений в командах следует избегать, так как это также может повлиять на общее качество продукта.
Стандарты обеспечения качества программного обеспечения
Разработка ПО в целом и обеспечение его качества в частности может потребовать соблюдения одного или нескольких стандартов.
Ниже рассматриваются некоторые из наиболее популярных стандартов
ISO 9000: Этот стандарт основан на семи принципах управления качеством, которые помогают организациям гарантировать, что их продукция или услуги соответствуют потребностям клиентов.
Семь принципов ISO 9000 представлены на рисунке ниже:
Уровень CMMI: CMMI расшифровывается как набор моделей совершенствования процессов (Capability maturity model Integration). Эта модель возникла в программной инженерии. Она может быть использована для совершенствования процессов в рамках проекта, отдела или всей организации.
Пять уровней CMMI и их характеристики описаны на рисунке ниже
Организация оценивается и получает рейтинг уровня зрелости (1—5) в зависимости от типа оценки.
Test Maturity Model integration, TMMi: Обобщённая модель зрелости процессов тестирования. Основанная на CMMi, эта модель фокусируется на уровнях зрелости в управлении качеством программного обеспечения и тестировании.
Пять уровней TMMi показаны на рисунке ниже
По мере перехода на более высокий уровень зрелости, организация достигает более высоких возможностей для производства высококачественной продукции с меньшим количеством дефектов и близким соответствием требованиям бизнеса.
Элементы обеспечения качества программного обеспечения
Существует десять основных элементов:
Техники обеспечения качества
Существует несколько техник, из которых наиболее распространен аудит. Но не стоит забывать и про другие.
Различные техники SQA включают в себя
SQA — это комплексная деятельность, которая осуществляется на протяжении всего жизненного цикла программного обеспечения.
Обеспечение качества программного обеспечения очень важно для того, чтобы программный продукт или услуга преуспели на рынке и оправдали ожидания клиентов.
Существуют различные виды деятельности, применяемые стандарты и методы, которым необходимо следовать, чтобы убедиться, что поставляемое программное обеспечение имеет высокое качества и соответствует потребностям бизнеса.
Перевод статьи – “What Is Software Quality Assurance (SQA): A Guide For Beginners”
Спецификация программного обеспечения (SBOM) — это список всех компонентов, библиотек и других зависимостей, используемых в программном приложении. Стандартные форматы SBOM включают SPDX, CycloneDX и CPE (Common Platform Enumeration). Эти форматы обеспечивают структурированный способ представления компонентов и зависимостей в программном приложении, упрощая понимание и управление рисками безопасности, связанными с этими компонентами.
В этой статье мы собираемся подробно объяснить, каковы различные форматы и стандарты SBOM, что должен включать SBOM и почему все организации должны его использовать.
Что такое стандарт SBOM?
Сложность и динамичный характер цепочек поставок современных программных систем создают серьезные проблемы для прозрачности. Отсутствие прозрачности увеличивает риски кибербезопасности и увеличивает затраты, связанные с разработкой, закупками и обслуживанием. Последствия этого имеют далеко идущие последствия, затрагивая не только бизнес, но и коллективные вопросы, такие как общественная и национальная безопасность в нашем взаимосвязанном мире.
Повышение прозрачности цепочек поставок программного обеспечения может привести к снижению рисков и затрат в области кибербезопасности за счет:
Сбор и обмен этой информацией в четком и последовательном формате может помочь снизить затраты, повысить надежность и повысить доверие к нашей цифровой инфраструктуре.
Для этой цели, Рабочая группа NTIA по прозрачности программного обеспечения по стандартам и форматам была создана в 2018 году для оценки текущих форматов спецификаций программного обеспечения и определения потенциальных вариантов использования в будущем. Группа изучила существующие стандарты и инициативы, связанные с идентификацией внешних компонентов и общих библиотек, используемых в программных продуктах, и передачей этой информации в машиночитаемом формате. Группа не рассматривала проприетарные форматы. Исходный опрос был выпущен в конце 2019 года и обновлен в 2021 году с упором на подчеркивание преимуществ экосистемы инструментов SBOM и важности координации и гармонизации в техническом мире SBOM. Ключевой вывод заключается в том, что данные SBOM могут передаваться в различных форматах, и экосистема должна поддерживать взаимодействие между ними.
Рабочая группа обнаружила, что обычно используются три формата:
Стоит отметить, что эти три формата имеют некоторую общую информацию. Однако они традиционно используются на разных этапах процесса разработки программного обеспечения и предназначены для разных аудиторий. В этой статье мы подробно обсудим каждый из этих форматов.
Что должно включать в себя SBOM?
Минимальные компоненты NTIA SBOM, называемые элементами, состоят из трех широких и взаимосвязанных областей. Эти элементы обеспечивают гибкий подход к прозрачности программного обеспечения, касаясь как технологии, так и функциональной работы. В будущем могут быть добавлены более подробные сведения или технические усовершенствования. Как упоминалось ранее, на данный момент это минимальные компоненты, и организациям может потребоваться больше компонентов. Возможность обеспечения прозрачности в цепочке поставок программного обеспечения может со временем улучшаться и развиваться.
минимально необходимые элементы для СБОМ обычно группируются в три категории:
Стандартный формат SPDX SBOM
Спецификация SPDX® (обмен данными программных пакетов) — это стандарт ISO/IEC для обмена информацией о компонентах программного обеспечения, лицензиях, авторских правах и сведениях о безопасности в различных форматах файлов. В рамках этого проекта был разработан и продолжает совершенствовать набор стандартов обмена данными, которые позволяют предприятиям и организациям обмениваться метаданными программного обеспечения в формате, понятном как людям, так и машинам, упрощая процессы цепочки поставок программного обеспечения.
Информация SPDX может быть связана с конкретными программными продуктами, компонентами или наборами компонентов, отдельными файлами или даже небольшими фрагментами кода. Проект SPDX сосредоточен на создании и совершенствовании языка для описания данных, которыми можно обмениваться как часть SBOM, а также на возможности представления этих данных в нескольких форматах файлов (RDF/XML, XLSX, тег-значение, JSON, YAML). и XML), чтобы упростить сбор и обмен информацией о пакетах программного обеспечения и соответствующем контенте, что приводит к сокращению времени и точности.
Спецификация SPDX описывает поля и разделы, необходимые для правильного документа, но важно отметить, что не все разделы являются обязательными — требуется только раздел информации о создании. Создатель документа может выбрать, какие разделы и поля он хочет включить, описывая программное обеспечение и метаданные, которыми он планирует поделиться.
SPDX может эффективно собирать данные спецификации программного обеспечения, представляя все компоненты, обнаруженные при разработке и развертывании программного обеспечения. Он используется для документирования образов дистрибутива .iso, контейнеров, пакетов программного обеспечения, двоичных файлов, исходных файлов, исправлений и даже небольших фрагментов кода, встроенных в другие файлы. SPDX предлагает комплексный набор связей для соединения элементов программного обеспечения внутри документов и между документами SBOM. Документ SPDX SBOM также может ссылаться на внешние источники, такие как Национальная база данных уязвимостей и другие метаданные системы упаковки.
Документ SPDX состоит из нескольких компонентов: информация о создании, информация о пакете, информация о файле, информация о фрагменте, другая информация о лицензировании, взаимосвязях и аннотациях.
Каждый документ SPDX может быть представлен полной реализацией модели данных и синтаксисом идентификатора, что позволяет осуществлять обмен между различными форматами вывода данных (RDF/XML, тег-значение, XLSX) и формальную проверку точности документа. Версия 2.2 спецификации SPDX включает дополнительные форматы вывода, такие как JSON, YAML и XML, а также устраняет «известные неизвестные», как указано в исходном документе SBOM. Дополнительную информацию о базовой модели данных SPDX можно найти в Приложении III к спецификации SPDX и на веб-сайте SPDX.
Стандартный формат CycloneDX SBOM
Проект CycloneDX был создан в 2017 году с целью разработки полностью автоматизированного стандарта SBOM, ориентированного на безопасность. Основная рабочая группа ежегодно выпускает неизменяемые и обратно совместимые версии, используя процесс стандартизации, основанный на оценке рисков. CycloneDX включает существующие спецификации, такие как URL-адрес пакета, CPE, SWID и идентификаторы лицензий и выражения SPDX. SBOM могут быть представлены в различных форматах, включая XML, JSON и буферы протокола (protobuf).
CycloneDX — это облегченная спецификация SBOM, предназначенная для использования в анализе компонентов цепочки поставок и обеспечении безопасности программного обеспечения. Он обеспечивает обмен информацией о перечне компонентов программного обеспечения, внешних службах и связях между ними. Это стандарт с открытым исходным кодом, разработанный OWASP (Open Web Application Security Project).
CycloneDX может отражать динамическую природу компонентов с открытым исходным кодом, исходный код которых доступен, модифицируется и может распространяться. Спецификация может представлять родословную компонента, включая его предков, потомков и варианты, описывая происхождение компонента с любой точки зрения, а также фиксации, исправления и различия, которые делают его уникальным.
Проект CycloneDX поддерживает список известных инструментов с открытым исходным кодом и проприетарных инструментов, которые поддерживают стандарт, поддерживаемый сообществом, или совместимы с ним.
Спецификация CycloneDX описывает подробную объектную модель, которая обеспечивает согласованность во всех реализациях. Его можно проверить с помощью схемы XML и схемы JSON или с помощью интерфейса командной строки CycloneDX. Типы мультимедиа для XML и JSON также предусмотрены для автоматической доставки и использования поддерживаемых форматов.
SBOM CycloneDX могут содержать следующую информацию: Метаданные спецификации, компоненты, сервисы, зависимости, композиции и расширения.
CycloneDX — это комплексный стандарт SBOM, который может характеризовать различные типы программного обеспечения, включая приложения, компоненты, службы, встроенное ПО и устройства. Он широко используется в различных отраслях для описания пакетов программного обеспечения, библиотек, платформ, приложений и образов контейнеров. Проект совместим с основными экосистемами разработки и предлагает реализации для фабрик программного обеспечения, такие как действия GitHub, что позволяет организациям полностью автоматизировать создание SBOM.
Теги SWID или теги идентификации программного обеспечения были созданы, чтобы позволить организациям прозрачно отслеживать программное обеспечение, установленное на их управляемых устройствах. Стандарт был установлен ISO в 2012 году и пересмотрен как ISO/IEC 19770-2:2015 в 2015 году. Эти теги содержат подробную информацию о конкретной версии программного продукта.
Стандарт SWID описывает жизненный цикл отслеживания программного обеспечения: тег SWID добавляется к конечной точке во время установки программного продукта и удаляется в процессе удаления продукта. Существование определенного тега SWID напрямую соответствует наличию описываемого им программного обеспечения. Многие организации по стандартизации, такие как Trusted Computing Group (TCG) и Internet Engineering Task Force (IETF), включают теги SWID в свои стандарты.
Для отслеживания жизненного цикла программного компонента в спецификации SWID предусмотрены четыре типа тегов: основной, исправленный, корпусной и дополнительный. Корпусные, первичные теги и теги исправлений служат схожим целям, поскольку они описывают существование и присутствие различных типов программного обеспечения, таких как установщики программного обеспечения, установки программного обеспечения и исправления программного обеспечения, а также возможные состояния программных продуктов. С другой стороны, дополнительные теги предоставляют дополнительную информацию, отсутствующую в корпусных, основных тегах или тегах исправлений.
Дополнительные теги можно связать с любым другим тегом, чтобы предоставить дополнительные метаданные, которые могут оказаться полезными. Вместе теги SWID могут выполнять различные функции, такие как обнаружение программного обеспечения, управление конфигурацией и управление уязвимостями.
Теги SWID могут функционировать как SBOM, поскольку они предоставляют идентифицирующую информацию для программного компонента, список файлов и криптографические хэши для артефактов компонента, а также информацию о происхождении создателя SBOM (тега) и создателя программного компонента. Теги также могут быть связаны с другими тегами, что позволяет представить дерево зависимостей.
Теги SWID могут создаваться в процессе сборки и упаковки, что позволяет автоматически создавать SBOM на основе тегов SWID при упаковке соответствующего программного компонента.
Почему важны спецификации программного обеспечения?
Спецификации программного обеспечения (SBOM) становятся все более важными для организаций, поскольку они стремятся управлять и защищать используемое ими программное обеспечение. На вопрос о том, нет короткого ответа что такое СБОМ. SBOM предоставляют полный список всех компонентов и зависимостей, составляющих пакет программного обеспечения, включая такую информацию, как номера версий, авторов и информацию о лицензии. Эта информация имеет решающее значение для безопасности и соответствия требованиям, а также для отслеживания происхождения программных компонентов.
Многие организации, в том числе в регулируемых отраслях, используют SBOM для обеспечения соблюдения таких правил, как Общий регламент по защите данных (GDPR) и Стандарт безопасности данных индустрии платежных карт (PCI DSS). SBOM также могут помочь в выявлении и устранении уязвимостей в программном обеспечении, а также в отслеживании происхождения компонентов программного обеспечения. Кроме того, SBOM могут помочь в управлении лицензиями на программное обеспечение, гарантируя, что организации используют программное обеспечение в соответствии с условиями своих лицензий.
SBOM также можно использовать для отслеживания использования программного обеспечения с открытым исходным кодом, которое становится все более распространенным в разработке программного обеспечения. Предоставляя подробную информацию о компонентах с открытым исходным кодом, используемых в пакете программного обеспечения, SBOM могут помочь организациям обеспечить соблюдение лицензий с открытым исходным кодом.
Кроме того, SBOM можно использовать для поддержки разработки и обслуживания программного обеспечения. Предоставляя подробную информацию о компонентах, используемых в пакете программного обеспечения, SBOM могут помочь разработчикам понять зависимости пакета программного обеспечения, что может помочь им выявить потенциальные проблемы совместимости и принять обоснованные решения об использовании новых компонентов.