Политика раскрытия уязвимостей (VDP)

Безопасность установок Netgap и передаваемых через них данных — приоритет проекта. Мы ценим вклад исследователей безопасности и принимаем конфиденциальные отчеты о потенциальных уязвимостях в приложении Netgap и связанных с ним ресурсах.

Этот документ — VDP (Vulnerability Disclosure Policy) проекта Netgap: официальные правила, куда и как направлять отчеты об уязвимостях. Обработка полученных отчетов ведется по модели CVD (Coordinated Vulnerability Disclosure) — детали не публикуются до выпуска исправления и согласования раскрытия.

Основной принцип: любой отчет об уязвимости передается только по закрытому каналу и только в зашифрованном виде. Публикация деталей уязвимости в открытых каналах (issues, merge request, блог, мессенджеры, социальные сети, конференции) до выпуска исправления и согласования раскрытия не допускается.

Раздел состоит из трех страниц:

Страница	Содержание
Политика раскрытия (VDP) — эта страница	Область действия, правила исследования, канал связи, состав отчета, сроки, регистрация в БДУ ФСТЭК и CVE, доставка исправлений, Safe Harbor
PSIRT и процесс CVD	Терминология, роль PSIRT, этапы обработки отчета, присвоение NG-SA, БДУ и CVE, содержание бюллетеня
Журнал уязвимостей	Публичный реестр подтвержденных уязвимостей и порядок его ведения

1. Область действия (Scope)

Приоритет — уязвимости в распространяемом приложении Netgap. Сайт и инфраструктура разработки рассматриваются как вторичная область: отчеты по ним принимаются, но обрабатываются с меньшим приоритетом.

Основная область (приоритет 1) — приложение Netgap:

• компоненты netgap-gateway и netgap-executor любых поставляемых версий;
• поставляемые артефакты релиза: архивы, контейнерные образы, контрольные суммы и подписи;
• схемы и обработка конфигурации, механизмы контроля доступа, изоляции контуров и передачи данных между ними;
• криптографические механизмы: проверка подписей, обработка ключей и сертификатов, TLS-профили;
• уязвимости в зависимостях, эксплуатируемые через штатные сценарии работы Netgap.

Вторичная область (приоритет 2) — ресурсы проекта:

• сайт документации netgap.io и его сборка;
• публичный бакет релизов release.netgap.io и цепочка публикации артефактов;
• репозиторий и инфраструктура разработки dev.netgap.io;
• публикация ключей: gpg.asc, WKD-каталог /.well-known/openpgpkey/.

Вне области действия — тестировать запрещено:

• продуктивные установки Netgap, принадлежащие третьим лицам (заказчикам, партнерам, пользователям);
• сторонние сервисы и интеграции, в том числе облачные провайдеры, на которых размещены ресурсы проекта;
• физическая инфраструктура и рабочие места;
• персонал проекта: социальная инженерия, фишинг, звонки, давление на мейнтейнеров;
• нагрузочное тестирование, DoS/DDoS и деструктивные автоматизированные сканеры в отношении ресурсов проекта.

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

2. Что сообщать через этот процесс

Тип находки	Канал
Уязвимость безопасности в компонентах Netgap (netgap-gateway, netgap-executor, конфигурация, поставляемые артефакты релиза)	Только зашифрованное письмо, описанное ниже
Ошибка (баг), которая потенциально влияет на изоляцию контуров, целостность или конфиденциальность передаваемых данных	Только зашифрованное письмо, описанное ниже
Уязвимость в ресурсах проекта: сайт документации, бакет релизов, подписи и ключи, цепочка сборки	Только зашифрованное письмо, описанное ниже
Функциональный баг без влияния на безопасность, вопрос по эксплуатации, предложение по улучшению	Публичный репозиторий проекта

Если вы не уверены, влияет ли находка на безопасность, используйте зашифрованный канал — это всегда безопасный вариант.

3. Правила проведения исследований (Rules of Engagement)

Оставаясь в рамках этой политики, вы обязуетесь:

• не вредить — не нарушать работу систем, не удалять и не изменять данные;
• не красть данные — при получении доступа к конфиденциальным данным немедленно прекратить тестирование и сообщить нам; не выгружать данные объемами, превышающими необходимое для подтверждения находки;
• соблюдать конфиденциальность — не раскрывать сведения об уязвимости третьим лицам до выпуска исправления и согласования публикации (принцип CVD);
• не применять деструктивные проверки — никаких нагрузочных тестов, DoS/DDoS и автоматических сканеров, способных вызвать отказ в обслуживании;
• тестировать только свое — исследовать приложение Netgap исключительно на собственных установках и стендах;
• не хранить лишнее — не сохранять полученные в ходе эксплуатации данные дольше, чем нужно для подготовки отчета, и удалить их после закрытия отчета;
• не оказывать давление — не использовать полученные сведения для вымогательства, угроз публикацией или иного давления на проект.

4. Как отправить отчет (Reporting a Vulnerability)

Отчет направляется письмом на адрес Lead Maintainer of Netgap (роль PSIRT):

andrey@ganyushkin.ru

Требования к письму:

• письмо шифруется PGP-ключом Lead Maintainer (см. раздел 5);
• тема письма не должна раскрывать детали уязвимости, используйте префикс [Netgap][Security];
• вложения (PoC, логи, дампы, скриншоты) также передаются в зашифрованном виде: либо внутри зашифрованного письма, либо отдельными файлами *.gpg;
• по возможности приложите свой публичный ключ, чтобы ответ также был зашифрован.

Машиночитаемое описание канала: /.well-known/security.txt (RFC 9116).

5. Ключ шифрования

Для шифрования отчета используется публичный ключ Lead Maintainer of Netgap. Этот же ключ используется для подписи коммитов и релизных артефактов проекта.

Параметр	Значение
Владелец	Andrei Ganiushkin (key for netgap project, for GitHub) <andrey@ganyushkin.ru>
Отпечаток (fingerprint)	6B83 5E5B B72C BC2A A35F 2E10 556B 4133 3653 BD5A
Key ID (long)	556B41333653BD5A
Алгоритм	ed25519 (подпись), cv25519 (шифрование)
Прямая ссылка	gpg.asc
WKD	автоматическое обнаружение по адресу andrey@ganyushkin.ru

Получение ключа:

# Вариант 1: WKD (автоматическое обнаружение ключа по email)
gpg --locate-keys andrey@ganyushkin.ru

# Вариант 2: прямая загрузка с сайта документации
curl -sSL https://netgap.io/gpg.asc | gpg --import

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

gpg --fingerprint 556B41333653BD5A

Шифрование отчета и вложений:

# Зашифровать текст отчета
gpg --encrypt --armor --recipient 556B41333653BD5A report.txt

# Зашифровать и подписать вложение своим ключом
gpg --encrypt --sign --recipient 556B41333653BD5A poc.tar.gz

Полученные файлы report.txt.asc и poc.tar.gz.gpg приложите к письму.

Публичный ключ (ASCII-armored)

-----BEGIN PGP PUBLIC KEY BLOCK-----

mDMEaixkThYJKwYBBAHaRw8BAQdAYxIU0X+IYddIB994Ght5zdPhamQZqXfBlZPm
nKjnwxO0TUFuZHJlaSBHYW5pdXNoa2luIChrZXkgZm9yIG5ldGdhcCBwcm9qZWN0
LCBmb3IgR2l0SHViKSA8YW5kcmV5QGdhbnl1c2hraW4ucnU+iK8EExYKAFcWIQRr
g15btyy8KqNfLhBVa0EzNlO9WgUCaixkThsUgAAAAAAEAA5tYW51MiwyLjUrMS4x
MiwwLDMCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQVWtBMzZTvVpn
8QD/XBwzNwR3ZzlEbAUfVEP8/6XrHdsRBg9nhP8d8aYu2zMBAKP6qB84fykcv4hu
T45EuV3yH949gD733ardcmvmMAsBuDgEaixkThIKKwYBBAGXVQEFAQEHQNQ/K/89
TYiKCStVBleWSyt8E6YEuALfcAtb/pCYk485AwEIB4iUBBgWCgA8FiEEa4NeW7cs
vCqjXy4QVWtBMzZTvVoFAmosZE4bFIAAAAAABAAObWFudTIsMi41KzEuMTIsMCwz
AhsMAAoJEFVrQTM2U71a2XoBAO9e8hkc5wrg1wkE8Z6rr/r6ZAaEUwyG1PYl+ClL
GERQAP4wSGmLxNinsO9sijJeD6S7AdeaUWaWzaeOl0E64htiDA==
=3ALb
-----END PGP PUBLIC KEY BLOCK-----

