Опубликовано: 03.10.2026 | Источник: SecurityLab (RSS)

Copilot и утечка кода: темы ВКР по защите репозиториев и политикам обучения ML

Поддомен: Cybersecurity / AI-Governance. Роль: специалист по информационной безопасности.

С 24 апреля GitHub расширяет использование пользовательских репозиториев для тренировки моделей Copilot — включая приватные проекты тех, кто не отключил соответствующую опцию. Для выпускника это не абстрактная новость: код дипломного проекта — интеллектуальная собственность, часто с закрытой лицензией, а иногда и с элементами, которые вуз потом патентно защищает. Если вы складываете ВКР в GitHub и не читали политику data residency, вы фактически отдаёте свою работу в датасет, который потом никто не отзовёт. Ниже — как этот кейс превратить в сильную, защищаемую тему ВКР: с архитектурой политик, метриками риска и ссылками на ГОСТ и OWASP.

Основная часть: от новости — к трём защищаемым темам ВКР

Тема 1. «Модель оценки риска утечки исходного кода при использовании сервисов генеративного ИИ»

Актуальность. Решение GitHub от 2026-03-26 делает риск утечки массовым: под обучение попадают репозитории, где разработчик не запретил использование явно. ВКР по информационной безопасности может формализовать этот сценарий как актив с угрозой.

Цель. Построить количественную модель риска для исходного кода в репозитории, размещённом в облачном сервисе с функцией обучения ИИ.

Задачи.

• Классифицировать чувствительные элементы кода (ключи, алгоритмы, бизнес-логика, конфиденциальные данные) по шкале критичности.
• Разработать матрицу «вероятность × ущерб» на базе ISO/IEC 27005.
• Реализовать прототип сканера, который помечает такие элементы, опираясь на OWASP Top 10 и SLSA.
• Валидировать модель на датасете из 30–50 репозиториев (можно взять собственные opensource-проекты).

Структура. Глава 1 — анализ угроз и стандартов (ГОСТ Р 50922, ISO/IEC 27005). Глава 2 — проектирование и реализация сканера + модели риска. Глава 3 — тестирование на выборке, расчёт precision/recall, выводы о порогах.

Тема 2. «Архитектура политик безопасного DevOps для изоляции проприетарного кода от обучающих контуров»

Актуальность. Кейс GitHug Copilot показывает, что политика «просто поставить private» не работает: приватность ≠ запрет на обучение. Вуз и будущий работодатель ценят выпускника, умеющего строить defense-in-depth вокруг репозитория.

Цель. Спроектировать архитектуру CI/CD, при которой код не может попасть в обучающие контуры облачного провайдера.

Задачи.

• Сравнить модели размещения: self-hosted GitLab, GitHub Enterprise с отключённым opt-in, git-сервер вуза.
• Разработать политику RBAC и DLP-правила (secret scanning, pre-commit hooks).
• Построить диаграмму C4 (контекст + контейнеры) и описать поток данных.
• Настроить метрики: время реакции на инцидент, доля «пойманных» секретов, MTTD/MTTR.

Структура. Гл. 1 — анализ угроз и обзор стандартов; Гл. 2 — проектирование политик и пайплайна; Гл. 3 — эксперименты, метрики OpenTelemetry, оценка эффективности.

Тема 3. «Применение дифференциальной приватности при дообучении ML-модели на закрытых репозиториях»

Актуальность. Если данные всё-таки участвуют в обучении (а в корпоративных задачах это неизбежно), нужны техники, которые не позволят восстановить обучающий код из модели. Это прямое продолжение кейса Copilot, но со стороны ML-инженера.

Цель. Оценить, насколько дифференциальная приватность (DP-SGD) сохраняет качество автодополнения кода при защите проприетарных фрагментов.

Задачи.

• Собрать корпус Python-кода, разметить «секретные» функции.
• Дообучить небольшую кодовую модель с DP-SGD и без него.
• Сравнить: perplexity, доля дословных утечек, precision/recall автодополнения.
• Оформить выводы в виде рекомендаций для компаний и вузов.

Структура. Гл. 1 — обзор Copilot, ISO/IEC 25010 (см. безопасность как характеристику качества) и подходов к приватности; Гл. 2 — пайплайн и обучение; Гл. 3 — метрики, сравнение, выводы.

Как встроить материал статьи в главы

В главе 1 свежая новость идёт как постановка проблемы — со ссылкой на дату и первоисточник. В главе 2 обязательно появляется схема: например, диаграмма C4 для варианта «код → репозиторий → CI → облачные сервисы» с зонами, где возможна утечка. В главе 3 — числовые метрики и таблица рисков. Если тема у вас не про Copilot напрямую, всё равно уместно добавить подраздел «Политики обучения внешних ML-сервисов» — это резко повышает новизну работы.

Пример минимального workflow, который ловит секреты и проверяет лицензии перед push — сразу в главу 2:

name: code-guardrails
on: [push, pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Secret scanning
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: License compliance
        run: |
          pip install pip-licenses
          pip-licenses --fail-on "GPL;AGPL"
      - name: SBOM
        run: |
          curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh
          ./bin/syft . -o spdx-json > sbom.json

Ниже — метрики, которые не стыдно защищать на ГАК, и стандарты, на которые можно ссылаться без выдумок.

FAQ: что чаще всего спрашивают студенты

Источник: Ваш код — теперь их учебник. GitHub начнет использовать проекты пользователей Copilot для тренировки ИИ (опубликовано 2026-03-26)