Базовая линия безопасности проектов с открытым исходным кодом, или OSPS Baseline, - это новая инициатива OpenSSF, направленная на укрепление безопасности проектов с открытым исходным кодом.
Другими словами, базовый уровень - это основа, включающая в себя лучшие практики безопасности, согласованные с международными рамками, стандартами и правилами кибербезопасности. Наличие прочного фундамента - это очень важно, поскольку безопасность открытого ПО - это серьезный вопрос, о котором мы неоднократно рассказывали здесь, на сайте IProgrammer. Во-первых, потому что программное обеспечение с открытым исходным кодом обеспечивает практически все, о чем мы рассказывали в статье «Европейский союз будет платить за обнаружение ошибок в программном обеспечении с открытым исходным кодом»:
Программное обеспечение с открытым исходным кодом используется во всем, от современных серверов до IoT и рабочих столов на работе, и, похоже, оно лежит в основе систем Европейского союза. Программный офис Еврокомиссии по открытому исходному коду решил предложить вознаграждение за ошибки в популярном ПО с открытым кодом. Что может быть лучше для признания важности OSS, чем спонсорство со стороны государства?
В частности, особое внимание уделяется OpenSSL и ошибке Heartbleed.
Во-вторых, обеспечить безопасность приложений не так-то просто, о чем мы писали в статье «The State Of Secure Software Development - Three OpenSSF Courses»:
Но как вам, разработчику библиотеки, фреймворка или приложения, придумать правила безопасного кодирования? Образование - вот что важно, и никакие инструменты, какими бы мощными они ни были, не смогут его заменить. Знание того, как писать безопасный код, минимизирует риски и может смягчить ограничения инструментов. Сложность современного программного обеспечения требует не только написания основного кода с учетом требований безопасности. Она требует обеспечения безопасности не как дополнения к процессу разработки, а как неотъемлемой части конвейеров CI/CD. Существует даже новый принцип на эту тему: пересечение DevOps и безопасности в DevSecOps. Этот принцип привел Linux Foundation к созданию Open Source Security.
Foundation (OpenSSF), целью которого является обучение разработчиков:
Новая базовая попытка укрепляет видение OpenSSF в отношении безопасного программного обеспечения с открытым исходным кодом, помогая разработчикам
начать с общего набора разумных настроек по умолчанию. Разумные настройки по умолчанию - это, конечно, то, что уже используется в таких инструментах, как Semgrep.
В блоге 2020 года «Будущее AppSec и почему я присоединился к r2c» эксперт по кибербезопасности Клинт Гиблер говорит следующее:
Невозможно найти все ошибки, какими бы продвинутыми ни были ваши инструменты.
Вместо этого он утверждает, что путь вперед заключается в следующем:
Создание библиотек и инструментов secure-by-default, которые разработчики могут использовать для предотвращения целых классов уязвимостей, а затем убедиться, что разработчики используют их. Именно в это верят дальновидные команды безопасности в таких компаниях, как Google, Microsoft, Facebook, Netflix, Dropbox и других, и вкладывают в это средства на протяжении многих лет.
Например, современные веб-фреймворки, такие как Django, Ruby on Rails и другие, имеют ряд безопасных настроек по умолчанию и встроенных ограждений, которые делают потенциально опасные задачи безопасными по умолчанию, включая контекстно-зависимое кодирование вывода (предотвращение XSS), тесную интеграцию с объектно-реляционными мапперами (предотвращение SQL-инъекций) и многое другое. По моему мнению и мнению многих других, именно поэтому улучшилась общая веб-безопасность, а не все те причудливые инструменты для поиска ошибок, которые мы создали.
Компания Chainguard сделала еще один шаг вперед, применив этот принцип разумных настроек по умолчанию к образам контейнеров, собранных с помощью Wolfi, Linux (un)distribution и инструментария сборки компании Chainguard. Таким образом, Wolfi создает образы контейнеров, которые отвечают требованиям безопасной цепочки поставок программного обеспечения; то есть образы уже снабжены подписями и разумными настройками по умолчанию.
Но вернемся к разумным умолчаниям Baseline в виде рекомендаций. Вместо того чтобы рассматривать методы обеспечения безопасности в привязке к кодированию, базовый уровень рассматривает их с точки зрения логистики проекта. То есть он не устанавливает правила написания безопасного кода без ошибок или как избежать ошибок, но вращается вокруг рекомендаций по контролю версий, конвейеру ci/cd, сопровождению и управлению. Например:
Контроль доступа фокусируется на механизмах и политиках, которые контролируют доступ к системе контроля версий и CI/CD конвейерам проекта. Эти средства контроля позволяют гарантировать, что только авторизованные пользователи могут получать доступ к конфиденциальным данным, изменять настройки репозитория или выполнять процессы сборки и выпуска.
Рекомендация: Обеспечьте многофакторную аутентификацию в системе контроля версий проекта, требуя от сотрудников предоставлять вторую форму аутентификации при доступе к конфиденциальным данным или изменении настроек репозитория. Для этого контроля допустимо использовать ключи доступа.
Сопоставления с внешним фреймворком
Как видите, базовая линия имеет общие черты с другими фреймворками, такими как SSDF от NIST, Европейский закон о киберустойчивости (CRA) и т. д.
Build and Release фокусируется на процессах и инструментах, используемых для компиляции, упаковки и распространения программного обеспечения проекта. Эти средства контроля помогают обеспечить безопасность, последовательность и надежность конвейеров сборки и выпуска проекта, снижая риск возникновения уязвимостей или ошибок в процессе распространения программного обеспечения.
Рекомендации: Документируйте все программные интерфейсы (API) выпущенных программных активов, объясняя, как пользователи могут взаимодействовать с программным обеспечением и какие данные ожидаются или производятся. Убедитесь, что эта документация обновляется при появлении новых функций или изменений.
Управление уязвимостями сосредоточено на процессах и практиках, используемых для выявления и устранения уязвимостей безопасности в программных зависимостях проекта. Эти средства контроля помогают гарантировать, что проект хорошо подготовлен к реагированию на угрозы безопасности и уязвимости в программном обеспечении.
Рекомендация: Предоставьте исследователям безопасности возможность сообщать об уязвимостях в частном порядке в проект. Это может быть специальный адрес электронной почты, веб-форма, специализированные инструменты VSC, адреса электронной почты контактных лиц службы безопасности или другие методы.
Это лишь несколько рекомендаций по каждой категории. Остальные категории включают в себя документацию, управление, право и качество.
Хотя фреймворк не носит обязательного характера, то есть не требуется правительством для использования программного обеспечения в своих приложениях, для проектов важно принять его, чтобы показать, что они серьезно относятся к безопасности, применяя проактивные меры по снижению рисков, и тем самым создать себе значительные возможности для принятия третьими сторонами, такими как предприятия.
В ходе довольно хитроумной атаки хакеры воспользовались слабым местом, позволившим им отправить поддельное письмо, которое казалось доставленным из систем Google, прошло все проверки, но при этом указывало на мошенническую страницу, на которой собирались логины.
Исследователи кибербезопасности из компании Socket обнаружили вредоносный пакет npm, который перехватывает управление сервером во время платежных операций.
Фишинговая платформа Tycoon2FA, известная тем, что обходит многофакторную аутентификацию в учетных записях Microsoft 365 и Gmail, получила обновления, улучшающие ее скрытность и возможности уклонения.