SDLC : ожидания, требования и предпочтения отечественных разработчиков

SDLC : ожидания, требования и предпочтения отечественных разработчиков

В рамках конференции PHDays VI прошел закрытый семинар сообщества Positive Development User Group.

Авторы:

  • Рами Мулейс, менеджер по продвижению продукта PT Application Inspector, Positive Technologies
  • Екатерина Килюшева, ИБ-аналитик, Positive Technologies

В рамках конференции PHDays VI прошел закрытый семинар сообщества Positive Development User Group, участники которого − разработчики из ведущих компаний и организаций, уделяющие особое внимание вопросам безопасности своих приложений. В рамках семинара был проведен опрос, коснувшийся того, к примеру, какие средства автоматизированного анализа исходного кода они используют в работе, что позволяет усовершенствовать процесс безопасной разработки, и что не устраивает в имеющихся на рынке инструментах и др. Полученные данные позволили выяснить, что ожидают разработчики от средств автоматизированного анализа кода, что оказывает первостепенное влияние на их решение использовать тот или иной инструмент. А также ─ получить общее представление о том, насколько принципы SDLC распространены в различных отраслях, о проблемах, с которыми сталкиваются разработчики, применяющие средства автоматизированного анализа кода, и о приоритетных векторах развития таких инструментов.

Используемые языки

В первую очередь, были собраны данные о наиболее часто используемых в разработке языках программирования. Самым популярным языком разработки оказался Java (64%), на втором месте находится Java (64%), за ними следуют JavaScript, C#, C++, ASP.NET, Python, PHP и др.


Используемые языки программирования

Готовность к внедрению процесса безопасной разработки

По результатам опроса было выяснено, что процесс безопасной разработки внедрен лишь в 13% организаций, большую часть которых составляют разработчики ПО.

Готовность к внедрению процесса безопасной разработки

На текущий момент существует повышенный интерес к инструментам, позволяющим повысить качество ПО, а также обеспечить более высокую степень защищенности конечного продукта, выявляя уязвимости еще на этапе разработки. В ближайшее время внедрить процесс безопасной разработки планируют 66% опрошенных участников. И среди них преобладают банки, разработчики ПО и интеграторы, что вполне обосновано.

Банковская отрасль обязана подчиняться требованиям регуляторов в вопросах безопасности, в частности, требованиям к оценке защищенности приложений. Очевидно, что для этих организаций высокий уровень безопасности является одним из важнейших факторов, от которого зависит как получение сертификатов соответствия отраслевым стандартам для осуществления деятельности, так и работоспособность в целом.

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

Тем не менее, в число тех, кто не собирается вводить процесс безопасной разработки, все же вошло некоторое число интеграторов, банков и разработчиков ПО. Лидером же в этой группе оказались государственные организации (50%).

Готовность к внедрению процесса безопасной разработки по отраслям

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

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

Среди опрошенных участников только 40% имели опыт использования анализаторов кода. Остальные 60% никогда не сталкивались с такими инструментами.

Чаще всего в разработке применялись анализаторы кода SonarQube, ReSharper, Veracode и CPAchecker. Также участники использовали Positive Technologies Application Inspector, Understand, Solar inCode, Coverity, HP Fortify и IBM Security AppScan.


Используемые средства автоматизированного анализа кода

Интересно отметить, что среди участников, использовавших в разработке анализаторы исходного кода, процент тех, кто не собирается внедрять процесс безопасной разработки, больше (25%), чем среди участников, никогда не применявших анализаторы (19%).


Готовность к внедрению процесса безопасной разработки в зависимости от имеющегося опыта применения

Отчасти, это может быть связано с предыдущим негативным опытом использования. По каким-то причинам анализаторы кода не оправдывают ожиданий разработчиков. Что привлекает разработчиков в инструментах автоматизированного анализа, а что заставляет отказаться от использования? Для ответа на этот вопрос, в первую очередь, необходимо разграничить сферы применения различных инструментов.

Для чего применяется

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

Такие анализаторы, как Understand, SonarQube, ReSharper и CPAchecker используются в основном для повышения качества кода, а остальные позволяют проверить безопасность приложений.

 
Цели применения средств автоматизированного анализа кода

Что понравилось

Участники отметили возможности анализаторов, которые посчитали наиболее важными в процессе поиска уязвимостей:

  • глубина сканирования исходного года: существует множество используемых сканерами подходов (лексический, инкрементный анализ и т.п.), различающихся по сложности и эффективности работы. Множество сканеров используют достаточно простые, но быстродействующие алгоритмы, что приводит к весьма поверхностным и неточным результатам;
  • возможность интеграции со средой разработки (IDE): любая лишняя консоль или интерфейс при работе, учитывая количество инструментов, используемых разработчиками в своей ежедневной работе, вызывает негативную реакцию. Поэтому возможность интеграции в привычные инструменты – огромное преимущество. Но самое главное – новые процессы безопасной разработки, внедрение которых проходит для разработки сложно и даже болезненно. Интеграция в среду разработки устраняет множество соответствующих проблем;
  • высокая скорость работы − оперативность нахождения уязвимостей и багов важна с точки зрения эффективности: найденная проблема устраняется намного быстрей на этапе работы над уязвимым участком кода, нежели спустя какое-то время, когда разработчику потребуется заново разбираться в написанном коде и выяснять, почему появилась уязвимость; 