6. Что указать в отчете

Обязательно:

1. Тип и краткая суть уязвимости (например: обход авторизации, утечка данных между контурами, RCE, DoS).
2. Затронутый компонент и версия (тег релиза, коммит или контрольная сумма артефакта).
3. Окружение: способ развертывания, ОС, значимые параметры конфигурации.
4. Пошаговое воспроизведение: минимальный сценарий, приводящий к проблеме.
5. Наблюдаемое и ожидаемое поведение.
6. Оценка влияния: что именно получает атакующий и какие предварительные условия ему нужны.

Желательно:

1. PoC (скрипт, запрос, конфигурация), логи, трассировки, дампы трафика.
2. Оценка критичности по CVSS v3.1 с вектором и класс слабости по CWE.
3. Предлагаемое исправление или обходное решение (workaround) для эксплуатирующих систем.
4. Ссылки на публичные материалы, CVE, CWE, отчеты по аналогичным проблемам.
5. Как вас указать в благодарностях (имя, ник, ссылка) или пометка о желании остаться анонимным.
6. Ваши планы по публикации: планируемая дата и место, если вы намерены раскрыть детали.
7. Нужен ли вам идентификатор CVE — он запрашивается только по вашему запросу (см. раздел 10).

7. Шаблон письма

Тема письма:

[Netgap][Security] <краткая суть без деталей>

Тело письма (шифруется целиком):

1. Тип уязвимости: <например, обход контроля доступа / утечка данных / DoS>
2. Компонент и версия: <netgap-gateway 1.0.0-rc / коммит abc1234>
3. Область: <приложение Netgap / сайт документации / инфраструктура разработки>
4. Окружение:
   - Способ развертывания: <контейнеры / systemd / иное>
   - ОС и ядро: <...>
   - Значимая конфигурация: <фрагменты YAML без секретов>
5. Влияние: <что получает атакующий, какие предварительные условия>
6. Оценка критичности: <CVSS v3.1 вектор и балл, CWE, если есть>
7. Шаги воспроизведения:
   1) <...>
   2) <...>
   3) <...>
8. Наблюдаемое поведение: <...>
9. Ожидаемое поведение: <...>
10. PoC и артефакты: <перечень зашифрованных вложений>
11. Предлагаемое исправление / workaround: <если есть>
12. Планы по публикации: <дата и место, либо "публикация не планируется">
13. Запрос CVE: <"требуется" / "не требуется" / "заявка подана самостоятельно">
14. Указание автора: <имя или ник для благодарностей, либо "анонимно">
15. Контакт для ответа и ваш публичный ключ (fingerprint): <...>

8. Наш ответ и обязательства (Our Commitment)

Получив отчет, соответствующий этой политике, PSIRT проекта обязуется:

• подтвердить получение отчета и сообщить присвоенный идентификатор NG-SA-YYYY-NNNN;
• проверить воспроизводимость, оценить критичность по CVSS v3.1 и держать вас в курсе хода исправления;
• согласовать с вами дату публичного раскрытия и не публиковать детали раньше выпуска исправления;
• зарегистрировать подтвержденную уязвимость в БДУ ФСТЭК России и, по вашему запросу, инициировать присвоение CVE (раздел 10);
• не инициировать юридические действия и не обращаться в правоохранительные органы, если вы добросовестно следовали правилам раздела 3 (Safe Harbor);
• указать вас как автора находки в бюллетене, примечаниях к релизу и журнале учета — только с вашего явного согласия; при желании остаться анонимным запись будет обезличена.

