# Подмена авторства коммитов в Git как угроза безопасности: темы ВКР и практика защиты
**Роль:** Специалист по информационной безопасности
**Поддомен:** Cybersecurity / безопасная разработка
В марте 2026-го в Git-репозиториях обнаружили пугающий паттерн: история коммитов выглядит безупречно — автор вы, дата ваша, а вот код чужой. Злоумышленник подделывает метаданные коммита так, что `git log` показывает легитимное изменение, хотя в реальности в проект попадает вредоносный или несогласованный код. Для студента ИТ-специальности это не просто новость из ленты безопасности, а готовая исследовательская проблема для ВКР. Ниже — как превратить этот кейс в полноценную выпускную работу: от анализа атаки до практической защиты репозиториев.
## Основная часть
### Угроза: почему `git log` — не доказательство авторства
Коммит хранит не только сам diff, но и метаданные: имя автора, email, timestamp, сообщение. Git по умолчанию доверяет этим полям, а при локальной работе они задаются через конфиги или переменные окружения `GIT_AUTHOR_NAME`, `GIT_AUTHOR_EMAIL`, `GIT_AUTHOR_DATE`. Атакующий может выставить их так, чтобы точь-в-точь скопировать ваш профиль и внести изменение от вашего имени. При этом сам `git log` покажет идеальную историю — без тревожных сигналов.
В дипломной работе это отличный объект для исследования: можно проанализировать вектор атаки, описать модель нарушителя, разработать методику верификации. В главе 1 классически рассматриваются теоретические основы: протокол Git, объектная модель, механизмы аутентификации. Здесь же уместно сослаться на практики OWASP (например, рекомендации из категории Security Misconfiguration), а также на стандарты ISO/IEC 25010 — как на критерий качества, среди которых важна аутентичность (подлинность) данных.
### Три направления ВКР и структура глав
Предлагаем три взаимосвязанные темы, которые легко защищаются и имеют явную практическую ценность. Выбирайте по своим интересам и доступному стеку.
| Направление | Актуальность | Цель работы | Задачи | Структура глав |
|---|---|---|---|---|
| **1. Анализ уязвимостей системы управления версиями Git** | Раскрывает, почему `git log` не является гарантией авторства, как в статье | Выявить и классифицировать способы подделки метаданных коммитов | 1) Изучить архитектуру Git и модель объектов; 2) Систематизировать векторы атаки на атрибуцию; 3) Разработать методику анализа подлинности коммитов; 4) Провести эксперимент на эталонном репозитории | Глава 1 — аналитический обзор, модель атаки; Глава 2 — проектирование методики; Глава 3 — экспериментальная проверка и рекомендации |
| **2. Корпоративный стандарт подписи коммитов с GPG** | Решает проблему, описанную в статье: без криптографической подписи метаданным нельзя верить | Создать регламент и технические настройки для обязательной GPG-подписи в команде | 1) Исследовать требования OWASP к аутентичности кода; 2) Настроить GPG-ключи и конфигурацию Git; 3) Реализовать pre-receive hook для проверки подписей; 4) Оценить эффективность внедрения | Глава 1 — обзор угроз; Глава 2 — проектирование и реализация регламента; Глава 3 — тестирование и метрики |
| **3. Автоматизация аудита истории коммитов в CI/CD** | Встраивает проверку подлинности коммитов в пайплайн, где обычно анализ уже не проводят | Разработать пайплайн, который автоматически детектирует неподписанные и подозрительные коммиты | 1) Выбрать инструменты анализа (git fsck, GPG, кастомные скрипты); 2) Интегрировать инструменты в CI/CD пайплайн; 3) Разработать алгоритм оповещений для неподписанных коммитов; 4) Выполнить нагрузочное тестирование | Глава 1 — анализ процесса поставки ПО; Глава 2 — проектирование пайплайна; Глава 3 — внедрение и оценка времени верификации |
Каждое из направлений даёт студенту понятную цель и защищаемые результаты — вы не просто «исследуете», а предлагаете конкретные артефакты.
### Практическая часть: инструменты, метрики, диаграммы
Вторая и третья главы ВКР должны содержать реализацию. Для выбранных тем пригодятся такие инструменты:
- **GPG-подпись** — базовая защита от подделки метаданных. Проверить подпись в истории можно одним скриптом:
```bash
git log --pretty=format:"%h %an <%ae> signed:%G? %s" --show-signature
# signed:G — чей-то коммит с валидной подписью
# signed:N — нет подписи или она не проверена
```
- **git fsck** — поиск «висячих» объектов и аномалий в истории. Может выявить коммиты, которые не связаны с официальными ветками, но присутствуют в базе объектов — вероятный след атаки.
- **Pre-receive hook** на серверной стороне (например, в GitLab или Gitea) — блокировка пушей, если коммит не подписан валидным ключом:
```bash
#!/bin/bash
while read oldrev newrev ref; do
for commit in $(git rev-list $oldrev..$newrev); do
signature=$(git cat-file -s "$commit")
if [ "$signature" = "N" ]; then
echo "Commit $commit has no GPG signature. Rejecting."
exit 1
fi
done
done
```
Для визуализации атаки и архитектуры решения в пояснительной записке используйте UML-диаграмму последовательности (атакующий задаёт переменные окружения, делает коммит, пушит — вы видите чистую историю) и C4-диаграмму контекста (разработчик → Git-репозиторий → CI/CD → артефакт). Обе хорошо ложатся в стандарты ГОСТ 19 и ГОСТ 34.
Какие метрики помогут показать эффективность вашей работы?
- доля неподписанных коммитов до и после внедрения GPG;
- количество ложных срабатываний при автоматической проверке;
- время на проверку 100 коммитов вручную и через скрипт.
Эти числа станут основой главы «Эффективность разработанных мероприятий».
## FAQ
**Вопрос:** Как связать эту новость с моей темой ВКР, если я занимаюсь автоматизацией тестирования или web-разработкой?
**Ответ:** Безопасность должна быть сквозной функцией. Любая разработка включает контроль версий и пайплайны — добавьте в дипломный проект раздел по обеспечению доверенного происхождения кода. Это усилит «практическую значимость» работы.
**Вопрос:** Где взять данные для анализа подделки коммитов?
**Ответ:** Не нужно использовать реальные коммерческие репозитории. Создайте собственную экспериментальную площадку: репозиторий с 20–50 коммитами, где часть «подделана» изменением `GIT_AUTHOR_*`. Опишите процесс генерации данных и алгоритм поиска аномалий — этого достаточно для честного эксперимента.
**Вопрос:** Как оформить листинги и схемы по ГОСТ?
**Ответ:** Для программного кода применяйте правила ГОСТ 19 (текст программы, описание алгоритма), для технической документации — ГОСТ 34. Схемы должны быть подписаны «Рисунок 1 — » и иметь ссылку в тексте. Код в приложениях оформляется моноширинным шрифтом, в основном тексте даются только фрагменты.
**Вопрос:** Какие метрики эффективности просить на защите ВКР?
**Ответ:** Вам достаточно трёх числовых показателей: время верификации одного коммита до/после; процент неподписанных коммитов в общем потоке; количество пропущенных атак. Сравните эти значения «было/стало» и убедительно покажите прирост безопасности.
## Чек-лист «Что проверить перед сдачей»
- Подберите минимум три литературных источника не старше 3–5 лет, включая оригинал статьи на SecurityLab.
- Проверьте, что каждая цель из введения подкреплена выводами в заключении.
- Нарисуйте хотя бы одну UML-диаграмму (последовательность или классы) и подпишите в строгом соответствии с ГОСТ.
- В практической части обязательно включите листинг с проверкой GPG-подписей и опишите его работу.
- Дайте метрики «до/после» внедрения защиты (неподписанные коммиты, время аудита).
- Убедитесь, что уникальность текста ≥ 70%, а заимствования из статьи оформлены как цитирование.
## Типичные ошибки студентов
**Ошибка 1.** Студенты доверяют `git log` как источнику истины. В теоретической части нужно явно сказать о недостатках механизма аутентификации. Используйте аргумент статьи: метаданные легко подделываются, поэтому доверять без GPG-подписи нельзя.
**Ошибка 2.** Предлагают «просто внедрить GPG» без анализа рисков. Избежать можно, если в главе 1 описать модель нарушителя, а в главе 3 показать, насколько снижается вероятность успешных атак. Это превращает банальный «регламент» в исследование.
**Ошибка 3.** Забывают о нормативных стандартах. Проверяющий спросит: «А по ГОСТ 19 вы оформили алгоритм?» Добавьте текст программы и блок-схему в приложения — это закроет вопрос.
## CTA — получите консультацию по своей теме
Если вы не хотите тратить 120 часов на разбор стандартов и методик, но готовы довести работу до идеала — начните с бесплатной консультации. Мы поможем выбрать тему, спланировать главы и найти именно те данные, которые дадут вам легко защититься. Пишите — подскажем, с какой стороны подойти к вашей ВКР.
## Эксперт
## Источник
Источник: История коммитов чистая. Автор — вы. Дата — ваша. Код — чужой. Вот почему git log больше нельзя доверять безоговорочно (опубликовано 2026-03-18)