12 признаков опасной AI‑правки в pull request: когда "рабочий код" — это не безопасный код

Разбираем red flags, которые AI генерирует по умолчанию, а ревьюеры пропускают — потому что всё выглядит нормально

Почему рабочий PR не равно безопасный PR

Когда команда перешла на AI-ассистентов, изменилось одно фундаментальное уравнение: скорость написания кода выросла в разы, а скорость его понимания при ревью — нет.

Исследование Veracode 2025 года, охватившее более 100 LLM-моделей на четырёх языках программирования, показало: AI-код содержит в 2,74 раза больше уязвимостей, чем код, написанный человеком [1]. Java-реализации провалились по security-тестам в 72% случаев. Но критично не это. Критично то, что этот код работает. Тесты проходят. CI зелёный. Ревьюер видит понятный, аккуратно оформленный diff и одобряет PR.

Apiiro в независимом исследовании Fortune 50 компаний зафиксировали рост уязвимостей класса CVSS 7.0+ в AI-коде в 2,5 раза по сравнению с человеческим. К июню 2025 года AI-код добавлял свыше 10 000 новых security findings в месяц в изученных репозиториях — это в 10 раз больше, чем в декабре 2024 [2].

Изменился и профиль уязвимостей. Синтаксические ошибки сократились на 76%. Логические баги упали на 60%. Зато архитектурные флоу выросли на 153%, а пути для privilege escalation — на 322% [2]. Это именно те проблемы, которые SAST-инструменты традиционно не ловят и которые ревьюер видит последним — если вообще видит.

CodeRabbit проанализировал 470 open-source GitHub pull requests и зафиксировал: AI-соавторский код содержит примерно в 1,7 раза больше major issues, чем человеческий. Critical issues при нормировании на 100 PR — на 40% больше, major issues — на 70% больше [5].

Ниже — 12 конкретных признаков, которые должны останавливать ревьюера. Не потому что код не работает. А потому что он небезопасен.

Признак 1. Fallback-секрет в коде

Выглядит как: if not os.getenv("API_KEY"): api_key = "sk-default-key-for-testing"

Или: строка подключения к базе с паролем прямо в конфиге. Или hardcoded JWT secret с комментарием # TODO: move to env.

AI-модели воспроизводят паттерны из обучающих данных. Поскольку значительная часть публичного кода содержит hardcoded credentials — Common Crawl-дамп декабря 2024 года содержал почти 12 000 живых секретов в HTML, JS и конфигах публичных сайтов [7] — модели воспроизводят этот паттерн как норму. GitGuardian зафиксировали: в 2025 году коммиты с соавторством Claude Code содержали секреты примерно в 3,2% случаев — более чем вдвое выше базового уровня в 1,5% по всему GitHub [3].

В 2025 году GitGuardian зафиксировал 28,76 млн новых секретов в публичных GitHub-коммитах — рост на 34% год к году, крупнейший за всю историю наблюдений [3]. Более 60% секретов, обнаруженных в 2022 году, оставались валидными в 2025-м.

Как ловить: grep по паттернам sk-, AIza, password =, secret = в diff. Проверять не только .env-файлы, но и конфиги, seed-данные, тесты и комментарии. Искать conditional fallback — когда секрет появляется как значение по умолчанию при отсутствии переменной окружения.

Признак 2. Permissive CORS

Выглядит как: Access-Control-Allow-Origin: * в сочетании с Access-Control-Allow-Credentials: true. Или динамическое отражение Origin-заголовка без проверки по whitelist.

CORS — не security-фича. CORS — это ослабление браузерного Same-Origin Policy. Когда AI пишет backend с нуля или добавляет новый эндпоинт, он нередко ставит разрешительную политику чтобы "всё работало". В реальной атаке это означает: злоумышленник может с произвольного сайта отправить аутентифицированный запрос от имени жертвы и получить ответ.

Реальный пример: CVE-2025-34291 в платформе Langflow (CVSS 4.0: 9.4) — полный account takeover и RCE благодаря комбинации из трёх слабостей: overly permissive CORS, отсутствие CSRF-защиты на эндпоинте обновления токена, и эндпоинт выполнения кода [8]. В NextChat аналогичная проблема была зафиксирована отдельно: wildcard CORS policy на всех API-эндпоинтах создавала возможность для cross-origin exploitation [9].

