Как поддерживать защищенный репозиторий GitHub.

8 мин

Здесь обсуждаются некоторые основные средства и методы обеспечения безопасности, доступные администраторам репозитория GitHub.

Примечание.

Следующее содержимое не охватывает основы написания защищенного кода, а довольно важные аспекты безопасности, инструменты и функции, используемые в репозитории GitHub.

Важность стратегии безопасной разработки

Безопасность приложений важна. Новости часто содержат истории о некоторых нарушениях систем компании и частных компаний и данных клиентов, которые были украдены.

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

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

Существует множество аспектов создания и развертывания безопасных приложений. Ниже приведены три вещи, которые следует учесть:

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

Безопасность на каждом этапе

Изображение щита GitHub с подписью

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

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

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

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

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

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

Функции вкладки "Безопасность"

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

На GitHub.com перейдите на главную страницу репозитория.
В поле имени репозитория выберите "Безопасность".

Снимок экрана: расположение вкладки

На вкладке "Безопасность" можно добавить функции в рабочий процесс GitHub, чтобы избежать уязвимостей в репозитории и базе кода. Эти функции включают перечисленные ниже.

Политики безопасности, позволяющие указать, как сообщить об уязвимости безопасности в проекте, добавив SECURITY.md файл в репозиторий.
Оповещения Dependabot, уведомляющие вас о том, что GitHub обнаруживает, что репозиторий использует уязвимую зависимость или вредоносные программы.
Рекомендации по безопасности, которые можно использовать для частного обсуждения, исправления и публикации сведений об уязвимостях безопасности в репозитории.
Сканирование кода, которое помогает находить, проверять и устранять уязвимости и ошибки в коде.

Дополнительные сведения см. в разделе "Функции безопасности GitHub".

Примечание.

Рекомендации по оповещениям Dependabot для вредоносных программ в настоящее время находятся в бета-версии и подвержены изменению. Только рекомендации, которые были проверены GitHub, будут запускать оповещения Dependabot.

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

Донесение политики безопасности с помощью SECURITY.md

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

Чтобы узнать больше о SECURITY.md, см. Добавление политики безопасности в репозиторий.

Исключение конфиденциальных файлов из репозитория с помощью .gitignore

Разработчикам легко пропустить файлы в фиксации. Иногда эти пропущенные файлы не опасны, например промежуточные файлы сборки. Однако всегда существует риск того, что кто-то может случайно зафиксировать конфиденциальные данные. Например, кто-то может зафиксировать ключ API или данные частной конфигурации, которые может использовать злоумышленник. Один из способов, которые помогут избежать этого риска, заключается в создании и обслуживании .gitignore файлов. Эти файлы предписывают клиентским средствам, таким как служебная программа командной строки git, игнорировать определенные пути и шаблоны при сборе файлов для фиксации.

В следующем примере показаны некоторые распространенные варианты использования для игнорировать файлы:

# User-specific files - Ignore all files ending in ".suo"
*.suo

# Mono auto generated files - Ignore all files starting with "mono_crash."
mono_crash.*

# Build results - Ignore all files in these folders found at any folder depth
[Dd]ebug/
[Rr]elease/
x64/
x86/

# Root config folder - Ignore this directory at the root due to leading slash
# Removing the slash would ignore "config" directories at all depths 
/config

# Ignore intermediate JS build files produced during TypeScript build at any 
# folder depth under /Web/TypeScript. This won't ignore JS files elsewhere. 
/Web/TypeScript/**/*.js

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

Дополнительные сведения .gitignore см. в Игнорировании файлов. Также ознакомьтесь с начальной коллекцией файлов .gitignore, предлагаемых для различных платформ в репозитории gitignore.

Удаление конфиденциальных данных из репозитория

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

Внимание

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

Правила защиты ветвей

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

Рабочие процессы, которые защищают ветвь, можно использовать:

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

Добавление файла CODEOWNERS

Добавьте в репозиторий файл CODEOWNERS, чтобы назначать отдельных участников команды или целые группы в качестве владельцев кода для путей в репозитории. Затем эти владелец кода требуются для проверки запроса на вытягивание любых изменений в файлах в пути, для которого они настроены.

# Changes to files with the js extensions need to be reviewed by the js-owner user/group:
*.js    @js-owner

# Changes to files in the builds folder need to be reviewed by the octocat user/group:
/build/ @octocat

Файл CODEOWNERS можно создать в корневом каталоге репозитория или в папкеdocs..github

Продолжить