It depends on the field. The SLSA v1.1 provenance page says consumers must ignore unrecognized fields unless noted, which keeps old verifiers working as formats grow. For externalParameters, verifiers should reject unrecognized or unexpected fields, because new user controlled inputs are exactly what you need to see.
The two rules look contradictory until you see what each protects.
Rule one: ignore unknown fields generally
The provenance page says consumers must ignore unrecognized fields unless otherwise noted. It also says the predicate type URI changes only for backward incompatible changes, with minor versions staying backward compatible.
The reason is compatibility. If a producer adds a harmless field in a minor version and every verifier rejects it, the ecosystem breaks. Ignoring unknown fields lets formats evolve.
Rule two: reject unexpected externalParameters
External parameters are inputs that come from outside the platform and are treated as untrusted. The pages say they must be verified downstream, and verifiers should reject unrecognized or unexpected fields in them.
Here ignoring would be dangerous. Suppose a new parameter lets a caller choose a different source or a build flag. If your verifier silently ignores the parameter, a build could be steered while your checks pass. Rejecting forces a human to look.
Side by side
| Area | Default behavior | Reason |
|---|---|---|
| Unknown top level or other fields | Ignore | Allow format growth |
| Unknown externalParameters | Reject | User controlled inputs need review |
| internalParameters | No verification needed | Platform is trusted |
| Builder and signer pair | Accept only known pairs | Prevent impostor platforms |
How to implement it
A verifier can do this with an allow list.
- Keep a file listing each external parameter name you accept, with the allowed value or pattern.
- Parse the provenance, then compare the set of parameter names against the file.
- If the provenance has a name not in the list, fail with a message that names it.
- If a name in the list is missing, decide whether that is also a failure. Usually it is.
- Leave other sections alone, but log unknown fields for later review.
Logging matters. A field you ignore today may become a field you care about later, and a record helps you notice.
Handling a legitimate change
Pipelines change. When a team adds a parameter on purpose, the expected flow is: the verifier fails, someone reviews the new input, the allow list gets updated in a pull request, and the next build passes. That friction is a feature. Make the update path quick so that people do not look for ways around the check.
Testing your verifier
Write three tests. Add an unknown top level field and expect a pass. Add an unknown external parameter and expect a failure. Change a known parameter to a disallowed value and expect a failure. These cover the core of the two rules.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a policy gate blocks a change until someone reviews it, which is the same pattern as rejecting an unexpected parameter.
Safeguard offers policies and gates for pull requests and dependencies. The free scan is at https://gold.safeguard.sh/scan.
Quick check
Is rejecting unknown fields everywhere safer?
It breaks forward compatibility. The spec asks for ignoring in general and rejecting in externalParameters.
Do I need to verify internalParameters?
No. The page says the platform is already trusted for those.
Sources
- SLSA v1.1 provenance (page marked retired, v1.2 is current)
- SLSA v1.1 verifying artifacts
Last reviewed: 19 October 2026.
