Verification Policy
prokodo Marketplace
1. Zweck und Grundsatz
1.1 Die Verifikation ist ein technischer Prüfprozess zur Erhöhung von Plattformvertrauen (Baseline: „installiert/läuft“ und „keine offensichtlichen Secrets“).
1.2 „Verified“ ist keine Garantie für Fehlerfreiheit oder vollständige Sicherheit. Ergebnisse sind Momentaufnahmen unter definierten Testbedingungen.
1.3 Diese Verification Policy ist eine Plattformregel und wird über die AGB-Einbeziehung als Vertragsbestandteil wirksam, soweit sie für die jeweilige Nutzung (insbesondere Seller-Funktionen, Verifikation, Release/Distribution) anwendbar ist.
2. Prüfklassen (v1 Baseline)
2.1 prokodo kann je Produktklasse unterschiedliche Prüfklassen anwenden. Im MVP sind insbesondere folgende Baseline-Checks vorgesehen:
- Install-/Import-Smoke-Test in isolierter Container-Umgebung (Hard Gate).
- Secrets-Scan (Hard Fail bei Credentials/Keys/Tokens/Private Keys o. ä.).
- Optional: weitere Checks (Warn-only oder Gate) nach Plattformentwicklung (z. B. License/SBOM in späteren Leveln).
3. Statusmodell / Lifecycle und Release-Gating
3.1 Jede Artefakt-Version durchläuft einen Lifecycle (Statusmodell). Die konkreten Statusnamen richten sich nach der implementierten State Machine.
3.2 Distribution („Release“) kann davon abhängig gemacht werden, dass eine Version einen bestimmten Status erreicht (z. B. verified_passed).
- Beispielhafte Stati: submitted/uploaded → verifying → verified_passed / verified_failed → released; sowie blocked/delisted bei Policy-/Security-Themen.
4. Testbedingungen, Grenzen, Nichtdeterminismus
4.1 Verifikation erfolgt in standardisierten, isolierten Umgebungen. Ergebnisse können von Abhängigkeiten, Build-Determinismus, externen Services und Netzrestriktionen beeinflusst werden.
4.2 prokodo kann Netz-/Systemzugriffe in der Sandbox einschränken. Artefakte müssen diese Einschränkungen tolerieren oder im Listing dokumentieren.
5. Findings, Policy-Verstöße, Maßnahmen
5.1 Bei Findings oder Policy-Verstößen kann prokodo Versionen vom Release ausschließen, Downloads blockieren, Listings/Versionen sperren/delisten oder Re-Verification verlangen. Ergänzend gelten Seller-Bedingungen und AGB.
- Secrets-Finding: regelmäßig schwerer Verstoß → sofortiger Block, ggf. Delisting; Seller muss Secrets entfernen und Rotation empfehlen.
- Malware/Backdoor-Verdacht: sofortige Deaktivierung; ggf. dauerhafte Sperre.
- Irreführung/verschleierte Telemetrie: Block/Delisting bis Korrektur und erneuter Prüfung.
6. Re-Verification und laufende Überprüfung
6.1 Re-Verification kann anlassbezogen erfolgen (neue Versionen, Dependency-Änderungen, Policy-Änderungen, Sicherheitsmeldungen, Incidents, Missbrauchsindikatoren).
6.2 Bereits veröffentlichte Versionen können nachträglich blockiert werden, wenn ein Sicherheitsrisiko festgestellt wird. prokodo kann als Option eine Ersatzbereitstellung erwägen (z. B. eine zuletzt als sicher bewertete Version), ohne dass hieraus eine zwingende Pflicht folgt; mögliche Erstattungsfolgen richten sich nach der Refund & Dispute Policy.
7. Evidenz, Logs, Retention (High-Level)
7.1 Prüfergebnisse (Logs/Reports) können zur Nachvollziehbarkeit gespeichert werden.
7.2 Aufbewahrung und Löschung richten sich nach den jeweils dokumentierten Retentionsregeln (z. B. TTL/Backups/Logs) und gesetzlichen Pflichten.
