D365 Audit

D365 Audit in Ihrer Deployment Pipeline

Integrieren Sie die Analysetools von D365 Audit direkt in Ihre Pipeline. Lassen Sie sich über neue Befunde informieren oder Ihre Pipeline abbrechen, wenn kritische Befunde auftauchen, etwa wenn Zugangsdaten unverschlüsselt übertragen würden, und erhalten Sie wertvolle Einblicke in die Veränderungen von Version zu Version.

Neuer API-Schlüssel

Wir schicken einen Link an die E-Mail-Adresse Ihres Abos. Er erzeugt einen neuen Schlüssel, der alte wird ungültig.

Pakete

Für Teams mit eigenen Lösungen

Pipeline-Abo Starter

79 € / Monat
netto, zzgl. 19 % MwSt. (94,01 € brutto), monatlich kündbar
10 Überprüfungen pro Monat, das entspricht 7,90 € je Überprüfung
BUILD-LOGJUNITSARIFEXCEL

Profitieren Sie von den Integrationsmöglichkeiten der Analyselösung D365 Audit. Sie erhalten alle Prüfergebnisse direkt in Ihrer Pipeline zur weiteren Verarbeitung. Behalten Sie Ihre Änderungen an Firmenlösungen im Blick und lassen Sie Deploymentvorgänge abbrechen, wenn kritische Schwellwerte überschritten sind oder Sicherheitsbedenken bestehen.

Was Sie bekommen

  • Jeder Build geprüft mit über 155 Regeln, denselben wie im Einmal-Report
  • Befunde direkt im Build-Log von Azure DevOps oder GitHub Actions, auf Wunsch als JUnit-Testergebnisse oder SARIF-Hinweise
  • Qualitätstor: Der Build bricht nur bei neuen Befunden ab der gewählten Schwere ab (Standard: hoch)
  • Vergleich mit dem letzten Lauf: neue und behobene Befunde je Projekt
  • Der erste Lauf warnt nur und legt die Ausgangsbasis fest, bestehende Befunde blockieren also nicht
  • Befundliste als Excel, 7 Tage über den Link im Log abrufbar
  • Beliebig viele Lösungen und Projekte je Publisher

Grenzen

  • 10 Überprüfungen pro Monat
  • 1 Publisher je Abo, festgelegt durch die ersten Läufe
  • Kein PDF- oder Word-Report und keine Flow-Dokumentation
  • .zip bis 60 MB, höchstens 30 Uploads je 10 Minuten
Starter
10 Überprüfungen pro MonatTeam
30 Überprüfungen pro MonatEnterprise
100 Überprüfungen pro Monat

Zahlungsabwicklung über Stripe. Sie haben die Möglichkeit Ihre USt-ID für die Rechnung im Checkout anzugeben.

Zwei Prüfungen · ohne Zahlungsdaten

Kostenlos testen

Überzeugen Sie sich selbst. Integrieren Sie unsere API in Ihre eigene Pipeline. Der Testschlüssel gilt für zwei Prüfungen und deaktiviert sich danach selbst.

Ihren API-Key erhalten Sie per Mail an die unten eingetragene Adresse. Pro Firmendomain und Lösungspublisher ist es möglich, unsere Schnittstelle einmalig ohne Kosten zu testen.

Testzugang anfordern

So funktioniert es

  1. Ihre Deployment Pipeline exportiert die Lösung wie bisher (Power Platform Build Tools oder pac solution export).
  2. Ein Befehl schickt das .zip zusammen mit Ihrem API-Schlüssel an die D365-Audit-API.
  3. Die Befunde erscheinen im Build-Log, auf Wunsch auch als Testergebnisse (JUnit) oder Code-Scanning-Hinweise (SARIF).

