Безопасность как часть качества ПО

На международном форуме Kazan Digital Week 2025 состоялся круглый стол «Безопасная и качественная разработка ПО: культура, конвейер, технологическая независимость». 

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

Почему скорость вытеснила качество и безопасность

В ИТ приоритет многие годы концентрировался на метрике time-to-market: бизнес хотел быстрее выпустить новую функциональность, а про качество и безопасность думал не в первую очередь. Ответственное отношение к коду приносили в жертву скорости, тестирование и ИБ воспринимались как сдерживающий фактор. При таком подходе итог предсказуем: дефекты и уязвимости всплывают уже в эксплуатации, где исправления самые дорогие. 

Сейчас ситуация постепенно меняется. Бизнес начал осознавать важность безопасности и тестирования и старается находить разумный компромисс между надежностью и темпом.

«Мексиканский тупик» в компаниях

Погоня за скоростью — лишь часть проблемы. В российской ИТ-практике до сих пор распространено смешение понятий: между тестированием ПО и QA (Quality Assurance) ставят знак равенства, а тестировщиков называют инженерами по качеству. При этом чаще всего речь идет лишь о финальном контроле перед релизом. Тогда как качество — это сквозной процесс. Он начинается с идеи и проектирования, проходит через код и продолжается на этапе использования продукта. 

Безопасность ПО в этой логике является частью качества. Сложно представить приложение, которое мы называем качественным, если оно заведомо уязвимо. 

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

Получается «мексиканский тупик» (Mexican standoff) — ситуация взаимного сдерживания, когда ни одна из сторон не может сделать ход, не ухудшив свое положение. Трое смотрят друг на друга, но не работают вместе.

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

Как избавиться от разрозненности 

Практический ответ на проблему лежит в переносе работы с качеством в начало жизненного цикла ПО. 

Подход Shift Left смещает внимание на ранние этапы: требования, дизайн, архитектура. Важный элемент здесь — принцип Security by Design, когда устойчивость к уязвимостям закладывается еще в проектировании. Это позволяет выявлять проблемы заранее и предотвращать их.

Полностью исключить риски невозможно, поэтому важен и второй подход Shift Right, который подразумевает проверку продукта в реальном использовании. Он опирается на запуски для ограниченного числа пользователей, наблюдение за поведением и  быструю реакцию на обратную связь. Такой режим помогает вовремя заметить сбои, ограничить их влияние и быстро вернуть систему к нормальной работе.

Культура качества как объединяющий фактор

Эти практики работают только там, где есть общая культура. Баланс между темпом и надежностью появляется, если установлены общие ценности, правила и разделена ответственность. Конвейер РБПО уже объединяет российские решения для полного цикла разработки, но интеграция инструментов не решит задачу без культуры как основы. Пока разработчики, тестировщики и безопасники действуют разобщенно, качество будет страдать.

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