Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Данные которые покидают контур
О чём
Предмет проверки — потоки данных наружу из защищённого контура Организации при работе CodeScoring. Это не про общую архитектуру on-premise (она в Offline и on-premise архитектура), а конкретно про каналы egress: что и куда уходит во время обновления баз знаний, проксирования запросов пакетных менеджеров, выгрузки логов и — отдельно — при поиске активности разработчиков в Open Source. Для on-premise/Offline-инсталляции важно перечислить эти каналы явно и понять, какие из них можно отключить.
Что подтверждено
По исследованию соответствия и ТЗ выделяются следующие потенциальные направления данных наружу:
- Источники уязвимостей. Подсистемы OSA/SCA используют NIST NVD, GitHub Security Advisory, OSS Index, OSV и БДУ ФСТЭК. В Offline-режиме они не запрашиваются онлайн напрямую — нужен механизм обновления локального индекса (offline update), см. Требования к offline обновлениям.
- OSA Proxy в режиме проксирования. По требованию ТЗ Proxy перехватывает запросы пакетных менеджеров, отправляет их в исходные репозитории, анализирует ответ и модифицирует его. Это означает исходящий трафик к публичным upstream-registry (Maven Central, NPM, PyPI и т. д.) в том режиме, где Proxy реально ходит наружу. Поддержанный список экосистем — отдельная тема, см. OSA Proxy и поддержанные экосистемы.
- Намеренная выгрузка логов. ТЗ (§3.3) требует передачи логов сервисов и аудит-логов во внешние системы — ELK, Syslog, SIEM. Это контролируемый egress внутри периметра Организации; способ выгрузки логов исследование помечает как требующий архитектурного подтверждения.
- TQI: поиск авторов по e-mail. В расширенной редакции ТЗ подсистема TQI должна искать активность разработчиков в Open Source проектах по адресу электронной почты. Это исходящий запрос с персональными данными разработчиков во внешние источники — самостоятельный канал egress, см. TQI как дополнительный контур.
Что не подтверждено или ограничено
Состав исходящего трафика и телеметрия не описаны Ни ТЗ, ни исследование соответствия не описывают, какую телеметрию продукт отправляет вендору (phone-home), что именно уходит при онлайн-обновлении баз и можно ли полностью изолировать инсталляцию. Это надо подтвердить у поставщика, а не достраивать из общих соображений.
- Offline update index. Механизм обновления базы знаний в air-gapped контуре в материалах детально не зафиксирован: как формируется и доставляется пакет обновления, какой канал требуется, периодичность.
- Online vs on-premise. Что хранится локально и что покидает контур различается между online и on-premise развёртыванием; для целевого варианта Организации это надо зафиксировать по фактической архитектуре пилота.
- OSA Proxy и приватные данные. При проксировании наружу уходят имена и версии запрашиваемых пакетов (то есть фактически состав зависимостей проектов). Насколько это критично для Организации и можно ли ограничить Proxy только внутренними/зеркальными репозиториями — вопрос архитектуры.
- TQI egress отключаем ли. Можно ли отключить внешний поиск авторов по e-mail, оставив только локальную аналитику репозиториев — не подтверждено.
Что проверить на пилоте
Что уходит наружу и можно ли это закрыть 1. Какую телеметрию продукт отправляет вендору и можно ли её полностью отключить в on-premise/Offline. 2. Как устроен offline update index: формат пакета обновления баз (NVD/GHSA/OSS Index/OSV/БДУ), способ доставки в air-gapped контур, периодичность. 3. В каких режимах OSA Proxy реально ходит во внешние публичные registry, а в каких — только во внутренние зеркала; что именно (имена/версии пакетов) уходит наружу. 4. Как и в каком формате выгружаются сервисные и аудит-логи в ELK/Syslog/SIEM (приёмочный сценарий 7). 5. TQI: отправляются ли e-mail разработчиков во внешние источники при поиске активности в Open Source и можно ли этот канал отключить, оставив локальную аналитику.
Связь
- Матрица соответствия требованиям OSA SCA — источники уязвимостей, логи, OSA-режимы.
- Вопросы для пилота CodeScoring — вопрос 7 (что покидает контур, offline update index).
- Offline и on-premise архитектура — фактическая архитектура развёртывания.
- OSA Proxy и поддержанные экосистемы — проксирование во внешние registry.
- TQI как дополнительный контур — egress персональных данных (e-mail авторов).
- Требования к offline обновлениям · Журналирование и audit trail · П32. CodeScoring offline architecture — практики и регламенты.