Compliance-Modul

Das Compliance-Modul bündelt die Ausgaben von ArchPilot, ArchScan und ArchSecurity zu einem einzigen Compliance-Score und einem prüfungsbereiten Bericht.

Funktionen

• Einziger Compliance-Score - die Modulausgaben werden zu einem einzigen, vergleichbaren Score zusammengefasst.
• Prüfungsbereiter Bericht - ein teilbarer Bericht, den Sie direkt einem Prüfer übergeben können.
• Lückenanalyse - zeigt Zeile für Zeile, welche Regeln nicht erfüllt werden konnten.
• Ihre eigenen Richtlinienregeln - Sie definieren, was Compliance bedeutet.
• Verfolgung im Zeitverlauf - verfolgen Sie, wie sich der Score über die Versionen hinweg entwickelt.

Limits

Monatliche Scan-Limits werden je nach Ihrem Paket angewendet. 5 Scans/Monat im Trial; unbegrenzt in den kostenpflichtigen Plänen.

Container-Images und Paketquellen

Vier Regeln lesen, wie der Dienst gebaut wird und woher seine Abhängigkeiten kommen:

Regel	Besteht, wenn
BE_DOCKERFILE_NON_ROOT_USER	Die letzte Stufe des Images als anderer Benutzer als root läuft - eine USER-Zeile, ein Benutzer aus der Stufe, von der sie per FROM gebaut wird, oder ein Basis-Image, das per Design nicht root ist (.NET chiseled, distroless nonroot). Gar kein USER bedeutet root.
BE_DOCKERFILE_APP_OWNED_BY_NON_ROOT	Die Dateien der Anwendung in der letzten Stufe diesem Benutzer übergeben werden - COPY --chown= / ADD --chown= oder RUN chown. Ein chown in einer Build-Stufe erreicht das Image nicht.
BE_DOCKERFILE_BASE_IMAGE_ALLOWED	Jedes Image, das das Dockerfile zieht, aus einer erlaubten Quelle kommt. Ein über ein Build-Argument benanntes Image (FROM ${BASE_IMAGE}) wird aus der Pipeline, den eingebundenen Vorlagen und den CI/CD-Variablen des Projekts aufgelöst; ein nicht auflösbares wird übersprungen, nie als Fehler gewertet.
DEP_NUGET_SOURCES_ALLOWED	Nur .NET: jede Paketquelle in der nuget.config im Wurzelverzeichnis ist ein erlaubter Feed. Ohne <clear/> gilt das nuget.org der Maschine weiter; das wird mit der Korrektur gemeldet.

