Sécurité

La posture de sécurité d'Apothem repose sur cinq piliers : durcissement de la chaîne d'approvisionnement, réponse aux vulnérabilités, protection des branches, signature des publications et analyse de sécurité continue. Cette section documente chaque surface.

Modèle de menaceCopy Anchor Link

Apothem est un materializer de configuration. Il lit un profil partagé et écrit des fichiers de configuration natifs de l'environnement dans les répertoires que lit chaque environnement. Cette unique fonction délimite ce à quoi il fait confiance et ce à quoi il ne fait pas confiance.

• Ce à quoi Apothem fait confiance. Le profil partagé que vous rédigez et l'arborescence source fournie par l'installateur. Le profil est votre intention déclarée ; le moteur le traite comme une entrée faisant autorité après validation par rapport au schéma.
• Ce à quoi Apothem ne fait pas confiance. Le contenu du profil n'atteint le système de fichiers qu'après validation : les échecs de schéma, les identifiants d'environnement inconnus, les chemins de projet non sûrs, les sources de manifeste manquantes, la traversée de cible et les franchissements de liens symboliques s'arrêtent tous avant toute écriture et renvoient des diagnostics structurés avec files_written: [].
• Ce que la sortie matérialisée ne transporte jamais. Aucun secret. Les diagnostics du profil masquent les clés qui ressemblent à des secrets et les valeurs en forme de jeton avant qu'elles n'atteignent la sortie en texte brut, le JSON, les journaux, les extraits de documentation ou les tests ; les exemples publics utilisent des identités et des domaines fictifs servant d'espaces réservés. La configuration matérialisée est destinée à être commitée et partagée ; elle ne transporte aucun identifiant.
• Le socle de refus universel. Le fichier settings.json de Claude Code qu'Apothem matérialise porte un socle de refus non négociable, quelle que soit la liste d'autorisation propre à un environnement ; sur les autres environnements, ce même socle est un texte de politique dans les règles matérialisées, et non une liste de refus au niveau des paramètres. Ce socle couvre les chemins de secrets (.env*, ~/.ssh/**, magasins d'identifiants), les opérations shell destructrices (rm -rf, sudo, force-pushes vers des branches protégées) et l'exécution d'entrées non fiables. Aucune liste d'autorisation n'élargit silencieusement ce socle.
• Rayon d'impact. Les écritures sont limitées aux répertoires des environnements et aux sous-arborescences de support détenues par Apothem. Les cibles gérées existantes sont sauvegardées avant remplacement, et les répertoires de découverte partagés sont fusionnés enfant par enfant, de sorte que les fichiers sans rapport rédigés par l'opérateur restent en place.

Posture de sécurité à l'exécutionCopy Anchor Link

Les commandes de cycle de vie des environnements et d'écriture de profil valident avant d'écrire. Les échecs de schéma de profil, les identifiants d'environnement inconnus, les chemins de projet non sûrs, les sources de manifeste manquantes, la traversée de cible et les franchissements de liens symboliques s'arrêtent avant les écritures sur le système de fichiers et renvoient des diagnostics structurés avec files_written: [].

Les opérations d'installation et de mise à jour préservent les cibles gérées existantes en les sauvegardant avant remplacement. Les répertoires de découverte partagés sont fusionnés enfant par enfant, de sorte que les fichiers sans rapport rédigés par l'opérateur restent en place. --dry-run effectue la même validation et signale les résultats prévus sans créer de répertoires ni de fichiers.

Les diagnostics du profil masquent les clés qui ressemblent à des secrets et les valeurs en forme de jeton avant qu'elles n'atteignent la sortie en texte brut, la sortie JSON, les journaux, les extraits de documentation ou les tests. Les exemples publics utilisent des identités et des domaines fictifs servant d'espaces réservés.

Liens rapidesCopy Anchor Link

• Posture OpenSSF Scorecard — preuves par contrôle et limites connues de la plateforme
• Audit des webhooks — preuves d'hygiène des secrets de webhook
• Protection de branche — exigence de pull request, vérifications de statut requises, et blocage des force-pushes et des suppressions
• Balayage des artefacts binaires — preuve que l'arborescence source ne contient aucun fichier binaire
• Politique de sécurité — signalement des vulnérabilités et versions prises en charge
• Badge OpenSSF Scorecard — score en direct

Signaler une vulnérabilitéCopy Anchor Link

Utilisez le signalement privé des vulnérabilités dans l'onglet Security du dépôt. La politique complète, la matrice des versions prises en charge et les délais de réponse se trouvent dans SECURITY.md.

Preuves de publication de la chaîne d'approvisionnementCopy Anchor Link

Chaque artefact de publication est livré avec :

• Provenance de build SLSA-3 via slsa-framework/slsa-github-generator
• Signatures Sigstore via sigstore/cosign-installer
• SBOM CycloneDX du wheel et du sdist livrés, écrit par scripts/release/generate_sbom.py : le paquet apothem, chaque paquet vendorisé sous apothem/_vendor avec sa licence, les exigences d'exécution déclarées et le SHA-256 de chaque distribution. Le SBOM est signé et couvert par la provenance de build, comme les distributions
• Déclarations de provenance npm via l'OIDC de Trusted Publishing sur @ahmed-g-gad/apothem
• Étiquettes git signées avec GPG (clé EDDSA 70396FED9C634163)

Vérifier une publicationCopy Anchor Link

Téléchargez toutes les ressources d'une publication dans un répertoire vide, puis vérifiez les signatures et la provenance de build. Remplacez vX.Y.Z et X.Y.Z par la publication que vous avez téléchargée.

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 affiche Verified OK et slsa-verifier affiche PASSED: SLSA verification passed. Répétez la commande cosign pour toute autre ressource avec son <asset>.cosign.bundle (les publications antérieures nomment les paquets de l'archive de plateforme et de SHA256SUMS <asset>.sig). Les archives darwin et linux sont les mêmes octets sous deux noms ; SHA256SUMS liste donc deux fois le même condensé. Depuis un clone, bash scripts/release/verify-provenance.sh <download-dir> exécute les trois vérifications, manifeste SHA256SUMS compris, en une seule passe.

Deux détails déterminent si la vérification a un sens :

• Casse du propriétaire. Les vérifications d'identité sont sensibles à la casse, et les certificats portent le propriétaire tel que GitHub le rapporte : Ahmed-G-Gad. Un propriétaire en minuscules fait échouer les deux outils.

• Identité exacte. Préférez --certificate-identity avec le sujet complet ci-dessus. Pour accepter n'importe quelle étiquette de publication, ancrez le motif à ses deux extrémités :

  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]+$'

  Un motif non ancré tel que github.com/Ahmed-G-Gad/apothem correspond aussi à un sujet falsifié qui se contente de contenir ce texte, par exemple un workflow dans un autre dépôt sur une branche nommée d'après celui-ci.

Le runbook du cycle de publication consigne les mêmes commandes comme vérification post-publication du mainteneur.

Recompiler une publication et comparerCopy Anchor Link

Le wheel et le sdist sont reproductibles : recompiler l'étiquette avec la chaîne d'outils de publication donne les condensés SHA-256 publiés. Utilisez Python 3.12 sous Linux, comme le fait la publication :

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/*

Comparez les condensés avec le wheel et le sdist publiés. La compilation utilise le setuptools verrouillé par hash que pyproject.toml épingle, et normalize_sdist.py retire du sdist l'heure de compilation, les propriétaires de fichiers et les horodatages du checkout.