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

• 37 БЕЗОПАСНАЯ РАЗРАБОТКА www.itsec.ru Процесс безопасной разработки Для начала хотелось бы напомнить еще раз, что такое процесс безопасной разработки, а также посмотреть на основные принципы его построения, так как это существенно поможет нам в дальнейшем. Процесс безопасной разработки – это интеграция практик безопасности в раз- работку таким образом, чтобы вместе они создавали единый, непрерывный и законченный процесс, каждый участник которого знает свою зону ответственно- сти, задачи и требования. Ключевое слово в этой фразе – процесс. Самая распространенная ошибка при начале формирования этой активности в компании связана с выбором инстру- ментов. Нередко организация сначала их закупает, а уже потом пытается как- то интегрировать в имеющиеся процес- сы. Порой это приводит к печальным последствиям, когда дорогие и хорошие, но не подходящие конкретной компании инструменты начинают создавать боль- ше проблем, чем пользы, а вместо тес- ной интеграции они стоят отдельно и на них просто проводят периодические про- верки с переменным успехом. А нужно действовать по-другому: сначала понять, какие процессы есть в разработке, какие решения исполь- зуются, какие нюансы присутствуют и как их учитывать. И только после того, как сформируется полное понимание технологий внутри компании, нужно… Нет, не покупать инструменты, а понять, как все будет устроено, как все участни- ки станут взаимодействовать друг с дру- гом, у кого какие зоны ответственности и как это лучше автоматизировать. Для примера обратимся к одному из возможных процессов в популярной практике, основанной на анализе ком- понентов с открытым исходным кодом (см. рис. 2). Порядок работы с уязвимой компо- нентой, обнаруженной в процессе ана- лиза используемых библиотек с откры- тым исходным кодом, можно описать следующим образом: 1. Идентифицируется репозиторий исходного кода, в котором была обнару- жена библиотека с уязвимостями. 2. Инженер ИБ проводит анализ уязви- мости, ее критичности и возможностей эксплуатации. 3. Если существует безопасная версия и ее можно использовать, то инженер ИБ создает дефект с рекомендацией перейти на данную версию компоненты. В ином случае процесс переходит на шаг 6. 4. Если команда разработки готова сразу отказаться от использования уязвимой компоненты (то есть готова устранить дефект в ближайшее время), то процесс заканчивается с ошибкой – компонента недоступна. В ином случае процесс переходит на шаг 5. 5. Команда разработки не может в ближайшее время отказаться от исполь- зования уязвимой компоненты. В этом случае определяется дата или релиз устранения дефекта, связанного с дан- ной компонентой. Процесс переходит на шаг 8. DevSecOps в текущих реалиях: что изменилось и как быть? ема безопасной разработки сегодня актуальна как никогда. На рынке есть большой спрос на создание безопасных программных решений, а потому без DevSecOps никак не обойтись. Что изменилось в текущих реалиях, когда крупные игроки ушли с нашего рынка, а использовать оставшийся зарубежный софт может быть рискованно и даже, в некоторых случаях, опасно? Постарается разобраться в этом и подумать над вариантами решения существующих проблем. Статья будет полезна всем, кто работает в области ИБ и делает продукт в своей компании более безопасным. Т Юрий Шабалин, ведущий архитектор Swordfish Security Рис. 1. Процесс безопасной разработки