Эти тенденции заставляют руководителей компаний задуматься над фундаментальным вопросом: могут ли они уверенно отчитаться за программное обеспечение, которое разрабатывают, покупают и внедряют? Для предприятий, стремящихся сочетать инновации с устойчивостью, прозрачность ПО может стать ценной основой. Она помогает разобраться в вопросах интеллектуальной собственности, лицензионных обязательств и экономических последствий решений, связанных с цепочкой поставок ПО.
Аарон Брэнсон — директор по развитию FossID, компании в сфере анализа состава программного обеспечения (SCA), специализирующейся на анализе исходного кода и прозрачности цепочек поставок ПО. Он отмечает, что ответ на этот вопрос начинается с понимания самого кода.
«Организации могут знать, с какими поставщиками они работают и какие программные продукты закупают, но для того, чтобы установить точный состав этих продуктов, может потребоваться дополнительное исследование», — говорит он.
Пробел в видимости
Библиотеки с открытым исходным кодом, транзитивные зависимости, компоненты, разработанные поставщиками, и фрагменты кода, сгенерированные ИИ, могут попадать в кодовую базу по разным каналам. Брэнсон подчёркивает важное различие. Данные поставщиков могут дать полезный контекст. Изучение же самого кода способно дать более глубокое понимание его происхождения и связанных с ним обязательств.
Этот пробел в видимости может сказываться на работе сразу нескольких подразделений бизнеса. Неясное происхождение ПО способно осложнить оценку интеллектуальной собственности, проверку лицензий, решения о закупках и гарантии, предоставляемые клиентам.
Брэнсон поясняет: «От того, насколько организация понимает своё программное обеспечение, может зависеть, насколько уверенно она оценивает создаваемые активы, принимаемые обязательства и обещания, которые даёт клиентам».
В этом контексте прозрачность ПО может способствовать принятию более обоснованных решений на протяжении всего жизненного цикла продукта.
ИИ меняет темп
Разработка с помощью ИИ добавляет этой проблеме ещё одно измерение.
«Компаниям нужно перестраивать контроль по мере ускорения разработки, — говорит Брэнсон. — ИИ может выдавать код за секунды, но наши процессы проверки, документирования и контроля соответствия просто не рассчитаны на такую скорость. К тому же небольшие фрагменты кода могут незаметно проникать в приложения, так и не появляясь в стандартных записях о зависимостях».
Он добавляет, что в связи с этим организациям может быть полезно проанализировать, как они составляют реестры своего ПО. Стоит также проверить, насколько достоверно эти записи отражают реально используемый код.
Важную роль в этом процессе играет качество документации. Спецификации программного обеспечения (SBOM) представляют собой структурированные реестры программных компонентов и зависимостей. Они помогают командам упорядочивать информацию о сложных продуктах. Документ CISA «Минимальные элементы спецификации программного обеспечения» 2026 года содержит рекомендации о том, какую информацию может включать SBOM и какую роль она играет в обеспечении прозрачности цепочки поставок ПО.
Для предприятий, получающих ПО от нескольких поставщиков, ценность таких реестров может зависеть от детальности, согласованности и актуальности предоставленной информации. Анализ исходного кода может дополнять документацию о зависимостях. Он помогает командам оценить, соответствуют ли записи о компонентах проверяемому программному обеспечению.
От происхождения к обязательствам
Работа FossID в области анализа состава ПО напрямую связана с этой потребностью в проверяемой информации. FossID разработала свою технологию для выявления компонентов с открытым исходным кодом, лицензий и фрагментов стороннего кода — в том числе тех, которые сложно отследить только по декларациям пакетов. Эта возможность помогает организациям исследовать состав ПО, включающего сторонние наработки или код, созданный с помощью ИИ.
«Сведения о происхождении ПО становятся полезнее, когда команды могут связать источник компонента с обязательствами, которые из этого могут вытекать», — отмечает Брэнсон.
Такая информация может дать инженерным, юридическим командам, а также специалистам по безопасности и соответствию требованиям общую основу для оценки решений, касающихся ПО.
Эти соображения также указывают на возможность глубже интегрировать управление в повседневную работу. Проверки состава ПО и лицензий могут стать частью конвейеров разработки, процедур закупок и процессов управления поставщиками. Если команды обновляют сведения о компонентах по мере изменения ПО, им может быть проще оценивать новые зависимости, проверять лицензионные требования и готовиться к оценке продукта или регуляторным проверкам.
Организации могут распределять ответственность за эту работу между разными подразделениями. Инженеры предоставляют технический контекст, юристы толкуют обязательства, отдел закупок проверяет информацию поставщиков, а руководство определяет приоритеты и зоны ответственности.
С чего начать руководителям
Как отмечает Брэнсон, руководители компаний могут начать с того, чтобы определить, кто отвечает за риски цепочки поставок ПО. Им также стоит рассмотреть, как эта ответственность встраивается в существующие структуры управления. Анализ методов создания, проверки и обновления реестров ПО может помочь выявить, где дополнительная проверка окажется полезной.
В процедуру комплексной проверки поставщиков также можно включить вопросы о составе ПО, его происхождении и качестве SBOM. Процессы управления жизненным циклом продукта могут устанавливать требования к поддержанию этих записей в актуальном состоянии. Согласование этих мер со скоростью разработки позволит управлению поддерживать инновации по мере того, как команды создают, интегрируют и выпускают код.
По сути, прозрачность ПО может дать предприятиям практическую основу для устойчивости, подотчётности и долгосрочных инноваций. ИИ расширяет возможности команд по созданию ПО, а взаимосвязанные цепочки поставок всё глубже встраиваются в организации. Понимание состава кода может помочь руководителям оценивать как возможности, так и обязательства.
Для Брэнсона более широкая цель состоит в том, чтобы связать создание ПО с осознанным контролем.
Он говорит: «Задача в том, чтобы сделать целостность цепочки поставок ПО центральным элементом инноваций в организациях, чтобы стратегии роста учитывали происхождение кода и связанные с ним обязательства».
Предприятия, сочетающие возможности разработки с достоверными знаниями о своём ПО, могут оказаться в более выгодном положении для принятия обоснованных решений — и так на протяжении всего жизненного цикла продукта.
Опубликовано 30 октября 2026 - 05:10 Наверх
