Новый Tenable.cs для команд DevSecOps обеспечивает безопасность как код

Новый Tenable.cs для команд DevSecOps обеспечивает безопасность как код

Новый Tenable.cs для команд DevSecOps обеспечивает безопасность как код

Новая платформа Tenable.cs, по словам компании Tenable, реализует принципы DevSecOps и принцип Shift Left Security, внедряя безопасность на более ранних стадиях разработки. Особое внимание Tenable.cs уделяет Infrastructure as Code (IaC) — инфраструктуре как коду.

Многие специалисты ИБ жалуются на слишком большое количество точечных СЗИ и другие трудности, с которыми приходится сталкиваться на пути к эффективной защите. Они вынуждены использовать десятки инструментов для решения отдельных проблем безопасности и вручную агрегировать связанные с ними данные и события, полагаясь на свои знания и опыт.

Чтобы решить этот комплекс проблем, была создана единая платформа Tenable.cs для защиты облачной инфраструктуры от стадии разработки до среды исполнения с унифицированными политиками безопасности и регуляторного соответствия.

Платформа устраняет раздробленность СЗИ, упрощает настройку сред, позволяет системно применять политики и минимизировать слепые зоны. По сравнению с традиционными подходами к ИБ использование единой интегрированной платформы Tenable.cs помогает повысить эффективность защиты, ускорить реагирование на инциденты и снизить операционные расходы.

Как отмечают разработчики, Tenable.cs помогает реализовать безопасность как код: задать практики и политики ИБ в формате кода, который будет управлять облачной инфраструктурой и процессом разработки. Безопасность как код позволяет отслеживать киберриски на самых первых стадиях разработки и автоматизировать выполнение политик на протяжении всего жизненного цикла приложения.

Tenable.cs дополняет функциональные возможности платформы Accurics, которую Tenable приобрела в октябре 2021 года. В платформе полностью переработали пользовательский интерфейс, который сейчас представляет собой единую консоль с панелями управления различных облачных систем.

Теперь можно легко увидеть нарушения, ошибки конфигурации и риски, угрожающие безопасности репозиториев кода, облачных аккаунтов, кластеров Kubernetes, а также пайплайнов CI/CD и GitOps.

 

Помимо этого, Tenable.cs позволяет проще и удобнее настраивать сложные среды и проекты в облачных сервисах Amazon (AWS) , MIcrosoft Azure и Google Cloud Platform (GCP). А новый редактор политик безопасности не требует написания кода (low code), что упрощает управление их логикой и снимает необходимость учить язык политик Rego.

Кроме сканирования запущенных в облаке процессов по расписанию, запросу или событию Tenable.cs может непрерывно отслеживать изменения конфигурации AWS, обеспечивая управление облачной безопасностью в реальном времени.

 

Также добавилось комплексное управление безопасностью Kubernetes, включающее настройки безопасности для пайплайнов разработки и контроля доступа, а также применение политик и управление отклонениями конфигурации в запущенных кластерах.

Чтобы снизить нагрузку на команды разработчиков, Tenable.cs поддерживает интеграцию с пайплайнами разработки и применение в них политик безопасности. Сюда входят новые политики, проверяющие наличие уязвимостей в приложениях с помощью статического анализа кода (SAST), анализа компонентов кода (SCA) и аналитику по безопасности контейнеров.

 

Также в Tenable.cs есть рекомендации по политикам Kubernetes, основанные на руководстве по усилению безопасности этой технологии — Kubernetes Hardening Guidance — от Агентства национальной безопасности США (NSA) и Агентства по кибербезопасности и защите инфраструктуры (CISA). Благодаря этому разработчики могут легко проверить, соответствует ли настройка их систем Kubernetes рекомендациям NSA и CISA.

Пользователи SaaS-платформы Accurics автоматически получат ее обновление до Tenable.cs. Те, кто развернул Accurics локально, должны самостоятельно обновиться до Tenable.cs. Заказать расчёт, демо или тестирование можно по этой ссылке.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

Уязвимость в OpenSSH: имена пользователей позволяют выполнить код

Исследователь безопасности Дэвид Лидбитер обнаружил уязвимость в OpenSSH — CVE-2025-61984 — которая демонстрирует: даже мелкие особенности парсинга команд и поведения shell могут привести к удалённому выполнению кода.

Суть проблемы проста и неприятна: в OpenSSH (до версии 10.1) контрол-символы в именах пользователей, полученных из ненадёжных источников, могли не отфильтровываться.

Когда такое «имя» подставлялось в ProxyCommand (через переменную %r), OpenSSH формировал строку для exec, которую запускал через shell. Если в этой строке оказывались символы вроде $[ и символы новой строки, некоторые оболочки (например, bash) могли интерпретировать это так, что первая команда аварийно завершается, а затем выполняется то, что идёт после — то есть возможна инъекция команды.

Эксплуатация требует специфической связки: конфигурация, использующая ProxyCommand с %r, уязвимая оболочка и «входной» источник имени пользователя, который злоумышленник контролирует. Практический пример — злоумышленный .gitmodules, где в URL подставляют строку вроде:

[submodule "foo"]
  path = foo
  url = "$[+]\nsource poc.sh\n@foo.example.com:foo"

Если SSH-конфиг содержит строку вроде

ProxyCommand some-command %r@%h:%p

и вы запускаете git clone --recursive, то в подходящих условиях может выполниться source poc.sh — до установления самого соединения.

Важно понимать: условия для успешной атаки нишевые, но реальны — инструментальная цепочка Git → SSH → shell и автоматизация (CI/CD) дают атакующему много точек входа. Проблема усугубляется тем, что OpenSSH фильтровал многие метасимволы, но пропустил $ и [ — и это создало неожиданный вектор.

Исправление уже включено в OpenSSH 10.1: разработчики начали проверять и запрещать управляющие символы в именах пользователей через iscntrl() в ssh.c. То есть долгосрочное решение — обновиться до 10.1 или новее.

Если обновиться сразу нельзя, Лидбитер предлагает два практических временных шага. Во-первых, брать имя пользователя в одинарные кавычки в ProxyCommand, чтобы предотвратить подстановку:

ProxyCommand some-command '%r@%h:%p'

(Обратите внимание: одинарные кавычки нужны именно потому, что двойные не защитят от $[ — оболочка всё ещё будет их обрабатывать.) Во-вторых, по умолчанию отключить SSH-подмодули в Git и не позволять автоматические URL-хендлеры, которые могут передавать непроверенные SSH-команды:

git config --global protocol.ssh.allow user

Главный вывод — не полагаться на то, что «маленький» символ или строка не принесут беды: при передаче входа от ненадёжных источников через несколько инструментов даже неочевидная каверза в парсинге может стать критической. Рекомендуется как можно скорее обновить OpenSSH или применить временные защитные меры в конфигурациях ProxyCommand и политиках Git.

AM LiveПодписывайтесь на канал "AM Live" в Telegram, чтобы первыми узнавать о главных событиях и предстоящих мероприятиях по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru