Нормальная схема: фиксировать базовые образы (а то и distrolless), сканировать, смотреть критичность CVE и применимость, подписывать артефакты, проверять SBOM/происхождение и периодически обновлять.
Поощряем, но токенмаксинг не устраиваем. Я пока придерживаюсь мнения, что ллмки отлично делают некоторую часть рабочей рутины, заменяют личного ассистента и почти мидла на подхвате.
У нас неплохо заходят - подсобничество в проектировании и декомпозиции фичей (помочь собрать стройную картину, заметить несостыковки, оформить в задачи), правка багов по отчету, реализация достаточно шаблонного функционала, помощь в закрытие тех долга (тесты, переписывание с устаревшего стека). Это все частные примеры, но хорошо показывающие, что ллмки хотя бы понемногу, но почти везде
В целом, если атакующий может выполнять код в том же контексте, что и приложение, надежно “спрятать” токен уже нельзя, на мой взгляд. Всё, что приложение может предъявить Vault, атакующий в этом контексте тоже рано или поздно предъявит или вытащит.
Я бы пошел по пути снижении ущерба: короткоживущие токены, в первую очередь, ротация и может быть мониторинг рантайма контейнеров как последний эшелон защиты. Для последнего можно посмотреть наш OSS проект Runtime Radar
Контейнеры не притворяются отдельным компьютером, в отличие от ВМ. Они делят ядро хоста и изолируют процессы через namespaces/cgroups. Поэтому они легче и быстрее стартуют, например.
PR'ы по делу в Runtime Radar. Но без гарантий :)
Призываю не "редко" и не "часто", а управляемо.
Нормальная схема: фиксировать базовые образы (а то и distrolless), сканировать, смотреть критичность CVE и применимость, подписывать артефакты, проверять SBOM/происхождение и периодически обновлять.
Поощряем, но токенмаксинг не устраиваем.
Я пока придерживаюсь мнения, что ллмки отлично делают некоторую часть рабочей рутины, заменяют личного ассистента и почти мидла на подхвате.
У нас неплохо заходят - подсобничество в проектировании и декомпозиции фичей (помочь собрать стройную картину, заметить несостыковки, оформить в задачи), правка багов по отчету, реализация достаточно шаблонного функционала, помощь в закрытие тех долга (тесты, переписывание с устаревшего стека). Это все частные примеры, но хорошо показывающие, что ллмки хотя бы понемногу, но почти везде
Если я правильно понял вопрос, речь про продукты PT?
У нас отличная связка с PT SIEM, например - отдельная интеграция и обмен экспертизой. Можно взглянуть прямо в документации
В целом, если атакующий может выполнять код в том же контексте, что и приложение, надежно “спрятать” токен уже нельзя, на мой взгляд. Всё, что приложение может предъявить Vault, атакующий в этом контексте тоже рано или поздно предъявит или вытащит.
Я бы пошел по пути снижении ущерба: короткоживущие токены, в первую очередь, ротация и может быть мониторинг рантайма контейнеров как последний эшелон защиты. Для последнего можно посмотреть наш OSS проект Runtime Radar
Контейнеры не притворяются отдельным компьютером, в отличие от ВМ. Они делят ядро хоста и изолируют процессы через namespaces/cgroups. Поэтому они легче и быстрее стартуют, например.
Респект за актуальность!
Я не был уверен, что не придумал это в своей голове, так что убрал из статьи)