Помимо исправления ошибок и добавления новых функций, долгосрочное существование проекта зависит не только от его полезности, но и от доверия, которое он заслуживает у пользователей. Надёжные меры безопасности важны для сохранения этого доверия. Ниже приведены ключевые действия, которые вы можете предпринять, чтобы значительно повысить безопасность вашего проекта.
Убедитесь, что все привилегированные участники включили двухфакторную аутентификацию (MFA)
Злоумышленник, которому удастся выдать себя за участника с привилегированным доступом, может нанести катастрофический ущерб.
Получив привилегированный доступ, такой злоумышленник может изменить ваш код, чтобы тот выполнял нежелательные действия (например, майнинг криптовалюты), распространить вредоносное ПО в инфраструктуре ваших пользователей или получить доступ к закрытым репозиториям, чтобы похитить интеллектуальную собственность и конфиденциальные данные, включая учётные данные для других сервисов.
MFA обеспечивает дополнительный уровень защиты от захвата учётной записи. После включения вы должны входить с логином и паролем, а также предоставлять дополнительную форму аутентификации, к которой у вас есть доступ (например, одноразовый код из приложения).
Обеспечьте безопасность кода в рамках процесса разработки
Уязвимости в коде дешевле исправлять на ранних этапах, чем после выхода в продакшн.
Используйте инструмент статического анализа безопасности (SAST), чтобы обнаруживать уязвимости в коде. Эти инструменты работают на уровне кода и не требуют исполняемой среды, поэтому их можно запускать на ранних этапах и легко интегрировать в обычный процесс разработки — на этапе сборки или при проверке кода.
Это как если бы опытный эксперт просматривал ваш репозиторий и помогал находить распространённые уязвимости, которые могут быть незаметны при обычной разработке.
Как выбрать SAST-инструмент? Проверьте лицензию: некоторые инструменты бесплатны для open-source проектов, например GitHub CodeQL или SemGrep. Проверьте поддержку ваших языков программирования.
- Выбирайте инструмент, который легко интегрируется с уже используемыми вами средствами и процессами. Например, лучше, если оповещения будут отображаться в рамках вашего текущего процесса проверки кода, а не в отдельном инструменте.
- Остерегайтесь ложных срабатываний! Вы не хотите, чтобы инструмент замедлял вашу работу без причины!
- Проверьте функциональность: некоторые инструменты очень мощные и поддерживают анализ потоков данных (например, GitHub CodeQL), другие предлагают исправления, сгенерированные ИИ, третьи упрощают написание пользовательских запросов (например, SemGrep).
Не храните и не публикуйте свои секреты
Конфиденциальные данные, такие как API-ключи, токены и пароли, иногда случайно попадают в репозиторий.
Представьте ситуацию: вы — сопровождающий популярного open-source проекта, в который вносят вклад разработчики со всего мира. Однажды участник случайно коммитит в репозиторий API-ключи стороннего сервиса. Через несколько дней кто-то находит эти ключи и использует их для несанкционированного доступа. Сервис оказывается скомпрометирован, пользователи вашего проекта сталкиваются с простоем, а репутация проекта страдает. Как сопровождающий, вы теперь вынуждены отозвать скомпрометированные ключи, выяснить, какие действия злоумышленник мог совершить с этим доступом, уведомить пострадавших пользователей и внедрить исправления.
Чтобы предотвратить такие инциденты, существуют решения для сканирования секретов, которые помогают обнаруживать такие данные в вашем коде. Некоторые инструменты, например GitHub Secret Scanning и Trufflehog от Truffle Security, могут предотвратить отправку секретов в удалённые ветки, а некоторые автоматически отзывают обнаруженные ключи.
Проверяйте и обновляйте зависимости
Уязвимости в зависимостях вашего проекта могут подорвать его безопасность. Ручное обновление зависимостей — трудоёмкая задача.
Представьте: проект построен на прочной основе широко используемой библиотеки. Позже в этой библиотеке обнаруживается серьёзная уязвимость, но разработчики приложения об этом не узнают. Конфиденциальные данные пользователей остаются открытыми, и злоумышленник, воспользовавшись этой уязвимостью, похищает их. Это не теория — именно так произошло с Equifax в 2017 году: они не обновили зависимость Apache Struts после уведомления о критической уязвимости. Она была эксплуатирована, и в результате утечки пострадали данные 144 миллионов пользователей.
Чтобы избежать подобного, инструменты анализа состава ПО (SCA), такие, как Dependabot и Renovate, автоматически проверяют зависимости на наличие известных уязвимостей из публичных баз данных (например, NVD или GitHub Advisory Database) и создают pull request’ы для обновления до безопасных версий. Поддержание зависимостей в актуальном состоянии защищает ваш проект от потенциальных рисков.
Защитите основные ветки от нежелательных изменений
Неограниченный доступ к основным веткам может привести к случайным или злонамеренным изменениям, которые вызовут уязвимости или нарушат стабильность проекта.
Новый участник получает права на запись в основную ветку и случайно пушит непроверенные изменения. В результате обнаруживается серьёзная уязвимость, вызванная этими изменениями. Чтобы избежать таких проблем, правила защиты веток гарантируют, что изменения не могут быть влиты в важные ветки без предварительной проверки и прохождения указанных проверок статуса. С этой дополнительной мерой вы будете в большей безопасности, обеспечивая высокое качество кода при каждом изменении.
Настройте механизм приёма отчётов об уязвимостях
Хорошей практикой является упрощение процесса сообщения об ошибках, но главный вопрос: как пользователи могут безопасно сообщить об уязвимости, не привлекая внимание злоумышленников?
Представьте: исследователь безопасности обнаруживает уязвимость в вашем проекте, но не находит понятного или безопасного способа сообщить о ней. Без чёткого процесса он может создать публичный issue или обсудить проблему в соцсетях. Даже если он действует добросовестно и предлагает исправление, при публичном pull request’е другие увидят уязвимость до её исправления! Такое раскрытие сделает уязвимость доступной для злоумышленников до того, как вы сможете её устранить, что может привести к эксплуатации «в ноль» и атаке на ваш проект и его пользователей.
Политика безопасности
Чтобы избежать этого, опубликуйте политику безопасности. Политика безопасности, описанная в файле SECURITY.md, детализирует шаги для сообщения о проблемах безопасности, создаёт прозрачный процесс координированного раскрытия и определяет обязанности команды проекта по устранению сообщённых проблем. Политика может быть простой: «Пожалуйста, не публикуйте детали в публичных issue или PR, отправьте нам письмо на security@example.com», но также может содержать дополнительные сведения, например, когда ожидать ответа. Любая информация, которая поможет сделать процесс раскрытия эффективным и быстрым, полезна.
Приватное сообщение об уязвимостях
На некоторых платформах можно упростить и усилить процесс управления уязвимостями — от приёма до оповещения — с помощью приватных обращений. В GitLab это реализовано через приватные issue. В GitHub это называется приватным сообщением об уязвимостях (PVR). PVR позволяет сопровождающим получать и обрабатывать отчёты об уязвимостях прямо в GitHub. GitHub автоматически создаёт приватный форк для написания исправлений и черновик security advisory. Всё это остаётся конфиденциальным, пока вы не решите раскрыть проблему и выпустить исправления. В завершение, security advisory публикуются и информируют, а также защищают всех ваших пользователей через их SCA-инструменты.
Заключение: несколько шагов для вас — огромное улучшение для ваших пользователей
Эти шаги могут показаться вам простыми или базовыми, но они значительно повышают безопасность вашего проекта для пользователей, обеспечивая защиту от наиболее распространённых проблем.
Участники
Большое спасибо всем сопровождающим, которые поделились с нами своим опытом и советами для этого руководства!
Это руководство было написано @nanzggits и @xcorail при участии: