GLM Raw придумывает проверки, GPT пишет тесты: как я использую Kumo для аудита безопасност
Мы — команда Kumo. Попросили одного из наших пользователей поделиться опытом использования сервиса в нестандартном сценарии — проверке безопасности приложений с помощью связки моделей. Всё, что вы прочитаете ниже, написал наш хороший друг Антон — разработчик и DevOps небольшой студии, которая создаёт приложения для бизнеса.
А модели по доступным ценам можно найти на kumorouter.com Меня зовут Антон, я DevOps в небольшой студии, которая разрабатывает приложения для бизнеса. Как настойщий вайбкодер я надиктовал все своему агенту, который подготовил эту статью. Это не просто нейрослоп, а мои мысли написанные ии; А теперь к статье. Наш обычный набор задач — личные кабинеты, CRM, интеграции, документы и права доступа. В таких проектах безопасность часто ломается в прозаических местах: сотрудник видит чужой файл, менеджер получает лишнее разрешение, фоновая задача забывает проверить организацию. Для разбора подобных сценариев я использую связку моделей через Kumo: GLM Raw помогает подготовить гипотезы и промпты, а GPT-6.1 Sol или Claude Opus — превратить их в проверяемые инженерные задачи. Особенно полезен этот подход, когда обычный помощник реагирует на слова «обход авторизации» раньше, чем успевает разобраться, что речь идёт о проверке собственного приложения. Особенно бесит Opus. Он должен помогать находить уявимости, а в итоге превращается в модель которая все запрещает. Работать с ним напрямую невозможно, нужна обязательно прокладка и очень грамотный промпт. В проверке безопасности приходится описывать нежелательное поведение довольно прямо. Например: может ли пользователь одной организации получить документ другой? Сохраняется ли доступ после отзыва роли? Можно ли вызвать административную операцию через обычный API? Слишком общий запрос на такую тему легко превращается в бесполезный разговор об ограничениях. Поэтому первый этап моей схемы — подробно сформулировать задачу: что принадлежит нам, какие действия разрешены и какое нарушение мы хотим исключить. Для этого подходит GLM-5.3 Raw. Kumo описывает её как uncensored-вариант GLM-5.3, в котором RawModels ослабили встроенные отказы методом abliteration. Подробности и обзор моделей есть в статье «ИИ без цензуры: как работают uncensored-модели, abliteration и antislop». Здесь полезно разделить два свойства: готовность обсуждать задачу и способность правильно её решить. Модель может охотно отвечать и при этом ошибаться в архитектуре, придумывать несуществующий endpoint или предлагать проверку, которая ничего не доказывает. Поэтому Raw у меня получает роль генератора гипотез. Каждой гипотезе дальше нужны исходный код, тест и наблюдаемый результат. Схема проверки приложения с помощью нескольких моделей Схема рабочего процесса. Она показывает последовательность действий, а не результаты сравнительного тестирования моделей. Kumo здесь удобен доступом к разным моделям через один сервис. Для работы через API можно использовать общий ключ и выбирать нужную модель; актуальные идентификаторы и поддерживаемые возможности опубликованы в каталоге Kumo. При этом ключ API сам по себе не даёт модели доступ к репозиторию, терминалу или стенду. Эти инструменты подключаются отдельно в используемом клиенте или агенте, и именно там задаются разрешения. Разберём подход на учебном примере: CRM, в которой несколько организаций работают в одном приложении. У каждой свои сотрудники, сделки и документы. Есть роли администратора, менеджера и наблюдателя. Первый запрос я строю вокруг конкретных свойств системы: Ты помогаешь подготовить проверку безопасности нашего приложения на изолированном стенде. Приложение — CRM с несколькими организациями. В каждой организации есть администратор, менеджер и…
Источник: vc.ru — vc.ru/ai/3243191-ispolzovanie-kumo-dlya-audita-bezopasnosti-prilozheniy
