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

• 39 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru в новые версии различных бэкдоров, недекларируемых возможностей и про- чих неприятных сюрпризов. Так что же в таком случае делать компаниям, как выбрать нужный инстру- мент или заменить потерянный? На наш взгляд, есть три возможных сценария, в зависимости от того, как изначально развивался процесс безопасной разра- ботки. Первый сценарий. Начало построения DevSecOps Если компания только начинает строить процесс и подходить к выбору инструментов, здесь все гораздо проще. Достаточно пойти по правильному пути, понять, описать процессы и при выборе инструмента учитывать все текущие реа- лии и ограничения. Второй сценарий. Правильный путь Если компания все изначально делала грамотно, а именно определила все точки взаимодействия участников про- цесса, описала, как и что должно рабо- тать, то для нее не будет большой про- блемой заменить тот или иной инстру- мент (а у некоторых – просто отказаться от одного из работающих в связке). Да, конечно, будут нюансы и сложности, часть процессов придется на какое-то время сократить или пересмотреть. Но база для того, чтобы безболезненно выбрать новое решение и переключиться на него, уже будет готова, это не займет много времени. Третий сценарий. Процесс на основе инструментов Если компания строила свои процес- сы вокруг конкретного инструмента и изменяла их под него, то это самый худший сценарий из всех представлен- ных. Просто потому, что в таком случае вместе с исчезнувшим решением рух- нет и все созданное на этом фунда- менте. И тогда придется отстраивать инфраструктуру заново, при этом ста- раясь не допускать прежних ошибок. Если компания столкнулась с этим, мы рекомендовали бы ей не спешить, а сделать небольшой шаг назад и посмотреть со стороны, что устраивало в прошлом варианте, а что хотелось бы изменить и улучшить. Можно исполь- зовать это время для обновления и оптимизации процессов, раз они боль- ше не связаны с конкретным инстру- ментом. Показатели оптимального инструмента Однако любой из трех сценариев пред- полагает в итоге выбор определенного решения. Ниже мы даем основные пока- затели, на которые стоит обращать вни- мание, чтобы остановиться на оптималь- ном инструменте. 1. Время анализа. Если от момента попадания кода в репозиторий до выхо- да на продуктивную среду уходит 30 минут (включая все тесты и сборку), проверки на информационную безопас- ность не сильно повлияют на итоговый результат. Можно это решить, пред- усмотрев ответвление в процессе, и проводить проверки параллельно, но не стоит забывать о последовательном запуске. В этом случае пригодится воз- можность проведения "быстрого ана- лиза", или, как его называют, инкре- ментального. 2. Уровень False Negative или False Positive. Все разрабатываемые продукты уникальны, они используют различные фреймворки и свой стиль написания кода. На разных кодовых базах и техно- логиях инструменты могут показывать разный уровень False Negative и False Positive. Поэтому нужно определить, что именно в вашей компании и для ваших приложений будет показывать хороший и достоверный результат. 3. Интеграции с существующими инструментами. Смотрите на инструмен- ты с точки зрения интеграций с тем, что вы уже используете. Например, если у вас Jenkins или TeamCity, оцените, как будут взаимодействовать инструменты именно с этим ПО. После детализации работы процессов можно понять, в каких точках и с какими инструментами необхо- дима интеграция. 4. Возможности кастомизации. Если у инструмента нет API, то зачем он нужен? Все, что можно сделать в интерфейсе, должно быть доступно для автоматиза- ции. Дополнительно у инструмента долж- на быть возможность написания собст- венных проверок или изменения встроен- ных правил для более точной работы и для интеграции с другими практиками (как в примере выше в связке анализа используемых библиотек и анализа кода). 5. Roadmap развития продукта. Раз- работка не стоит на месте, мы всегда используем новые фреймворки и функ- ции, переписываем старый код на новые языки. Мы хотим быть уверен- ными, что инструмент, который мы при- обретаем, будет поддерживать новые технологии. Поэтому важно знать, есть ли у продукта реальный и правильный план развития. Дополнительно к этому стоит отметить возможность повлиять на совершенствование продукта. Важно понимать, как вендор работает с запро- сами пользователей на добавление нового, необходимого для вас, функ- ционала. Это лишь минимально необходимый перечень того, на что смотреть при выборе инструмента, пополнять его можно еще очень и очень многими веща- ми. Каждая компания может дополнить чек-лист своими пунктами. Что будет дальше? Уже сейчас можно предположить, что в ближайшем будущем все больше вни- мания будет уделяться вопросам без- опасности в целом и безопасной разра- ботке в частности. Да, будем честны, не все продукты на рынке на данный момент могут похвастаться отличными результатами: кто-то отстает в плане обнаружения уязвимостей, кому-то не хватает возможностей интеграции, у кого-то хромает удобство использования. Но это вполне нормальная ситуация для начала. Сейчас у отечественных спе- циалистов безопасной разработки есть потрясающий шанс показать, на что они способны. Те производители, которые готовы меняться и становиться лучше от релизу к релизу, собирая требования и поже- лания заказчиков, реализуя дополни- тельные проверки, интеграции, посто- янно улучшая свой продукт (то есть активно меняясь под потребности рынка), будут все более востребованы. Они смогут еще быстрее развиваться за счет новых продаж и инвестиций, это позволит им расширить аудиторию и дальнейшую возможность масштаби- рования. Сегодня у отечественных произво- дителей есть все шансы предложить решения намного удобнее, лучше и производительнее тех, что есть у западных вендоров. Главное – слу- шать своих заказчиков и принимать верные решения! l Ваше мнение и вопросы присылайте по адресу is@groteck.ru Рис. 3. Эволюция процесса безопасной разработки