AmicusProof

Prüfkatalog AP-26 · Version 1.0

Unser Prüfstandard

Unser Prüfstandard ist öffentlich. Jeder soll nachvollziehen können, wie eine Note entsteht.

Warum AmicusProof?

„Amicus curiae“ ist Latein und heißt „Freund des Gerichts“. So nennt man eine neutrale Stelle, die ein Gericht unterstützt, ohne selbst Partei zu sein: Sie hat kein eigenes Interesse am Ausgang, nur an der Sache.

Genau so verstehen wir unsere Rolle. Wir haben deinen Code nicht geschrieben und verkaufen dir kein Werkzeug. „Proof“ steht für den Nachweis – und dafür, dass deine App danach abgesichert ist.

Sechs Prüfprinzipien

  1. 01

    Unabhängig

    Wir prüfen nur, wir bauen nicht. So haben wir keinen Grund, eigene Fehler zu übersehen.

  2. 02

    Auf deiner Seite

    Funde gehören dir, nicht der Öffentlichkeit. Das Siegel zeigst du nur, wenn du willst.

  3. 03

    Nachvollziehbar

    Jede Note folgt festen, öffentlichen Regeln. Du kannst jeden Abzug selbst nachrechnen.

  4. 04

    Dokumentiert

    Jede Prüfung endet in einem Protokoll mit Fundstelle und Beleg. Das hilft dir, deinen Kunden und Behörden.

  5. 05

    Datensparsam

    Wir verarbeiten nur, was wir für die Prüfung brauchen. Code wird danach gelöscht, kein KI-Training.

  6. 06

    Klartext

    Wir erklären Funde so, dass man sie ohne Informatikstudium versteht. Und zu jedem Fund gibt es eine Lösung.

Prüfkatalog AP-26

BereichWas geprüft wirdTypische Funde bei KI-CodeGewicht
AZugang & RechteAnmeldung, Rollen, Zugriffsregeln in der Datenbank (RLS), geschützte Seiten und Funktionen.Tabellen ohne RLS, Admin-Seiten nur im Frontend geschützt, Rollen im Profil statt in eigener Tabelle.25 %
BGeheimnisse & SchlüsselAPI-Schlüssel, Passwörter und Tokens in Code, Konfiguration und ausgelieferten Dateien.Secret Keys im Frontend-Bundle, öffentlich abrufbare .env-Datei, Schlüssel im Git-Verlauf.15 %
CEingaben & AngriffeUmgang mit Benutzereingaben: Validierung, Injection, XSS, Rate Limits.Validierung nur im Browser, ungefiltertes HTML, Formulare ohne Limit.20 %
DAbhängigkeiten & LieferketteEingebundene Pakete, bekannte Schwachstellen (CVEs), Herkunft und Aktualität.Veraltete Pakete mit bekannten Lücken, ungenutzte Abhängigkeiten, erfundene Paketnamen.15 %
EKonfiguration & BetriebHTTPS, Security-Header, Cookies, Fehlermeldungen, öffentlich erreichbare Dateien.Fehlende CSP und HSTS, Stacktraces in Fehlermeldungen, offener .git-Ordner.10 %
FDatenschutz & Recht DEDSGVO, Impressum, Einwilligung, Datenflüsse in Drittländer.Google Fonts und US-Tracker ohne Einwilligung, fehlendes Impressum, keine Löschfristen.15 %

Notenlogik

Jeder Bereich bekommt eine Note von 1,0 bis 5,0. Die Gesamtnote ist der gewichtete Mittelwert – wie bei Schulnoten oder im Warentest gilt: 1,0 ist die beste Note.

NoteBewertungBedingung
1,0 – 1,5sehr gutKeine kritischen oder hohen Funde, höchstens vereinzelte niedrige.
1,6 – 2,5gutKeine kritischen Funde, wenige mittlere oder einzelne hohe mit geringem Risiko.
2,6 – 3,5befriedigendKeine kritischen Funde, mehrere hohe oder viele mittlere.
3,6 – 4,5ausreichendErhebliche Mängel oder ein kritischer Fund (siehe K.-o.-Regel).
4,6 – 5,0mangelhaftMehrere kritische Funde; der Betrieb ist so nicht zu empfehlen.

K.-o.-Regel

Ein kritischer Fund in Bereich A (Zugang & Rechte) oder B (Geheimnisse & Schlüssel) deckelt die Gesamtnote bei 4,0 – egal, wie gut der Rest ist. Eine offene Datenbank lässt sich nicht durch gute Header ausgleichen.

Schweregrade

  • kritisch

    Fremde können sofort und ohne besondere Kenntnisse Daten lesen, ändern oder Kosten verursachen.

    Beispiel: Die Kundentabelle ist ohne Anmeldung abrufbar.

  • hoch

    Ein Angriff ist mit etwas Aufwand möglich und hätte ernste Folgen.

    Beispiel: Admin-Funktionen prüfen die Rolle nur im Browser.

  • mittel

    Eine Schutzschicht fehlt; allein meist nicht ausnutzbar, aber zusammen mit anderen Lücken gefährlich.

    Beispiel: Es fehlt eine Content-Security-Policy.

  • niedrig

    Gute Praxis wird nicht eingehalten; das Risiko ist gering.

    Beispiel: Es fehlt eine Permissions-Policy.

Grundlagen

AP-26 ist kein Selbstzweck. Der Katalog bündelt anerkannte Standards und übersetzt sie in prüfbare Punkte für KI-gebaute Software.

  • OWASP Top 10 – Die zehn häufigsten Risiken für Web-Anwendungen.
  • OWASP ASVS – Der Application Security Verification Standard mit detaillierten Prüfanforderungen.
  • OWASP Top 10 für LLM-Anwendungen – Risiken speziell für Anwendungen mit Sprachmodellen.
  • BSI TR-03183 – Technische Richtlinie des BSI zur Cyber-Resilienz, u. a. zu SBOM und Schwachstellenmanagement.
  • EU Cyber Resilience Act, Annex I – Die grundlegenden Sicherheitsanforderungen an Produkte mit digitalen Elementen.
  • DSGVO – Die Datenschutz-Grundverordnung der EU.

Transparenzhinweis

AmicusProof Verified ist ein eigener Prüfstandard von AmicusProof. Es ist keine behördliche Zertifizierung.

AP-26, Version 1.0

VersionDatumÄnderung
1.001.10.2026Erste veröffentlichte Fassung mit sechs Bereichen, Gewichtung und K.-o.-Regel.
0.915.08.2026Entwurf, öffentliche Kommentierung mit Pilotkunden.