Уязвимость в AST-дереве и условия ее эксплуатации

  • удобный интерфейс: визуализация и отчеты достаточно важны для больших команд −  разработчики, тестировщики и архитекторы имеют разные взгляды на процесс безопасной разработки и наличие адекватного и удобного интерфейса с гибкой отчетностью ощутимо экономит время работы. Например, подсветка уязвимого участка в AST-дереве помогает понять, на каком уровне чаще всего появляются уязвимости и предпринять меры для оптимизации их устранения. А автоматическая генерация экспплойта проверки уязвимости встроенным сканером существенно упрощает тестирование;
  • многоязыковая поддержка: разработчики, как и все, предпочитают использование родного языка в интерфейсе анализатора;
  • кастомизация запросов для более узкого поиска или изменения набора правил: никто не разбирается в коде так, как его разработчик, однако написать проверки анализатора самостоятельно возможно в редких случаях, хотя это безусловно увеличило бы эффективность поиска типовых ошибок и уязвимостей. 

 


Что понравилось в средствах автоматизированного анализа кода

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

Еще одним важным преимуществом использования анализаторов исходного кода является возможность интеграции с системами предотвращения атак на уровне приложений (WAF). Такая интеграция позволяет защищать веб-приложения в автоматическом режиме (с помощью virtual patching) сразу при обнаружении уязвимости и не дожидаясь ее устранения разработчиками, которое может занимать от нескольких часов до недель. Этот функционал дает огромное преимущество тем, кто не закрывает глаза на риски информационной безопасности, связанные с повышенным вниманием злоумышленников к веб-приложениям в последние годы.

Что не понравилось

Основными недостатками средств автоматизированного анализа кода, по мнению участников опроса, являются следующие:

  • высокий процент ложных срабатываний (false-positive);
  • отсутствие поддержки требуемого языка программирования;
  • сложность установки и конфигурации;
  • плохие рекомендации по исправлению выявленных уязвимостей и недостатков программного кода;
  • невозможность настраивать запросы для более узкого поиска уязвимостей или изменения набора правил.


Что не понравилось в средствах автоматизированного анализа кода

Как считают респонденты, к серьезным недостаткам, замедляющим процесс разработки, относится высокий процент ложных срабатываний (false positive). Подобные проблемы могут быть связаны с внутренними особенностями решения, встроенными алгоритмами и критериями обнаружения уязвимостей. Также респонденты отмечают, что процесс установки и первоначальной конфигурации большинства анализаторов кода является достаточно сложным процессом. Кроме того, в некоторых инструментах отсутствует возможность тонкой настройки запросов для поиска определенных типов уязвимостей или изменения набора правил. Не менее важным пунктом является, по мнению разработчиков, отсутствие понятных рекомендаций по исправлению обнаруженных критических участков в коде.

Именно эти недостатки затрудняют использование автоматизированного анализа исходного кода и усложняет внедрение процессов безопасной разработки. Вместо ожидаемого автоматизированного процесса поиска уязвимых мест, разработчик вынужден тратить значительную часть своего времени на фильтрацию ложных срабатываний, учитывая отсутствие возможности верифицировать найденные уязвимости в автоматическом режиме.Доля ложных срабатываний напрямую зависит от алгоритмов поиска анализатора и использующихся правил, если разработчик не имеет возможности изменить набор применяемых правил, он будет постоянно сталкиваться с проблемой верификации большого числа полученных результатов. Разработчик также может обнаружить, что устранение выявленной уязвимости в отдельных случаях представляет собой довольно сложную задачу, особенно, если анализатор не дает четких указаний по исправлению кода или этих указаний недостаточно.

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

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

Вывод

Как показал опрос, проблема защищенности приложений достаточно актуальна для разработчиков ПО в различных сферах, но ряд недостатков предлагаемых инструментов анализа кода негативно сказывается на общей производительности, затрудняя процесс контроля уязвимостей. В первую очередь, за счет использования автоматизированных средств анализа кода разработчики рассчитывают улучшить производительность, что обеспечивается низким процентом false positive, высокой скоростью работы, возможностью настройки запросов и удобством интерфейса. В дополнение к этому, разработчики хотели бы видеть понятные рекомендации по исправлению найденных уязвимостей и наглядную отчетность для контроля устранения уязвимостей. Анализатор должен не только выявлять проблемные участки, но и содействовать в процессе верификации и поиске оптимального решения. Перечисленные факторы имеют наибольшее влияние на готовность участников перейти на процессы безопасной разработки ПО.

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

Согласно исследованию, опыт использования анализаторов имели лишь 40% респондентов. Возможно, часть разработчиков, не использовавших анализаторы кода, уже имеет некоторые предубеждения, так как в обзорах распространенных анализаторов и отзывах о их применении регулярно упоминаются такие недостатки, как ошибки false positive, поверхностное сканирование и прочие затрудняющие процесс проверки кода проблемы. Как следствие, могло сформироваться мнение, что применение средств анализа кода не стоит трудозатрат, потраченных на внедрение, но при этом, как правило, не учитываются трудозатраты на устранение найденных уязвимостей по результатам аудитов после выпуска продуктов. Изменить негативное представление об анализаторах кода можно лишь путем сравнения существующих решений на практике.


Мир сходит с ума и грянет киберапокалипсис. Подпишись на наш Телеграм канал, чтобы узнать первым, как выжить в цифровом кошмаре!