Skip to main content

​
Detection Summary

This detection indicates that a model failed verification against its cryptographic signature: signed files were modified or removed, the signature itself does not validate, or the directory contains files the signature does not cover. The detection evidence identifies which verification step failed and which files are affected.

​
Security Impact

A model that fails signature verification cannot be shown to be the artifact its publisher approved and signed. Where the failure is genuine tampering, altered weights can change model behavior in targeted ways, altered configuration or tokenizer files can redirect loading behavior or degrade safety filtering, and files added outside the signature can introduce code or content that was never reviewed. A verification failure does not by itself prove malicious tampering — it can also mean a legitimate post-signing change or a verifier configured with the wrong key — but until it is resolved the chain of custody between approval and production is broken, so deploying the model defeats the purpose of the signing control.

​
False Positive Considerations

Legitimate post-signing edits produce the same signals as malicious tampering: regenerating a README, converting or re-quantizing weights, or adding files to a signed directory all invalidate or under-cover the signature. Symbolic links in the model directory are reported as uncovered because verification never follows them. A stale or truncated signature file, or verification against the wrong public key or an unsupported signing method, fails validation without any content change. Confirm with the model’s owner whether a post-signing change was intentional and that the correct signing key is configured; an intentional content change still requires re-signing.
  • Do not promote or deploy the model until verification passes.
  • Obtain a pristine copy of the model from the publisher, or from a storage location whose integrity is independently assured, and verify it before use.
  • If the content change was intentional, re-run the approval process for the new content and re-sign the model with the publisher’s signing identity, rather than deploying with a failing signature.
  • If the change was not intentional, treat the artifact and the storage or transport path it came through as compromised: identify where the modification was introduced, and review other artifacts from the same path.
  • Verify that the public key or trust material used for verification matches the publisher’s current signing identity, to rule out a key-rotation mismatch.