Политика использования открытого ПО

Настоящий документ определяет правила и процедуры, регулирующие использование компонентов с открытым исходным кодом (OSS) в продуктах и услугах VAHREST. Политика распространяется на всех сотрудников, подрядчиков и участников, вносящих вклад в разработку платформы.

1. Общие положения

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

1.2. Настоящая политика применяется ко всем программным компонентам сторонних производителей, включаемым в ПО VAHREST, независимо от их происхождения или метода распространения.

1.3. Использование OSS-компонентов должно быть явно одобрено ответственным за безопасность цепочки поставок перед включением в продукт.

2. Классификация лицензий OSS

Все используемые лицензии с открытым исходным кодом классифицируются по трём категориям:

Категория A — Разрешительные лицензии (Approved)

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

MIT License
Apache License 2.0
BSD 2-Clause и BSD 3-Clause
ISC License
The Unlicense / Public Domain
CC0-1.0

Категория B — Слабые копилефт-лицензии (Conditional)

Допускается использование при выполнении условий соответствующей лицензии. Требуется проверка перед включением в продукт:

GNU Lesser General Public License v2.1 (LGPL-2.1)
GNU Lesser General Public License v3.0 (LGPL-3.0) — только динамическое связывание
Mozilla Public License 2.0 (MPL-2.0) — при сохранении изменений в открытом виде
Eclipse Public License 2.0 (EPL-2.0)
Common Development and Distribution License (CDDL-1.0)

Категория C — Сильные копилефт-лицензии (Prohibited)

Использование компонентов под данными лицензиями в закрытом коде VAHREST запрещенобез специального юридического заключения и письменного разрешения руководства:

GNU General Public License v2.0 (GPL-2.0)
GNU General Public License v3.0 (GPL-3.0)
GNU Affero General Public License v3.0 (AGPL-3.0)
Server Side Public License (SSPL)
Commons Clause (ограничение коммерческого использования)

3. Реестр компонентов

3.1. VAHREST ведёт актуальный реестр всех OSS-компонентов, используемых в продукте. Реестр содержит следующую информацию для каждого компонента:

Наименование компонента и версия
Идентификатор лицензии (SPDX)
Категория лицензии (A/B/C)
URL репозитория
Статус (одобрен / требует проверки / запрещён)
Дата последней проверки безопасности
Известные CVE и статус патчей

3.2. Реестр обновляется при каждом добавлении, обновлении или удалении компонента, а также при выходе новых версий используемых компонентов.

4. Процедура включения OSS-компонентов

4.1. Перед включением нового OSS-компонента разработчик обязан:

Идентифицировать все лицензии компонента и его транзитивных зависимостей
Проверить компонент на наличие известных уязвимостей (CVE) с помощью Trivy или аналогичного инструмента
Оценить активность сопровождения проекта (последний коммит, количество мейнтейнеров)
Создать запрос на включение (Pull Request) с заполненной формой OSS-проверки

4.2. Включение компонентов категории B требует явного одобрения технического директора. Компоненты категории C не включаются без юридического заключения.

4.3. Запрещается использовать компоненты, последние обновления которых датированы более чем двумя годами назад, без проведения дополнительного аудита безопасности.

5. Программный перечень материалов (SBOM)

5.1. VAHREST генерирует и поддерживает SBOM (Software Bill of Materials) для каждого релиза продукта в форматах CycloneDX и SPDX.

5.2. SBOM обновляется автоматически в рамках CI/CD-процессов при каждом релизе и хранится совместно с артефактами сборки.

5.3. SBOM предоставляется корпоративным клиентам (тарифный план Enterprise) по запросу для целей аудита и соответствия требованиям безопасности.

5.4. Содержимое SBOM включает: идентификаторы пакетов (PURL), хеши компонентов, зависимости первого и последующих уровней, лицензии и известные уязвимости.

6. Безопасность цепочки поставок программного обеспечения

6.1. VAHREST применяет следующие меры защиты цепочки поставок:

Проверка целостности зависимостей — использование lock-файлов (go.sum, package-lock.json) и верификация хешей
Сканирование уязвимостей — автоматическая проверка всех зависимостей с помощью Trivy и Gitleaks в рамках CI/CD
Политика минимальных привилегий — компоненты получают только необходимые разрешения
Изоляция инструментов — security-инструменты запускаются в изолированных контейнерах с ограниченным сетевым доступом
Мониторинг CVE — еженедельная автоматическая проверка всех компонентов на наличие новых уязвимостей

6.2. Критические уязвимости (CVSS ≥ 9.0) в используемых компонентах должны быть устранены в течение 48 часов с момента обнаружения. Высокие (CVSS ≥ 7.0) — в течение 7 рабочих дней.

7. Политика форков и модификаций OSS

7.1. Создание форков OSS-компонентов допускается только в случаях:

Необходимости исправления критической уязвимости до выхода официального патча
Добавления функциональности, необходимой для работы VAHREST, при условии передачи изменений обратно в апстрим (upstream)
Использования проекта, разработка которого официально прекращена

7.2. Все модификации OSS-компонентов документируются и хранятся отдельно от оригинального кода.

7.3. VAHREST стремится к участию в upstream-проектах: патчи, улучшающие безопасность или исправляющие ошибки, должны быть предложены сообществу оригинального проекта.

8. Соответствие Реестру российского программного обеспечения Минцифры

8.1. При наличии отечественных аналогов аналогичной функциональности VAHREST отдаёт предпочтение программному обеспечению, включённому в Единый реестр российских программ для ЭВМ и баз данных Министерства цифрового развития РФ.

8.2. При работе с клиентами, являющимися субъектами критической информационной инфраструктуры (КИИ), VAHREST обеспечивает предоставление документации, необходимой для подтверждения соответствия требованиям импортозамещения.

8.3. Реестр OSS-компонентов VAHREST включает сведения о стране происхождения каждого компонента для целей анализа импортозависимости.

9. Ответственность и роли

Технический директор (CTO) — общая ответственность за соблюдение настоящей Политики; одобрение компонентов категории B и C
Ведущий разработчик — проверка OSS-компонентов перед включением; поддержание актуальности реестра компонентов
DevSecOps-инженер — настройка и мониторинг автоматического сканирования зависимостей; ведение SBOM
Каждый разработчик — проверка лицензий и уязвимостей используемых зависимостей; соблюдение процедуры включения компонентов

10. Аудит и пересмотр политики

10.1. Настоящая Политика пересматривается не реже одного раза в год, а также при существенных изменениях в составе продукта или применимом законодательстве.

10.2. Ежеквартально проводится аудит реестра OSS-компонентов на предмет:

Актуальности версий используемых компонентов
Наличия новых уязвимостей (CVE)
Изменений в лицензионных условиях компонентов
Соответствия требованиям импортозамещения

10.3. Результаты аудита фиксируются и хранятся не менее 3 лет. По запросу клиентов Enterprise отчёт об аудите предоставляется в рамках пакета документации по безопасности.

По вопросам применения настоящей Политики обращайтесь: info@vahrest.ru.