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

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

Модель угрозCopy Anchor Link

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

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

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

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

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

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

Быстрые ссылкиCopy Anchor Link

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

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

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

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

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

• Происхождением сборки SLSA-3 через slsa-framework/slsa-github-generator
• Подписями Sigstore через sigstore/cosign-installer
• CycloneDX SBOM поставляемых wheel и sdist, который записывает scripts/release/generate_sbom.py: пакет apothem, каждый пакет, вендоренный в apothem/_vendor, с его лицензией, объявленные требования времени выполнения и SHA-256 каждого дистрибутива. SBOM подписан и покрыт происхождением сборки так же, как дистрибутивы
• Заявлениями о происхождении npm через OIDC Trusted Publishing для @ahmed-g-gad/apothem
• Подписанными GPG тегами git (ключ EDDSA 70396FED9C634163)

Проверка релизаCopy Anchor Link

Скачайте все ресурсы релиза в пустой каталог, затем проверьте подписи и происхождение сборки. Замените vX.Y.Z и X.Y.Z на скачанный релиз.

gh release download vX.Y.Z --repo ahmed-g-gad/apothem
cosign verify-blob \
  --bundle apothem-X.Y.Z-py3-none-any.whl.cosign.bundle \
  --certificate-identity https://github.com/Ahmed-G-Gad/apothem/.github/workflows/release.yml@refs/tags/vX.Y.Z \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  apothem-X.Y.Z-py3-none-any.whl
slsa-verifier verify-artifact \
  --provenance-path provenance.intoto.jsonl \
  --source-uri github.com/Ahmed-G-Gad/apothem \
  --source-tag vX.Y.Z \
  apothem-X.Y.Z-py3-none-any.whl apothem-X.Y.Z.tar.gz

cosign печатает Verified OK, а slsa-verifier печатает PASSED: SLSA verification passed. Повторите команду cosign для любого другого ресурса с его <asset>.cosign.bundle (в более ранних релизах бандлы платформенных архивов и SHA256SUMS называются <asset>.sig). Архивы darwin и linux — это одни и те же байты под двумя именами, поэтому SHA256SUMS перечисляет один дайджест дважды. Из клона bash scripts/release/verify-provenance.sh <download-dir> выполняет все три проверки, включая манифест SHA256SUMS, за один проход.

От двух деталей зависит, имеет ли проверка какой-либо смысл:

• Регистр владельца. Проверки идентичности чувствительны к регистру, а сертификаты содержат владельца в том виде, в каком его сообщает GitHub: Ahmed-G-Gad. Владелец в нижнем регистре не проходит проверку ни в одном из двух инструментов.

• Точная идентичность. Предпочитайте --certificate-identity с полным субъектом, указанным выше. Чтобы принимать любой тег релиза, привяжите шаблон с обоих концов:

  Copy Text

  --certificate-identity-regexp '^https://github\.com/Ahmed-G-Gad/apothem/\.github/workflows/release\.yml@refs/tags/v[0-9]+\.[0-9]+\.[0-9]+$'

  Непривязанный шаблон, такой как github.com/Ahmed-G-Gad/apothem, также совпадает с поддельным субъектом, который лишь содержит этот текст, например с рабочим процессом в другом репозитории на ветке, названной в честь этого репозитория.

Руководство по циклу релиза фиксирует те же команды как проверку сопровождающего после релиза.

Пересборка релиза и сравнениеCopy Anchor Link

Wheel и sdist воспроизводимы: пересборка тега с помощью релизного инструментария даёт опубликованные дайджесты SHA-256. Используйте Python 3.12 в Linux, как это делает релиз:

git clone https://github.com/ahmed-g-gad/apothem && cd apothem
git checkout vX.Y.Z
python3.12 -m venv .build && . .build/bin/activate
pip install --require-hashes -r scripts/release/requirements-build-linux.txt
export SOURCE_DATE_EPOCH="$(git log -1 --pretty=%ct)"
python -m build --no-isolation
python scripts/release/normalize_sdist.py dist/*.tar.gz
sha256sum dist/*

Сравните дайджесты с опубликованными wheel и sdist. Сборка использует зафиксированный по хешу setuptools, закреплённый в pyproject.toml, а normalize_sdist.py удаляет из sdist время сборки, владельцев файлов и временные метки чекаута.