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

Банки, ритейлеры, маркетплейсы, образовательные центры, государственные органы - всё это начало трансформироваться в FinTech, GovTech, GameTech, EdTech, объединённые одним ключевым термином - DevOps.

DevOps превратился в один из основных инструментов бизнеса.

☑ Новые фичи,

☑ Покупка товаров или услуг в два касания,

☑ Наличие онлайн банкинга,

☑ Доступ к цифровым документам гражданина РК,

☑ Возможность вытащить любую нужную справку.

И всё это из одного приложения, из одного «окна» каждого смартфона, на iOS или Android. Именно эти задачи и решает DevOps: как сделать, чтобы клиенту было удобно?

Вопрос, на который Бизнес не даёт времени представителям DevOps, - это анализ кода приложений на наличие ошибок или уязвимостей.

И здесь в игру вступает концепция ИБ, нацеленная на защиту программного кода сайтов и приложений - DevSecOps.

DevSecOps - направление информационной безопасности, которое отвечает за защищённость программных продуктов на выходе из отдела разработки. (Это самый упрощённый вариант определения всей этой истории).

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

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

Чтобы снизить риски выхода в релиз «дырявого» программного продукта, концепция DevSecOps предусматривает процесс, который именуется как AST (Application Security Testing).

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

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

Так на рынке ИБ появились такие классы инструментов защиты, как:

☑ SAST (Static Application Security Testing)

☑ DAST (Dynamic Application Security Testing)

☑ IAST (Interactive Application Security Testing).

SAST - статический анализ проводится на этапе написания кода приложения, сразу подсвечивая выявленные уязвимости или ошибки, указывая нужный участок строки кода (в современных реалиях это очень важный момент, особенно когда строк кода очень и очень много), а самое главное, что продукт данного класса сразу даёт рекомендацию по устранению/закрытию выявленных уязвимостей!

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

IAST - данный класс продуктов DevSecOps проводит тестирование приложения в момент его активности. IAST, имея доступ к исходному коду приложения, проверяет его на уязвимости в процессе, непосредственно работы самого приложения и анализирует безопасность приложения изнутри.

Что же круче? Ни один из выше описанных инструментов не является заменой другому. Самый оптимальный вариант, который рекомендуется использовать согласно концепции DevSecOps, - это анализ с помощью двух инструментов: SAST и DAST. Такой дуэт в анализе приложения даст больше развёрнутой и актуальной информации, которая позволит бизнесу делать его программные продукты не только удобными для его клиентов, но и безопасными!