Verification Policy
prokodo Marketplace
1. Purpose and principle
1.1 Verification is a technical process to increase platform trust (baseline: “installs/runs” and “no obvious secrets”).
1.2 “Verified” is not a warranty of defect-free or fully secure software. Results are snapshots under defined test conditions.
1.3 This Verification Policy forms part of the contractual framework via incorporation in the Terms (AGB), where applicable.
2. Check classes (v1 baseline)
2.1 prokodo may apply different check classes by product category. In the MVP, the following baseline checks are typically applied:
- Install/import smoke test in an isolated container environment (hard gate).
- Secrets scan (hard fail for credentials/keys/tokens/private keys etc.).
- Optional: additional checks (warn-only or gate) as the platform evolves (e.g., license/SBOM checks in later levels).
3. Status model / lifecycle and release gating
3.1 Each artifact version follows a lifecycle (status model). Concrete status names follow the implemented state machine.
3.2 Distribution (“release”) may be gated on reaching a certain status (e.g., verified_passed).
- Example statuses: submitted/uploaded → verifying → verified_passed / verified_failed → released; plus blocked/delisted for policy/security reasons.
4. Test conditions, limitations, non-determinism
4.1 Verification runs in standardized isolated environments. Results may depend on dependencies, build determinism, external services, and network restrictions.
4.2 prokodo may restrict network/system access in the sandbox. Artifacts must tolerate such restrictions or document requirements in the listing.
5. Findings, policy violations, measures
5.1 For findings or policy violations, prokodo may exclude versions from release, block downloads, suspend/delist listings/versions, or require re-verification. Related seller obligations follow the Seller Terms.
- Secrets finding: typically severe → immediate block, possible delisting; seller must remove secrets and recommend rotation.
- Malware/backdoor suspicion: immediate takedown; possible permanent ban.
- Misrepresentation/undisclosed telemetry: block/delist until corrected and re-verified.
6. Re-verification and continuous review
6.1 Re-verification may be triggered by new versions, dependency changes, policy changes, security advisories, incidents, or abuse indicators.
6.2 Previously released versions may be blocked retroactively if a security risk is identified. Where possible, prokodo may prioritize a reasonable replacement (e.g., last safe version); potential refund consequences are governed by the Refund & Dispute Policy.
7. Evidence, logs, retention (high level)
7.1 Verification results (logs/reports) may be retained for traceability.
7.2 Retention and deletion follow documented retention rules (e.g., TTL/backups/logs) and statutory obligations.
