Compliance module

The Compliance module aggregates the outputs of ArchPilot, ArchScan and ArchSecurity into a single compliance score and an audit-ready report.

Features

• Single compliance score - the module outputs are reduced to a single, comparable score.
• Audit-ready report - a shareable report you can hand directly to an auditor.
• Gap analysis - shows line by line which rules could not be passed.
• Your own policy rules - you define what compliance means.
• Tracking over time - follow how the score progresses across versions.

Limits

Monthly scan limits are applied according to your package. 5 scans/month on Trial; unlimited on paid plans.

Container images and package sources

Four rules read how the service is built and where its dependencies come from:

Rule	Passes when
BE_DOCKERFILE_NON_ROOT_USER	The image’s final stage runs as a user other than root - a USER line, one inherited from the stage it is built FROM, or a base image that is non-root by design (.NET chiseled, distroless nonroot). No USER at all means root.
BE_DOCKERFILE_APP_OWNED_BY_NON_ROOT	The application’s files are handed to that user in the final stage - COPY --chown= / ADD --chown= or RUN chown. A chown in a build stage does not reach the image.
BE_DOCKERFILE_BASE_IMAGE_ALLOWED	Every image the Dockerfile pulls comes from an allowed source. An image named by a build argument (FROM ${BASE_IMAGE}) is resolved from the pipeline, the templates it includes and the project’s CI/CD variables; one that cannot be resolved is skipped, never failed.
DEP_NUGET_SOURCES_ALLOWED	.NET only: every package source in the root nuget.config is an allowed feed. Without <clear/> the machine’s nuget.org still applies, and that is reported with the fix.

Allowed sources are set once for the installation (Administration → Settings → Policies → Allowed sources) and every workspace can add its own (Workspace settings → Allowed sources); a rule accepts a source on either list. An entry is a registry host or path (registry.example.com, everything under it) or a feed URL; * stands for any run of characters (registry.example.com/*, *.example.com/*, harbor.example.com/base/*:10.*) - it is not a regular expression. While no source of a kind is listed, its rule is skipped.

Private repositories

Seven rules speak to people outside the company - DOC_LICENSE_EXISTS, DOC_LICENSE_SPDX_RECOGNIZED, DOC_CONTRIBUTING_EXISTS, DOC_CODE_OF_CONDUCT_EXISTS, SEC_POLICY_EXISTS, DOC_README_HAS_BADGES and REPO_HAS_TOPICS. On a private repository (GitLab private or internal) they are off by default and show as skipped. Switch one on for the project, the workspace or the installation and it runs anyway.

Other rules now read the repository wherever the file is: a local docker-compose file under a sub-folder (infra/docker/) counts, and .env.example is asked only of stacks that configure through .env files (Node.js, Python, Ruby, PHP, Go), not of .NET or Java.

ISO 27001

AppArch maps ISO/IEC 27001:2022 Annex A to the evidence it already produces: Compliance rules, Git Health rules and ArchSecurity weakness classes (CWE), each marked direct or partial.

• Scan with a framework - on Rules → Compliance rules and Git Health rules, Only ISO 27001 rules switches the workspace to exactly the mapped rules; Back to default rules undoes it. The switches stay editable rule by rule, and project-level settings are kept. Administrators can apply the same profile to the installation defaults (Administration → Settings → Rules).
• ISO 27001 technical evidence (Compliance → ISO 27001 evidence) - every control with what the latest scans say about it: passing, failing, no evidence yet, or not measurable from code. Most controls are organisational, people or physical measures; they are listed apart. The report is technical evidence, not a certification.

Manual checks

Some checks no scan can make - an access review, a restore test, signed confidentiality agreements. Write them as your own rules under Rules → Manual checks, or import the list you already keep as CSV (a template is on the import page; columns code, title, description, category, severity, recheck_days, iso_controls, enabled, comma or semicolon separated). An import matches rules by code and saves all or nothing.

• Switch a rule on for the workspace or per project, like any other compliance rule.
• On a project’s manual-check page a person records passed or failed, with a note. Every decision keeps who made it and when; a correction is a new decision, never an edit.
• With re-check days set, a passed decision becomes re-check due when the period runs out.
• Name ISO 27001 controls on the rule and the ISO 27001 report counts the decisions as evidence for them - the way people and physical controls get evidence at all.
• Manual checks do not change the compliance score. Each rule’s decisions across projects can be downloaded as CSV; a deleted rule that has decisions is archived with its history.

Retired rules

These rules no longer run. Findings from earlier scans stay in the history; the rule that answers the same question now is listed beside each one.

Rule	Replaced by	Why
SEC_BRANCH_PROTECTION	Git Health GIT_DEFAULT_BRANCH_PROTECTED	Branch protection is a Git provider setting; Git Health reads it, and its force-push and direct-push rules build on it.
SEC_NO_ENV_AT_ROOT	Git Health REPO_SECRET_FILE_COMMITTED	The Git Health rule searches the whole repository for .env files, private keys and production settings, not only the root.
INT_ARCHPILOT_ENABLED, INT_ARCHSCAN_ENABLED	-	Modules are no longer switched on per project, so there is nothing to check.