🗂 SECURITY.md — простой путь к безопасному gen-AI коду
Зайду, как водится, издалека. На работе я сейчас вожусь со штукой, для тестирования которой нужно заставить LLM, работающую с кодинг-агентом, ненамерено генерировать уязвимый код. И это, должен заметить, оказалось не так уж и легко, что навело на весьма очевидную мысль.
LLM, в массе своей, вполне способны писать безопасный код. Знаний на эту тему у них — уж точно больше, чем у любого среднестатистического эксперта в этой области. Но скажите на милость, когда разработчик пишет агенту:
— какая из букв в этом промпте означает security? Может быть, про неё упоминается в скилле? Да тоже нет. В куче же скиллов для secure-кодинга буквально каждый — представляет собой перечень избитых (плюс и так известных моделям) правил, поверх «усредненных» моделей угроз.
А весь мой опыт, полученный за полтора десятка лет работы в области безопасности кода, говорит о том, что работая с усредненной моделью угроз, нельзя рассчитывать на что-либо, кроме усредненных результатов.
Так может, модели нужна подсказка о том, чем именно является безопасность в данном конкретном проекте и как применять к ней имеющиеся у модели знания? GitHub уже предлагает иметь в корне проекта SECURITY.md, с поддерживаемыми версиями проекта и процедурой репортинга уязвимостей, называя это «политикой безопасности». Так может, стоит её там таки описать?
Так и родился скилл security-policy-generator, генерирующий SECURITY.md, который включает в себя, помимо гихабовских разделов, ещё и модель угроз с правилами secure-кодинга, построенными относительно конкретного проекта со всей его спецификой. Ну и, скилл также добавляет референс на созданный файл в AGENTS.md с инструкцией по использованию, чтобы агент уж точно его не пропустил. Коль скоро SECURITY.md создан, обновлять его можно простым «Update SECURITY.md to reflect the latest changes.», отдельный скилл для этого не требуется.
Посмотреть результаты работы скилла на конкретном проекте можно здесь.
Бенчи не проводил (в планах это есть), но достаточно плотно потестировал результаты работы скилла на нескольких проектах под Qoder, OpenCode и собственным кодинг-агентом. Рассуждения вида «This [won't] become a vulnerability because » появляются, что как бы намекает на правильную работу всей задумки.
P.S: отдельно порадовало, что мой кодинг-агент (по ссылке выше — результаты именно его работы) самоотверженно включил самого себя в потенциальные threat-actors модели угроз. Это так мило... 🥹
А вы говорите, AI-агенты в безопасности не шарят))
Зайду, как водится, издалека. На работе я сейчас вожусь со штукой, для тестирования которой нужно заставить LLM, работающую с кодинг-агентом, ненамерено генерировать уязвимый код. И это, должен заметить, оказалось не так уж и легко, что навело на весьма очевидную мысль.
LLM, в массе своей, вполне способны писать безопасный код. Знаний на эту тему у них — уж точно больше, чем у любого среднестатистического эксперта в этой области. Но скажите на милость, когда разработчик пишет агенту:
Эй, /explore, давай спроектируем крутую фичу feat-XXX для !
— какая из букв в этом промпте означает security? Может быть, про неё упоминается в скилле? Да тоже нет. В куче же скиллов для secure-кодинга буквально каждый — представляет собой перечень избитых (плюс и так известных моделям) правил, поверх «усредненных» моделей угроз.
А весь мой опыт, полученный за полтора десятка лет работы в области безопасности кода, говорит о том, что работая с усредненной моделью угроз, нельзя рассчитывать на что-либо, кроме усредненных результатов.
Так может, модели нужна подсказка о том, чем именно является безопасность в данном конкретном проекте и как применять к ней имеющиеся у модели знания? GitHub уже предлагает иметь в корне проекта SECURITY.md, с поддерживаемыми версиями проекта и процедурой репортинга уязвимостей, называя это «политикой безопасности». Так может, стоит её там таки описать?
Так и родился скилл security-policy-generator, генерирующий SECURITY.md, который включает в себя, помимо гихабовских разделов, ещё и модель угроз с правилами secure-кодинга, построенными относительно конкретного проекта со всей его спецификой. Ну и, скилл также добавляет референс на созданный файл в AGENTS.md с инструкцией по использованию, чтобы агент уж точно его не пропустил. Коль скоро SECURITY.md создан, обновлять его можно простым «Update SECURITY.md to reflect the latest changes.», отдельный скилл для этого не требуется.
Посмотреть результаты работы скилла на конкретном проекте можно здесь.
Бенчи не проводил (в планах это есть), но достаточно плотно потестировал результаты работы скилла на нескольких проектах под Qoder, OpenCode и собственным кодинг-агентом. Рассуждения вида «This [won't] become a vulnerability because » появляются, что как бы намекает на правильную работу всей задумки.
P.S: отдельно порадовало, что мой кодинг-агент (по ссылке выше — результаты именно его работы) самоотверженно включил самого себя в потенциальные threat-actors модели угроз. Это так мило... 🥹
А вы говорите, AI-агенты в безопасности не шарят))