Аудит соответствия лицензионным требованиям посредством анализа зависимостей.

Запрос на проведение комплексной проверки в рамках сделки слияния и поглощения поступает во вторник утром: полный отчет о соответствии лицензионным требованиям для всего программного обеспечения с открытым исходным кодом должен быть представлен в пятницу. У юридического отдела есть три дня, чтобы составить перечень каждого компонента с открытым исходным кодом во всей кодовой базе продукта, каждой применимой лицензии и каждого обязательства, которые должны быть выполнены до юридической проверки приобретающей стороной. Для организаций, которые рассматривают соблюдение лицензионных требований как периодическую ручную проверку, это утро вторника становится началом одной из самых дорогостоящих аварийных ситуаций в сфере корпоративного программного обеспечения. Для организаций с развитой инфраструктурой анализа зависимостей это начинается с составления отчета.

Программное обеспечение в основном собирается, а не пишется. В отчете Black Duck 2026 OSSRA установлено, что 98% коммерческих кодовых баз содержат компоненты с открытым исходным кодом, 87% имеют как минимум одну известную уязвимость, а среднее число уязвимостей на одну кодовую базу увеличилось более чем вдвое за год. Аудит соответствия лицензиям — это дисциплина, которая отвечает на другой, но связанный вопрос: не только какие компоненты содержат уязвимости, но и какие компоненты налагают юридические обязательства в отношении того, как программное обеспечение может распространяться, модифицироваться или коммерциализироваться. Отсутствие зависимости от GPL-2.0 в проприетарном коммерческом продукте не является инцидентом безопасности. Это нарушение лицензии, которое может потребовать раскрытия исходного кода, судебного урегулирования или отзыва продукта.

Основой аудита соответствия лицензионным требованиям является анализ зависимостей — систематическое выявление каждого программного компонента, от которого кодовая база прямо или косвенно зависит, с полным указанием лицензии, регулирующей каждый компонент. Анализ зависимостей — это не сканирование манифеста пакета. Это полное структурное исследование того, что программное обеспечение фактически включает в себя во время сборки и выполнения, независимо от того, являются ли эти включения объявленными, транзитивными, встроенными или неявными.

Почему анализ зависимостей является основой?

Соблюдение лицензионных требований — это проблема зависимостей, а не юридическая проблема. Невозможно оценить лицензионные обязательства программного продукта, не зная сначала, из чего этот продукт состоит, из каждого компонента, каждой библиотеки, каждого скопированного фрагмента кода. Анализ лицензий является следствием инвентаризации зависимостей. Если инвентаризация проведена неправильно, анализ лицензий будет основан на неполной картине.

Для обеспечения соответствия лицензионным требованиям необходимо ответить на три вопроса, связанные с анализом зависимостей:

Какие компоненты включены? Не только прямые зависимости, объявленные в package.json or pom.xmlНо при этом учитывается каждая транзитивная зависимость, каждая встроенная библиотека, скопированная в исходный код, каждый статически связанный компонент, скомпилированный в бинарный файл, и каждый динамически загружаемый модуль, вызываемый во время выполнения. Хороший механизм анализа лицензий сопоставляет эти компоненты с базами данных уязвимостей, такими как NVD, проверяет метаданные лицензий и отмечает известные эксплойты или юридические риски до того, как они повлияют на ваш конвейер доставки. Этот же механизм должен также точно определять, что фактически находится в программном обеспечении, прежде чем анализ лицензий можно будет считать достоверным.

На каких лицензиях они распространяются? Компонент может иметь единую заявленную лицензию, двойную лицензию с опциями, несколько лицензий, применяемых к разным файлам, или лицензию, которая менялась в разных версиях. Механизм обнаружения лицензий FOSSA заявляет о точности в 99.8%, что важно, когда вашей юридической команде необходимо проверять обязательства в отношении открытого исходного кода наряду с перечнем требований безопасности. Идентификация лицензий на уровне компонента необходима, но недостаточна; идентификация на уровне файла или фрагмента кода необходима для компонентов, где разные файлы имеют разные лицензии.