Комбинация origin: '*' + credentials: true в Express.js — это невалидная конфигурация, которую браузеры отклонят, но которая сигнализирует о намерении сделать доступ максимально открытым. Не менее опасна substring-валидация: if (origin.includes('example.com')) — легко байпассится через evil.example.com.

Как ловить: в diff ищем Allow-Origin, cors(, middleware с CORS-заголовками. Проверяем: есть ли allowlist конкретных origins? Установлен ли credentials: true? Используется ли отражение входящего Origin без проверки?

Признак 3. Debug-режим как дефолт

Выглядит как: app.run(debug=True) в Flask. Или DEBUG = True в settings.py. Или NODE_ENV не выставлен, и фреймворк по умолчанию работает в development-режиме.

AI-модели генерируют код, который нужно "запустить и проверить". Debug-режим — удобный дефолт при прототипировании. Проблема в том, что такой код попадает в PR, а PR проходит ревью как рабочий. В debug-режиме Flask, например, открывает интерактивный Werkzeug-дебаггер, который даёт произвольное выполнение кода в браузере при наличии доступа к эндпоинту с ошибкой.

По данным VentureBeat, 43% AI-сгенерированных изменений требуют дополнительной отладки в production [10]. Veracode фиксирует: AI-модели оптимизируют код под "работает", а не под "безопасно" [1]. Включённый debug — классический признак этого разрыва.

Как ловить: ищем debug=True, DEBUG = True, development как значение NODE_ENV, -D DJANGO_DEBUG=True в Dockerfile или docker-compose. Особое внимание — к конфигам, которые AI затронул при рефакторинге.

Признак 4. Резкий рост diff без понятной причины

Выглядит как: PR с описанием "добавить поле в форму" содержит 800 строк изменений в 15 файлах. Или "небольшой рефакторинг" задевает auth-модуль, middleware и конфиг одновременно.

Salesforce задокументировали этот паттерн в своём engineering-блоге: после перехода на AI-ассистентов объём кода вырос на 30%, PR регулярно превышали 20 файлов и 1000 строк изменений. Время ревью самых крупных PR начало снижаться — что означало: ревьюеры перестали содержательно взаимодействовать с кодом [11].

Исследование Georgia Tech's Vibe Security Radar задокументировало 74 подтверждённых случая реальных уязвимостей с подписью AI-инструментов в публичных advisory-базах, из которых 14 критических и 25 высокой степени [12]. Один из системных паттернов — уязвимость, встроенная в нейтральный контекст, окружённая множеством несвязанных изменений.

CodeRabbit фиксирует: AI-соавторские PR концентрируют изменения в более крупных, но менее частых pull request'ах, затрагивающих несколько файлов и сервисов сразу. Это рассеивает внимание ревьюера и повышает вероятность пропустить security issue [5].

Как ловить: устанавливать лимит строк на PR (например, 400) и требовать дополнительного ревьюера при превышении. Смотреть не только на размер, но на семантическую связность: изменения в diff должны объясняться одной задачей.

Признак 5. Внезапный workflow change

Выглядит как: в PR с фичей появляется изменение в .github/workflows/. Или добавляется новый step в CI, который запускает внешний скрипт. Или меняются permissions у существующего workflow.

Атака на tj-actions/changed-files в марте 2025 года — один из самых наглядных примеров этого класса угроз. Злоумышленник внёс малозаметный коммит в популярный GitHub Action, используемый более чем в 23 000 репозиториях. Коммит был замаскирован под изменение от легитимного renovate[bot] и автоматически смёрджен — потому что так был настроен workflow [6]. CISA присвоила инциденту CVE-2025-30066 (CVSS: 8.6) и включила в KEV-каталог [13].

Отдельно: GhostAction-кампания, обнаруженная GitGuardian 5 сентября 2025 года, скомпрометировала 327 GitHub-аккаунтов в 817 репозиториях, похитив 3 325 секретов через инжекцию вредоносных workflow-файлов, замаскированных под "Github Actions Security" [14]. В марте 2026 года схожая атака затронула aquasecurity/trivy-action — злоумышленники использовали pull_request_target с избыточными permissions, который присутствовал в репозитории с октября 2025 года [15].

AI-ассистенты при помощи вполне легитимных задач — "добавить деплой", "ускорить билд", "настроить кеш" — могут генерировать workflow-изменения, которые открывают векторы для secret exfiltration или расширения permissions.

Как ловить: любое изменение в .github/workflows/ или аналогах должно проходить отдельный ревью человека с пониманием CI/CD-безопасности. Проверять: нет ли новых curl к внешним адресам? Не расширились ли permissions? Не появился ли pull_request_target?

Признак 6. Скачок зависимостей

Выглядит как: package.json обновился с 12 до 18 зависимостей. Или requirements.txt пополнился пятью новыми пакетами, которых не было в задаче. Или появилась зависимость с именем, похожим на известный пакет, но не совпадающим точно.

Исследование USENIX Security 2025, протестировавшее 16 моделей на 576 000 code samples, показало: почти 20% AI-сгенерированного кода ссылается на пакеты, которых не существует [4]. Эти галлюцинации следуют устойчивым паттернам: 38% — слияния реальных пакетов (например, express-mongoose), 13% — typo-варианты, 51% — чистые выдумки. В 43% случаев при повторном запросе одного и того же промпта модель воспроизводит то же несуществующее имя.

На этой механике построена атака slopsquatting [4]: злоумышленники мониторят вывод AI-моделей, регистрируют имена галлюцинированных пакетов на PyPI и npm, и ждут, когда разработчик установит их, доверяя AI-рекомендации. В январе 2026 года галлюцинированный npm-пакет react-codeshift распространился через 237 репозиториев через AI-сгенерированные agent skill files — без намеренного внедрения со стороны атакующих [16].

Инструменты вроде "vibe coding" усугубляют ситуацию: разработчик описывает желаемое, AI реализует, включая установку пакетов — без ручной верификации имён.

Как ловить: при любом изменении lock-файла или файла зависимостей проверять каждый новый пакет: существует ли он в реестре? Давно ли существует? Сколько у него загрузок? Совпадает ли имя с тем, что ожидалось по задаче?

Признак 7. Мягкая авторизация или её отсутствие

Выглядит как: новый API-эндпоинт без middleware-проверки токена. Или функция, которая принимает user_id из тела запроса и не верифицирует, что запрашивающий — именно этот пользователь. Или isAdmin проверяется только на фронтенде.

Apiiro зафиксировали рост путей privilege escalation в AI-коде на 322% по сравнению с человеческим [2]. OWASP Top 10:2025 — Broken Access Control (A01) — остаётся на первом месте с 2021 года и выявляется в 94% протестированных приложений [17]. AI-модели при написании нового функционала воспроизводят паттерн "сделать, чтобы работало": эндпоинт создаётся, данные возвращаются, а auth-middleware добавляется "потом".

"Потом" в AI-driven разработке нередко означает "никогда" — потому что следующий PR тоже написан AI, который не знает контекста предыдущего.

Атаки типа command injection, authentication bypass и server-side request forgery входят в топ уязвимостей, зафиксированных в публичных advisory с подписью AI-инструментов по данным Vibe Security Radar [12].

Как ловить: для каждого нового эндпоинта проверять: есть ли auth-middleware? Проверяется ли ownership ресурса (не просто аутентификация, а авторизация)? Нет ли параметра user_id, role, admin в теле запроса, который влияет на логику без server-side проверки?

Признак 8. Широкие permissions в новых компонентах

Выглядит как: сервисный аккаунт с правами admin вместо минимально необходимых. Или IAM-роль с :. Или Dockerfile с USER root без явной необходимости.

AI-ассистенты работают в логике "сделать, чтобы заработало". Широкие permissions решают проблему доступа немедленно. OWASP MCP Top 10:2025 выделяет Insufficient Authentication & Authorization (MCP07) и Privilege Escalation via Scope Creep (MCP02) как отдельные категории риска именно для AI-агентных систем [18].

Реальная опасность: если AI-агент с широкими правами становится вектором для prompt injection, он может быть использован для действий за пределами своей задачи. CVE-2025-53773 в GitHub Copilot (CVSS: 9.6) в 2026 году продемонстрировал: скрытый prompt injection в описании PR позволял выполнить удалённый код [19].

Как ловить: для каждого нового IAM-объекта, сервисного аккаунта или Dockerfile-инструкции проверять принцип least privilege. Является ли каждый permission необходимым для конкретной задачи? Ограничены ли права по ресурсу и действию?

Признак 9. Небезопасная обработка ошибок

Выглядит как: except Exception as e: return jsonify({"error": str(e)}). Или stack trace в production HTTP-ответе. Или логирование request.body целиком при ошибке.

AI-код оптимизирован под отладку: подробные сообщения об ошибках помогают понять, что пошло не так. В production это означает утечку внутренней архитектуры, путей к файлам, имён переменных окружения и структуры базы данных.

CodeRabbit зафиксировали: gaps в error and exception handling почти вдвое чаще встречаются в AI-соавторских PR, чем в человеческих [5]. Это один из самых предсказуемых и при этом недооцениваемых паттернов.

Как ловить: ищем в diff except: без специфичного типа исключения, str(e) в HTTP-ответах, print(traceback) в production-коде, логирование объектов request/response целиком.

Признак 10. Инъекции через конкатенацию строк

Выглядит как: query = "SELECT * FROM users WHERE id = " + user_id. Или subprocess.run(f"git clone {repo_url}", shell=True). Или innerHTML = "<div>" + userInput + "</div>".

Veracode зафиксировал: Cross-Site Scripting (CWE-80) имеет 86% failure rate в AI-сгенерированном коде [1]. AI-модели последовательно воспроизводят паттерны строковой конкатенации там, где нужны параметризованные запросы, экранирование или whitelist-валидация. Это один из старейших классов уязвимостей, который AI стабильно воспроизводит.

CodeRabbit также фиксирует рост insecure deserialization findings на 80% в AI-соавторском коде [5] — ещё один класс, связанный с доверием к входным данным без валидации.

Как ловить: в diff ищем конкатенацию строк, которая включает данные из запроса или внешних источников. Особое внимание — к SQL-запросам, shell-командам, HTML-шаблонам и путям к файлам.

Признак 11. Слабая или самодельная криптография

Выглядит как: hashlib.md5(password.encode()).hexdigest(). Или самодельная реализация XOR-шифрования. Или JWT, подписанный алгоритмом none. Или фиксированный IV в AES-CBC.

AI-модели обучены на огромном корпусе кода, включая устаревшие примеры с MD5, SHA1 и DES. Они воспроизводят эти паттерны, особенно в примерах "как быстро зашифровать пароль" или "как хранить токен". OWASP A02:2025 — Cryptographic Failures — включает в себя именно эти сценарии [17].

Самодельная крипто — классический признак AI-генерации: модель знает концепт шифрования, но не знает актуальных best practices для конкретного языка и контекста. В CodeRabbit исследовании improper password handling (включая hardcoded credentials и unsafe hashing) встречается в AI-PR почти вдвое чаще [5].

Как ловить: ищем md5, sha1, des, прямые вызовы random для генерации токенов, самописные функции с xor, cipher, encrypt в названии. Проверяем, используются ли проверенные библиотеки (bcrypt, argon2, cryptography) вместо стандартного hashlib.

Признак 12. Изменение конфигурации без явного требования задачи

Выглядит как: PR на добавление поля в форму попутно меняет nginx.conf. Или "рефакторинг" задевает .env.example с новыми переменными. Или появляется новый файл .cursorrules или CLAUDE.md с инструкциями для AI-агента.

Это — особый и нарастающий класс риска. AI-агенты могут модифицировать конфигурационные файлы как побочный эффект выполнения задачи. Несвязанное изменение конфига часто теряется в общем шуме большого diff.

Отдельная история — файлы с инструкциями для AI-агентов: .cursorrules, CLAUDE.md, system_prompt.txt. Если злоумышленник может изменить такой файл через PR (или внедрить его в репозиторий), он фактически программирует поведение AI-агента в последующих сессиях. Это форма prompt injection на уровне supply chain.

GitHub в марте 2026 года опубликовал рекомендации, прямо указывающие на риск внешних PR, модифицирующих workflow- и конфигурационные файлы [20].

Как ловить: при ревью явно проверять, что все изменённые файлы объясняются задачей из тикета. Конфиги, workflow, AI-инструкции — отдельная категория для обязательного ревью вне зависимости от размера изменения.

Общий паттерн: архитектурные флоу, которые SAST не видит

Большинство из описанных признаков объединяет одно: они не ловятся стандартными SAST-инструментами. SAST ловит синтаксические и структурные проблемы. AI генерирует архитектурные — логически корректные конструкции, которые небезопасны в конкретном контексте.

Именно поэтому Apiiro зафиксировали падение синтаксических ошибок в AI-коде на 76% при одновременном росте architectural flaws на 153% [2]. AI научился писать синтаксически правильно. Теперь проблема переместилась туда, где автоматика слабее всего.

Это именно та точка, где нужен дополнительный контрольный слой — не вместо SAST/SCA, а рядом с ними. Ревьюер читает diff быстро и может пропустить fallback-секрет на 43-й строке из 800. SAST не видит логику авторизации. SCA не знает, галлюцинирован ли пакет. Именно для этого существует HighVibe — как слой контроля, который анализирует конкретное изменение в контексте релиза и выдаёт короткий сигнал: что из этого PR действительно блокирует выпуск, а что можно принять.

Практический чек-лист: что проверять до merge

При ревью AI-соавторского PR последовательно проходим по следующим пунктам.

Секреты и credentials: нет ли hardcoded значений в коде, конфигах, тестах? нет ли fallback-секретов при отсутствии env-переменной? нет ли изменений в .env.example с реальными значениями?

CORS и HTTP-заголовки: какой origin whitelist? есть ли динамическое отражение Origin? сочетается ли credentials: true с wildcard?

Debug и production-настройки: выключен ли debug-режим? выставлен ли NODE_ENV/DJANGO_ENV корректно? нет ли verbose error output в ответах API?

Размер и связность diff: объясняется ли каждый изменённый файл задачей? нет ли несвязанных изменений конфигов, middleware, workflow?

Workflow-файлы: появились ли новые или изменились существующие .github/workflows? нет ли новых внешних curl-запросов? не расширились ли permissions?

Зависимости: верифицирован ли каждый новый пакет в реестре? сравниваем ли lock-файл до и после? нет ли пакетов с подозрительно новой датой публикации?

Авторизация: у каждого нового эндпоинта есть auth-middleware? проверяется ли ownership, а не только аутентификация? нет ли параметров user_id, role, admin в теле без server-side проверки?

Ошибки и антипаттерны при работе с AI-кодом

Доверять CI как единственному gate. CI проверяет работоспособность, не безопасность архитектурных решений. Зелёный пайплайн не означает безопасный PR.

Читать только изменённые строки. AI нередко меняет поведение функции, не меняя её сигнатуру. Проверять нужно контекст вокруг изменения, не только сам diff.

Пропускать конфиги и workflow как "служебные". Именно они — наиболее частая точка входа для supply chain атак и наименее читаемая часть больших PR.

Считать review comment AI-ассистента достаточным. AI-ревьюеры ловят паттерны, но не понимают бизнес-контекст и угрозовую модель. Они — первый слой, не последний.

Игнорировать транзитивные зависимости. Прямые зависимости проверяют. Lock-файл с транзитивными — нет. Атака может прийти через вложенный пакет, которого нет в package.json.

Тренды и что ожидать дальше

Vibe Security Radar Georgia Tech документирует ускорение: в первом квартале 2026 года они обнаружили 56 подтверждённых AI-уязвимостей — больше, чем за всё второе полугодие 2025 [12]. Месяц март 2026 года один дал 35 случаев — больше, чем весь 2025 год.

Параллельно растёт автономность агентов. Claude Code, Copilot Workspace и аналоги уже создают файлы, пишут архитектуру и принимают технические решения. Когда агент строит компонент без аутентификации — это не опечатка, это архитектурный дефект, встроенный с самого начала [12].

Количество утечек AI-сервисных секретов в 2025 году выросло на 81% год к году. Двенадцать из пятнадцати самых быстрорастущих типов утечек — AI-сервисы [3]. Это отражает, как реально строятся команды: быстро, с несколькими провайдерами, с приоритетом рабочего кода над credential governance.

Что делать дальше

AI-ассистенты стали частью инженерной реальности. Вопрос не в том, использовать их или нет. Вопрос в том, как контроль качества успевает за их скоростью.

Конкретные шаги для команды:

1. Ввести явный чек-лист для AI-соавторских PR — как описано выше.
2. Установить лимиты на размер PR и требовать дополнительного ревьюера при превышении.
3. Отдельно обрабатывать изменения в workflow, конфигах и зависимостях — независимо от размера изменения.
4. Интегрировать SCA с проверкой существования пакета в реестре, не только CVE-сканирование.
5. Рассмотреть дополнительный слой контроля до merge — инструмент, который анализирует конкретное изменение в контексте и выдаёт сигнал о реальных рисках, а не генерирует длинный отчёт по всему репозиторию.

Рабочий код — это не безопасный код. И именно сейчас, когда AI пишет быстрее, чем ревьюер успевает читать, этот разрыв становится критическим.

Источники

[1] Veracode — "2025 GenAI Code Security Report" — https://www.veracode.com/blog/ai-generated-code-security-risks/

[2] SoftwareSeni — "Security Risks in AI-Generated Code and How to Mitigate Them" — https://www.softwareseni.com/security-risks-in-ai-generated-code-and-how-to-mitigate-them/

[3] The Security Ledger — "Exposed Developer Secrets Surge: AI Drives 34% Increase in 2025" — https://securityledger.com/2026/03/exposed-developer-secrets-surge-ai-drives-34-increase-in-2025/

[4] Aikido Security — "Slopsquatting: The AI Package Hallucination Attack Already Happening" — https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks

[5] Help Net Security — "AI code looks fine until the review starts" — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

[6] Unit42 Palo Alto Networks — "GitHub Actions Supply Chain Attack: Targeted Attack on Coinbase Expanded to tj-actions/changed-files" — https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/

[7] PointGuard AI — "AI Training Data Secret Leak 2025: 12,000 API Keys Exposed" — https://www.pointguardai.com/ai-security-incidents/12-000-api-keys-and-passwords-exposed-in-ai-training-data

[8] Obsidian Security — "CVE-2025-34291: Critical Account Takeover and RCE Vulnerability in Langflow" — https://www.obsidiansecurity.com/blog/cve-2025-34291-critical-account-takeover-and-rce-vulnerability-in-the-langflow-ai-agent-workflow-platform

[9] GitHub Issues — "Permissive CORS Wildcard Policy on All API Endpoints — NextChat" — https://github.com/ChatGPTNextWeb/NextChat/issues/6756

[10] VentureBeat — "43% of AI-generated code changes need debugging in production, survey finds" — https://venturebeat.com/technology/43-of-ai-generated-code-changes-need-debugging-in-production-survey-finds

[11] Salesforce Engineering — "Scaling Code Reviews: Adapting to a Surge in AI-Generated Code" — https://engineering.salesforce.com/scaling-code-reviews-adapting-to-a-surge-in-ai-generated-code/

[12] Infosecurity Magazine — "Researchers Sound the Alarm on Vulnerabilities in AI-Generated Code" — https://www.infosecurity-magazine.com/news/ai-generated-code-vulnerabilities/

[13] The Hacker News — "CISA Warns of Active Exploitation in GitHub Action Supply Chain Compromise" — https://thehackernews.com/2025/03/cisa-warns-of-active-exploitation-in.html

[14] GitGuardian Blog — "The GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows" — https://blog.gitguardian.com/ghostaction-campaign-3-325-secrets-stolen/

[15] Snyk — "Trivy GitHub Actions Supply Chain Compromise" — https://snyk.io/articles/trivy-github-actions-supply-chain-compromise/

[16] ToxSec — "What is Slopsquatting? AI Hallucinations Ship Malware" — https://www.toxsec.com/p/what-is-slopsquatting-ai-hallucinations

[17] OWASP — "Top 10:2025 — A01 Broken Access Control" — https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/

[18] OWASP — "MCP07:2025 — Insufficient Authentication & Authorization" — https://owasp.org/www-project-mcp-top-10/2025/MCP07-2025–Insufficient-Authentication&Authorization

[19] Cycode — "Top AI Security Vulnerabilities to Watch out for in 2026" — https://cycode.com/blog/ai-security-vulnerabilities/

[20] GitHub Blog — "Securing the open source supply chain across GitHub" — https://github.blog/security/supply-chain-security/securing-the-open-source-supply-chain-across-github/