Action-side parity for VEX/license/calibration/attestation/plugin inputs in Bitbucket + Azure DevOps templates

[Metbcy]

Context

v0.9.7 expanded action.yml to expose the v0.7-v0.9.7 CLI flag surface for the GitHub Action. The examples/bitbucket-pipelines/bitbucket-pipelines.yml and examples/azure-devops/azure-pipelines.yml templates haven't kept pace — they document the diff invocation but don't expose VEX, plugin, license-policy, or attestation flags as template parameters. Adopters on Bitbucket / Azure DevOps have to hand-edit the YAML or set env vars by hand for each.

Scope

Bring examples/bitbucket-pipelines/bitbucket-pipelines.yml and examples/azure-devops/azure-pipelines.yml to the same flag-parity that the GitHub Action has post-v0.9.7. Specifically expose as template parameters / pipeline variables:

VEX

• vex (path or list of paths to VEX files to consume)
• emit-vex (path to write OpenVEX output)
• vex-author
• vex-default-justification

License policy

• allow-licenses (comma-list)
• deny-licenses
• allow-exception
• deny-exception
• allow-ambiguous-licenses

Enrichment toggles

• no-epss
• no-kev
• no-registry
• fail-on-epss

Calibration

• recently-published-days
• typosquat-similarity-threshold
• young-maintainer-days
• cache-ttl-hours
• multi-major-delta

Attestation

• before-attestation
• after-attestation
• cosign-identity
• cosign-issuer
• require-attestation

Plugins

• plugin (list of manifest paths, one flag per entry)

For each, follow the existing pattern in the template (a YAML-anchored variable + a conditional args+=( ... ) shell shape, mirroring entrypoint.sh's logic).

Acceptance criteria

• python3 -c "import yaml; yaml.safe_load(open('examples/bitbucket-pipelines/bitbucket-pipelines.yml'))" parses cleanly.
• Same for examples/azure-devops/azure-pipelines.yml.
• bash -n clean on any inline shell scripts.
• docs/src/bitbucket.md and docs/src/azure-devops.md get an "Action input reference" section mirroring docs/src/github-action.md (regrouped by purpose).
• Empty / unset inputs contribute zero CLI args (existing template invocations stay byte-identical).

A note on commit signing

main requires verified signatures (the repo ships cosign-signed releases — we hold our own commits to the same bar).

You usually don't need to set up signing as a contributor — when a maintainer merges via "Merge" or "Squash", GitHub auto-signs the resulting commit and your unsigned PR-branch commits are fine. The friendlier path for everyone.

If you'd like your individual commits to land verbatim on main (so your name shows up in git blame), set up local signing once and your PR can be rebase-merged:

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

Then add the same SSH public key under GitHub → Settings → SSH and GPG keys → Signing keys.

See CONTRIBUTING.md → Commit signing on main for the full picture. Either way, please don't sweat it — if your PR is otherwise great, the maintainer will pick a merge mode that works.