Какие обязательства налагают эти лицензии? Разрешительная лицензия (MIT, Apache-2.0) налагает требования об указании авторства. Слабая лицензия с копилефтом (LGPL) налагает различные обязательства в зависимости от того, динамически или статически связан компонент. Сильная лицензия с копилефтом (GPL-2.0, GPL-3.0) может потребовать распространения исходного кода всего объединенного произведения. Понимание обязательств требует понимания условий лицензии, а не только идентификатора лицензии.

Четыре типа зависимостей, создающих уязвимость для лицензионных соглашений

Не все зависимости одинаково заметны или одинаково управляемы существующими инструментами. Раскрытие информации о лицензии происходит из-за четырех различных типов зависимостей, для каждого из которых требуются разные методы обнаружения:

1. Зависимости менеджера пакетов (объявленные и транзитивные)

Наиболее заметный слой: зависимости, объявленные в файлах манифеста (package.json, pom.xml, requirements.txt, go.mod, Cargo.toml) и транзитивные зависимости, которые они разрешают во время сборки. Зависимости от менеджеров пакетов — наиболее хорошо изученная категория; инструменты SCA сканируют манифесты, файлы блокировки и артефакты сборки, чтобы перечислить их.

Ключевое различие заключается между прямой и транзитивной зависимостью. Прямая зависимость — это та, которую выбрал разработчик. Транзитивная зависимость — это то, что требуется для прямой зависимости. Разработчик, который добавляет одну зависимость, может это сделать. react-data-grid В проекте Node.js пакет может импортировать десятки транзитивных зависимостей, каждая со своей лицензией. Разработчик не выбирал эти лицензии. Они существуют в дереве зависимостей независимо от этого.

JSON

// package.json: 1 direct dependency declared
{
  "dependencies": {
    "react-data-grid": "^7.0.0"
  }
}

// npm lockfile resolves to 47 transitive dependencies, including:
// - react@18.2.0 (MIT)
// - clsx@1.2.1 (MIT)
// - scheduler@0.23.0 (MIT)
// - tslib@2.6.0 (0BSD)
// - ...43 more, each with its own license
// The developer declared 1 license obligation; they shipped 47.

Ловушка транзитивных лицензий: риск, связанный с лицензией, заключается не в том, что вы объявили, а в том, что объявили ваши зависимости и что объявили их зависимости. Чистое дерево прямых зависимостей с разрешительными лицензиями может скрывать транзитивную зависимость, распространяемую по лицензии GPL, на три уровня вложенности, которая налагает обязательства копилефта на весь дистрибутив.

2. Исходный код, предоставленный поставщиком и скопированный пользователем.

Исходный код из внешних проектов копируется непосредственно в репозиторий — это распространенный подход в проектах на C/C++, проектах на Go без модулей и в устаревших кодовых базах. Встроенный код не отображается в манифестах менеджера пакетов, поскольку он был добавлен путем копирования и вставки, а не через менеджер зависимостей.

Сканирование на уровне фрагментов кода в SCANOSS выходит далеко за рамки обнаружения на основе манифестов, сопоставляя фрагменты исходного кода с более чем 100 миллионами файлов с открытым исходным кодом в OSSKB. Сканирование на уровне фрагментов кода необходимо для идентификации кода, принадлежащего сторонним разработчикам, и скопированных функций — подходов, которые не заявляют о зависимости от манифеста, но несут полные лицензионные обязательства, как если бы компонент был явно включен.

Вспомогательная функция, скопированная из ответа на Stack Overflow, который изначально был создан на основе кода, распространяемого по лицензии GPL, несет те же обязательства по копилефту, что и прямая зависимость от GPL, но она нигде не фигурирует в манифесте пакета, файле блокировки или в любом автоматическом сканировании, которое считывает только объявленные зависимости.

