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

Реализация рисков на этапе эксплуа- тации может привести к серьезному финансовому и репутационному ущербу. Финансовый ущерб, как правило, вклю- чает в себя затраты на устранение уязви- мости и выпуск новой версии программы, а также упущенную выгоду, которая может стать следствием снижения инте- реса клиентов к небезопасному прило- жению. Безопасная разработка про- граммного обеспечения (Secure Software Development Lifecycle – SSDL) представ- ляет собой подход, нацеленный на свое- временное выявление и устранение уязвимостей в исходном коде. Построе- ние SSDL силами разработчика про- граммного обеспечения является наи- более верным решением, ведь именно разработчик заинтересован в снижении накладных расходов на поддержание продукта. Стоимость устранения уязвимости на этапе разработки, как правило, сводится к затратам разработчика на проведение аналитики, выполнение необходимых изменений в исходном коде и проведе- ние повторной проверки. Если же уязви- мость была выявлена на этапе промыш- ленной эксплуатации, то к указанным ранее затратам могут добавиться: l расходы на выявление уязвимости (все сводится либо к оплате в рамках программы Bug Bounty, либо к оплате работы исследователя, выявившего уязвимость); l расходы на обработку обращений клиентов (ставших следствием публи- кации информации об уязвимости или нарушением в работе программы); l расходы на проведение анализа влия- ния уязвимости на участки кода, изме- ненные после ее появления; l а также расходы на сборку и вывод в промышленную эксплуатацию новой вер- сии программы. Учитывая, что выявление критиче- ской уязвимости вносит существенные коррективы в расстановку приоритетов по доработке, сроки вывода нового функционала в промышленную экс- плуатацию могут существенно изме- ниться. Стоит отметить, что внедрение SSDL является обязательным при разработке приложений, осуществляющих обработ- ку банковских карт и пр. В сложившейся практике внедрение SSDL сводится к включению средства статического анализа исходного кода (Static Application Security Testing – SAST) в процесс тестирования приложения. Как правило, тестирование безопасности приложения осуществляется одновре- менно с функциональным тестированием (Quality Assurance – QA). То есть если приложение успешно проходит все про- верки, его можно отправлять в промыш- ленную эксплуатацию. При построении процесса непрерыв- ной безопасной разработки обязательно используются три основных компонента: 1. GIT – распределенная система управления версиями, хранения и вер- сионирования исходного кода. 2. CI (Continuous Integration – непре- рывная интеграция) – основная логика распространения новых версий про- граммного обеспечения. Непрерывная интеграция – это практика разработки программного обеспечения, которая заключается в постоянном слиянии рабо- чих копий в общую основную ветвь раз- работки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявле- ния потенциальных дефектов и решения интеграционных проблем. 3. SAST – средство статического ана- лиза исходного кода. Основной инстру- мент для поиска уязвимостей. Риски, связанные с уязвимостями исходного кода Существуют риски, связанные с уязвимостями, появившимися на этапе разработки программного обеспечения, и проведение статического анализа исходного кода приложения позволяет сравнительно быстро их выявить. Рас- смотрим, какие недостатки исходного кода встречаются и к чему приводит их упущение: 1. Нарушение синтаксиса языка. Чаще всего такие уязвимости вызывают нару- шение работы приложения. 2. Использование уязвимых функций или библиотек. В последнее время доста- точно часто появлялась информация о внедрении вредоносного кода в Open Source, библиотеки или иные расшире- ния. Так как многие коммерческие про- дукты используют сторонние библиотеки без дополнительной проверки, уязви- мость библиотеки становится уязви- мостью приложения. 3. Хранение отладочных данных в исходном коде. Часто случаются ситуа- ции, когда в исходном коде приложения записаны логины и пароли, используе- мые для отладки или тестирования. Получив доступ к исходному коду, зло- умышленник может получить доступ и к приложению. 4. Ошибки конфигурации приложения. Чаще всего сводятся к некорректной настройке используемых протоколов, а также внешних модулей и иных систем, включая базы данных. Такие ошибки позволяют получить несанкционирован- ный доступ к информации. 5. Обработка данных, полученных без предварительной проверки. Чаще всего источником таких данных является пользователь, который может ввести различные сомнитель- ные сведения в приложение. Отсут- ствие проверки позволяет загрузить даже вредоносное программное обес- печение. 42 • ТЕХНОЛОГИИ Практические аспекты построения процесса безопасной разработки программного обеспечения аличие слабых мест в исходном коде программного обеспечения ухудшает его работу и провоцирует возникновение рисков, связанных с нарушением целостности и конфиденциальности информации. Чем грозит эксплуатация таких уязвимостей и можно ли сделать разработку приложения безопасной? Н Игорь Беляков, CISO kupibilet.ru , к.т.н. Рис. 1. Схема SSDL