Как исправляли 2000+ проблем с безопасностью

Нашу экосистему OpenSource можно разделить на три области: Our Code, Our Binary Artifacts & Our Docker Images.

Каждый уровень может вызывать у нас (и у наших клиентов) различные проблемы с безопасностью. Из-за природы нашего продукта с открытым исходным кодом крайне важно, чтобы мы были бдительны. Эксплойты затрагивают не только нашу базу пользователей OpenSource, но и представляют риск для наших пользователей Cloud DBaaS.

Наш стандартный процесс релиза включает в себя тщательную последовательность действий, с Tag Checkpoint в базовом коде, за которой следует создание Binary Artifacts и, наконец, Docker Images.

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

На втором уровне, т. е. на уровне Our Binary Artifacts, мы сосредоточены на создании артефактов в безопасной среде для снижения риска несанкционированных модификаций. Тщательная генерация и проверка соответствующих SHA для целостности и подлинности выпущенных артефактов.

На третьем уровне Our Docker Images наше внимание направлено на Linux. Мы тщательно следим за тем, чтобы пакеты Linux постоянно обновлялись, чтобы предотвратить любые известные уязвимости (также известные как CVE). Естественно, требуется и безопасная среда для предотвращения любых необоснованных манипуляций или компрометации.

CVE (распространенные уязвимости и риски) служат универсальным идентификатором для определения конкретных уязвимостей и проблем безопасности. Эта стандартизированный справочник для отслеживания уязвимостей на различных платформах.

Система CVE присваивает каждой записи уникальный идентификатор (например, CVE-2021-12345). Эти записи содержат информацию об уязвимости, включая ее описание, оценку воздействия и соответствующие ссылки или ресурсы.

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

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

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

Изображение ниже иллюстрирует нашу настройку, состоящую из двух отдельных компонентов: фазы кода и сборки и фазы после релиза. Каждый этап служит определенной цели.

Во время Code & Build Phase мы используем Aqua Trivy Scans для сканирования нашего кода и слоев Docker. Эти сканирования выполняются при каждом изменении кода (pull request), а результаты регистрируются на вкладке безопасности Github. Это обеспечивает легкую визуализацию, сортировку и быстрое решение любых проблем. Для безопасности на уровне кода мы используем линтеры, о которых писали выше.

В Post Release Phase мы полагаемся на сканирование Snyk для проверки выпущенных артефактов Docker на предмет любых проблем безопасности. Хотя этот процесс использует аналогичный подход к устранению любых выявленных проблем, он выполняется за пределами экосистемы Github.

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

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

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

Мы также включили DependaBot, чтобы помочь нам с автоматическим исправлением (мы считаем, что это будущее).

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

Благодаря внедрению этой настройки непрерывного аудита безопасности мы добились замечательных результатов, успешно исправив более 2000+ проблем безопасности и более 1000+ CVE в различных проектах OpenSource и ClosedSource в Dgraph Labs Inc.

Мы получили значительные преимущества от некоторых функций. Надежная экосистема GitHub Security сыграла ключевую роль в облегчении этого процесса, позволив нам не только добиться успеха и Improved Visibility, но и Faster Security Issue Resolution.