3. Статически связанные библиотеки

Библиотеки компилируются непосредственно в исполняемый файл приложения во время сборки. В отличие от динамически связанных библиотек, которые существуют как отдельные файлы во время выполнения, статически связанные библиотеки встраиваются в исполняемый файл. Они не видны в манифестах менеджера пакетов, а отображаются в конфигурациях сборки.Makefile, CMakeLists.txt(скрипты компоновщика) и в самом скомпилированном бинарном файле.

В частности, для библиотек, распространяемых по лицензии LGPL, различие между статической и динамической компоновкой определяет лицензионные обязательства. LGPL разрешает динамическую компоновку без распространения копилефта; статическая компоновка может повлечь за собой требования копилефта для объединенного произведения. Для идентификации статически связанных компонентов и их лицензий необходим инструмент бинарного анализа, который исследует скомпилированный артефакт, а не только манифест исходного кода.

4. Зависимости, загружаемые во время выполнения

Библиотеки загружаются динамически во время выполнения через архитектуру плагинов, позднее связывание или интеграцию с механизмами сценариев. Эти зависимости могут быть неразрешимы только на основе анализа исходного кода, они зависят от среды выполнения, конфигурации и пути выполнения. Драйверы баз данных, загружаемые через рефлексию, плагины парсеров, обнаруживаемые механизмами загрузки служб, и расширения сценариев, загружаемые из файловых путей при запуске, — все это зависимости времени выполнения, которые могут иметь последствия для лицензирования.

Категории лицензионных рисков и их обязательства

Лицензии с открытым исходным кодом располагаются в диапазоне от разрешительных до ограничительных. Понимание того, где каждая лицензия находится в этом диапазоне, определяет обязательства по соблюдению требований, которые она влечет за собой:

Разрешительные лицензии (MIT, Apache-2.0, BSD-2-Clause, BSD-3-Clause, ISC)

Обязательства: Указание авторства, включение текста лицензии и уведомления об авторских правах в распространяемые материалы. Раскрытие исходного кода не требуется. Коммерческое использование разрешено без ограничений. Интеграция в проприетарные продукты разрешена.

Уровень риска для коммерческого программного обеспечения: низкий. Атрибуцию легко автоматизировать.

Слабые лицензии copyleft (LGPL-2.0, LGPL-2.1, LGPL-3.0, MPL-2.0, EUPL-1.2)

Обязательство: Указание авторства и внесение изменений в лицензированный компонент должны быть распространены. В частности, для LGPL: динамическая компоновка, как правило, удовлетворяет условиям лицензии, не вызывая копилефта в вызывающем коде; статическая компоновка может не удовлетворять.

Уровень риска для коммерческого программного обеспечения: средний. Зависит от метода компоновки. Динамическая компоновка, как правило, безопасна; статическая компоновка требует тщательной юридической проверки.

Надежные лицензии с копилефтом (GPL-2.0, GPL-3.0, AGPL-3.0)

Обязательство: Авторство, а также вся совокупность работ, включающая компонент GPL, должны быть доступны на условиях GPL (раскрытие исходного кода). AGPL распространяет это требование на программное обеспечение, доступ к которому осуществляется по сети.

Уровень риска для коммерческого программного обеспечения: высокий. Компонент, распространяемый по лицензии GPL и статически связанный с проприетарным коммерческим продуктом или являющийся его производным, может потребовать раскрытия проприетарного исходного кода. Это тот лицензионный риск, который приводит к самым крупным судебным искам.

Сетевое копилефт (AGPL-3.0)

Обязательство: Все обязательства лицензии GPL-3.0, а также: пользователи, взаимодействующие с программным обеспечением по сети, считаются получающими это программное обеспечение, что влечет за собой обязательство раскрытия исходного кода даже для SaaS-продуктов, которые никогда не распространяют бинарные файлы.

Уровень риска для SaaS-продуктов: Очень высокий. Лицензия AGPL специально разработана для устранения «лазейки SaaS» в GPL. Коммерческий SaaS-продукт, включающий компонент, защищенный AGPL, должен раскрывать свой исходный код любому пользователю, взаимодействующему с ним по сети.

Собственные и коммерческие лицензии

Обязательства: определяются лицензионным соглашением и варьируются от «запрет на распространение» до «роялти за единицу» и «лицензии на корпоративное использование». Эти компоненты не являются открытым исходным кодом, но отображаются в деревьях зависимостей при использовании коммерческих компонентов.

Уровень риска: Зависит от условий сделки. Часто выявляется в ходе комплексной проверки при слияниях и поглощениях, когда перечисляются обязательства по лицензионным платежам за приобретаемые продукты.

Совместимость лицензий: ключевой аспект.

При объединении компонентов с различными лицензиями в одном программном продукте, лицензии должны быть совместимы. Несовместимые комбинации лицензий создают юридический риск, который нельзя устранить одним лишь указанием авторства, поскольку сама комбинация может нарушать одну или обе лицензии.

В сочетании с	MIT	Apache-2.0	LGPL-2.1	GPL-2.0	GPL-3.0	АГПЛ-3.0
MIT	совместимый	совместимый	совместимый	совместимый	совместимый	совместимый
Apache-2.0	совместимый	совместимый	совместимый	Несовместимый	совместимый	совместимый
LGPL-2.1	совместимый	совместимый	совместимый	совместимый	Несовместимый	Несовместимый
GPL-2.0	совместимый	Несовместимый	совместимый	совместимый	Несовместимый	Несовместимый
GPL-3.0	совместимый	совместимый	Несовместимый	Несовместимый	совместимый	совместимый
Запантентованная	совместимый	совместимый	Предупреждение	Несовместимый	Несовместимый	Несовместимый

Наиболее существенная несовместимость для коммерческого программного обеспечения: лицензии Apache-2.0 и GPL-2.0 несовместимы. Библиотека, распространяемая по лицензии Apache-2.0, не может быть объединена с компонентом, распространяемым по лицензии GPL-2.0, в одном проекте. Поскольку многие базовые компоненты с открытым исходным кодом (модули ядра Linux, некоторые старые библиотеки Java) распространяются по лицензии GPL-2.0, а не GPL-3.0, эта несовместимость создает реальный риск несоответствия требованиям в деревьях смешанных зависимостей.

Лицензия AGPL-3.0 является наиболее ограничительной для SaaS-продуктов: по сути, ничто не может быть корректно интегрировано с AGPL-3.0 в коммерческом продукте без возникновения обязательств по соблюдению сетевого авторского права (copyleft).

Обеспечение соблюдения лицензионных правил в системах CI/CD

Соблюдение лицензионных требований, основанное на периодических проверках, терпит неудачу в момент внедрения: зависимость под лицензией GPL, добавленная кем-то в прошлом спринте, находится в продакшене уже три недели, прежде чем её обнаружит ежеквартальная проверка. Непрерывное обеспечение соблюдения лицензионных требований на этапе слияния — единственный подход, предотвращающий попадание не соответствующих требованиям зависимостей в кодовую базу.

YAML

# GitHub Actions: license compliance gate on every PR
name: License Compliance Check

on:
  pull_request:

jobs:
  license-audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install license checker
        run: npm install -g license-checker fossa-cli

      - name: Scan dependency licenses
        run: |
          license-checker --summary --excludePrivatePackages \
            --out license-report.json

      - name: Enforce license policy
        run: |
          # Block GPL-2.0, GPL-3.0, AGPL-3.0, SSPL in commercial product
          FORBIDDEN=$(license-checker --failOn \
            "GPL-2.0;GPL-3.0;AGPL-3.0;SSPL" \
            --excludePrivatePackages 2>&1 || true)

          if echo "$FORBIDDEN" | grep -q "FAIL"; then
            echo "Forbidden license detected in dependencies"
            echo "$FORBIDDEN"
            exit 1
          fi

      - name: Generate SBOM artifact
        run: |
          # Generate CycloneDX SBOM for audit trail
          npx @cyclonedx/cyclonedx-npm \
            --output-file sbom-$(date +%Y%m%d).json

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom
          path: sbom-*.json

Внимание: лицензионная политика является специфичной для каждой организации. Запрещенный список в приведенном выше примере отражает общую коммерческую политику, но юридический отдел вашей организации должен определить, какие лицензии разрешены, какие отмечены для проверки, а какие запрещены для вашего конкретного типа продукта, модели распространения и клиентских соглашений. Библиотека, разрешенная во внутреннем инструменте, может быть запрещена в продукте, распространяемом клиентом.

Стандарты генерации и форматирования спецификаций материалов (SBOM).

Спецификация программного обеспечения (SBOM) — это структурированный документ, который делает соответствие лицензионным требованиям проверяемым, доступным для обмена и машинной проверки. При наличии SBOM группы по обеспечению соответствия могут подтверждать лицензионные обязательства без ручных проверок. На рынке доминируют два формата:

CycloneDX , разработанный OWASP, предназначен для использования в сценариях обеспечения безопасности и управления цепочками поставок. Поддерживает спецификации компонентов, сервисов, уязвимостей (VEX), формул и моделей машинного обучения. Предпочтительный формат для спецификаций материалов, ориентированных на безопасность, и формат, требуемый большинством современных инструментов интеграции с системами анализа цепочек поставок.

СПДКССтандарт ISO/IEC (ISO 5962:2021), поддерживаемый Linux Foundation, является обязательным для соблюдения некоторых государственных стандартов закупок, включая аспекты Указа Президента № 14028. В большей степени ориентирован на соблюдение лицензионных требований, чем на безопасность, и имеет более богатый язык выражений лицензий (выражения SPDX могут охватывать сложные сценарии с несколькими лицензиями): GPL-2.0-only AND MIT OR Apache-2.0).

Указ президента № 14028 уже запрещает поставщикам, не использующим спецификации материалов (SBOM), участвовать в федеральных контрактах, Канадское агентство по соблюдению налогового законодательства (CRA) начнет обеспечивать соблюдение требований по отчетности об уязвимостях в сентябре 2026 года, а стандарт PCI DSS 4.0 уже находится в руках аудиторов. Либо вы поставляете продукцию, соответствующую спецификациям материалов (SBOM), либо теряете сделки.

Для корпоративных программных продуктов создание обоих форматов обходится недорого, за исключением генерации на основе одного и того же анализа зависимостей. Целевая аудитория различается: CycloneDX используется командами по безопасности и системами управления уязвимостями; юридические отделы, отделы закупок и отделы соблюдения нормативных требований обычно предпочитают SPDX.

Проблема устаревшего кода: нет менеджера пакетов, нет манифеста.

Описанные выше инструменты анализа зависимостей — сканеры SCA, парсеры файлов блокировок, генераторы SBOM — работают, исходя из предположения, что программные зависимости управляются через менеджеры пакетов и объявляются в файлах манифеста. Это предположение справедливо для современных проектов на Java, JavaScript, Python, Go и Rust. Оно не справедливо для устаревших корпоративных сред, построенных на COBOL, JCL и платформах мэйнфреймов.

В среде мэйнфреймов зависимость от стороннего программного обеспечения проявляется тремя способами, которые стандартные инструменты SCA обнаружить не могут:

Лицензированная сортировочная и вспомогательная продукция. Потоки заданий JCL вызывают служебные программы, продукты сортировки (DFSORT, SyncSort/Syncsort, теперь известные как Precisely, CA Sort), генераторы отчетов (SAS, EASYTRIEVE) и инструменты преобразования данных, которые представляют собой лицензированное коммерческое программное обеспечение со своими собственными условиями лицензирования, договорами на техническое обслуживание и требованиями соответствия. В JCL они отображаются как PGM=SORT, PGM=IEBGENER, PGM=ICETOOLНазвания программ, а не идентификаторы пакетов. Инструмент SCA не читает эти названия. package.json or pom.xml найдет их.

