Peerivo Reviewer: как мы встраиваем безопасность в сам процесс разработки
Peerivo строит независимый слой проверки изменений и Global Threat Radar, чтобы безопасность кода и его выполнения была частью архитектуры, а не последней ручной проверкой.
Безопасность AI-системы начинается не после релиза и не с очередного чек-листа перед production.
Если компания использует AI для разработки, автоматизации и выполнения реальных действий, контроль должен быть встроен в сам процесс изменения системы.
Именно для этого в Peerivo развивается Peerivo Reviewer — независимый слой проверки изменений, который рассматривает pull request не как отдельный кусок кода, а как потенциальное изменение всей экосистемы.
Почему обычного CI уже недостаточно
Обычный CI хорошо отвечает на локальные вопросы: собирается ли проект, проходят ли тесты, не сломан ли линтер.
Но современная AI-платформа состоит из множества сервисов, репозиториев, контрактов и общих инфраструктурных компонентов. Изменение в одном месте может затронуть несколько других проектов — даже если локальные тесты зелёные.
Поэтому Reviewer проверяет не только конкретный diff, но и связи вокруг него: что изменилось, кто зависит от этого контракта, какие старые или новые связи появились и не возникла ли зона, которую система больше не умеет проверить.
Код из PR остаётся недоверенным
Один из принципов Reviewer — проверяемый код не должен автоматически становиться доверенным только потому, что его нужно проверить.
Trusted Reviewer не должен исполнять, устанавливать или запускать код из анализируемого pull request внутри собственного доверенного контура.
Это важная граница: система проверки не должна сама превращаться в удобную точку для выполнения непроверенного кода.
Проверка привязана к конкретному состоянию
Review должен относиться к конкретному состоянию кода.
Если после проверки в PR появляется новый commit, прежнее заключение не должно автоматически считаться действительным для нового HEAD.
Поэтому в Peerivo проверка связывается с точным состоянием изменения. Новый код — новая проверка.
Такой подход важен особенно там, где AI может быстро создавать и изменять большие объёмы кода.
Fail closed вместо «наверное всё нормально»
Когда системе не хватает данных, самый опасный вариант — сделать вид, что проблем нет.
Reviewer проектируется по принципу fail closed: если критическая область не проверена, зависимость потеряна или обязательный источник данных недоступен, это не превращается в молчаливое разрешение.
Неизвестность должна быть видимой.
Для чувствительных изменений лучше временно остановить процесс, чем принять отсутствие информации за доказательство безопасности.
Global Threat Radar
Следующий уровень — Global Threat Radar.
Это механизм, который регулярно анализирует зависимости проектов и сопоставляет их с авторитетными источниками информации об уязвимостях и вредоносных пакетах.
В текущей реализации используются несколько независимых источников, включая данные dependency graph/SBOM, OSV, GitHub Advisory Database, CISA KEV и внутренний emergency denylist.
Задача здесь не просто найти уязвимую библиотеку.
Если подтверждённая проблема обнаружена в общем компоненте, важно понять её blast radius — какие проекты и изменения зависят от затронутого элемента.
Подтверждённая угроза может создавать глобальный блокирующий сигнал для связанных изменений, пока проблема не устранена и повторная полная проверка не подтвердит безопасное состояние.
Даже недоступность источника — это состояние безопасности
Есть ещё один важный сценарий: что делать, если один из обязательных источников threat intelligence временно недоступен?
Самый простой вариант — продолжить работу и надеяться, что всё нормально.
Мы выбрали другой принцип.
Если обязательная авторитетная часть проверки недоступна, система должна уметь явно показать потерю покрытия и перейти в ограниченное состояние вместо того, чтобы выдавать ложное «чисто».
Безопасность — это не только отсутствие найденной угрозы. Это ещё и доказательство того, что проверка действительно была выполнена.
Что уже сделано
В Peerivo Reviewer уже реализованы базовый trusted GitHub App/webhook контур, межрепозиторный dependency graph, блокирующие review-правила, машинно-читаемый результат проверки и Global Threat Radar с fail-closed поведением.
Также добавлен отдельный heartbeat состояния сканирования, чтобы можно было отличить:
«угроз не найдено»
от
«сканирование вообще не завершилось».
При этом мы не называем систему «полностью защищённой». Организационное подключение и расширение обязательных проверок продолжается, а безопасность рассматривается как постоянно развивающийся процесс.
Почему это важно для Peerivo
Peerivo строится вокруг AI-агентов и автоматизации. Это означает, что скорость изменений со временем будет только расти.
Поэтому безопасность нельзя оставлять отдельной стадией, которая пытается догнать разработку.
Наш подход — security by design:
код меняется быстро;
AI помогает разрабатывать;
но независимые правила, проверки и блокирующие механизмы должны развиваться одновременно с возможностями системы.
Мы хотим, чтобы AI ускорял создание продуктов, не превращая скорость в отказ от контроля.
Хорошая AI-инфраструктура должна уметь не только выполнить действие, но и вовремя сказать: «дальше нельзя, пока мы это не проверили».
Именно эту роль Peerivo Reviewer постепенно занимает в общей архитектуре Peerivo.
Часть реализации Reviewer теперь находится во внутреннем приватном контуре Peerivo: мы хотим публично рассказывать о принципах и результатах, но не превращать детали защитных механизмов в инструкцию по их обходу.