Процесс кода DevSecOps | Кибербезопасность AT&T


Лучшие практики

В первой статье этой серии мы рассмотрели основы. Во второй статье о процессе планирования мы рассмотрели, как разработчики включают безопасность в начале своего проекта. В этой статье рассматривается DevSecOps на этапе непрерывной интеграции (CI) процесса кодирования и способы защиты кода от атак в цепочке поставок, проблем с лицензиями и кражи. Разработчикам рекомендуется при планировании использовать передовые методы безопасного кодирования в процессе кодирования.

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

Что такое репозиторий исходного кода?

Репозиторий исходного кода «репозиторий» — это централизованное хранилище файлов, в котором используется система контроля версий для сохранения истории изменений файлов и комментариев разработчиков о том, почему были внесены изменения. Репозитории также позволяют сотрудничать в команде разработчиков, которые работают над одним и тем же проектом, будучи защищенными от дублирования или конфликтующих изменений. У разработчиков есть выбор, какой репозиторий использовать, в зависимости от требований и цели программного обеспечения, которое они создают. Например, общедоступный репозиторий подходит для открытого исходного кода (FOSS), в то время как частный репозиторий может потребоваться для защиты проприетарного программного кода «жемчужины короны» бизнеса.

Публичное и частное репо

Веб-сайты репозиториев «программное обеспечение как услуга», такие как Github, Gitlab и Bitbucket, являются примерами общедоступных репозиториев, где люди могут хранить проекты, сотрудничать и делиться ими с другими людьми по всему миру. Поскольку общедоступные репозитории доступны из Интернета, они предназначены в первую очередь для того, чтобы быть доступными для всех.

Частные репозитории в таких службах, как Azure DevOps (могут быть общедоступными или частными) или локальная установка Gitlab, предлагают дополнительные уровни безопасности, но также сопряжены с дополнительными административными издержками. Элементы управления сетевой безопасностью, такие как доступ к виртуальной частной сети (VPN), брандмауэры, системы защиты от потери данных (DLP) и системы обнаружения/защиты от вторжений, защищают частный репозиторий от злонамеренной активности. Накладные расходы по управлению и администрированию платформы частного репо ложатся на компанию.

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

Аутентификация и авторизация

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

Например, аудитору может потребоваться доступ только для чтения, в то время как разработчику потребуется добавлять или изменять элементы в репозитории. Для частных репозиториев DevSecOps рекомендует интегрировать аутентификацию в платформу единого входа (SSO) компании, а многофакторная аутентификация (MFA) обеспечит более надежную защиту от атак с использованием пароля.

Ветвление исходного кода

Проект в репозитории, скорее всего, имеет несколько пользовательских историй, над которыми работают несколько разработчиков, чтобы доставить приложение. «Основная» ветвь исходного кода в репозитории представляет собой «единственный источник правды».

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

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

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

Пулл-реквесты

Слияние функциональной ветки с основной веткой не должно происходить без пул-реквеста. Запрос на включение — это инструмент в репозиториях, который объявляет о желании разработчика другим членам команды просмотреть внесенные ими изменения. Другие разработчики просматривают внесенные изменения и могут отправить отзыв о дополнительных изменениях или одобрить запрос на слияние кода с основной веткой. После завершения экспертной проверки запрос на извлечение утверждается, а код функциональной ветки объединяется с основной веткой для создания нового «единого источника достоверной информации». После завершения слияния ветвь функции может быть удалена.

Разветвление

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

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

Разделение исходного кода

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

Следующие шаги

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

https://cyberxhack.org/