Это 9-й спринт из 10-ти запланированных для вашего следующего крупного релиза веб-сайта. Ваша команда веб-разработчиков спешит запустить новую версию вашего сайта в начале сентября. Вы хотите, чтобы сайт работал и работал как минимум за два месяца до Черной пятницы и большого сезона покупок, чтобы избавиться от любых ошибок. Вместо того, чтобы кодировать всю функциональность, необходимую вашему сайту с нуля, команда разработчиков использует широкий спектр библиотек JavaScript, которые она находит на GitHub. «Все ли библиотеки протестированы и проверены?» — спрашиваете вы команду. Они уверяют, что все проверили.

Через несколько недель после запуска вы получаете уведомление от исследовательской группы по информационной безопасности о том, что они обнаружили на вашем сайте скиммер для кредитных карт. Однако вы не узнаете библиотеку JavaScript, которая, по словам исследователей безопасности, была скомпрометирована; его не было в окончательном списке, который вы получили от своей команды разработчиков. Оказывается, одна из команд переключилась в последнюю минуту, потому что в первоначально выбранной библиотеке отсутствовали некоторые ключевые возможности, в которых они нуждались.

Теперь у вас на руках гигантская неразбериха с разгневанными клиентами и надвигающийся масштабный аудит кода для всего сайта. Вы стали жертвой «Кода теней». И вы не одиноки.

Код восстания теней

Shadow Code — это аналог Shadow IT для разработки программного обеспечения. В Shadow IT сотрудники используют облачные сервисы и программное обеспечение, которые не одобрены, не отслеживаются и не поддерживаются ИТ. Теневые ИТ могут варьироваться от несанкционированных подписок SaaS до облачных серверов AWS, развернутых на кредитной карте без надзора или соблюдения требований.

Теневой код — это когда разработчики включают в приложения код стороннего программного обеспечения, иногда без одобрения или какой-либо проверки безопасности. Они делают это потому, что обычно это быстрее, чем писать функционал с нуля. Конкретная часть теневого кода может решить проблему более точно или может показаться, что она лучше подходит для других компонентов приложения. Некоторыми примерами этого могут быть программное обеспечение корзины покупок, платежные системы или требования к адаптивному дизайну. Иногда разработчики также ошибочно включают теневой код, который является подделкой, но имеет похожее имя (это называется опечаткой).

По правде говоря, Shadow Code существует с самого начала появления программного обеспечения. Большая часть кода используется более чем в одном приложении, поэтому, естественно, повторное использование и копирование кода давно стало общепринятой практикой. Что недавно изменилось, так это объем используемого стороннего кода и все более важная функция, которую эти сторонние библиотеки кода играют в приложениях. Интерфейсные приложения, как и веб-сайты, в основном состоят из стороннего кода — некоторые более чем на 70%. Основной формой стороннего кода, используемого сегодня, являются библиотеки JavaScript, хотя сторонний код используется во всех других современных языках, включая Ruby, Python и Golang. Что касается веб-сайтов, разработчики используют сторонние библиотеки JavaScript практически для всех конфиденциальных задач, включая обработку платежной информации, вход в систему клиентов и многое другое. Многочисленные поставщики SaaS (включая PerimeterX) используют JavaScript для расширения функциональности приложений на веб-сайтах клиентов. Однако большая часть библиотеки JavaScript используется для более приземленных задач, таких как проверка формы, предоставление правильной даты и времени и доставка шрифта.

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

Приглашение незнакомцев в свой дом

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

Некоторые гости, которых мы знаем, ведут себя очень хорошо. Например, Facebook создает и поддерживает популярную библиотеку и фреймворк React JavaScript, используемые для создания веб-приложений. Поскольку у него большое сообщество и поддерживается Facebook, вы можете быть уверены, что он безопасен и хорошо поддерживается.

С другими гостями может быть сложнее узнать наверняка. Существуют сотни популярных библиотек JavaScript, предоставляющих полезную функциональность, которые редко обновляются и имеют сопровождающих, которые являются отдельными лицами, с которыми может быть трудно связаться в случае взлома. Библиотека может работать достаточно хорошо, но представляет реальную угрозу безопасности. В других случаях несколько сопровождающих имеют привилегии над программным кодом библиотеки, и изменения версии не отслеживаются тщательно. Это может привести к незаметному проскальзыванию тонких изменений, которые превращают безупречную в остальном библиотеку во вредоносную.

