Информационная безопасность при закупке ПО, к сожалению, часто воспринимается как формальность. Проверки проходят без связки между этапами: тендер готовят одни люди, за безопасность отвечают другие, бюджет согласовывают третьи. В результате исполнитель сталкивается с требованиями, которые предполагают низкую цену, сжатые сроки и высокое качество – «треугольник невозможного». Между тем, мало просто оценить безопасность до закупки, нужно четко понимать, что именно проверять и каким способом.
Автор: Сергей Терешин, presale-инженер по AppSec, руководитель и создатель курсов по ИБ MONT
Этап 1: Требования ИБ
Информационная безопасность держится на трех принципах: конфиденциальность, целостность и доступность информации. Нарушение любого из этих свойств влечет последствия. В тендерной документации это можно и нужно фиксировать прямо.
Например: «Исполнитель работ гарантирует обеспечение конфиденциальности, целостности и доступности всех информационных ресурсов, к которым он получает доступ». Или: «Подрядчик гарантирует конфиденциальность, целостность и доступность информации после выполнения работ, если они не возникли в результате его действий или проведенных работ». Поставщик берет на себя ответственность, и это должно быть прямо прописано в договоре.
Прямая ответственность подрядчика за ИБ — условие, которое позволяет потом предъявлять претензии. Важен и учет регуляторики, поскольку заказчики иногда не учитывают, что они субъекты КИИ или подлежат иным нормативным регулированиям. Если это не отражено в тендере, то значит, нарушение закладывается на старте.
Важно учесть и требования к процессу разработки. Национальный стандарт ГОСТ 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» описывает построение и развитие процессов разработки безопасного ПО. Наличие у производителя сертификата по этому ГОСТу это прямое подтверждение качества и безопасности его решений. Еще один фактор: наличие сертификации ФСТЭК у внедряемого решения. Это напрямую помогает убедиться в том, что решение проверено и безопасно.
Согласно данным компании Swordfish Security, лишь 30% российских разработчиков обладают начальными знаниями в области безопасной разработки, что подчеркивает актуальность требований к обучению, зафиксированных в ГОСТ Р 56939-2024.
Стоит обратить внимание и на квалификацию исполнителя. Требования вроде «наличие в штате не менее N специалистов с опытом не менее X лет» могут выглядеть как избыточные, но без них тендер либо открывает доступ всем желающим, включая сомнительных исполнителей, либо превращается в ситуацию, когда вместо качества побеждает минимальная цена.
Этап 2: проверка до внедрения
Перед внедрением стоит ответить себе на вопрос: «Какую задачу я решаю или какую боль я хочу закрыть?». Изменение ландшафта инфраструктуры всегда влечет за собой вызовы для ИБ. Одна лишь проверка сертификатов здесь не работает и, соответственно, нужна система. Базовые фильтры — это только начало. Например, отслеживание репутации вендора — способ не самый надежный, однако в современных реалиях очень важный показатель.
Системная проверка включает несколько обязательных компонентов. Перед внедрением новых решений нужно провести анализ модели угроз и влияния на нее новых компонентов. Затем идет анализ бизнес-рисков и угроз бизнес-логике. Это прямой ответ на вопрос, что именно может пойти не так и какие последствия могут возникнуть. Также необходимо оценить безопасность внедряемых изменений и предположить компенсирующие меры. Например, наложенные средства защиты информации. Еще одна важная проверка — влияние на инфраструктуру.
Рост атак на цепочки поставок ПО становится системной проблемой: аналитики компании IBM зафиксировали почти четырехкратное увеличение числа крупных инцидентов, связанных с подрядчиками и цепочками поставок, за последние 5 лет.
Есть несколько практических инструментов, позволяющих оценить состояние внутренней ИТ-инфраструктуры до внедрения новых решений. Один из ключевых — автоматизированное тестирование на проникновение: оно дает возможность сопоставить состояние системы до и после изменений (по уровню защищенности, реализуемым сценариям атак и выявленным уязвимостям).
Требований по безопасности много не бывает. Если есть возможность все вышесказанное соблюдать, то ИБ-специалистам будет существенно проще. Многие банки взяли себе за правило тестирование на проникновение поставщиков услуг перед заключением договора, что выглядит вполне обоснованным. Аудит архитектуры и пентест работают в связке: первый оценивает замысел, второй — реальность.
Экономическая эффективность proactive-подхода очевидна: исследования показывают, что каждый доллар, потраченный на тестирование безопасности, позволяет организациям сэкономить до десяти долларов на расходах, связанных с устранением последствий взлома
Этап 3: приемочные испытания
Критерии успешной приемки должны быть прописаны еще в исходном техническом задании. Это избавляет обе стороны от недопонимания. Нужно четкое ТЗ, согласованное и подписанное обеими сторонами. Да, документ может корректироваться по ходу проекта, но каждое изменение должно фиксироваться и подписываться заново.
На приемке в обязательном порядке проверяют соответствие тому самому ТЗ — без вариантов. Также проверяют функциональность: работает ли система так, как заявлено. И обязательно проверяют безопасность не на уровне документов, а подтвержденную реальными инструментальными тестами.
Однако есть вещи, которые на приемке почти всегда упускают. Например, влияние нового продукта на работу компании в целом. Возьмем ИИ-помощников: вещь полезная, но при их внедрении почти никто не смотрит, кто, что и как им передает, где эти данные хранятся и что именно помощник выдает в ответ. Также в тени остаются новые риски ИБ, которые система приносит с собой.
Проверяют ли, как внедрение влияет на доступность информации? А ведь оно не должно приводить к отказам в обслуживании легитимных пользователей. И почти никогда не тестируют поведение системы в сценариях атак: как она ведет себя под нагрузкой, при попытках эксплуатации уязвимостей, в нештатных ситуациях.
Именно эти вещи регулярно игнорируют, и именно они потом становятся причинами реальных инцидентов. Проверять внедренные решения стоит не только формально — на работоспособность, но и на нарушение бизнес-логики, привнесение новых рисков ИБ, сбои в доступности.
Актуальность контроля за новыми технологиями подтверждается и ростом числа инцидентов: по данным ГК «Солар», по итогам 2025 года объем информации, передаваемой сотрудниками российских компаний в публичные нейросети, вырос в 30 раз.
Минимальный ИБ чек-лист
Попробуем собрать короткий список требований, которые действительно влияют на безопасность. Представим, что компания — субъект КИИ и обрабатывает персональные данные. Вот как выстраивается рассуждение директора по ИБ при общении с вендором:

