Módulo de cumplimiento

El módulo de cumplimiento agrega los resultados de ArchPilot, ArchScan y ArchSecurity en una única puntuación de cumplimiento y un informe listo para auditoría.

Características

Puntuación de cumplimiento única - los resultados de los módulos se reducen a una única puntuación comparable.
Informe listo para auditoría - un informe compartible que puedes entregar directamente a un auditor.
Análisis de brechas - muestra línea por línea qué reglas no se pudieron superar.
Tus propias reglas de política - defines qué significa el cumplimiento.
Seguimiento a lo largo del tiempo - observa cómo evoluciona la puntuación entre versiones.

Límites

Se aplican límites mensuales de escaneo según tu paquete. 5 escaneos al mes en el plan Trial; ilimitados en los planes de pago.

Imágenes de contenedor y fuentes de paquetes

Cuatro reglas leen cómo se construye el servicio y de dónde vienen sus dependencias:

Regla	Se cumple cuando
`BE_DOCKERFILE_NON_ROOT_USER`	La etapa final de la imagen se ejecuta con un usuario distinto de root: una línea `USER`, uno heredado de la etapa desde la que se construye con `FROM`, o una imagen base que no es root por diseño (.NET chiseled, distroless nonroot). Sin ningún `USER` se entiende root.
`BE_DOCKERFILE_APP_OWNED_BY_NON_ROOT`	Los archivos de la aplicación se entregan a ese usuario en la etapa final: `COPY --chown=` / `ADD --chown=` o `RUN chown`. Un `chown` en una etapa de build no llega a la imagen.
`BE_DOCKERFILE_BASE_IMAGE_ALLOWED`	Cada imagen que descarga el Dockerfile viene de una fuente permitida. Una imagen nombrada por un argumento de build (`FROM ${BASE_IMAGE}`) se resuelve desde el pipeline, las plantillas que incluye y las variables CI/CD del proyecto; la que no se puede resolver se omite, nunca falla.
`DEP_NUGET_SOURCES_ALLOWED`	Solo .NET: cada fuente de paquetes del `nuget.config` raíz es un feed permitido. Sin `<clear/>` el `nuget.org` de la máquina sigue aplicándose, y se informa con la corrección.

Las fuentes permitidas se definen una vez para la instalación (Administración → Ajustes → Políticas → Fuentes permitidas) y cada espacio de trabajo puede añadir las suyas (Ajustes del espacio de trabajo → Fuentes permitidas); una regla acepta una fuente de cualquiera de las dos listas. Una entrada es un host o ruta de registro (registry.example.com, todo lo que cuelga de él) o una URL de feed; * representa cualquier secuencia de caracteres (registry.example.com/*, *.example.com/*, harbor.example.com/base/*:10.*); no es una expresión regular. Mientras no haya ninguna fuente de un tipo, su regla se omite.

Repositorios privados

Siete reglas se dirigen a personas ajenas a la empresa: DOC_LICENSE_EXISTS, DOC_LICENSE_SPDX_RECOGNIZED, DOC_CONTRIBUTING_EXISTS, DOC_CODE_OF_CONDUCT_EXISTS, SEC_POLICY_EXISTS, DOC_README_HAS_BADGES y REPO_HAS_TOPICS. En un repositorio privado (GitLab private o internal) están desactivadas por defecto y aparecen como omitidas. Activadas para el proyecto, el espacio de trabajo o la instalación, se ejecutan igualmente.

Otras reglas leen ahora el archivo donde esté: un docker-compose local en una subcarpeta (infra/docker/) cuenta, y .env.example solo se pide a los stacks que se configuran con archivos .env (Node.js, Python, Ruby, PHP, Go), no a .NET ni a Java.

ISO 27001

AppArch asigna el Anexo A de ISO/IEC 27001:2022 a la evidencia que ya produce: reglas de Compliance, reglas de Git Health y clases de debilidad de ArchSecurity (CWE), cada una marcada como directa o parcial.

Escanear con un marco - en Reglas → Reglas de Compliance y Reglas de Git Health, Solo reglas ISO 27001 deja el workspace exactamente con las reglas asignadas; Volver a las reglas predeterminadas lo deshace. Los interruptores siguen editables regla a regla y se conservan los ajustes de proyecto. Los administradores pueden aplicar el mismo perfil a los valores predeterminados de la instalación (Administración → Ajustes → Reglas).
Evidencia técnica ISO 27001 (Compliance → Evidencia ISO 27001) - cada control con lo que dicen los últimos escaneos: cumple, no cumple, aún sin evidencia o no medible desde el código. La mayoría de los controles son organizativos, de personas o físicos y se listan aparte. El informe es evidencia técnica, no una certificación.

Comprobaciones manuales

Algunas comprobaciones no las puede hacer ningún escaneo: una revisión de accesos, una prueba de restauración, acuerdos de confidencialidad firmados. Escríbalas como reglas propias en Reglas → Comprobaciones manuales o importe la lista que ya tiene como CSV (hay una plantilla en la página de importación; columnas code, title, description, category, severity, recheck_days, iso_controls, enabled, separadas por coma o punto y coma). La importación empareja las reglas por código y guarda todo o nada.

Active una regla para el workspace o por proyecto, como cualquier otra regla de Compliance.
En la página de comprobaciones manuales de un proyecto, una persona registra superada o no superada, con una nota. Cada decisión guarda quién la tomó y cuándo; una corrección es una decisión nueva, nunca una edición.
Con días de revisión, una decisión superada pasa a revisión pendiente cuando vence el plazo.
Indique controles ISO 27001 en la regla y el informe ISO 27001 cuenta las decisiones como evidencia para ellos; así obtienen evidencia los controles de personas y físicos.
Las comprobaciones manuales no cambian la puntuación de Compliance. Las decisiones de cada regla en todos los proyectos se pueden descargar como CSV; una regla eliminada que tiene decisiones se archiva con su historial.

Reglas retiradas

Estas reglas ya no se ejecutan. Los hallazgos de escaneos anteriores quedan en el historial; junto a cada una figura la regla que responde ahora a la misma pregunta.

Regla	Sustituida por	Motivo
`SEC_BRANCH_PROTECTION`	Git Health `GIT_DEFAULT_BRANCH_PROTECTED`	La protección de rama es una configuración del proveedor Git; la lee Git Health, y sus reglas de force push y push directo se apoyan en ella.
`SEC_NO_ENV_AT_ROOT`	Git Health `REPO_SECRET_FILE_COMMITTED`	La regla de Git Health busca archivos .env, claves privadas y configuraciones de producción en todo el repositorio, no solo en la raíz.
`INT_ARCHPILOT_ENABLED`, `INT_ARCHSCAN_ENABLED`	-	Los módulos ya no se activan por proyecto, así que no queda nada que comprobar.