Копибуки COBOL, предоставляемые поставщиками. Сторонние поставщики программного обеспечения предоставляют копибуки COBOL, которые являются лицензированным программным обеспечением. Поставщик программного обеспечения для финтех-компаний, предоставляющий программы COBOL для обработки платежей, может предоставлять копибуки, определяющие его собственные структуры данных. Каждая программа COBOL, включающая эти копибуки, использует лицензированное программное обеспечение. Лицензионные обязательства реальны; записи в менеджере пакетов не существует.

Встроенные алгоритмы из лицензированных источников. Финансовые учреждения, использующие системы на COBOL, могли интегрировать лицензированные алгоритмы, процедуры актуарных вычислений, криптографические реализации, библиотеки численного анализа непосредственно в исходный код COBOL. Эти алгоритмы могли изначально быть скомпилированы в кодовую базу и не могут быть идентифицированы менеджерами пакетов.

Для этих компонентов метод обнаружения основан на анализе исходного кода: отслеживание операторов CALL для идентификации вызываемых программ, изучение операторов COPY для идентификации включенных компонентов и сопоставление имен программ с реестром известных сторонних компонентов. Полученные данные используются в том же процессе проверки соответствия лицензионным требованиям, но для этого требуется инструмент, который понимает семантику COBOL и JCL, а не только современные форматы манифестов пакетов.

Создание готового к аудиту пакета документов, соответствующего требованиям законодательства.

Когда юридический отдел, отдел по соблюдению нормативных требований или внешний аудитор запрашивают доказательства соответствия лицензионным требованиям, отчет о проверке необходим, но недостаточен. Пакет документов, готовый к аудиту, включает в себя:

• Полный перечень зависимостейкаждый компонент, версия и лицензия, включая транзитивные зависимости, организованы по продукту и версии.
• Матрица лицензионных обязательствДля каждой категории лицензий указаны конкретные обязательства (указание авторства, раскрытие источника, уведомление о внесении изменений) и порядок их выполнения.
• файл с уведомлениями об авторствеБыли составлены юридические уведомления для всех компонентов, требующих указания авторства, в формате, требуемом каждой лицензией (файл NOTICE для Apache-2.0, файл LICENSE для MIT и т. д.).
• Анализ несовместимостидокументация, подтверждающая отсутствие несовместимых комбинаций лицензий в объединенном продукте, с юридическим обоснованием любых спорных моментов.
• артефакт SBOMтекущий файл CycloneDX или SPDX, подписанный и снабженный меткой времени, охватывающий все компоненты, входящие в область действия.
• Документация по политикеписьменная политика организации в отношении лицензий на открытый исходный код, включая процесс утверждения новых лицензий.
• Документы об утвержденииДля любой лицензии, требующей юридической проверки перед включением, необходимо предоставить документально подтвержденное одобрение и обоснование целесообразности проекта.
• История рекультивациидокументация о любых ранее выявленных нарушениях и действиях, предпринятых для их устранения.

В частности, в контексте комплексной проверки при слияниях и поглощениях: покупатели все чаще запрашивают этот пакет в рамках технической проверки. Безупречный пакет документов, не содержащий неустраненных нарушений, ускоряет процесс проверки. Пакет, выявляющий неустраненные нарушения GPL в запатентованном продукте, обычно приводит либо к корректировке цены, либо к необходимости депонирования средств, либо к устранению нарушений в качестве условия закрытия сделки, что обходится дороже, чем программа обеспечения соответствия, которая могла бы предотвратить эти нарушения.

Как SMART TS XL Обеспечивает соответствие лицензионным требованиям в корпоративных кодовых базах.

