Опубликовано: 06.05.2026 | Источник: ZDNet – Enterprise Software

Безопасность ИИ в дипломе: как защита кода стала архитектурным решением

Компания Cal, ранее активно развивавшая open-source-проект, приняла радикальное решение — перевести свой флагманский продукт в проприетарную модель. Причина? Растущие риски, связанные с использованием ИИ для анализа и эксплуатации открытого кода. Как отмечается в статье ZDNet, теперь «открытый исходный код — это как раздавать чертежи банковского хранилища». Умные модели могут находить уязвимости, генерировать атаки, масштабировать эксплойты — и всё это в разы быстрее, чем человек.

Этот случай — не исключение. Это сигнал: безопасность в разработке перестаёт быть «последним пунктом в чек-листе». Она становится частью архитектуры. Для студентов ИТ-специальностей это означает, что ВКР, игнорирующие угрозы со стороны ИИ, рискуют быть признанными устаревшими ещё до защиты. Напротив, работа, в которой вы не просто пишете код, а обосновываете его устойчивость к новым формам атак, автоматизированному анализу и перехвату интеллектуальной собственности — будет выделяться. Особенно если вы используете актуальные стандарты, метрики и фреймворки.

Актуальные темы ВКР на основе кейса Cal

1. Переход от open-source к проприетарным решениям: архитектурные и экономические последствия

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

Цель: Оценить влияние перехода на закрытую модель на безопасность, стоимость поддержки и скорость разработки.

Задачи:

• Проанализировать риски эксплуатации open-source ИИ-инструментами (CodeQL, GitHub Copilot, CodeWhisperer).
• Сравнить модели лицензирования (MIT, GPL, SSPL) с точки зрения защиты от ИИ-анализа.
• Разработать модель оценки TCO (Total Cost of Ownership) при переходе на проприетарную модель.
• Предложить архитектурные меры по защите исходного кода (обфускация, SaaS-доступ, API-ограничения).

Структура: Глава 1 — Анализ угроз и моделей лицензирования; Глава 2 — Проектирование архитектуры с учётом безопасности; Глава 3 — Оценка экономической эффективности и метрик безопасности.

2. Архитектура защищённой разработки в эпоху ИИ: от кода до CI/CD

Актуальность: ИИ не только читает код — он может встраиваться в пайплайны, подменять зависимости, генерировать фальшивые коммиты. Нужна «защита по глубине».

Цель: Разработать модель безопасного CI/CD-пайплайна, устойчивого к ИИ-угрозам.

Задачи:

• Идентифицировать угрозы на каждом этапе CI/CD (сборка, тестирование, деплой).
• Внедрить SAST/DAST-анализ с учётом ИИ-генерации уязвимого кода.
• Настроить аудит зависимостей (SBOM) и блокировку подозрительных пакетов.
• Оценить эффективность через метрики MTTR, RTO, RPO.

Структура: Глава 1 — Обзор угроз и стандартов (ISO/IEC 25010, NIST SP 800-160); Глава 2 — Проектирование защищённого пайплайна; Глава 3 — Тестирование и расчёт метрик.

3. Обфускация и контроль доступа к исходному коду: практическая реализация

Актуальность: Если вы не можете доверять открытому коду — вы должны контролировать его доступность. Это не просто «секретность», а архитектурное решение.

Цель: Реализовать систему контроля доступа и обфускации для критически важного модуля.

Задачи:

• Выбрать язык и фреймворк с поддержкой обфускации (например, Java + ProGuard, .NET + Dotfuscator).
• Реализовать механизм динамической загрузки зашифрованных модулей.
• Настроить аутентификацию и аудит доступа к исходным репозиториям.
• Протестировать устойчивость к декомпиляции и ИИ-анализу.

Структура: Глава 1 — Анализ методов защиты кода; Глава 2 — Проектирование и реализация; Глава 3 — Тестирование и сравнение с открытыми аналогами.

Аналитическая глава: как использовать кейс Cal в обосновании выбора

В первой главе ВКР вы не просто описываете технологии — вы доказываете, почему выбрали именно их. Кейс Cal — отличный аргумент для отказа от open-source в критических системах.

Пример сравнения:

Используйте стандарты:

• ISO/IEC 25010 — оценка качества ПО (надёжность, безопасность, сопровождаемость).
• ГОСТ 34.602-89 — техническое задание на разработку. Включите в него требования к защите кода.
• NIST Cybersecurity Framework — если вуз разрешает иностранные стандарты.

Проектная часть: архитектура с учётом ИИ-угроз

Во второй главе вы проектируете систему. Не ограничивайтесь UML-диаграммами — покажите, как вы защищаете каждый компонент.

Пример архитектуры:

[Клиент] 
   ↓ HTTPS
[API Gateway] — (аутентификация, лимиты)
   ↓
[Микросервис A] — (обфусцированный код, SAST-проверка)
   ↓
[SBOM-анализатор] — (проверка зависимостей)
   ↓
[Защищённый репозиторий] — (доступ по ключам, аудит)

Инструменты, которые можно использовать:

• Kubernetes — для изоляции сред, но с настройкой Network Policies.
• OpenTelemetry — сбор метрик безопасности (например, количество попыток доступа к репозиторию).
• Trivy, Snyk — сканирование образов и зависимостей.
• GitGuardian — обнаружение утечек ключей.

Тестирование и метрики: как доказать эффективность

Третья глава — не просто «мы запустили и работает». Вы должны измерить, насколько ваше решение защищено.

Пример метрик:

• MTTR (Mean Time to Repair) — время устранения уязвимости.
• RTO/RPO — для оценки восстановления после атаки.
• Количество обнаруженных уязвимостей до и после внедрения мер.
• Время декомпиляции обфусцированного кода — если проводили тесты.

Используйте нагрузочное тестирование, но не только по производительности — проверьте, как система реагирует на попытки массового доступа к API, подбор токенов, загрузку вредоносных пакетов.

Чему вы научитесь

Работая над такой темой, вы освоите:

• Анализ архитектурных решений с точки зрения безопасности.
• Работу с фреймворками и стандартами (ISO/IEC 25010, ГОСТ 34.602-89).
• Проектирование защищённых CI/CD-пайплайнов.
• Сбор и интерпретацию метрик безопасности.
• Оформление технической документации по требованиям вуза.
• Обоснование выбора стека — не «потому что знаю», а «потому что соответствует угрозам».

Можно ли не писать код в дипломе?

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

Как оформить UML-диаграммы?

Используйте стандарты: диаграммы классов, последовательности, развёртывания. Инструменты: PlantUML, draw.io, StarUML. Убедитесь, что диаграммы читаемы в PDF, подписаны и упомянуты в тексте.

Где брать тестовые данные?

Используйте синтетические данные (Faker, Mockaroo), публичные датасеты (Kaggle, OpenData), или моделируйте нагрузку (JMeter, Locust). Важно: не используйте реальные персональные данные без согласия.

Обязательно ли использовать Kubernetes?

Нет. Но если вы делаете распределённую систему — это сильный аргумент. Kubernetes показывает масштабируемость и современный подход. Однако, для простых задач можно использовать Docker Compose или даже виртуальные машины.

Источник: 'Like handing out the blueprint to a bank vault': Why AI led one company to abandon open source (опубликовано 2026-04-15)