The short answer

Require a public disclosure policy that names scope (firmware, companion app, cloud), a direct contact or PGP key, and verifiable advisories/CVEs. Check report→acknowledge→patch timestamps and demand numeric triage and patch SLAs; disqualify vendors missing both public policy and demonstrable responsiveness unless you obtain a signed SLA.

Time needed about two hours, spread over one day

Key takeaways
  • A public, specific disclosure policy that names firmware, companion apps and cloud is a procurement gate.
  • Proof of responsiveness requires dated report→acknowledge→fix timestamps from advisories or CVEs.
  • No public policy plus no verifiable CVE history should disqualify a vendor unless you get a signed SLA.
  • Security.txt, GitHub advisories and NVD/CVE entries provide the fastest verifiable evidence.
  • Threatening legal language or insisting on private-only contact are immediate red flags.
Before you start
  • Vendor website URL and the exact product model strings you plan to buy (include firmware model numbers if available).
  • A web browser with access to NVD/CVE search or an equivalent CVE lookup tool.
  • A procurement or legal contact able to accept SLAs and sign amendments.
  • An email account you will use to contact the vendor and record their replies.
  • Access to the vendor’s public GitHub organisation or release notes, if the vendor publishes them.

The steps

  1. Open the vendor security pageNavigate to the vendor website and click links titled Security, Trust, or Vulnerability Disclosure. If none exist, fetch https://<vendor-domain>/.well-known/security.txt.You should see: You see a page or file that names a security contact, a PGP key or triage email and a link to the disclosure policy or advisories.
  2. Capture the policy link and contactCopy the exact URL of the disclosure policy and any PGP public key block or triage email into your procurement record.You should see: The procurement record contains a working URL and a verifiable email address or a PGP public key block you can validate.
  3. Search CVE/NVD and GitHub for advisoriesSearch the NVD/CVE database and the vendor’s GitHub for advisories using the vendor and exact model strings; record any CVE IDs and advisory URLs with visible publish dates.You should see: You have at least one or two advisory links or CVE IDs tied to the vendor’s products, each with a visible publish date.
  4. Extract report, acknowledgement and fix datesOpen each advisory or release note and record the report date (if present), vendor acknowledgement date and the fix or patch publication date.You should see: A timeline per advisory showing report date (or initial disclosure), acknowledgement date and fix/publish date recorded in your spreadsheet.
  5. Compare timelines to your thresholdsCalculate days from report→acknowledgement and from acknowledgement→fix for each advisory and compare them to your organisation’s acceptable windows.You should see: A clear comparison that shows whether the vendor’s observed behaviour meets your acceptance thresholds.
  6. Send the vendor Q&A emailEmail the vendor’s triage contact with the Q&A: request the policy link, PGP/security.txt, two advisories/CVEs for your models, and numeric acknowledgement and patch SLAs.You should see: You receive a dated reply containing working links and numeric SLAs or a refusal/evading response.
  7. Evaluate the response and decideCompare the vendor’s reply to your pass/fail criteria: public policy present, two advisories, PGP or security.txt, numeric SLAs; mark the vendor pass, conditional or fail.You should see: A procurement status: pass (proceed), conditional (require SLA/escrow), or fail (disqualify).
  8. Enforce contract terms and validate with a staged rolloutIf the vendor passes, sign the SLA into contract; if conditional, add escrow or third‑party patching clauses and run a staged rollout to validate one patch cycle.You should see: A signed contract amendment or SLA is on file and a staged rollout plan is scheduled with success criteria for OTA updates.

How to check vendor vulnerability disclosure policy

