Безопасность

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

Модель угроз

Apothem — это материализатор конфигурации. Он читает общий профиль и записывает нативные для окружения файлы конфигурации в каталоги, которые читает каждый harness. Эта единственная функция ограничивает то, чему он доверяет, и то, чему не доверяет.

• Чему Apothem доверяет. Общему профилю, который вы составляете, и включённому дереву исходного кода, размещённому установщиком. Профиль — это ваше заявленное намерение; движок после проверки по схеме рассматривает его как авторитетный ввод.
• Чему Apothem не доверяет. Содержимое профиля достигает файловой системы только после проверки: сбои схемы, неизвестные идентификаторы окружения, небезопасные пути проекта, отсутствующие источники манифеста, обход цели и пересечения символических ссылок — все они останавливаются до любой записи и возвращают структурированную диагностику с files_written: [].
• Что материализованный вывод никогда не несёт. Никаких секретов. Диагностика профиля затемняет ключи, похожие на секреты, и значения, похожие на токены, прежде чем они достигнут обычного вывода, JSON, журналов, фрагментов документации или тестов, а публичные примеры используют поддельные личности-заполнители и домены. Материализованная конфигурация предназначена для коммита и совместного использования; она не несёт учётных данных.
• Универсальный порог запрета. Правила, которые материализует Apothem, несут не подлежащий обсуждению порог запрета независимо от любого списка разрешений для конкретного окружения — пути секретов (.env*, ~/.ssh/**, хранилища учётных данных), деструктивные операции оболочки (rm -rf, sudo, принудительные отправки в защищённые ветки) и выполнение недоверенного ввода. Ни один список разрешений не расширяет этот порог незаметно.
• Радиус поражения. Записи ограничены каталогами окружения и принадлежащими Apothem поддеревьями поддержки. Существующие управляемые цели резервируются перед заменой, а общие каталоги обнаружения объединяются потомок за потомком, поэтому несвязанные файлы, составленные оператором, остаются на месте.

Позиция безопасности во время выполнения

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

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

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

Быстрые ссылки

• Позиция по OpenSSF Scorecard — доказательства по каждой проверке и известные ограничения платформы
• Аудит вебхуков — доказательства гигиены секрета вебхука
• Защита веток — контроль ревью, проверки статуса и ограничения отправки
• Прочёсывание бинарных артефактов — доказательство выпуска без бинарных файлов в исходном коде
• Политика безопасности — сообщение об уязвимостях и поддерживаемые версии
• Значок OpenSSF Scorecard — оценка в реальном времени

Сообщение об уязвимости

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

Доказательства выпуска для цепочки поставок

Каждый артефакт выпуска поставляется с:

• Происхождением сборки SLSA-3 через slsa-framework/slsa-github-generator
• Подписями Sigstore через sigstore/cosign-installer
• SBOM в формате CycloneDX через anchore/sbom-action
• Заявлениями о происхождении npm через OIDC Trusted Publishing на @ahmed-g-gad/apothem
• Подписанными GPG тегами git (ключ EDDSA 70396FED9C634163)

Рецепты проверки документированы встроенно в Цикл выпуска и Восстановление выпуска; отдельный runbook по проверке выпуска готовится.