Safe Harbor не распространяется на действия, выходящие за область действия политики (раздел 1) и нарушающие правила исследования (раздел 3), а также не отменяет обязательств исследователя перед третьими лицами, чьи установки Netgap были затронуты.

9. Сроки реагирования

Сроки отсчитываются от момента получения корректно расшифрованного отчета. Рабочие дни — по календарю Российской Федерации. Отчеты по основной области (приложение Netgap) обрабатываются в первую очередь.

Этап	Срок
Подтверждение получения отчета	до 5 рабочих дней
Первичная проверка воспроизводимости и предварительная оценка критичности	до 15 рабочих дней
Согласование плана устранения и целевой даты исправления	до 20 рабочих дней
Уведомление БДУ ФСТЭК России о подтвержденной уязвимости	по процедуре раздела 10
Запрос идентификатора CVE	по запросу исследователя, срок согласуется индивидуально
Выпуск исправления: Critical	цель — 45 календарных дней
Выпуск исправления: High	цель — 90 календарных дней
Выпуск исправления: Medium и Low	в рамках планового цикла релизов
Согласованное публичное раскрытие	не ранее выпуска исправления, по умолчанию — до 120 календарных дней с момента подтверждения

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

Дополнительные условия:

• сроки могут быть пересмотрены в одностороннем порядке в зависимости от технической сложности уязвимости и архитектурных особенностей приложения Netgap; в этом случае вам будет направлено обоснование и новая целевая дата;
• указанные сроки являются целевыми ориентирами (best effort), а не договорными обязательствами или публичной офертой; их несоблюдение не порождает ответственности Правообладателя проекта перед исследователем или третьими лицами;
• уязвимости уровня Critical обрабатываются в первую очередь; находки уровня Medium и Low устраняются в рамках плановых релизов без отдельной целевой даты;
• если отчет признан невоспроизводимым или не относящимся к безопасности, вы получите мотивированный ответ и, при необходимости, будете перенаправлены в публичный репозиторий;
• если вы не получили подтверждения получения в течение 5 рабочих дней, отправьте повторное письмо с тем же префиксом темы — не публикуйте детали;
• отдельное SLA с договорными сроками реагирования предоставляется только в рамках коммерческого договора (см. раздел 11).

10. Регистрация уязвимости: NG-SA, БДУ ФСТЭК России и CVE

Каждая подтвержденная уязвимость регистрируется в трех контурах учета. Состав присваиваемых идентификаторов различается по обязательности.

Идентификатор	Реестр	Когда присваивается
NG-SA-YYYY-NNNN	Журнал уязвимостей проекта	всегда, сразу при подтверждении отчета
BDU:YYYY-NNNNN	Банк данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru)	всегда для уязвимостей в приложении Netgap
CVE-YYYY-NNNNN	Международный реестр CVE (через CNA)	по запросу исследователя

БДУ ФСТЭК России — обязательная процедура. Национальный аналог CVE в Российской Федерации — Банк данных угроз безопасности информации (БДУ) ФСТЭК России; идентификатор имеет вид BDU:2026-XXXXX. После подтверждения уязвимости в приложении Netgap PSIRT направляет официальное уведомление об обнаруженной уязвимости в программном обеспечении через официальный сайт bdu.fstec.ru. Для средств защиты информации — особенно для решений класса airgap, к которым относится Netgap, — фиксация уязвимостей в БДУ является обязательной процедурой и условием сертификации в РФ. Уведомление направляется без публикации деталей эксплуатации в открытых каналах; полученный идентификатор BDU указывается в записи Журнала уязвимостей и в бюллетене NG-SA.