Кроме того, есть библиотеки, которые, хотя и поддерживаются, не соответствуют вашим стандартам. Было несколько случаев взлома часто поддерживаемого, но небезопасного стороннего сервиса. В результате крупные бренды, использующие эту библиотеку, были скомпрометированы, подвергая своих клиентов реальным рискам. Со сторонними сервисами вы настолько сильны, насколько ваше самое слабое звено.

Суть Shadow Code? Как владелец веб-сайта, вы несете полную ответственность за любое нарушение или проблему безопасности, которую несанкционированные или плохо выбранные библиотеки могут злонамеренно или непреднамеренно представить вашим клиентам и пользователям.

Исправление теневого кода

Как и в случае с Shadow IT, жесткое правоприменение расстроит ваших разработчиков. Имейте в виду, что они используют Shadow Code для повышения скорости и производительности, а не из каких-либо злонамеренных намерений. Вот несколько основных шагов:

  1. Настройте процессы быстрого утверждения и открытия для любой библиотеки или внешнего кода, который вы планируете включить. Это разработано, чтобы убедиться, что он проверяет основные поля безопасности, а также видимость и отзывчивость сопровождающего. Если вы видите вопросы без ответов, которые месяцами лежат в репозитории проекта на GitHub, знайте, что дела идут не очень хорошо.
  2. Запустите все сторонние библиотеки и код с помощью инструментов обнаружения и проверки, которые проверяют код на наличие признаков несанкционированной модификации. Есть отличные сервисы, которые делают это, а также есть инструменты с открытым исходным кодом, которые присваивают содержимому библиотеки уникальный идентификатор (хеш-номер), который изменится при изменении кода. Браузеры могут запрашивать хэш и проверять его правильность перед загрузкой кода.
  3. Ознакомьтесь с концепцией политики безопасности контента (CSP) и с тем, как она может помочь повысить уровень безопасности вашего веб-сайта. Хороший CSP может предотвратить распространенные атаки, запущенные из скомпрометированных сторонних библиотек Javascript, таких как межсайтовый скриптинг (XSS), кликджекинг и другие атаки с внедрением кода. Да, управление CSP осуществляется вручную и требует много времени, но вы можете снизить многие риски Shadow Code с помощью некоторых простых правил CSP.
  4. Убедитесь, что у вас есть четкие возможности мониторинга и оповещения во время выполнения, где код фактически выполняется. Технология должна быть в состоянии, например, определить, была ли добавлена ​​новая форма на ваш веб-сайт или появилась ли новая кнопка «Купить» для корзины покупок, которой раньше не было — все признаки того, что вы стали жертвой Атаки Magecart и другие компрометации вашего стороннего кода. Этот мониторинг должен работать как в промежуточной, так и в производственной среде. В идеале вы хотите отловить проблемы в постановке до того, как они будут запущены.

Заключение: серьезный сдвиг

Исправление Shadow Code требует серьезных изменений в том, как мы разрабатываем программное обеспечение. Игнорировать проблему не вариант; правила соответствия становятся все более жесткими, юридические и деловые риски растут. К счастью, исправление не должно быть болезненным. Компании, применяющие современные методы DevOps, могут легко проводить проверку любых новых библиотек в качестве обязательного шага в конвейерах CI/CD. Кроме того, существуют инструменты для разработчиков, которые могут отслеживать библиотеки и сторонний код, поступающий в конвейер, и обеспечивать прохождение этими инструментами базовых проверок безопасности, а также отслеживать изменения кода в этих библиотеках с течением времени. Наконец, появилось новое поколение инструментов машинного обучения, которые могут изучать поведение вашего кода в промежуточной или производственной среде и отмечать любые изменения в том, как сайт загружает контент, формы или страницы, чтобы выявлять аномалии, которые могут быть вызваны Shadow Code. .

Реальность такова, что каждый владелец веб-сайта имеет дело с теневым кодом. Команды разработчиков сосредоточены на решении проблем, и иногда самый простой и быстрый способ сделать это — выйти за пределы одобренных каналов, чтобы быстро выполнить работу. К сожалению, это может поставить под угрозу их бизнес и их клиентов. Владельцы веб-сайтов должны внедрить процессы, которые предотвращают теневой код и позволяют их командам разработчиков быстро и четко утверждать сторонний код в рамках обычного цикла DevOps. Это лучший способ сохранить гибкость и ценность использования всего уже существующего полезного кода, не подвергая ваш бизнес и ваших клиентов ненужным рискам.