Представим: у нас стоит задача придумать продукт, который должен спасти разработчика, и при этом он должен не мешать ему создавать. “Не мешать” - это одно из ключевых требований к ИБ-решениям. Заменим это требование: “он должен ускорять процесс разработки”.

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

На рынке Application Security существует достаточное количество продуктовых категорий, которые решают одну и ту же задачу, но с разных сторон. Создавать еще одно решение - риск потратить ресурс. Только если результат не будет кардинально менять расстановку сил на поле “attack-defense”. Поэтому уточним задачу: разработать продукт, который спасет разработчика, и который будет эффективно использовать уже имеющуюся технологическую базу.

Эффективно - это значит, мы не будем собирать новые велосипеды, если старые еще работают. Мы будем добавлять инкрементальные изменения в существующие знания и подходам, которые работают. Как минимум, нам предстоит разобраться во всех этих велосипедах.

Платформы вроде ASPM решают задачу эффективности, собирая под капотом актуальные appsec-технологии и добавляя инкремент: снижают шум от всех этих продуктов. И все же это не решает основную задачу: не тратить внимание разработчика на исправление security-проблем.

Мир движется к автономным и самовосстанавливающимся системам. Autonomous и self-healing в задачах кибербезопасности идут рука об руку. Например, недавно DARPA (то самое агентство, которое создало ARPANET) объявило грант на разработку self-healing системы для защиты прошивок. То есть DARPA предложила пересмотреть фундаментальные принципы защиты на уровне компьютерной шины.

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