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

Именно при анализе и сборе информации должны закладываться первоначаль- ные требования к безопасно- сти: не позволять загружать файлы большого размера, работать асинхронно, иметь ограничения по доступу, логирование, балансировка и т.д. Бывали случаи, когда в компании код не принимал- ся для слияния, если не был прокрыт тестами или хоть немного не соответствовал общей стилистике. Здесь выбор за вами – компромис- сы или четкое соответствие всем требованиям. Начиная от постановки ТЗ и заканчивая сопровож- дением кода, вышедшего в релиз, и, соответственно, работой готового модуля, использование потенциаль- ных дыр в безопасности будет стоить дороже, а про- активность на этапах под- держки может и вовсе не сработать. а этапы уточнения или тестиро- вания и вовсе игнорируются. Правильный жизненный цикл задачи не допустит реализации какого-либо шага без участия ответственного. 2. Жизненный цикл задачи. В качестве примера возьмем финтех-компанию средних объе- мов с командой разработки из 12 человек (Java/Angular), в которой он может выглядеть так: идея – анализ – сбор тре- бований (формирование ТЗ) – определение исполнителя и сро- ков – согласование – разработ- ка – внутреннее тестирование – внешнее тестирование – пред- релизное тестирование – релиз – поддержка. Если у чита- теля возникает вопрос о том, где же здесь проактивность в безопасности разработки, то ответ довольно прост: от каче- ства постановки задачи зависит большая часть ее дальнейшей жизни. Именно при анализе и сборе информации должны закладываться первоначальные требования к безопасности. 3. Назначение ответственных за каждый этап. Целью является не поиск виноватых, а четкое понимание задач и результатов, которых ждут коллеги. То есть при хорошо поставленном про- цессе для реализации конкретной задачи, помимо программистов, понадобится тестировщик – биз- нес-аналитик (методолог), ответ- ственный за задачу со стороны тех, кто ее поставил (эдакий локальный Product Owner). Допол- нительным плюсом будет наличие в команде технического писателя и системного аналитика вкупе с архитектором для выстраивания правильных связей с уже имею- щимся функционалом. 4. Требования непосредствен- но к разработке. Паттерн разра- ботки, Code-Style, написание юнит-тестов (до или после напи- сания основного кода), правила работы с контролем версий (пра- вила ветвления и подтверждения изменений), Code Review и т.д. – практически все пункты являют- ся залогом проактивной без- опасности и, к сожалению, в полном комплекте используются только в 20–30% компаний. Стоит упомянуть, что львиной доли проблем в будущем можно избежать, если имеются под- робные требования при поста- новке задачи, включая техниче- ский анализ, и хорошо знающий ваше ПО разработчик-техлид, выполняющий Code Review (рецензирование кода) при Merge Request. Организация и осу- ществление процесса Code Revi- ew должны проходить в соответ- ствии с устоявшимся в компании стилем и требованиями, зало- женными техническим директо- ром или техлидами команд. Бывали случаи, когда в компании код не принимался для слияния, если не был прокрыт тестами или хоть немного не соответ- ствовал общей стилистике. Здесь выбор за вами – компро- миссы или четкое соответствие всем требованиям. Проактивное устранение и предотвращение уязвимостей в коде особенно актуально на старте проекта или задачи. Со временем, начиная от постанов- ки ТЗ и заканчивая сопровож- дением кода, вышедшего в релиз, и, соответственно, рабо- той готового модуля, использо- вание злоумышленниками потен- циальных дыр в безопасности будет стоить дороже, а проактив- ность на этапах поддержки может и вовсе не сработать. Проактивная поддержка кода Рассказывать о том, как писать безопасный код, можно очень долго. И здесь нужно говорить не только про контроль утечек памяти, строгую типизацию, конт- роль доступа, правильную вали- дацию и правильный возврат ожидаемых данных. Такие вещи, как стиль кода, комментирование и документирование, имеют очень большое значение в без- опасном сопровождении кода. Очень важно обязательное покрытие тестами ключевого функционала. Именно ключево- го, потому что на практике бывают задачи, написание юнит- тестов к методам которых дей- ствительно может являться избы- точной разработкой. Например, если ваша функция возвращает true или false в зависимости от типа единственного аргумента, то такому методу действительно может не требоваться проверка тестами. А методы авторизации, сравнения, обработки входящих данных крайне важно покрывать юнит-тестами для того, чтобы впоследствии при сборке при- ложения не было проблем с ключевыми местами, на кото- рые со временем будет обра- щаться все меньше внимания. На самом деле написание тестов не поздно внедрять на любом этапе разработки, даже если вашему ПО уже декада лет и ни один метод в нем до сих пор ими не покрыт. Просто начинайте планировать разработку немного иначе и вводите новые требова- ния для технических специали- стов. Если, конечно, остро не стоит вопрос тотального рефак- торинга – в этом случае можно вернуться к описанному в пре- дыдущей части статьи. Интеграционное тестирование Интеграционное тестирование – это более сложный и комплекс- ный подход к проверке всего при- ложения путем написания тестов к связке модулей и классов, то есть проверка взаимодействия различных компонентов ПО. В случае необходимости внедре- ния такого функционала нужно понимать, что данную область будет очень сложно "повесить" на разработчиков (как в случае с юнит-тестированием) и что эффективнее иметь ведущих спе- циалистов именно по тестирова- нию вашего ПО для своевремен- ного внедрения, расширения и изменения библиотек. Системное (функциональное) тестирование Системное (функциональное) тестирование, которое в неболь- ших проектах с успехом заме- няется ручным, является эффек- тивным инструментом для поиска большого числа уязви- мостей, равно как и ошибок работы приложения, и предла- гается в виде готовых решений, повсеместно использующихся в отделах тестирования по всему миру, – Selenium, HPE UFT и др. Статический и динамический анализ кода Дополнительными инструмен- тами, повышающими качество кода и в некоторых случаях существенно снижающими риск уязвимостей, станут статические и динамические анализаторы кода. Это разные по назначению и процессу исполнения проверок программы, направленные, в сущности, на одно и то же – предотвращение и поиск уже имеющихся ошибок, то есть повышение надежности и без- опасности разрабатываемого функционала. Различий между ними много, но основное в том, что статиче- ские анализаторы проверяют код до его исполнения (компиляции), а динамические – проверяют работающую программу на пред- • 43 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru