Безопасность программного обеспечения — это не финальный этап, а часть каждого шага разработки. Уязвимости, обнаруженные после релиза, обходятся в разы дороже, чем своевременная профилактика. Эксперты AM Live обсудили, как внедрить лучшие практики и стандарты разработки безопасного ПО и избежать ошибок.
- Введение
- Российские и международные стандарты РБПО: ФСТЭК, NIST, OWASP
- Обучение разработчиков безопасному программированию: подходы и мотивация
- Как совместить цели бизнеса и требования безопасной разработки
- ТОП ошибок при внедрении РБПО и реальные кейсы их последствий
- Безопасность на уровне архитектуры: микросервисы, API, авторизация
- ИИ в безопасной разработке: риски, возможности и перспективы
- Выводы
Введение
Современное программное обеспечение становится всё сложнее, а кибератаки — всё изощрённее. Уязвимости в коде, неправильная настройка инфраструктуры или недостаточная защита данных могут привести к катастрофическим последствиям: утечкам информации, финансовым потерям и репутационному ущербу.
Традиционный подход, при котором безопасность рассматривается лишь на этапе тестирования или после релиза, уже не работает. Разработка безопасного программного обеспечения (РБПО) уже рассматривается как необходимость. Безопасность должна быть встроена в процесс разработки на всех этапах: от проектирования архитектуры до развертывания и эксплуатации.
Рисунок 1. Эксперты в студии AM Live
Участники эфира, справа налево:
- Евгений Тодышев, руководитель направления безопасной разработки, УЦСБ.
- Роман Андреенко, руководитель разработки продукта SafeERP, «Газинформсервис».
- Михаил Парфёнов, главный архитектор по ИБ, DPA Analytics.
- Дмитрий Шмойлов, руководитель отдела безопасности программного обеспечения, «Лаборатория Касперского».
- Светлана Газизова, руководитель направления построения процессов безопасной разработки, Positive Technologies.
- Антон Михайлов, владелец продукта SASTAV, ITD Group.
- Особый гость Ирина Гефнер, заместитель начальника управления, ФСТЭК России.
Ведущий и модератор эфира — Дмитрий Пономарёв, сотрудник НТЦ «Фобос-НТ» / ИСП РАН / МГТУ им. Н. Э. Баумана.
Российские и международные стандарты РБПО: ФСТЭК, NIST, OWASP
Светлана Газизова напомнила, что стандарты, методологии и фреймворки — это фундаментально разные вещи. Стандарты читаются однозначно, методологии и фреймворки можно под себя адаптировать, учитывая позицию компании в текущий момент, её ограничения. Обязательно нужно смотреть российские стандарты. Рекомендуемые из международных — NIST, CIS Benchmarks, они помогают добиться измеряемости в работе. Заслуживающие внимания методологии и фреймворки — BSIMM, OWASP SAMM, DSOMM. Также есть российские методологии высокого качества. Все компании, которые оказывают услуги по построению процессов безопасной разработки, имеют собственные наработки, лучшие практики. Есть риск-ориентированные фреймворки.
Светлана Газизова, руководитель направления построения процессов безопасной разработки, Positive Technologies
Дмитрий Шмойлов рекомендует OWASP для веб-приложений и REST API. Это хороший ресурс для разработок на стеке фронтенда. В OWASP всё «разложено по полочкам», есть тесты, методологии, хорошие инструменты. Это очень полезно даже просто почитать.
Стандарты ФСТЭК России по безопасной разработке ПО
Ирина Гефнер рассказала, что первый стандарт по безопасной разработке ПО появился в 2016 году. Общий стандарт описывал базовые процессы, регламентные процедуры и пр. Отрасль встретила его с непониманием. Сложно было объяснить, что безопасностью нужно заниматься и от этого зависит качество продукта.
Разработчики средств защиты подхватили эту инициативу, стали использовать, после чего началась практика активного внедрения, в том числе в рамках сертификации средств защиты информации. В итоге компании пришли к тому, что эти подходы нужно внедрять, развивать и совершенствовать. Сейчас эта деятельность продолжается. Есть стандарт, который описывает общие положения, выпущенный в 2024 году. Будут разрабатываться другие стандарты по конкретным процедурам.
В первом опросе зрители предположили, какая тема будет наиболее востребована в РБПО в ближайшие три года:
- Безопасность технологий ИИ — 32%.
- Переход на отечественные среды разработки, сборки и хранения кода — 27%.
- Безопасное применение ИИ — 25%.
- Контейнеризация и Kubernetes — 11%.
- Безопасность бескодовой и малокодовой разработки (no-code / low-code) — 5%.
Рисунок 2. Какая тема будет наиболее востребована в РБПО в ближайшие три года?
Обучение разработчиков безопасному программированию: подходы и мотивация
Дмитрий Шмойлов считает, что обучение — это в первую очередь задача институтов. Нужно получать хороший поток новых людей со знаниями в области ИБ. Сейчас есть возможность создавать код с помощью ИИ, но безопасность таких разработок остаётся под вопросом. Что касается мотивации, то люди не пишут небезопасный код специально, но все совершают ошибки. Важно выстраивать культуру работы с ошибками по части ИБ внутри организации и поднимать вопросы безопасности кода. Программист должен иметь право на ошибку, но в то же время знать, что он несёт за это ответственность. Чем выше уровень специалиста и его опыт, тем больше у него этого понимания.
Дмитрий Шмойлов, руководитель отдела безопасности программного обеспечения, «Лаборатория Касперского»
Светлана Газизова по своему опыту преподавания в вузах поняла, что студентам интересно узнавать тонкости работы компаний и разных отраслей. При обучении разработчиков полезно найти то, что вызовет у студента любопытство (например, пройти путь злоумышленника, взломать приложение, получить доступ), а потом постепенно рассказывать, как этого не допускать. Это хорошо работает, учить нужно на практике.
Антон Михайлов добавил, что сейчас явно видно, как люди стали делать акцент на безопасной разработке. В вузах об этом стали говорить гораздо больше, растёт общая зрелость страны в части безопасной разработки. Есть одно правило: когда разработчик приходит работать в компанию, он принимает её уровень зрелости — это база.
Антон Михайлов, владелец продукта SASTAV, ITD Group
Евгений Тодышев подчеркнул, что нужно показывать обучающемуся, как его код можно эксплуатировать для нанесения ущерба, объяснять, что такое безопасный и небезопасный код, к чему ему нужно стремиться.
Как совместить цели бизнеса и требования безопасной разработки
Михаил Парфёнов уверен, что требования к безопасности должны быть частью бизнес-требований. Но на практике бывает сложно определить, что первичнее. Допустим, за два дня до релиза при согласовании с ИБ обнаруживается пять библиотек, которые не обновлялись два года, тысяча уязвимостей в отчёте SAST-анализатора, отсутствие валидации параметров на входе. Можно было бы заблокировать релиз, но бизнес этого не допускает — выпуск должен состояться послезавтра.
В таких условиях начинается срочная приоритизация — выявляются уязвимые места, через которые действительно могут взломать уже завтра, устраняются эти ошибки и разрешается релиз. При этом устанавливается договорённость, что за следующие три месяца всё должно быть исправлено. Нужно понимать потребности бизнеса, договариваться, доносить ценности. Когда говоришь разработчику, что безопасность — это тоже показатель качества, он начинает к этому относиться по-другому. По мере роста зрелости процесса РБПО в компании безопасность становится частью бизнес-требований.
Михаил Парфёнов, главный архитектор по ИБ, DPA Analytics
ТОП ошибок при внедрении РБПО и реальные кейсы их последствий
Евгений Тодышев:
«История о доставке вредоносного файла в виде библиотек. В компании не выстроена цепочка поставок, разработчик берёт всё напрямую из интернета. Это привело к полной остановке ряда информационных систем. В итоге разработчик отказался признавать вину, пришлось проводить расследование».
Роман Андреенко:
«Процесс безопасной разработки построен, код на прод приходит после проверки. Но бухгалтеру пришло от контрагента фишинговое письмо, после открытия в систему загрузился вредоносный файл, который находил других контрагентов и распространял заражение, сопровождая это шифрованием. Несмотря на то, что процесс построен, компания пострадала из-за того, что не ограничила права и полномочия».
Роман Андреенко, руководитель разработки продукта SafeERP, «Газинформсервис»
Михаил Парфёнов:
«В 2018 году в компании British Airways злоумышленники скомпрометировали один из серверов. На нём были статические JavaScript-файлы, которые подключались к фронтенд-приложению — были частью веб-страницы, где клиенты бронировали билеты. Взломщики добавили в них шесть строчек кода — JavaScript-сниффер. Как он работал: в момент, когда клиент нажимал на кнопку «Оплатить» в форме бронирования билетов, скрипт перехватывал данные банковской карты из браузера пользователя и отправлял на хост злоумышленника. Обнаружили это только через 15 дней, за которые было похищено более 300 тысяч наборов данных банковских карт. Ущерб на выплаты компенсаций и штраф за утечку данных составил более 1 млрд фунтов».
Во втором опросе выяснилось, какая технология РБПО, по мнению зрителей, в наибольшей степени способствуют качеству и эффективности процессов разработки:
- Статический анализ (SAST) — 28%.
- Композиционный анализ (SCA) — 25%.
- Динамический анализ API — 22%.
- Модульные тесты и генетический фаззинг кода — 17%.
- Микросервисные архитектуры и харденинг на уровне Kubernetes — 3%.
Рисунок 3. Какая технология РБПО повышает качество и эффективность процессов разработки?
Безопасность на уровне архитектуры: микросервисы, API, авторизация
Евгений Тодышев объяснил, что идеи, которые нужно реализовать в части безопасности, не изменились — аутентификация, авторизация, аудит, разграничение прав и т. д. Подходы остались прежними, изменились правила их применения.
В монолитной архитектуре в целом все API доступны с одного IP-адреса, здесь понятно, что и от чего защищать. В микросервисной архитектуре неправильное проектирование приводит к появлению большого количества конечных точек в неожиданных местах. Микросервисная архитектура в целом порождает большое количество API, их нужно контролировать, выявлять забытые, отключать их. Это отдельный сложный процесс.
Евгений Тодышев, руководитель направления безопасной разработки, УЦСБ
В микросервисах приняты подходы, когда есть единая централизованная точка аутентификации, единая точка принятия решений — например, шлюз (API Gateway), который приобретает функции безопасности. API-шлюзы принимают запросы и знают о том, что есть точка, например, с ролевой моделью, откуда возвращается ответ о наличии или отсутствии прав. Такой стандартный подход даёт хорошие результаты. Есть проблемы с производительностью и отказоустойчивостью, но они решаемы. Часто точки принятия решения переносят в сами микросервисы — есть кейсы успешной реализации, но разработчикам нужно решить проблему синхронизации политик и её достаточной скорости.
Определение площади атаки и контроль всех точек доступа
Ирина Гефнер рассказала, что в ходе оценки экспертизы, материалов сертификационных испытаний средств защиты информации видится проблема в определении площади атак. Часто разработчики не учитывают все её составляющие. Нельзя забывать основные программные интерфейсы, которые выходят наружу и обеспечивают взаимодействие с внутренним составом программного обеспечения — API, служебные интерфейсы, консоли.
Важно понимать, что основную площадь атаки составляет программный код, который стоит за всем многообразием интерфейсов и модулей. Нужно этому уделять внимание и проводить проверки, чтобы именно там не было уязвимостей. Это рубеж, преодолев который злоумышленник получает доступ к интерфейсам, способам реализации угроз и деструктивных воздействий.
Ирина Гефнер, заместитель начальника управления, ФСТЭК России
Композиционный анализ и защищённые репозитории зависимостей
Михаил Парфёнов считает, что задача композиционного анализа — находить известные уязвимости в сторонних компонентах ПО. Несмотря на то, что все боятся уязвимостей «нулевого дня» (0-day), большая часть атак проходят через уязвимости, которые уже известны, в том числе массовые автоматизированные атаки. Если разработчик решит создать новый продукт на базе старого (legacy) с большим количеством уязвимостей, то композиционный анализ и контролируемые репозитории помогут это обнаружить. Такая практика важна, она даёт наиболее быстрый рост уровня защищённости, особенно она востребована в энтерпрайзе.
Статический (SAST) и динамический (DAST) анализ кода в DevSecOps
Антон Михайлов уверен, что SAST — это минимальный базовый уровень. Любая компания, которая начинает строить свой DevSecOps-конвейер, использует SAST, а во многих компаниях это единственная практика. Разработка — это первый этап, когда можно встроить автоматизированный процесс. SAST-инструменты работают с репозиториями, средой написания кода. Уже на этом этапе можно отследить какой-то набор проблем. Недостаток SAST — в ложноположительных срабатываниях. Есть две метрики — полнота и точность, и они друг другу противоречат. Любой SAST-инструмент «из коробки» должен дорабатываться под условия компания. Сейчас тестируется практика запускать несколько движков SAST в рамках одного сканирования и потом делать корреляцию.
Дмитрий Пономарёв объяснил, что динамический анализ охватывает огромную область, включая модульные тесты, покрытие кода (code coverage), санитайзеры (особенно компилируемых языков), инструментирующий фаззинг и пр. Это сложный вопрос: есть много всего, что можно причислить к DAST. Не хватает ГОСТа по DAST, который определил бы всё, что к нему относится.
Дмитрий Пономарёв, сотрудник НТЦ «Фобос-НТ» / ИСП РАН / МГТУ им. Н. Э. Баумана
В третьем опросе зрители ответили, для какого типа инструментов РБПО они больше всего ждут требований и методологий сравнения:
- Сканеры уязвимостей и средства автоматизации пентеста — 28%.
- Статические анализаторы — 25%.
- Среды разработки и сборки ПО — 25%.
- Анализаторы корректности и безопасности ИИ-моделей — 8%.
- Анализаторы защищенности Kubernetes — 6%.
Рисунок 4. Для какого типа инструментов РБПО вы ждёте требований и методологий сравнения?
Проверка фронтенда (FAST): защита JavaScript и внешних скриптов
Михаил Парфёнов рассказал, что за последние годы в сфере безопасности фронтенда было много случаев внедрения вредоносного кода в зависимости JavaScript-приложений, например, NPM-пакеты. У злоумышленников есть масса способов монетизации такого внедрения — от размещения сниффера и кражи данных в браузере через фишинговые баннеры до заражения устройства пользователя через эксплуатацию уязвимости в браузере. Осложняется всё тем, что на фронтенде есть две проблемы:
- JavaScript в браузере может динамически догружать дополнительные модули и сторонний код.
- Почти всегда на фронтенде есть сторонние скрипты, например система аналитики, которые тоже находятся вне контролируемой зоны.
Внешние скрипты могут в любой момент измениться, из-за этого классические подходы (статический и композиционный анализ) теряют достоверность. Эти проблемы призван решить класс анализаторов FAST. Это фронтенд-песочница, которая взаимодействует с конечным приложением как обычный пользователь. FAST в процессе выполнения сценария анализирует поведение приложения и формирует его профиль. Специалист по информационной безопасности или разработчик применяет к нему правила белого списка — при следующем сканировании всё отклоняющееся считается инцидентом.
ИИ в безопасной разработке: риски, возможности и перспективы
Ирина Гефнер:
«Внедрение инструментов ИИ для повышения качества и безопасности кода влечёт за собой дополнительные риски, связанные с принятием решения искусственным интеллектом, но за этим будущее. Для ФСТЭК России не имеет значения, кто написал код — программист или искусственный интеллект. Все практики по безопасной разработке одинаково применимы в обоих случаях».
Светлана Газизова:
«Стоит признать, что ИИ — это технология, которые прочно укоренилась в нашей жизни. Пока большая часть инструментов (SAST, DAST) не умеют работать со специфическими проблемами безопасности ИИ моделей».
Антон Михайлов:
«Невозможно автоматизировать процесс, который до конца не выстроен. Примерно так же сейчас приходится эксплуатировать ИИ. К этому нужно относиться зрело. Чем более узкую задачу даёшь, тем лучше будет результат. Даже в базовых задачах используя готовые модели ИИ можно делать шаги вперёд».
Четвёртый опрос показал, каково мнение зрителей об РБПО после эфира: будут усиливать процессы и внедрять лучшие практики — 60%, убедились, что всё делают правильно — 32%.
Рисунок 5. Каково ваше мнение об РБПО после эфира?
Выводы
Безопасность разработки ПО — это не просто набор инструментов и проверок, а комплексный процесс, который должен быть интегрирован на всех этапах жизненного цикла программного обеспечения. Как показали на практических примерах эксперты, ключевые проблемы — это не только технические уязвимости, но и организационные вопросы: мотивация разработчиков, согласование требований с бизнесом и выстраивание культуры безопасности.
Российские и международные стандарты, такие как методики ФСТЭК России, NIST и OWASP, задают рамки для безопасной разработки, но их внедрение требует адаптации под конкретные проекты. Важно не просто формально выполнять требования, а понимать их смысл — например, контролировать не только сетевые интерфейсы, но и весь код, включая сторонние библиотеки.
Автоматизированные инструменты (SAST, DAST, SCA, FAST) помогают находить уязвимости на ранних этапах, но их эффективность зависит от правильной настройки и интеграции в процессы. Особое внимание стоит уделять фронтенд-безопасности, микросервисным архитектурам и управлению зависимостями, поскольку именно здесь чаще всего возникают критические риски.
Как известно, безопасность — это не разовая акция, а непрерывный процесс, требующий вовлечения всей команды. Только сочетая технологические решения, обучение и осознанный подход, можно создавать ПО, устойчивое к современным угрозам. Будущее за гибкими практиками, которые не тормозят разработку, но делают её более надежной — и начинать этот путь нужно уже сейчас.
Телепроект AM Live еженедельно приглашает экспертов отрасли в студию, чтобы обсудить актуальные темы российского рынка ИБ и ИТ. Будьте в курсе трендов и важных событий. Для этого подпишитесь на наш YouTube-канал. До новых встреч!