Безопасная разработка по ГОСТ 56939-2024. Вопрос к вендору: «А у вас пайп разработки безопасен? Покажите!» Сертификация процессов разработки — не просто документ, а доказательство того, что код не закладывает уязвимости на этапе написания.

Сертификат ФСТЭК. Это независимое подтверждение того, что решение проверено и действительно безопасно.

Готовность к пентесту. «Мы хотим заказать пентест. Вы готовы?» Вендор, который отказывается от независимого пентеста, скорее всего, скрывает проблемы.

Юрисдикция разработки. «А вы разрабатываете в России?» Это вопрос про контроль над кодом и невозможность скрытых закладок со стороны иностранных спецслужб.

Влияние на бизнес-логику. Важно понимать, как внедрение ПО меняет ключевые бизнес-процессы и не создает ли новые точки отказа.

Уровень поддержки. Речь о том, сможет ли вендор оперативно закрыть критическую уязвимость, когда на счету будут часы.

Использование open-source. Каждый такой компонент — потенциальная уязвимость, если вендор не ведет строгий контроль зависимостей.

Любой технический специалист задал бы еще миллиард уточняющих вопросов. Но для усредненного сценария этот список — достаточный минимум.

Проблема системного подхода к безопасности критична и для регуляторики: по данным ФСТЭК, более 80% нарушений в сфере защиты критической информационной инфраструктуры, выявленных в 2025 году, носят типовой характер.
Информационную безопасность нельзя «добавить в конце» или додумать на этапе приемки то, что не было заложено в тендере. Даже если пентест выявит уязвимости, заложенные при проектировании, их устранение на поздних этапах обойдется значительно дороже и потребует больше времени. Безопасность — процесс, который начинается с тендера и проходит через весь цикл: требования в ТЗ, проверка до внедрения, приемочные испытания со сценариями реальных атак.
Важно не просто следовать требованиям ИБ, но и понимать их смысл. Понимание и умение донести этот смысл до всех участников процесса закупки — самая важная часть работы. И начинать эту работу нужно не с экстренного пентеста после инцидента, а с ближайшего тендера.