CVE — по запросу исследователя. Проект не является CNA и не декларирует автоматическое оформление CVE для каждой находки. Если вам нужен идентификатор CVE, укажите это в отчете или в переписке до согласованной даты раскрытия: PSIRT обратится в профильный CNA либо подтвердит данные для заявки, поданной самим исследователем. Присвоенный CVE добавляется в запись Журнала уязвимостей; срок получения идентификатора зависит от CNA и не входит в целевые сроки раздела 9.

Отсутствие CVE не влияет ни на факт регистрации уязвимости в Журнале, ни на приоритет ее исправления, ни на уведомление БДУ ФСТЭК России.

11. Как пользователи получают исправления безопасности

Порядок доставки исправления зависит от того, на каких условиях используется Netgap.

Категория пользователей	Канал получения исправления	Как отслеживать
Свободное (некоммерческое) использование	Официальный публичный канал релизов: бакет релизов и страница «Детали релиза»	Журнал уязвимостей и CHANGELOG соответствующего релиза
Коммерческая лицензия с платной поддержкой	Условия договора, в том числе доставка исправлений безопасности с опережением публичного релиза	Уведомления в рамках договора, далее — те же публичные источники

Свободное использование. Пользователи бесплатной версии получают все исправления безопасности исключительно через официальный публичный канал релизов — в составе очередного релиза, опубликованного в бакете release.netgap.io. Отдельных приватных сборок, патчей или предварительных уведомлений для этой категории не предоставляется. Наличие уязвимости и факт выпуска исправления отслеживаются по двум публичным источникам: записи в Журнале уязвимостей (идентификатор NG-SA-YYYY-NNNN, статус, затронутые и исправленные версии) и примечаниям к релизу в CHANGELOG соответствующей версии, доступным на странице «Детали релиза». Рекомендуемая мера защиты — своевременное обновление до последней опубликованной версии.

Коммерческая поддержка. Для организаций, использующих Netgap по коммерческой лицензии с платной поддержкой, порядок и сроки доставки исправлений безопасности определяются условиями договора. Договор может предусматривать доставку исправлений с опережением официального публичного релиза (предварительные сборки, целевые патчи, обходные решения), персональные уведомления о применимых уязвимостях и согласованное SLA по срокам реагирования. Условия договора имеют приоритет над целевыми ориентирами из раздела 9; при расхождении применяются положения договора.

Во всех случаях детали уязвимости публикуются не ранее выпуска исправления и согласованной даты раскрытия (раздел 8). Передача полученных в рамках коммерческой поддержки предварительных исправлений и сведений об уязвимости третьим лицам до публичного раскрытия не допускается.

12. Вознаграждение не предоставляется

В проекте Netgap нет программы Bug Bounty. За сообщение об уязвимости, а также за любой связанный с ним материал (отчет, PoC, предложенное исправление) никакое вознаграждение не предоставляется: ни денежная выплата, ни бонусы, ни подарки, ни коммерческая лицензия, ни иные компенсации. Направляя отчет, вы подтверждаете, что не рассчитываете на вознаграждение и не предъявляете имущественных требований к Правообладателю проекта.

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

13. Соответствие политике принятия изменений

Процесс раскрытия уязвимостей не отменяет и не изменяет политику принятия изменений в проект. Если вы предлагаете не только отчет, но и исправление (патч, merge request, фрагмент кода, тест или правку документации), такой вклад принимается исключительно на условиях, описанных в:

• CONTRIBUTING.md — руководство для контрибьюторов (английская версия);
• CONTRIBUTING.ru.md — руководство для контрибьюторов (русская версия);
• CONTRIBUTING-CAA.en.md — Contributor Assignment Agreement (английская версия);
• CONTRIBUTING-CAA.ru.md — Соглашение о передаче прав на вклад (русская версия).

Исправления безопасности передаются в проект только по закрытому каналу (в составе зашифрованного письма) до момента согласованного публичного раскрытия. Публичный merge request с исправлением создается после выпуска релиза или по прямому согласованию с Lead Maintainer.