VEX record assembler

What does the vex record assembler produce?

Assemble explicitly approved affected-status statements in OpenVEX 0.2.0 format.

Use the exact local files and task-specific inputs listed below. Preparation and review stay in this browser. Inspect all findings before preparing the finalized pack.

What do you need before you start?

• Define the authorized source population and your review rules.
• Keep the unchanged original files and record the snapshot and exclusions.
• Review missing and invalid inputs before preparing the finalized pack.

What information do you enter?

Select the actual local sources and freeze the task-specific inputs below. Keep source files and complete findings private.

• Exact source records. Exact headings statement_id, vulnerability_id, product_id, status, statement_at, justification, impact_statement, action_statement, action_at, approved_by, approval_ref, source_ref
• Approved product identities. Exact headings product_id, product_version, identifier, source_ref
• Review reference. Customer-controlled review identifier.
• Responsible reviewer. Owner of the supplied facts and selected method.
• Observation date. Real YYYY-MM-DD date.
• Source and version scope. Name actual population, selected source versions and known omissions.
• VEX document IRI. Absolute IRI identifying this exact version.
• VEX document version. Positive integer. Increment when changing content.
• VEX issue timestamp. Explicit-offset timestamp, no more than three fractional digits. Statements cannot be later than this issue time.

What you can download

Every result must identify its supplied facts, assumptions and unresolved items.

Fictional review report (PDF). Editable review (DOCX). Complete fictional pack (ZIP). Requires tailoring and responsible review. Samples use the finalized renderer.

How does the vex record assembler work?

1. 1
   Select the actual sources

   Exact source records. Exact headings statement_id, vulnerability_id, product_id, status, statement_at, justification, impact_statement, action_statement, action_at, approved_by, approval_ref, source_ref

2. 2
   Freeze the review rules

   Resolve exact product references and versions. Require explicit approved status, evidence and statement time. A not_affected statement needs an allowed justification or impact statement. An affected statement requires an action statement. Reject conflicting statuses for the same product, vulnerability and instant. Produce an OpenVEX 0.2.0 JSON document, retaining customer approval and source lineage separately. Statuses are supplied conclusions, not scanner-derived decisions.

3. 3
   Inspect complete findings

   Review all source-linked results and unresolved items. Free JSON and CSV preserve complete results.

4. 4
   Keep recoverable work

   Original files and exact input strings save in this browser. Restore validates identity, schema and actual file hashes before replacing current work. Earlier browser work and historical purchases remain separate.

5. 5
   Prepare the finalized pack

   Prepare seven core files and the exact selected attachments, then download them free. Review the fictional sample below.

Method and sources

Apply the steps above to the supported inputs. Use the listed source sections to review the rule basis, assumptions and limits.

• Common Format and MIME Type for CSV FilesSupports CSV interchange only. It specifies no approved domain population, legal criterion or task decision. Sections 2 and 3 describe comma-separated fields, escaping, headers and the text/csv media type.RFC Editor. Reviewed 2026-10-09.
• OpenVEX Specification 0.2.0Supports OpenVEX 0.2.0 structure. All impact conclusions and approvals are customer supplied and remain unverified. Document metadata, product and vulnerability identifiers, status labels and conditional statement fields define the supported machine-readable output.OpenVEX. Reviewed 2026-10-09.

Common questions

What still needs review?

Working results use exact local sources and explicitly selected versions. Originals remain unchanged in this browser. No source authenticity, population completeness, vulnerability exploitability, legal applicability, license conclusion, consent validity, food safety or external submission is established.

Each source supports at most 10 MB. Table sources support 5000 rows, 50 fields, 100000 cells and 5000000 parsed characters. JSON documents support depth 40 and 100000 nodes.

Working artifacts are produced only when their required named checks pass. Complete findings remain available even when an artifact is withheld.

Related working records

The related workspace contains working administrative records. Open it for the related administrative task.

Related tools

Browse all cybersecurity tools.

• Vulnerability report normalizerCombine scanner exports into a consistent structure. Try a free example, then review your inputs and the result. No account or payment required.
• Vulnerability deduplicatorMerge repeated findings while preserving source evidence. Try a free example. Review your inputs and result. No account or payment required.
• Remediation SLA trackerCalculate remediation due dates, overdue intervals and completion outcomes under your approved severity and timing rules. Review the result.
• Vulnerability exception packAssemble compensating controls and approval evidence. Try a free example, then review your inputs and the result. No account or payment required.
• SBOM validatorCheck required fields, identifiers and structural consistency. Try a free example. Review your inputs and result. No account or payment required.