AI-Assisted Secure Coding (Appendix C) · Generation Audit Trail Completeness and Validation
Reject unverifiable provenance before merge
Verify that artifacts with incomplete, inconsistent, or unverifiable origin and generation metadata are rejected before merge or deployment, and that the rejection event is logged so trends can be tracked. Rejection happens on the verifier side, against the attestation or proof model defined in SLSA and the verification criteria in ISO/IEC 42001.
OWASP AISVS v1.01, requirement AC.10.3
In plain English
Reject artifacts whose provenance is incomplete, inconsistent or cannot be verified, before they merge or deploy, and log each rejection so trends can be tracked. The decision belongs to the verifier, the party consuming the artifact, and never to the producer's own say-so. This is a Level 3 control.
What good looks like
- The verifier rejects such artifacts before merge or deployment.
- Verification follows the SLSA model: the consumer checks attestations against its own expectations.
- Each rejection is logged with its reason.
- Rejection trends are reviewed and the causes fixed.
How teams usually do it
- Verifier-side policy that encodes the expected builder, source repository and required fields, enforced at the merge check and at deployment admission.
- Rejection events sent to monitoring, with a dashboard by reason and by team.
- Linking the practice to your AI management system records if you follow ISO/IEC 42001.
Suggested evidence
- Verifier policy.
- Rejection logs and a trend report.
- A corrective action that came out of the trend.
Common mistakes
- Rejections nobody reviews, so the same gap recurs.
- Letting the producing pipeline attest that its own provenance is fine.
Not sure which requirements apply to your system? Take the assessment, or browse every guide in this chapter.
Requirement text from the OWASP AI Security Verification Standard, licensed under CC BY-SA 4.0. This guidance is shared under the same licence.