Sicherheit für IT-Admins
  • Kein nachgeladener Code. Die Pipeline ruft curl auf, das zum Agent gehört, und schickt eine HTTPS-Anfrage mit der .zip. Nichts von d365audit.de wird auf Ihrem Agent ausgeführt, die Antwort ist reiner Text fürs Log.
  • Aus der Pipeline geht nur der Lösungsexport raus, nie ein Zugriff auf Ihre Umgebung. Was gespeichert wird: Die hochgeladene Datei wird direkt nach der Analyse gelöscht, die Befundliste (Excel) bleibt 7 Tage abrufbar. Für die Bindung an Ihren Publisher (bei Enterprise an zwei) bleibt je Publisher nur ein Fingerabdruck seines Namens (SHA-256 mit dem Salz Ihres Kontos), bis 30 Tage nach Ende des Abos. Für den Vergleich mit dem letzten Lauf bleibt je Befund nur ein Fingerabdruck (SHA-256 über ein zufälliges Salz Ihres Kontos, Regel, Tabelle und Komponentenname), keine Namen und keine Inhalte. Die Fingerabdrücke bleiben 400 Tage gespeichert, die des jeweils letzten Laufs je Projekt als Vergleichsbasis für den nächsten Lauf bis 30 Tage nach Ende des Abos.
  • Der Schlüssel liegt bei uns nur als Hash. Erneuern jederzeit: Link per Mail oder POST /api/v1/keys/rotate; der alte Schlüssel ist sofort ungültig.
  • Link im Log. Wer das Build-Log lesen kann, kann die Befundliste (Excel) über den Link 7 Tage lang abrufen. JUnit, SARIF und Summary brauchen den API-Schlüssel.
  • Werte aus der Lösung schleusen keine Log-Befehle ein: Namen und Hinweise kommen ohne Zeilenumbrüche, „##“ und „::“.
  • Proxy: curl nutzt HTTPS_PROXY (und NO_PROXY) der Maschine oder --proxy in der Zeile. Freigeben: www.d365audit.de, Port 443.

Sie sind bereits Kunde oder haben Ihren Schlüssel verloren?

Ihr Abo können Sie hier im Stripe-Kundenportal verwalten (Anmeldung mit der E-Mail-Adresse Ihres Abos). Dort haben Sie Einblick in Ihre Rechnungen und Zahlungsmittel und können kündigen.

Sollten Sie einen neuen API-Schlüssel benötigen, können Sie ihn hier mit der E-Mail-Adresse Ihres Abos anfordern; der bisherige wird dabei ungültig.

Integration mit Azure DevOps

Für eine bestehende Pipeline, die die Lösung schon exportiert (Power Platform Build Tools oder pac CLI). Ein HTTPS-Aufruf mit curl, das auf jedem Agent schon da ist: ohne Erweiterung, ohne Skript, ohne nachgeladenen Code. Sie brauchen den API-Schlüssel aus dem Abo (Pakete oben).

  1. Schlüssel als geheime Variable anlegen. Pipeline bearbeiten → Variablen → Neue Variable, Name D365AUDIT_API_KEY, „Diesen Wert geheim halten“ anhaken.
  2. Schritt direkt hinter den Export setzen.
    - script: | curl --fail-with-body -sS -H "Authorization: Bearer $(D365AUDIT_API_KEY)" -F "file=@$(Build.ArtifactStagingDirectory)/MeineLoesung.zip" "https://www.d365audit.de/api/v1/scan?ci=azure" displayName: D365 Audit
  3. Pfad der .zip eintragen. Statt $(Build.ArtifactStagingDirectory)/MeineLoesung.zip denselben Pfad wie bei SolutionOutputFile Ihres Export-Schritts (PowerPlatformExportSolution@2), zum Beispiel $(Build.ArtifactStagingDirectory)/$(SolutionName).zip.

Was dann passiert

  • Der Schritt wartet auf die Analyse (meist wenige Sekunden) und schreibt das Ergebnis ins Build-Log: Zusammenfassung, Befunde und der Link zur Befundliste als Excel.
  • Erster Lauf: Die Befunde werden zur Ausgangsbasis. Der Build warnt nur (teilweise erfolgreich), er bricht nicht.
  • Danach bricht der Build nur bei NEUEN Befunden der Stufe hoch oder kritisch: Der Server antwortet mit HTTP 422, curl endet mit Exit-Code 22, der Schritt wird rot, die Befunde stehen im Log.
  • Läuft auf windows-latest (cmd.exe), ubuntu-latest und macos-latest (bash) und auf self-hosted Agents mit curl ab 7.76.
Optional: Befunde im Reiter „Tests“

Der Schritt D365 Audit setzt die Variable D365AUDIT_JUNIT_URL. Zwei weitere Schritte holen damit das JUnit-XML und veröffentlichen es:

- script: | curl --fail-with-body -sS --create-dirs -H "Authorization: Bearer $(D365AUDIT_API_KEY)" -o "$(Common.TestResultsDirectory)/d365audit.xml" "$(D365AUDIT_JUNIT_URL)" displayName: D365 Audit - JUnit condition: and(succeededOrFailed(), variables['D365AUDIT_JUNIT_URL']) - task: PublishTestResults@2 displayName: D365 Audit - Tests condition: and(succeededOrFailed(), variables['D365AUDIT_JUNIT_URL']) inputs: testResultsFormat: JUnit testResultsFiles: $(Common.TestResultsDirectory)/d365audit.xml testRunTitle: D365 Audit
Anpassen: Schwelle, Liste, Projektname

Als Parameter in der Adresse, zum Beispiel /api/v1/scan?ci=azure&threshold=medium&mode=delta

thresholdcritical, high (Standard), medium, low, none (nur berichten)
modeWelche Befunde im Log stehen, das Gate bleibt gleich: critical (Standard) = neue Befunde ab der Schwelle, also was den Build bricht; delta = neue und behobene Befunde seit dem letzten Lauf, alle Stufen; all = der gesamte Befund der aktuellen Version.
projectName für den Vergleich mit dem letzten Lauf (Standard: Lösungsname)
first_runfail = auch der erste Lauf bricht (Standard warn)
only_new0 = alle Befunde zählen fürs Gate, nicht nur neue
langen = englische Reports und Meldungen
Strenger: der Schlüssel nur als Umgebungsvariable

Azure DevOps setzt $(D365AUDIT_API_KEY) vor dem Start ins Skript ein und maskiert den Wert im Log, das ist dokumentiert und funktioniert. Microsoft empfiehlt, geheime Variablen stattdessen als Umgebungsvariable zu übergeben. Dann steht der Schlüssel nicht in der temporären Skriptdatei. Die Schreibweise unterscheidet sich zwischen cmd.exe und bash, deshalb je eine Zeile:

# Linux, macOS (bash) - script: | curl --fail-with-body -sS -H "Authorization: Bearer $D365AUDIT_API_KEY" -F "file=@$(Build.ArtifactStagingDirectory)/MeineLoesung.zip" "https://www.d365audit.de/api/v1/scan?ci=azure" displayName: D365 Audit env: D365AUDIT_API_KEY: $(D365AUDIT_API_KEY) # Windows (cmd.exe) - script: | curl --fail-with-body -sS -H "Authorization: Bearer %D365AUDIT_API_KEY%" -F "file=@$(Build.ArtifactStagingDirectory)/MeineLoesung.zip" "https://www.d365audit.de/api/v1/scan?ci=azure" displayName: D365 Audit env: D365AUDIT_API_KEY: $(D365AUDIT_API_KEY)

In beiden Varianten gibt die Shell den Schlüssel als Argument an curl weiter, solange der Schritt läuft. Auf Microsoft-gehosteten Agents bekommt jeder Job eine frische Maschine; auf geteilten self-hosted Agents können andere Prozesse derselben Maschine Befehlszeilen sehen.

Integration mit GitHub Actions

Den Schlüssel als Repository-Secret D365AUDIT_API_KEY hinterlegen und den Schritt hinter den Export setzen. Mit shell: bash läuft dieselbe Zeile auch auf Windows-Runnern.

- name: D365 Audit shell: bash run: | curl --fail-with-body -sS -H "Authorization: Bearer $D365AUDIT_API_KEY" -F "file=@out/MeineLoesung.zip" "https://www.d365audit.de/api/v1/scan?ci=github" env: D365AUDIT_API_KEY: ${{ secrets.D365AUDIT_API_KEY }}

Befunde erscheinen als Anmerkungen (::error:: und ::warning::); GitHub zeigt je Schritt die ersten 10 jeder Art, der Rest steht im Log.

Integration mit anderen CI-Systemen

Jedes System, das curl ausführen kann (GitLab CI, Jenkins, Bitbucket, TeamCity …). Ohne ci= enthält die Antwort keine Log-Befehle. Exit-Code 0 = Gate bestanden, 22 = Gate verletzt oder Fehler (der Text sagt, was).

curl --fail-with-body -sS -H "Authorization: Bearer $D365AUDIT_API_KEY" -F "file=@MeineLoesung.zip" "https://www.d365audit.de/api/v1/scan"

API-Dokumentation

Authorization: Bearer d365a_…

POST /api/v1/scan.zip im Feld file, Analyse im selben Aufruf, Text fürs Build-Log. Parameter ci (azure, github, plain), threshold, mode, project, first_run, only_new, lang. 200 = Gate bestanden, 422 = Gate verletzt.
POST /api/v1/analyses.zip hochladen (Feld file, optional project, lang). Antwort 202 mit id, danach abfragen.
GET /api/v1/analyses/<id>Stand und Ergebnis als JSON. Parameter threshold, only_new, first_run und mode (delta, critical, all; ohne mode die ganze Liste).
GET /api/v1/analyses/<id>/junitJUnit-XML
GET /api/v1/analyses/<id>/sarifSARIF 2.1.0
GET /api/v1/analyses/<id>/summaryMarkdown
GET /api/v1/accountPaket, Status, Kontingent
POST /api/v1/keys/rotateNeuer Schlüssel, der alte wird ungültig

Fehlerbehandlung

„Kein API-Schlüssel angekommen“ (HTTP 401)Die geheime Variable D365AUDIT_API_KEY fehlt oder der Name ist anders geschrieben.
HTTP 401Schlüssel unbekannt oder ersetzt: neuen Schlüssel anfordern
HTTP 402Abo nicht aktiv (Zahlung fehlgeschlagen oder gekündigt): Bitte überprüfen Sie Ihr Abo hier: Abo verwalten.
HTTP 429Überprüfungen des Monats aufgebraucht, ab dem 1. des Folgemonats (UTC) wieder verfügbar. Oder zu viele Uploads in 10 Minuten, die Meldung nennt die Wartezeit. Oder es läuft noch eine Überprüfung desselben Abos (scan_running); nach deren Ende erneut senden. Uploads, die wegen eines fremden Publishers oder ohne .zip abgelehnt werden, zählen nicht aufs Kontingent.
HTTP 422Kein Fehler: Das Quality Gate ist verletzt, die Befunde stehen im Log.
HTTP 400Keine .zip im Feld file, kein Lösungsexport oder ein Parameter falsch geschrieben; die Meldung sagt, was.
curl: (26) … readDie .zip liegt nicht unter dem Pfad: Der Schritt steht vor dem Export, oder der Pfad in der curl-Zeile weicht von SolutionOutputFile ab.
curl: option --fail-with-body: is unknowncurl älter als 7.76 (manche ältere self-hosted Agents). curl --version zeigt die Version; curl aktualisieren.
curl: (6) oder (7), Name oder VerbindungSelf-hosted Agent hinter Proxy oder Firewall: www.d365audit.de auf Port 443 freigeben. curl nutzt HTTPS_PROXY der Maschine; oder --proxy http://proxy:8080 in die Zeile schreiben.
Proxy mit Anmeldung (HTTP 407)--proxy-user "benutzer:passwort" in die Zeile, das Passwort am besten als geheime Variable, für den Proxy des Agents etwa --proxy "$(Agent.ProxyUrl)" --proxy-user "$(Agent.ProxyUsername):$(Agent.ProxyPassword)".
HTTP 504Die Analyse hat länger als 90 Sekunden gedauert. Sie läuft weiter, die Meldung nennt die Adresse des Ergebnisses.