Все, что я здесь упоминаю, имеет ряд возможностей, пригодность которых зависит от вашего бюджета и степени уверенности, которую вы и ваши клиенты желаете. Многие из приведенных ниже шагов включают в себя применение криптографических хэшей и подписей, и это не случайно. При применении надлежащих технических средств контроля они представляют собой однозначную отметку о том, что тот, кто (или какой-либо компьютер) обладал ключом подписи, подтвердил, что процесс выполнялся должным образом.
Доставка
Давайте начнем с конца доставки и продолжим наш путь. Основной мерой здесь является подписание ваших двоичных файлов. Любой, кому это нужно, должен иметь возможность проверить подлинность этой подписи и значение этой конкретной подписи (это поддерживаемая версия, или она была сгенерирована нами, или возможно что-либо еще). Это означает, что открытые ключи должны быть широко распространен, отдельно от поставляемого двоичного файла. Это может быть сделано по предварительной договоренности с вашими клиентами или подписано сторонним сертификатом. В любом случае, если вам важно, проверка подписи должна быть обычной частью процесса принятия, который выполняют ваши клиенты. Для действительно параноиков ( кашель Apple кашель ) аппаратное обеспечение может выполнить эту проверку подписи.
Компиляция
Сделайте шаг назад в прошлое двоичного файла: каким процессом был создан двоичный файл? Был ли он скомпилирован и подписан на защищенном сервере сборки? Случайный разработчик нажал «Построить» на панели инструментов IDE? Для непроизводственных сборок может быть приемлемо использовать двоичные файлы, сгенерированные случайными разработчиками. Ключ для подписания сборок релиза, вероятно, должен быть доступен только для процесса автоматической сборки. Затем вы можете сосредоточиться на обеспечении безопасности одной или нескольких благословенных сборочных машин. Кроме того, назначение систем сборки также дает возможность применять автоматизированные тесты и обеспечивать использование проверенной цепочки инструментов (версии компиляторов и т. Д.). Возможно, имеет смысл сделать все возможное для защиты этих машин, с очень ограниченным доступом к сети, строгой авторизацией и аудитом при входе в систему, обнаружением вторжений и т. Д.
Если идти дальше назад, какой код создается? Все основные проекты с открытым исходным кодом выпускают подписанные GPG архивы выпущенного исходного архива. Те, кто использует популярные DVCS, такие как Git и Mercurial, поддерживают аналогичные подписанные теги в самом хранилище. Чтобы система сборки подписывала двоичный файл как выпуск, она должна была проверить, что она собирает правильно подписанный источник указанной версии и что подпись принадлежит кому-то, уполномоченному делать выпуск.
Интеграция
Откуда берется код? Ну, люди пишут это, а затем они помещают это в хранилище. Прежде чем какой-либо код будет интегрирован в ветку релиза, вы, вероятно, захотите принять меры для проверки того, кто написал этот код и соответствует ли он вашим стандартам качества.
Часть «кто это написал» (или реально (если вы не смотрите за их плечами), «кто за нее ручается») проста: принудительная проверка подлинности и ведение журнала аудита при любом доступе к записи в хранилище. Это могут быть пароли, ключи SSH, подписи GPG (опять же, подписанные теги), крипто-токены OTP и т. Д. Существует целая индустрия, построенная вокруг обеспечения аутентификации.
«До стандартов качества» может потребоваться несколько больше усилий. Если у вас есть тесты, которые должны пройти, процесс интеграции должен это проверить. Инструменты непрерывной интеграции могут быть действительно полезны здесь. Если код должен пройти проверку (он же просмотр), интеграция должна быть прямым результатом положительного отчета о проверке. Чтобы увидеть пример реализации для такого рода политики, взгляните на Gerrit.
Разработка
Что касается написания кода, то это зависит от здравого смысла ваших разработчиков. Множество людей подробно писали о процессе разработки, инструментах и методах.