Но ты не сильно не переживай. Все относительно тип-топ. Я в ГС дал комментарий по ситуации, а по ссылке развернутая история от проекта.
А вот тебе промпт для аудита.
Проведи defensive security audit моего GitHub-окружения и связанных локальных репозиториев.
Контекст:
- У тебя есть доступ к `gh` CLI, и он уже авторизован.
- Работай как security-аудитор, а не как атакующий.
- Ничего не меняй без явного подтверждения.
- Ничего не удаляй, не ревокай, не пушь, не отключай workflows.
- Твоя задача — собрать факты, найти аномалии и выдать отчёт с приоритетами.
Что нужно проверить:
1. GitHub account / org / repo access
- Определи, под каким аккаунтом авторизован `gh`.
- Получи список доступных организаций и репозиториев.
- Для каждой доступной org, где хватает прав:
- проверь members / outside collaborators;
- отметь новых, неожиданных или подозрительных участников;
- если доступно, проверь audit log начиная с 2026-05-11 или за последние 14–30 дней;
- отдельно ищи:
- добавление/удаление участников,
- изменения ролей,
- создание/изменение secrets,
- изменения webhook,
- изменения GitHub Actions settings,
- suspicious token / app / integration activity.
2. GitHub Actions / CI security
- Для всех доступных репозиториев проверь `.github/workflows`.
- Найди и отдельно выдели:
- `pull_request_target`,
- запуск untrusted code,
- выдачу лишних `permissions`,
- использование secrets в рискованных местах,
- self-hosted runners,
- actions без pin по полному commit SHA,
- скачивание и выполнение внешних скриптов,
- кэширование через недоверенные trust boundaries.
- Посмотри недавние workflow runs и выдели:
- неожиданные запуски,
- странные branches,
- ручные dispatch без понятной причины,
- падения/аномалии,
- workflow-файлы, недавно изменённые перед подозрительными раннами.
3. Dependency / supply-chain triage
- В локальных репозиториях найди lockfiles и manifests:
- `package-lock.json`
- `pnpm-lock.yaml`
- `yarn.lock`
- `requirements.txt`
- `poetry.lock`
- `Pipfile.lock`
- `uv.lock`
- Проверь наличие или следы зависимостей, связанных с недавними supply-chain инцидентами:
- TanStack ecosystem
- `@antv/*`
- `guardrails-ai`
- Если встречается `durabletask`, просто отметь отдельно как “встретилось”, но не называй это подтверждённым инцидентом без доказательств.
- Для найденных совпадений укажи:
- репозиторий,
- файл,
- пакет,
- версию,
- почему это может быть важно.
4. Git history / suspicious repo changes
- Проверь недавние изменения в:
- `.github/workflows/**`
- `package.json`
- lockfiles
- dependency manifests
- scripts, связанные с release/publish/install/postinstall
- Отметь:
- неожиданные коммиты,
- forged-looking author identity,
- force-push indicators,
- резкие изменения CI/CD логики,
- добавление внешних curl/wget/bash installer pattern.
5. Secrets / exposure indicators
- Если доступно через GitHub security features/API, проверь alerts:
- secret scanning,
- Dependabot,
- code scanning.
- Локально найди явные индикаторы секретов в repo-конфигах и workflow-файлах, но:
- не печатай сами секреты целиком;
- маскируй значения;
- в отчёте показывай только тип и расположение.
6. Формат результата
Сделай итоговый отчёт в 4 блоках:
A. Executive summary
- кратко: есть ли явные красные флаги или нет.
B. Critical findings
- только действительно опасное/срочное.
C. Suspicious / needs manual review
- всё, что не доказано, но требует проверки человеком.
D. Recommended actions
- отдельно:
- что можно сделать прямо сейчас;
- что стоит проверить вручную в GitHub UI;
- что лучше не автоматизировать без подтверждения.
Требования к работе:
- Не фантазируй.
- Если данных/прав не хватает — так и пиши.
- Явно разделяй:
- confirmed,
- suspicious,
- not enough access.
- Не выполняй destructive actions.
- Если находишь потенциальный компромисс, не скрывай uncertainty, но и не смягчай формулировки.