Locate the vendor’s public disclosure policy or a /.well-known/security.txt, confirm a named contact or PGP key, find verifiable advisories or CVEs for the product, and compare report→acknowledge→patch timestamps. Treat vendors without both a discoverable policy and demonstrable responsiveness as unsuitable for procurement.

  • Open the vendor website and look for links titled Security, Trust, Vulnerability Disclosure or similar.
  • Fetch /.well-known/security.txt on the vendor domain for an intake address and optional PGP key (for example: https://vendor.example/.well-known/security.txt).
  • Search the vendor’s public GitHub organisation for Security Advisories or release notes that reference CVE IDs.
  • Search NVD/CVE entries for the vendor name and exact product or firmware model strings.

What a usable disclosure policy contains

A usable policy names scope (firmware, device OS, companion phone apps, cloud services and third‑party modules), gives a direct contact or PGP key, states triage and acknowledgement timelines, explains coordinated disclosure rules, and includes safe‑harbour language. The policy should be machine-findable and versioned so you can cite it in procurement.

  • Explicit scope: list model numbers, firmware channels, companion apps and cloud endpoints.
  • Named contact: a triage email address and an optional PGP public key.
  • Triage SLA: stated time to acknowledge and to classify reported issues (numeric SLAs).
  • Coordinated disclosure rules: maximum public-disclosure window the vendor expects.
  • Safe‑harbour: an explicit promise not to pursue legal action against good‑faith researchers.

How to verify responsiveness with CVEs and advisories

Find past advisories or CVEs tied to the vendor’s products and extract dates for report, acknowledgement and fix. Use those timestamps to measure real-world response windows. Two or more dated advisories across components or years show an operational process; a single undated advisory does not.

  • Search NVD/CVE for the vendor and exact product or firmware model strings and note CVE IDs.
  • Open each advisory or GitHub Security Advisory and record report date, acknowledgement date and fix or publish date.
  • Compare dates: days from report→acknowledgement and days from acknowledgement→fix for each advisory.
  • Accept evidence that shows a clear remediation path and changelog entry; reject advisories that list fixes without version or patch links.

Red flags that should stop a purchase or require contract remediation

Some vendor responses are immediate procurement blockers; others need contract remedies. Block procurement for legal threats to researchers, no public policy plus no verifiable advisories, or explicit exclusion of firmware/OTA from the scope. Accept borderline answers only with signed SLAs or escrow arrangements.

  • No public disclosure policy and no CVE/advisory history — do not proceed without a signed SLA that sets patch SLAs and penalties.
  • 'Contact us privately only' with no security.txt or PGP — insist on a triage email plus verifiable past responses before accepting.
  • Vague or adversarial legal language toward researchers — disqualify the vendor.
  • Policy that explicitly excludes firmware, companion apps or cloud — require scope expansion in contract.

Vendor Q&A and the exact questions to demand

Send a short, exact vendor Q&A that demands links to the public policy, a PGP key or security.txt, two recent advisories/CVEs for your product models, and the numeric acknowledgement and patch SLAs. Accept only clickable links and dated evidence; ambiguous answers fail the procurement check.

  • Ask for: a link to the public disclosure policy; confirmation that the policy covers firmware/OTA and companion apps; PGP key or security.txt link; two CVE IDs or advisory URLs for your device models; and stated numeric SLAs for acknowledgement and patching.
  • Acceptable evidence: working links to the policy and advisories, a PGP key or security.txt entry, and numeric SLAs or a contractual commitment to add them.
  • Unacceptable: verbal promises without links, evasive phrasing, or 'we handle case-by-case' with no SLAs.

If the vendor lacks evidence: concrete procurement options

If a vendor cannot provide a public policy and verifiable advisories, require contractual mitigations: a signed disclosure and patch SLA, security‑escrow, a third‑party patching clause, staged rollout limits, or indemnities limited to defined incident types. Do not rely on verbal assurances.

  • Signed SLA that defines scope (firmware, companion app, cloud), numeric acknowledgement and patch SLAs, and contractual remedies for missed SLAs.
  • Security‑escrow of sources or signing keys allowing a trusted third party to release patches if the vendor fails.
  • Third‑party patching clause permitting commissioned, vendor‑certified patches from a named partner.
  • Staged rollout: limit initial devices until the vendor proves one patch cycle works.

How this verification fails in practice and why

The typical failure path: procurement skips the security.txt check, accepts a salesperson’s emailed promise, and deploys devices. When a field incident occurs, there is no OTA channel and no contractual leverage, creating a multi‑week operational outage. Log dated responses and require the vendor Q&A before contracting.

  • Common sequence: procurement accepts promise → deployment → a vulnerability surfaces → vendor has a long patch window → organisation lacks SLA or escrow.
  • Who is affected: field users and support teams face delays and operational downtime.
  • Fix: enforce the vendor Q&A before contract signature and validate with a staged rollout.

Next step for Maria

Send the vendor Q&A email, collect the policy link and two CVE or advisory links for the specific models you plan to buy, and insist on signed SLAs for acknowledgement and patch timelines before approving purchase. If answers are incomplete, escalate to contracts for escrow or walk away.

  • If this is a workplace device, for example a Vuzix model, use the vendor’s advisories plus a staged rollout to check OTA updates — see /devices/vuzix-shield.
  • If the device is consumer-facing, for example Ray‑Ban Meta, insist the policy explicitly covers the companion phone app — see /devices/ray-ban-meta.
  • For headsets such as XREAL Air 2 Ultra, confirm GitHub advisories and NVD entries and follow a staged rollout pattern — see /devices/xreal-air-2-ultra.
  • For guidance after an advisory is published, read the follow-up steps at /articles/after-smart-glasses-advisory.

Sources and further reading

  • [$60 Smart Glasses Hacked Without a Password [2026]](https://news.google.com/rss/articles/CBMigAFBVV95cUxOUC1jaVdsZzdhVnd5OFFLRDhic0ExR3hBZ2pzaVdJblJFUFRnRG5PTjFnbVA4c2NtbVNiUmxwWVlSZFV5MTZTbkE3VUdhMUFOSkcyWWxpbnIwWGpTX0g2Wlg2SGFjSTZHdTlfeERWYV9nMEhRZ3F6R0xvLV9SckF5eg?oc=5) — Google News
  • Samsung Rolls Out October 2026 Security Update for Galaxy S24 Series — Google News

Where this usually goes wrong

  • You find no public policy and the vendor gives a verbal promiseProcurement accepted a salesperson’s assurance without linkable evidence.Pause the purchase, demand the policy link and written SLAs, and refuse verbal-only promises in the procurement record.
  • An advisory exists but lists no fix or CVE referenceVendor published advisory text without a reproducible remediation or changelog tied to a release.Request a changelog entry or patch link that names the exact firmware or app version with the fix and require that in contract.
  • Vendor acknowledges slowly or not at all after you report a test issueThe policy exists but the vendor has no staffed operational triage process.Use recorded evidence to enforce SLA remedies or escalate to the vendor’s legal/procurement contact; consider security escrow if unresolved.
  • Vendor threatens legal action when a researcher reports a vulnerabilityPolicy lacks safe‑harbour language or the vendor’s legal posture is adversarial.Disqualify the vendor or require explicit contractual legal protections for researchers and a rewritten policy before purchase.

The checklist

  • Open the vendor security page
  • Capture the policy link and contact
  • Search CVE/NVD and GitHub for advisories
  • Extract report, acknowledgement and fix dates
  • Compare timelines to your thresholds
  • Send the vendor Q&A email
  • Evaluate the response and decide
  • Enforce contract terms and validate with a staged rollout

Frequently asked questions

Is a private disclosure policy acceptable if the vendor provides proof on request?

No. Procurement-grade policies must be public and discoverable so independent verification is possible. If a vendor insists on private handling, require signed contractual SLAs and verifiable past advisories before approving the purchase.

What acknowledgement and patch timelines should I demand?

Demand explicit numeric SLAs for acknowledgement and for patching that scale by severity. If the vendor refuses numeric SLAs, treat them as high risk and require contractual protections such as escrow or staged rollout validation.

Can I accept a vendor with no CVE history but a strong policy?

Yes, only if the policy is public, the triage process is clear, and the vendor signs an SLA guaranteeing patch timelines. Absence of CVEs may indicate a new product; verify operational capability via a staged rollout and enforceable contract terms.

What if the vendor refuses to provide a PGP key or security.txt?

Refusal to provide PGP or security.txt indicates the vendor has not operationalised secure intake. Require at minimum a dedicated triage email and dated examples of past advisories; otherwise insist on contractual remedies or disqualify the vendor.

Find apps that work on your glasses

Every app in the directory lists the glasses it runs on, how it works on each, and the official source that proves it.

Browse the app directory