SMART TS XLАвтора сопоставление зависимостей приложения Предоставляет уровень анализа структурных зависимостей для корпоративных кодовых баз, особенно в устаревшей среде, где стандартные инструменты анализа структурных зависимостей достигают своих пределов.

В средах мэйнфреймов карта зависимостей идентифицирует каждую программу, вызываемую каждой другой программой (выявляя вызовы сторонних утилит, встроенных в JCL и COBOL), каждый копибук, включенный каждой программой (выявляя зависимости от копибуков, предоставляемых поставщиком), и каждый набор данных, к которому обращается каждая программа (выявляя зависимости уровня данных от лицензированных продуктов баз данных). Этот анализ создает перечень компонентов, который является необходимым условием для аудита соответствия лицензиям в средах, где отсутствует менеджер пакетов.

Функция статического анализа кода выявляет шаблоны кода, связанные с конкретными компонентами сторонних разработчиков: сигнатуры вызовов проприетарных API, соглашения о структуре данных, специфичные для поставщика, и реализации лицензированных алгоритмов, встроенные в пользовательский исходный код COBOL. Эти данные дополняют инвентаризацию на основе манифеста зависимостями на уровне кода, недоступными для сканирования манифеста.

Возможность анализа воздействия позволяет принимать обоснованные решения при изменении лицензионной политики: если изменяется лицензия компонента, зависимость перелицензируется с MIT на AGPL-3.0, поставщик изменяет свои условия, анализ воздействия выявляет каждую программу в портфеле, которая зависит от этого компонента, напрямую или косвенно. Это превращает событие изменения лицензии из неизвестного риска в четко определенную область устранения проблемы.

Функция корпоративного поиска позволяет запрашивать информацию об зависимостях в целях соблюдения нормативных требований: за считанные секунды можно найти каждую программу, которая вызывает определенную утилиту, каждый шаблон кода, включающий определенный компонент, предоставленный поставщиком, каждую программу, которая зависит от определенного лицензированного компонента, по всему портфелю устаревших систем. Эта функция поиска — практичный инструмент для запроса на аудит сделок слияния и поглощения во вторник утром: запрос вместо ручной проверки.

Для организаций, создающих комплексное описание спецификации материалов (SBOM), охватывающее как современные, так и устаревшие системы, SMART TS XL Предоставляет доступ к устаревшему перечню компонентов, который не могут создать стандартные генераторы SBOM, дополняя такие инструменты, как Syft, FOSSA и Dependency-Track, для современного стека.

Аудит, который никогда не должен быть неожиданностью

Аудит соблюдения лицензионных требований — одна из немногих областей регулирования, где последствия несоблюдения часто обнаруживаются не регулятором, а деловым партнером, приобретающей стороной, юридической командой клиента или дистрибьютором, которые изучают условия лицензии и запрашивают доказательства соответствия. Цена такого обнаружения варьируется от неприятных до катастрофических в зависимости от серьезности нарушения и стадии сделки.

Программа анализа зависимостей, предотвращающая неожиданное обнаружение подобных проблем, не является дорогостоящей по сравнению с рисками, которые она снижает. Она требует знания содержимого программного обеспечения, каждого компонента, каждой транзитивной зависимости, каждого фрагмента кода от поставщика, каждой устаревшей утилиты, а также постоянной, а не периодической, проверки каждого компонента на соответствие лицензионной политике организации. Инструменты существуют. Стандарты (SBOM, SPDX, CycloneDX) существуют. Нормативы (EO 14028, CRA, PCI-DSS 4.0) существуют. Единственное, чего не хватает большинству организаций, — это дисциплины, позволяющей рассматривать анализ зависимостей как инфраструктурный процесс, а не как аудит.

Утро вторника, начинающееся с отчета, а не с учебной тревоги, — это утро вторника, ставшее возможным благодаря инфраструктуре анализа зависимостей.