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

38 • ТЕХНОЛОГИИ 6. Уязвимая компонента не имеет без- опасной версии. Необходимо провести анализ уязвимого кода компоненты и оценить вероятность его использования. Если ни при каких условиях нельзя при- менять компоненту, инженер ИБ создает дефект с рекомендацией отказаться от ее использования. Процесс переходит на шаг 4. В ином случае – принятие ком- пенсационных мер, процесс переходит на шаг 7. 7. Если эксплуатация уязвимости зави- сит от способа применения компоненты в исходном коде приложения, то необхо- димо создать правило в инструменте статического анализа, осуществляющее проверку на наличие условий, при кото- рых исключается эксплуатация уязви- мости. В ином случае – принять компен- сирующие меры на стороне WAF, кон- фигурации, ручного ревью кода и т.д. 8. Разрешить использование компо- ненты с уязвимостью с применением компенсирующих мер. 9. Процесс заканчивается успешно. В приведенном примере работа с уязвимостями и участие в ней каждой стороны описываются прозрачно. Понят- но, где находится зона ответственности разработки, где безопасности, а также что происходит при любом варианте развития событий. И все это вне зави- симости от конечного решения, которое будет использоваться. Вместе с тем мы сразу понимаем, какими особенностями должен обладать не только инструмент, реализующий конкретно эту практику, но и связанные с ним инструменты. В данном процессе участвуют и решения для статического анализа, и системы защиты вроде WAF. Только проработав подобные процес- сы, согласовав их со всеми участниками и определив основные требования, кото- рым должны соответствовать инстру- менты, можно переходить к следующему шагу в формировании безопасной раз- работки – подбору решений, которые будут гармонично встраиваться в про- цесс. И вот тут как раз произошли основные интересные изменения, о кото- рых хочется поговорить немного под- робнее. Что изменилось и как действовать Что изменилось в DevSecOps в связи с текущей ситуацией на рынке? На самом деле поменялась только одна часть – инструменты. Их стало суще- ственно меньше, так как ведущие запад- ные игроки вышли из игры, а использо- вать оставшиеся зарубежные решения достаточно опасно: неизвестно, что будет с ними через некоторое время и как они себя поведут. Таким образом, сейчас нужно ориен- тироваться только на российские разра- ботки и рассматривать возможность импортозамещения различных инстру- ментов DevSecOps либо использовать Open Source. Инструменты с открытым исходным кодом стоит применять с боль- шой осторожностью, поскольку в послед- нее время участились случаи добавления Рис. 2. Работа с уязвимостями в библиотеках с открытым исходным кодом