Erlaubte Quellen werden einmal für die Installation festgelegt (Administration → Einstellungen → Richtlinien → Erlaubte Quellen), und jeder Workspace kann eigene hinzufügen (Workspace-Einstellungen → Erlaubte Quellen); eine Regel akzeptiert eine Quelle aus beiden Listen. Ein Eintrag ist ein Registry-Host oder -Pfad (registry.example.com, alles darunter) oder eine Feed-URL; * steht für eine beliebige Zeichenfolge (registry.example.com/*, *.example.com/*, harbor.example.com/base/*:10.*) - kein regulärer Ausdruck. Solange keine Quelle einer Art eingetragen ist, wird ihre Regel übersprungen.

Private Repositories

Sieben Regeln richten sich an Menschen außerhalb des Unternehmens - DOC_LICENSE_EXISTS, DOC_LICENSE_SPDX_RECOGNIZED, DOC_CONTRIBUTING_EXISTS, DOC_CODE_OF_CONDUCT_EXISTS, SEC_POLICY_EXISTS, DOC_README_HAS_BADGES und REPO_HAS_TOPICS. In einem privaten Repository (GitLab private oder internal) sind sie standardmäßig aus und erscheinen als übersprungen. Für das Projekt, den Workspace oder die Installation eingeschaltet, laufen sie trotzdem.

Andere Regeln lesen das Repository jetzt dort, wo die Datei liegt: eine lokale docker-compose-Datei in einem Unterordner (infra/docker/) zählt, und .env.example wird nur bei Stacks verlangt, die über .env-Dateien konfiguriert werden (Node.js, Python, Ruby, PHP, Go), nicht bei .NET oder Java.

ISO 27001

AppArch ordnet ISO/IEC 27001:2022 Anhang A den Nachweisen zu, die es ohnehin erzeugt: Compliance-Regeln, Git-Health-Regeln und ArchSecurity-Schwachstellenklassen (CWE), jeweils als direkt oder teilweise gekennzeichnet.

• Mit einem Framework scannen - unter Regeln → Compliance-Regeln und Git-Health-Regeln schaltet Nur ISO-27001-Regeln den Workspace genau auf die zugeordneten Regeln um; Zurück zu den Standardregeln macht es rückgängig. Die Schalter bleiben einzeln änderbar, Projekteinstellungen bleiben erhalten. Administratoren können dasselbe Profil auf die Installationsvorgaben anwenden (Administration → Einstellungen → Regeln).
• ISO 27001 - technische Nachweise (Compliance → ISO-27001-Nachweise) - jede Maßnahme mit dem, was die letzten Scans dazu sagen: erfüllt, nicht erfüllt, noch kein Nachweis oder aus Code nicht messbar. Die meisten Maßnahmen sind organisatorisch, personell oder physisch und werden getrennt aufgeführt. Der Bericht ist ein technischer Nachweis, keine Zertifizierung.

Manuelle Prüfungen

Manche Prüfungen kann kein Scan leisten - eine Zugriffsüberprüfung, ein Wiederherstellungstest, unterschriebene Vertraulichkeitsvereinbarungen. Legen Sie sie unter Regeln → Manuelle Prüfungen als eigene Regeln an oder importieren Sie Ihre vorhandene Liste als CSV (eine Vorlage liegt auf der Importseite; Spalten code, title, description, category, severity, recheck_days, iso_controls, enabled, durch Komma oder Semikolon getrennt). Der Import ordnet Regeln über den Code zu und speichert alles oder nichts.

• Schalten Sie eine Regel wie jede andere Compliance-Regel für den Workspace oder pro Projekt ein.
• Auf der Seite der manuellen Prüfungen eines Projekts hält eine Person bestanden oder nicht bestanden fest, mit Notiz. Jede Entscheidung speichert, wer sie wann getroffen hat; eine Korrektur ist eine neue Entscheidung, nie eine Änderung.
• Mit Wiederholungsintervall (Tage) wird eine bestandene Entscheidung nach Ablauf zu erneute Prüfung fällig.
• Nennen Sie ISO-27001-Maßnahmen an der Regel, dann zählt der ISO-27001-Bericht die Entscheidungen als Nachweis dafür - nur so erhalten personelle und physische Maßnahmen überhaupt Nachweise.
• Manuelle Prüfungen ändern den Compliance-Score nicht. Die Entscheidungen einer Regel über alle Projekte lassen sich als CSV herunterladen; eine gelöschte Regel mit Entscheidungen wird samt Verlauf archiviert.

Stillgelegte Regeln

Diese Regeln laufen nicht mehr. Befunde früherer Scans bleiben in der Historie; daneben steht, welche Regel dieselbe Frage jetzt beantwortet.

Regel	Ersetzt durch	Grund
SEC_BRANCH_PROTECTION	Git Health GIT_DEFAULT_BRANCH_PROTECTED	Branch-Schutz ist eine Einstellung des Git-Providers; Git Health liest sie, und seine Force-Push- und Direkt-Push-Regeln bauen darauf auf.
SEC_NO_ENV_AT_ROOT	Git Health REPO_SECRET_FILE_COMMITTED	Die Git-Health-Regel sucht im ganzen Repository nach .env-Dateien, privaten Schlüsseln und Produktionseinstellungen, nicht nur im Wurzelverzeichnis.
INT_ARCHPILOT_ENABLED, INT_ARCHSCAN_ENABLED	-	Module werden nicht mehr pro Projekt eingeschaltet, es gibt nichts mehr zu prüfen.