Seguridad

La postura de seguridad de Apothem se basa en cinco pilares: endurecimiento de la cadena de suministro, respuesta a vulnerabilidades, protección de ramas, firma de lanzamientos y análisis de seguridad continuo. Esta sección documenta cada superficie.

Modelo de amenazasCopy Anchor Link

Apothem es un materializador de configuración. Lee un perfil compartido y escribe archivos de configuración nativos de cada entorno en los directorios que lee cada entorno. Esa única función delimita en qué confía y en qué no.

• En qué confía Apothem. El perfil compartido que redactas y el árbol de código fuente incluido que coloca el instalador. El perfil es tu intención declarada; el motor lo trata como entrada autoritativa después de la validación del esquema.
• En qué no confía Apothem. El contenido del perfil llega al sistema de archivos solo después de la validación: los fallos de esquema, los ID de entorno desconocidos, las rutas de proyecto inseguras, las fuentes de manifiesto ausentes, los recorridos fuera del destino y los cruces de enlaces simbólicos se detienen antes de cualquier escritura y devuelven diagnósticos estructurados con files_written: [].
• Lo que la salida materializada nunca lleva. Ningún secreto. Los diagnósticos del perfil ocultan las claves con apariencia de secreto y los valores con forma de token antes de que lleguen a la salida en texto plano, al JSON, a los registros, a los fragmentos de documentación o a las pruebas, y los ejemplos públicos usan identidades y dominios ficticios como marcadores de posición. La configuración materializada está pensada para incluirse en commits y compartirse; no lleva credenciales.
• El piso de denegación universal. El settings.json de Claude Code que Apothem materializa lleva un piso de denegación innegociable, con independencia de cualquier lista de permitidos por entorno; en los demás entornos, ese mismo piso es texto de política dentro de las reglas materializadas, no una lista de denegación a nivel de ajustes: rutas de secretos (.env*, ~/.ssh/**, almacenes de credenciales), operaciones de shell destructivas (rm -rf, sudo, force-pushes a ramas protegidas) y la ejecución de entradas no confiables. Ninguna lista de permitidos amplía silenciosamente este piso.
• Radio de impacto. Las escrituras se limitan a los directorios de los entornos y a los subárboles de soporte propiedad de Apothem. Los destinos gestionados existentes se respaldan antes de reemplazarse y los directorios de descubrimiento compartidos se fusionan hijo por hijo, de modo que los archivos no relacionados escritos por el operador permanecen en su lugar.

Postura de seguridad en tiempo de ejecuciónCopy Anchor Link

Los comandos de ciclo de vida de entornos y de escritura del perfil validan antes de escribir. Los fallos de esquema del perfil, los IDs de entorno desconocidos, las rutas de proyecto inseguras, las fuentes de manifiesto faltantes, los recorridos fuera del destino y los cruces de enlaces simbólicos se detienen antes de cualquier escritura en el sistema de archivos y devuelven diagnósticos estructurados con files_written: [].

Las operaciones de instalación y actualización preservan los destinos gestionados existentes respaldándolos antes de reemplazarlos. Los directorios de descubrimiento compartidos se fusionan hijo por hijo, de modo que los archivos no relacionados escritos por el operador permanecen en su lugar. --dry-run realiza la misma validación e informa los resultados previstos sin crear directorios ni archivos.

Los diagnósticos del perfil ocultan las claves con apariencia de secreto y los valores con forma de token antes de que lleguen a la salida en texto plano, a la salida JSON, a los registros, a los fragmentos de documentación o a las pruebas. Los ejemplos públicos usan identidades y dominios ficticios como marcadores de posición.

Enlaces rápidosCopy Anchor Link

• Postura de OpenSSF Scorecard — evidencia por comprobación y límites conocidos de la plataforma
• Auditoría de webhooks — evidencia de higiene de los secretos de webhook
• Protección de ramas — requisito de pull request, comprobaciones de estado obligatorias y bloqueo de force-pushes y eliminaciones
• Barrido de artefactos binarios — evidencia de que el árbol de código fuente no contiene archivos binarios
• Política de seguridad — notificación de vulnerabilidades y versiones admitidas
• Insignia de OpenSSF Scorecard — puntuación en vivo

Reportar una vulnerabilidadCopy Anchor Link

Usa el reporte privado de vulnerabilidades en la pestaña Security del repositorio. La política completa, la matriz de versiones admitidas y los plazos de respuesta están en SECURITY.md.

Evidencia de lanzamiento de la cadena de suministroCopy Anchor Link

Cada artefacto de lanzamiento se distribuye con:

• Procedencia de compilación SLSA-3 mediante slsa-framework/slsa-github-generator
• Firmas de Sigstore mediante sigstore/cosign-installer
• SBOM de CycloneDX del wheel y el sdist distribuidos, escrito por scripts/release/generate_sbom.py: el paquete apothem, cada paquete incorporado bajo apothem/_vendor con su licencia, los requisitos de tiempo de ejecución declarados y el SHA-256 de cada distribución. El SBOM está firmado y cubierto por la procedencia de compilación, igual que las distribuciones
• Declaraciones de procedencia de npm mediante OIDC de Trusted Publishing en @ahmed-g-gad/apothem
• Etiquetas de git firmadas con GPG (clave EDDSA 70396FED9C634163)

Verificar un lanzamientoCopy Anchor Link

Descarga todos los recursos de un lanzamiento en un directorio vacío y luego comprueba las firmas y la procedencia de compilación. Reemplaza vX.Y.Z y X.Y.Z por el lanzamiento que descargaste.

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 imprime Verified OK y slsa-verifier imprime PASSED: SLSA verification passed. Repite el comando cosign para cualquier otro recurso con su <asset>.cosign.bundle (en los lanzamientos anteriores, los bundles de los archivos comprimidos por plataforma y de SHA256SUMS se llaman <asset>.sig). Los archivos comprimidos de darwin y linux son los mismos bytes con dos nombres, por lo que SHA256SUMS lista un mismo digest dos veces. Desde un clon, bash scripts/release/verify-provenance.sh <download-dir> ejecuta las tres comprobaciones, incluido el manifiesto SHA256SUMS, en una sola pasada.

Dos detalles deciden si la verificación significa algo:

• Mayúsculas en el propietario. Las comprobaciones de identidad distinguen entre mayúsculas y minúsculas, y los certificados llevan el propietario tal como lo reporta GitHub: Ahmed-G-Gad. Un propietario en minúsculas hace fallar ambas herramientas.

• Identidad exacta. Prefiere --certificate-identity con el sujeto completo indicado arriba. Para aceptar cualquier etiqueta de lanzamiento, ancla el patrón en ambos extremos:

  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 patrón sin anclar como github.com/Ahmed-G-Gad/apothem también coincide con un sujeto falsificado que solo contiene ese texto, por ejemplo un flujo de trabajo de otro repositorio en una rama con el nombre de este.

El runbook del ciclo de lanzamiento recoge los mismos comandos como la comprobación posterior al lanzamiento del mantenedor.

Recompilar un lanzamiento y compararCopy Anchor Link

El wheel y el sdist son reproducibles: recompilar la etiqueta con la cadena de herramientas de lanzamiento produce los digests SHA-256 publicados. Usa Python 3.12 en Linux, como hace el lanzamiento:

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

Compara los digests con el wheel y el sdist publicados. La compilación usa el setuptools bloqueado por hash que fija pyproject.toml, y normalize_sdist.py elimina del sdist la hora de compilación, los propietarios de archivos y las marcas de tiempo del checkout.