Журнал "Information Security/ Информационная безопасность" #2, 2026

Как быстро внедрить DevSecOps: Кроме того, заказчику не нужно фор- мировать дорогостоящую команду узко- профильных специалистов – экспертиза предоставляется как сервис. Мы не просто выгружаем результаты автома- тических сканирований, а проводим их верификацию. В итоге заказчик полу- чает вместо сотни страниц отчета корот- кий список фактически подтвержденных уязвимостей или уязвимостей с высокой степенью критичности. Это позволяет разработчикам сфокусироваться на дей- ствительно значимых проблемах. Apsafe не ограничивается только типо- выми вещами. За счет ручной проверки и экспертизы мы можем выявлять и более сложные, в том числе логические уязвимости, связанные с особенностями бизнес-процессов приложения. – Из чего состоит Apsafe? – Изначально Apsafe строился вокруг ключевых модулей. Статический анализ (SAST) и композиционный анализ (SCA), которые позволяют находить уязвимости в исходном коде и зависимостях, выявлять известные проблемы безопас- ности и небезопасные паттерны. Дина- мический анализ включает в себя несколько направлений: классический DAST (тестирование через веб-интерфейс с поиском типовых уязвимостей) и более продвинутый уровень – фаззинг, позво- ляющий выявлять ошибки обработки входных данных и находить как типовые, так и более сложные дефекты, в том числе на уровне логики. Используется также инструментальная верификация – по сути, имитация атак (Penetration Test- ing), где дополнительно проверяется реальная эксплуатируемость уязвимо- стей, включая логические сценарии. Все результаты проходят экспертную проверку, и заказчик получает уже очи- щенный, приоритизированный список проблем. Со временем платформа расширилась: мы добавили модуль Container Security, который отвечает за безопасность кон- тейнерной инфраструктуры и сред оркест- рации, в частности Kubernetes в рантайме. Решение интегрировано с партнерскими технологиями (Luntry) и предоставляется как сервис, без необходимости сопро- вождения со стороны заказчика. Следующим шагом развития плани- руется добавление AI Firewall. Это отдельный модуль для защиты систем на базе LLM от типовых атак, таких как Prompt Injection и утечки данных. В итоге ценность Apsafe для заказчи- ка заключается в комплексном покры- тии: от кода и зависимостей до инфра- структуры и новых классов рисков, при этом без необходимости строить собст- венную экспертизу и инфраструктуру с нуля. – Какие сложности возникают при анализе кода на разных язы- ках и как вы их решаете? – Ключевой момент здесь в правиль- ной подборке инструментов под кон- кретный технологический стек. На рынке есть решения, которые заявляют под- держку десятков языков, но это не озна- чает одинаково высокое качество ана- лиза для каждого из них. Поэтому в Apsafe мы используем специализиро- ванные инструменты под конкретные языки и задачи. Отдельная специфика – компилируе- мые языки, такие как C или C++. Здесь важно, чтобы анализатор корректно встраивался в процесс сборки и учиты- вал реальные параметры компиляции. Это напрямую влияет на качество результатов и снижает как количество ложноположительных (False Positive), так и пропущенных (False Negative) сра- батываний. Важно также, чтобы анали- затор использовал такие техники как анализ потока данных и анализ поме- ченных данных. Не менее важна и компетенция спе- циалистов. Анализ кода требует пони- мания самого языка и контекста его применения. Например, для C в про- мышленной разработке прямой доступ к памяти может быть нормой, тогда как в других сценариях это считалось бы уязвимостью. Без учета таких нюансов автоматический анализ будет давать нерелевантные результаты. – Как быстро внедряется Apsafe и от чего это зависит? – Внедрение происходит достаточно быстро. В среднем мы ориентируемся примерно на 10 рабочих дней – и это уже с учетом организационных этапов: настройки доступа, интеграции и встраи- вания в процессы разработки. Сроки в первую очередь зависят от того, с каким технологическим стеком и пай- плайном мы работаем. Например, у нас были кейсы, когда изначально интегра- ция была настроена под GitLab, а затем заказчик стал использовать Jenkins – в этом случае требовалась дополни- тельная настройка, но она заняла бук- вально несколько дней. Важно также, на каких этапах заказчик хочет встроить проверки. Это может быть ранний этап – сразу при коммите или пуше в репозиторий, либо более поздние стадии, например перед рели- зом. Мы подстраиваемся под текущий процесс, при необходимости дорабаты- ваем пайплайн и добавляем этапы ска- нирования. – Что выгоднее заказчику: сер- вис или своя команда? И как посчитать эффект от безопасной разработки? – Здесь нет универсального ответа – все зависит от масштаба разработки. Если у компании большой объем ПО, частые релизы, десятки сервисов, то, как правило, имеет смысл выстраивать собственную экспертизу и внедрять практики безопасной разработки внут- ри. Мы в УЦСБ, кстати, часто помогаем заказчикам запускать такие процессы с нуля. Сервисная модель лучше работает в других сценариях. Например, у заказ- чика уже выстроены процессы безопасной разработки для десятка систем, но есть отдельные системы, которые не покрыты практиками, нанимать под них отдельную команду нецелесообразно. Или если ком- пания разрабатывает один-два продукта и хочет сосредоточиться на бизнесе, а вопросы безопасности отдать на аут- сорс. Например, вендоры узкоспециали- зированных решений не строят собст- венную DevSecOps-команду, используя сервис. Переход к собственной команде имеет смысл, когда суммарная стоимость найма и содержания двух-трех специали- стов становится сопоставимой или ниже, чем использование сервиса. Что касается оценки эффекта (ROI) от безопасной разработки, то это не всегда прямая метрика. Мы обычно под- ходим к этому через риск-ориентиро- ванную модель: оцениваем критичность сервиса, данные, с которыми он работа- ет, и потенциальные потери от инцидента или простоя. Дальше это сопоставляется со стои- мостью внедрения практик безопасности. Если стоимость инцидента кратно выше, чем инвестиции в DevSecOps, – ответ очевиден. Особенно это актуально для критичных систем, где простой может стоить миллионы рублей. – Существуют ли примеры неудачного внедрения безопас- ной разработки? – Примерно в половине случаев внед- рения безопасной разработки такие ини- циативы либо не дают ожидаемого эффекта, либо затухают. Выделю три основные причины. Первая – отсутствие четкой стратегии. Компании внедряют отдельные практики, не понимая, зачем именно они нужны и какой результат должны дать. Вторая причина кроется в попытке внедрить все и сразу. Базовый набор практик занимает один-два года и требует выделенной команды. Без этого процесс быстро пере- гружается и останавливается. Третья – культурный конфликт. Разработка ори- ентирована на скорость и Time-to-Market, а безопасность – на снижение рисков и отсутствие инцидентов. Если нет общей системы KPI, команды начинают тянуть проект в разные стороны. 12 • В ФОКУСЕ