Git-Plattformen
Repositories, Merge Requests und Mitglieder kommen von hier. Verbindung per Access Token oder OAuth-App; selbst gehostetes GitLab funktioniert auch.
Architekturprüfung bei jedem Pull Request, auf Ihren eigenen Servern.
AppArch liest die Struktur Ihrer Codebasis - Schichten, Abhängigkeiten, Verträge - und kommentiert den Pull Request, sobald er geöffnet wird. Es läuft in Ihrer CI und in Ihrem Netz. Nichts verlässt es.
- On-Premises installiert
- 9 Sprachen
- GitLab, GitHub, Bitbucket, Azure DevOps
9Sprachen: Sprachen: .NET, Java, Python, Go, TypeScript, Ruby, PHP, Kotlin, Swift
1000+Regeln: Regeln im Katalog, jede mit Dokumentationsseite
4Git-Plattformen: Git-Plattformen
5Module: Module auf einem Codegraphen
<2 minpro Review: pro Review: unter 2 Minuten, gemessen an einem 5-GB-Repository
4Sicherheits-Frameworks: Sicherheitsrahmen: OWASP, PCI DSS, STIG, CASA
Fünf Module, eine Lesart Ihres Codes
Jedes Modul beantwortet eine andere Frage zum selben Repository. Schalten Sie ein, was Sie brauchen; Regelkatalog und Abhängigkeitsgraph sind gemeinsam.
ArchPilot
Review-Kommentare im Pull Request
- Inline-Kommentare mit Regelcode und Link zur Dokumentation
- Ein Zusammenfassungskommentar pro Merge Request: neu, offen, gelöst
ArchScan
Ein vollständiger Bericht für die gesamte Codebasis
- Jeder Befund zeigt die betroffenen Zeilen, nicht nur einen Dateinamen
- Eine interaktive Abhängigkeitskarte von Projekten und Paketen
ArchSecurity
Statische Sicherheitsanalyse, zugeordnet zu den Rahmenwerken der Auditoren
- Ein Bericht je Rahmenwerk, auditbereit
- Verwundbare Abhängigkeiten gegen einen Offline-Advisory-Satz geprüft
Compliance
Richtlinienprüfungen mit Score und Prüfpfad
- Regeln je Projekt, je Workspace oder für die ganze Installation
- Geplante Scans, damit der Score aktuell bleibt, ohne dass jemand daran denken muss
Git Health
29 Prüfungen, wie das Repository geführt wird
- Branch-Schutz, Merge-Request-Regeln, Sicherheitstools in der CI
- Befunde tragen einen Wert, nicht nur bestanden oder nicht
Womit anfangen?
Die meisten Teams beginnen mit ArchPilot: Der erste Kommentar kommt mit dem nächsten Pull Request.
Wie ein Befund Ihren Pull Request erreicht
Drei Schritte, kein Agent auf dem Entwicklerrechner, nichts, das nach Hause telefoniert.
- 01
Repository registrieren
Verbinden Sie im Panel eine Git-Anmeldung und wählen Sie das Repository. AppArch stellt dafür ein Projekt-Token aus.
- 02
Fügen Sie einen Job zur Pipeline hinzu
Ein Container-Image je Sprache läuft als CI-Job auf dem ausgecheckten Code. Es holt die Regeln, analysiert vor Ort und sendet nur die Ergebnisse.
- 03
Kommentar lesen, Bericht öffnen
Der Entwickler sieht den Befund im Pull Request; das Team sieht Score, Trend und Befunde im Panel.
Regeln werden im Panel verwaltet, nicht in einer Datei
Jede Regel im Katalog hat Code, Namen, Beschreibung und Dokumentationsseite. Schalten Sie eine Regel für die ganze Installation, einen Workspace oder ein Projekt ab; die engere Einstellung gewinnt.
- Die Schwelle, die eine Pipeline scheitern lässt, ist eine Einstellung, keine Codeänderung.
- Der Scan-Umfang - welche Ordner zählen - wird an derselben Stelle festgelegt.
- Jede Regel hat eine eigene Dokumentationsseite auf docs.apparch.io.
Gebaut für den Betrieb in Ihrem Netz
Es gibt keine gehostete Version. AppArch wird auf einem Host installiert, den Sie kontrollieren, und der gelesene Code verlässt Ihre CI nie.
Installation auf einem Host
Docker Compose mit PostgreSQL und Redis. Ein Einrichtungsassistent legt den ersten Administrator an; Upgrades führen ihre Migrationen selbst aus.
Anmeldung mit Ihrem Verzeichnis
Anmeldung über LDAP und Active Directory, Zwei-Faktor-Authentifizierung, Einladung nach Domain. Kein Social Login.
Signierte Lizenz, bei Bedarf offline
Die Lizenz ist eine signierte Datei, die die Installation lokal prüft. Abgeschottete Standorte beziehen Images aus einer privaten Registry und rufen nie nach außen.
Keine Nutzungsdaten verlassen das Netz
Der einzige ausgehende Aufruf ist die optionale Update-Prüfung, und die lässt sich abschalten. Alles andere bleibt auf Ihrem Host.
Womit es sich verbindet
Git-Plattformen liefern Repositories und Merge Requests; der Rest ergänzt Deployments, Incidents, Tickets und KI drumherum.
CI-Pipelines
Der Analyzer läuft als ein Job in Ihrer eigenen Pipeline: fertige Snippets für vier Anbieter, ein einfaches docker run für den Rest.
Deployment
Welche Version in welcher Umgebung läuft, wird in den Service-Katalog geschrieben.
Observability
Mit Dynatrace, New Relic oder Percona PMM fließen Incident-Daten ein, und die zwei leeren DORA-Metriken, Change Failure Rate und Wiederherstellungszeit, füllen sich aus echten Daten. Percona PMM liefert zusätzlich Datenbank-Abfragezeiten.
Qualität und Tests
SonarQube-Messwerte und -Befunde stehen neben denen von AppArch; JMeter-Testzusammenfassungen landen auf der Performance-Test-Seite des Projekts.
KI
Der Betreiber der Installation verbindet einen Anbieter; Anfragen laufen über dieses Konto, nichts geht über AppArch.
Issue-Tracking
Befunde werden als Vorgänge auf dem Board angelegt, das Ihr Team ohnehin nutzt. Die Projektzuordnung erfolgt pro Workspace.
Anmeldung und Benachrichtigungen
Anmeldung mit dem LDAP- oder Active-Directory-Konto; Benachrichtigungen gehen per E-Mail über Ihren eigenen SMTP-Server. Slack- und Teams-Kanäle sind unterwegs.
Was leistet ein Architektur-Review-Werkzeug?
Eine Codebasis besteht aus Hunderten kleiner Entscheidungen, die einzeln richtig aussehen: welche Schicht welche aufruft, wann ein Servicevertrag gebrochen wurde, mit welcher Änderung eine Sicherheitsprüfung wegfiel. Code-Reviews sehen diese Entscheidungen, ermüden aber mit der Zeit; niemand schreibt dieselbe Warnung in jedem Pull Request von Hand.
Ein Architektur-Review-Werkzeug macht aus diesen Entscheidungen Regeln und wendet sie automatisch auf jede Änderung an. Der Entwickler sieht den Befund im eigenen Pull Request, die Teamleitung verfolgt den Trend im Panel, und das Sicherheitsteam erhält den Compliance-Bericht aus demselben Scan.
Der Unterschied zu einem Linter oder einer Code-Qualitätsplattform
Ein Linter betrachtet eine Datei nach der anderen. AppArch liest den Abhängigkeitsgraphen des gesamten Repositorys und kann deshalb sagen, dass ein Präsentationsprojekt auf die Infrastruktur verweist oder dass zwei Module voneinander abhängen. Befunde externer Scanner erscheinen im selben Panel, mit ihrer Quelle gekennzeichnet.
Worauf man bei der Auswahl achten sollte
- Verlässt der Code Ihr Netzwerk? Ein Werkzeug, das On-Premises läuft, hält den Code in Ihrem eigenen Netzwerk.
- Wem gehören die Regeln? Regeln in einem Panel statt in einer Datei zu verwalten, hält das ganze Team einheitlich.
- Schreibt es in den Pull Request? Berichte bleiben ungelesen; ein Inline-Kommentar wird gelesen.
Einzelheiten finden Sie auf den Seiten ArchPilot, On-Premise & Air-Gap und Regelkatalog.
Häufige Fragen
Was unterscheidet das von einem Linter oder SonarQube?
Ein Linter betrachtet eine Datei. AppArch liest den Abhängigkeitsgraphen des gesamten Repositorys und kann so sagen, dass ein Präsentationsprojekt auf Infrastruktur verweist oder zwei Module voneinander abhängen. SonarQube-Befunde können in ArchSecurity neben AppArchs eigenen gespiegelt werden, nach Quelle gekennzeichnet.
Welche Sprachen werden unterstützt?
.NET, Java, Python, Go, TypeScript und JavaScript (inklusive React, React Native und Node.js), Ruby, Kotlin, Swift und PHP. Jede hat ein eigenes Analyse-Image und einen eigenen Teil des Regelkatalogs.
Verlässt unser Code unser Netz?
Nein. Der Analyzer läuft als Job in Ihrer eigenen CI auf dem ausgecheckten Code und sendet nur Befunde an den AppArch-Server - der ebenfalls Ihrer ist. Kein gehosteter Dienst liegt dazwischen.
Was ist mit Fehlalarmen?
Schalten Sie die Regel für das Projekt, den Workspace oder die ganze Installation ab, oder verengen Sie den Scan-Umfang, damit der Ordner übersprungen wird. Befunde lassen sich im Panel bestätigen, und der Schweregrad einer Regel kann gesenkt werden, sodass sie die Pipeline nicht mehr scheitern lässt.
Wie wird lizenziert?
Pro Installation, mit einer signierten Lizenzdatei, die Benutzer und Projekte festlegt; alle Module sind enthalten. Keine Abrechnung pro Scan, keine gehostete Stufe. Kontaktieren Sie uns, wir dimensionieren es gemeinsam.
Wie lange dauert die Installation?
Ein Host mit Docker: Images ziehen, Compose-Datei starten, Einrichtungsassistent durchlaufen. Das erste Repository registrieren und den CI-Job hinzufügen dauert meist denselben Nachmittag.
Sehen Sie es an Ihrem eigenen Code
Buchen Sie eine dreißigminütige Demo. Wir gehen das Panel an einem echten Repository durch und beantworten die Fragen Ihres Teams.