Safeguard
Supply Chain•

Should you sign VEX documents, and what must the signature cover?

VEX documents should be signed. What CISA and OpenVEX say about signing, what the signature must cover, and when HTTPS alone may be enough for consumers.

Safeguard Security Team
3 min read

Yes, sign them. CISA's minimum requirements say VEX documents and statements should be signed, and that the signature must cover all document metadata and all statements in the document. Without a signature, a consumer has no way to tell a real supplier assertion from a forged one that says "not affected".

Why a forged VEX file is dangerous

A VEX file can close findings. That makes it an attractive target. An attacker who can swap a supplier's file for one that marks a live vulnerability as not_affected can quietly shift your attention elsewhere. Signing, or at least a trusted delivery channel, closes that gap.

What CISA says

The minimum requirements state:

  • Implementations must support commonly accepted and current signature and encryption mechanisms.
  • Cryptography may be applied at the statement or the document level.
  • It may be applied externally, for example a detached signature, the capabilities of a containing document, or transport level security such as HTTPS.
  • Documents and statements should be signed.
  • The author should be cryptographically associated with the identity of the signer.
  • The signature must cover all the document metadata and all statements within the document.

HTTPS alone

CISA says exchanging VEX documents over HTTPS may be sufficient, as long as the consumer sufficiently trusts and understands the certificate chain, the identity of the HTTPS provider and the identity of the author. That is a real option for a supplier publishing at a stable URL on their own domain. It is weaker once a file is copied, attached to a ticket or stored for audit, because the transport protection is gone.

What OpenVEX says

The OpenVEX spec does not define its own signing mechanism. It says the author's identity should be cryptographically associated with the document's signature or another exchange mechanism. So signing is left to the tooling around the format.

Practical advice for authors

  1. Decide on one signing method and document it where customers look.
  2. Sign the whole document, not individual statements, unless you have a reason.
  3. Publish how to verify, including key identity and rotation.
  4. Keep the author field consistent with the signing identity.

Practical advice for consumers

  1. Prefer signed files, and verify before ingesting.
  2. If the file is unsigned, record the channel and fetch time.
  3. Do not auto-close findings from unverified files.

Why the coverage rule matters

CISA's rule that the signature must cover all metadata and all statements closes a quiet attack. If only the statements were signed, an attacker could change the author, version or timestamps and make an old document look current. If only the document ID were signed, statements could be swapped.

A detached signature over the whole file, stored beside it, satisfies the rule with very little work. Whatever you choose, test verification on a clean machine before announcing it to customers.

Quick check

Is signing mandatory?

CISA says signing should happen, which is a recommendation. Consumers can still require it as a policy.

Does signing prove the statements are correct?

No. It proves who issued the document and that it was not altered. Correctness is still the author's responsibility.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.