To translate CVE identifiers, CWE weakness labels and CVSS vector strings accurately, a translator must separate vulnerability identity from weakness classification and severity scoring. Security advisories, incident reports, patch notes and vulnerability databases often place a CVE ID, CWE ID, CVSS score, vector string and human-readable description in the same record. The prose may need translation; the identifiers and scoring syntax normally must remain exact. One changed character can point the target document toward another vulnerability, another weakness class or an invalid severity vector.
This guide explains how to translate cybersecurity vulnerability information without changing CVE IDs, CWE IDs or CVSS vector strings. It solves one distinct high-intent search problem: what does each identifier represent, which parts may be localized, why CVE and CWE are not interchangeable, how CVSS scores differ from vector strings, and how multilingual security documentation can preserve the same vulnerability and severity assessment after translation.
The working rule is translate the human-readable security explanation, preserve the governed identifier or vector, keep the version and source visible, and verify the relationship between identity, weakness and severity. The CVE Program defines a CVE ID as the alphanumeric identifier for a publicly disclosed vulnerability; CWE is a community-developed list of software and hardware weakness types; FIRST’s current CVSS standard is CVSS v4.0, which represents vulnerability severity through metric values and a structured vector string. These layers answer different questions and must remain separate.
CVE ID identifies a disclosed vulnerability
A CVE ID provides a common identifier for one publicly disclosed vulnerability record. Translating the letters or punctuation breaks global lookup. Preserve the complete CVE ID exactly. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVE format is structured
CVE IDs use the CVE prefix, year and sequence components. Hyphens are structural rather than stylistic punctuation. Do not replace or localize them. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVE year is not publication date in every case
The year in the identifier reflects assignment conventions rather than every later disclosure or update date. Editors can wrongly harmonize the year with publication date. Keep the ID unchanged and translate dates separately. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Reserved CVE is not published CVE
CVE Records can exist in reserved, published or rejected states. A translator should not describe a reserved ID as a confirmed public vulnerability. Preserve record status language accurately. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Rejected CVE IDs remain part of the record history
Rejected identifiers can still appear in historical references. Deleting them because they are no longer active can break audit trails. Preserve the source-period record and status. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVE Record is more than the identifier
A CVE Record can contain descriptions, affected products, references and enrichment. Only the human-readable fields are translation targets. Keep the CVE ID as the anchor. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CNA identity is another field
CVE Numbering Authorities assign IDs and publish records within scope. The CNA name is organizational identity, not the vulnerability itself. Translate roles, preserve entity names. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
ADP enrichment is separate from CNA content
Authorized Data Publishers can add supplemental information to CVE Records. Translated enrichment should not be presented as if it came from the original CNA. Keep provenance visible. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Affected product is not CVE identity
One vulnerability can affect several product versions. Changing product names or version strings can misstate scope. Preserve technical identifiers and versions. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Version ranges are structured data
Advisories can include vulnerable and fixed version ranges. Locale formatting or punctuation changes can make ranges ambiguous. Treat version expressions as protected technical text. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CPE can appear beside CVE
Common Platform Enumeration strings identify products and platforms. A CPE name is not the same as the CVE ID. Keep platform and vulnerability namespaces separate. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CWE classifies weakness type
CWE identifiers refer to weakness categories or entries rather than specific vulnerability instances. Replacing a CVE ID with a CWE ID changes the question being answered. Preserve both fields. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CWE format is structured
CWE identifiers use the CWE prefix plus a numeric entry. The prefix is not translatable vocabulary. Keep it exact. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
One CVE can map to one or more CWEs
A vulnerability can involve multiple underlying weakness patterns or mappings. Treating one CWE as the CVE’s identity oversimplifies the record. Keep weakness mapping separate from vulnerability ID. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CWE title is human-readable terminology
Weakness names such as buffer overflow or improper validation can be translated. The CWE number remains the stable classification anchor. Translate the title, preserve the code. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CWE hierarchy matters
CWE entries exist in hierarchical views and categories. A parent weakness and a child weakness are not interchangeable. Preserve the mapped CWE entry. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CWE version matters
The CWE catalog evolves and publishes versioned content. Names and hierarchy can change over time. Record version when reproducibility matters. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CWE is not exploit technique
Weakness classification differs from attacker technique frameworks such as ATT&CK. Merging them into one threat code field creates semantic confusion. Keep framework names explicit. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CWE is not remediation status
A weakness type can persist while a particular vulnerability is fixed. Translating the weakness label as a status statement is wrong. Keep classification and lifecycle separate. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVSS measures technical severity characteristics
FIRST defines CVSS as a way to capture principal vulnerability characteristics and produce a severity score. It does not identify the vulnerability. Keep CVSS separate from CVE. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVSS current version is 4.0
FIRST officially published CVSS v4.0 in 2023 and maintains the current v4.0 specification. Using v3.1 metric names in a v4.0 vector can create invalid data. Keep version explicit. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVSS score and vector are different layers
The score is a calculated numerical result while the vector records metric values. A translated narrative should not replace the vector. Preserve both. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Vector string is machine-readable syntax
A CVSS vector uses ordered metric abbreviations and values. Translating abbreviations breaks parsing. Lock the entire vector. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVSS prefix is structural
Vector strings begin with a CVSS version prefix such as CVSS:4.0. Changing punctuation or decimal separators can invalidate it. Preserve exact syntax. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Base metrics describe intrinsic characteristics
CVSS uses vulnerability characteristics such as attack vector and privileges required. The metric names can be translated in prose, but vector tokens stay unchanged. Keep display and syntax separate. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Attack Vector token should not be translated
Vector values such as N, A, L or P have defined meanings. Replacing N with a translated initial creates invalid syntax. Preserve token letters. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Attack Complexity is another metric
Metric abbreviations encode predefined values. Expanding the abbreviation inside the vector breaks it. Translate only the explanatory label. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Attack Requirements is new in CVSS v4.0
CVSS v4.0 includes metric structure that differs from prior versions. A translator using older templates can omit or mislabel v4.0 content. Use the v4.0 specification for current vectors. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Privileges Required is governed syntax
The PR metric has defined values in the vector. Do not rewrite it as local-language initials. Keep the token unchanged. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
User Interaction is governed syntax
UI has defined values in the current standard. A prose translation of required or passive should remain outside the vector. Preserve machine syntax. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Vulnerable-system and subsequent-system impacts matter
CVSS v4.0 distinguishes impact metrics for vulnerable and subsequent systems. Collapsing them into one impact sentence can lose scoring meaning. Translate metric explanations accurately. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Supplemental metrics are another layer
CVSS v4.0 includes supplemental metrics that can add context without changing the base score in the same way. Do not imply every supplemental value changes the numerical score. Preserve specification semantics. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Environmental and threat metrics can alter context
CVSS allows additional metric groups beyond base characteristics. A score can differ depending on context and threat information. Record which score is being cited. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Qualitative severity labels are human-readable
Low, Medium, High and Critical can be translated. The numerical score and vector remain the anchor. Keep label translation aligned with the score. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Decimal separator should not be localized inside score fields without policy
A score such as 8.8 is conventionally represented with a period in security data. Replacing it with a locale comma can break machine imports. Separate display localization from raw data. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVSS score is not exploit probability
Severity is not the same thing as probability of exploitation. Translating high severity as likely exploited overstates the standard. Preserve conceptual distinction. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVSS is not business risk by itself
Technical severity does not automatically equal organizational risk. A target advisory should not turn a CVSS score into a business-impact conclusion unless the source does. Translate the source claim faithfully. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Exploit status is another field
Advisories can mention proof-of-concept or exploitation in the wild. Those statements should not be inferred from CVSS. Keep threat evidence separate. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Patch availability is another lifecycle field
A vulnerability can be critical with or without a patch. Severity does not encode remediation availability. Translate patch status independently. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CVE references must remain linked to the same record
Security advisories can cite CVE IDs in URLs and anchor text. Changing only visible text or only the link creates mismatch. Verify both layers. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
JSON keys are machine contracts
CVE JSON records and security APIs contain fixed field names. Translating schema keys breaks interoperability. Translate documentation, not payload syntax. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
YAML and XML exports have the same rule
Structured vulnerability feeds rely on stable element names and codes. A localization tool should not process the whole file as prose. Protect structural fields. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Spreadsheets can corrupt IDs and scores
CVE IDs can be parsed as text safely, but scores and vectors can be reformatted. Automatic conversion may change decimals or split strings. Define explicit data types. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
CSV needs namespace columns
A generic ID column can contain CVE, CWE, advisory or ticket references. Without namespace, translated labels can be attached to the wrong identifier. Store code system explicitly. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
OCR can misread CVE and CWE identifiers
Screenshots and PDFs can confuse digits or hyphens. A one-digit error can point to another real vulnerability. Verify against authoritative records. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Smart punctuation can damage vectors
Editors can replace slashes, colons or hyphens with typographic characters. Visually similar punctuation may fail parser validation. Protect vector strings. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Machine translation should lock identifiers and vectors
MT can expand abbreviations or translate metric letters. A fluent target can become machine-invalid. Mask structured tokens before translation. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Translation memory can carry stale scores
Advisory templates are repetitive and CVSS scores can be updated. A high TM match can reuse another vulnerability’s score or vector. Populate scores from the current source. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Scores can be recalculated under newer CVSS versions
The same vulnerability can be scored under v3.1 and v4.0 with different vectors. Replacing a historical v3.1 score with v4.0 silently changes the source. Preserve source version and add newer scoring separately if needed. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Worked example: CVE plus CWE
A fictional vulnerability has one CVE ID and maps to a CWE weakness. The target translates the weakness title but preserves both identifiers. Explain vulnerability instance versus weakness category. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Worked example: CVE plus CVSS
A fictional CVE record has a CVSS v4.0 score and vector. The target translates the severity explanation while preserving score and vector syntax. Keep version visible. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Worked example: multiple scores
A vendor and third party can publish different CVSS assessments for the same CVE. The target should preserve source attribution rather than merge scores. Keep provenance. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Error clinic
Common failures include translating CVE/CWE prefixes, changing vector tokens, localizing punctuation, using old metric labels and equating severity with exploitability. These errors can survive fluent security prose. Run dedicated vulnerability-data QA. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Release checklist
CVE ID, record state, CWE mapping, CVSS version, score, vector, affected product and source attribution all need verification. Checking only the translated advisory is insufficient. Validate both identifiers and relationships. The practical test is ecosystem traceability. A reviewer using only the target should be able to reach the same CVE Record, the same CWE entry and the same CVSS assessment without guessing which system a code belongs to.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Frequently asked questions
CVE IDs, CWE IDs and CVSS vector strings should not be translated. Users often ask whether CWE identifies the vulnerability or whether CVSS is a vulnerability ID. Explain vulnerability identity, weakness classification and severity scoring separately. For structured files, store identifiers and vectors as text with explicit namespace and version fields. Exclude them from locale formatting, spelling correction and generative rewriting while allowing explanatory security prose to be translated normally.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Connection to eduKateSG architecture
This specialist owner protects cybersecurity identifiers and severity syntax. A broad cybersecurity translation hub would overlap the existing security owner. Use this page for CVE/CWE/CVSS data and existing owners for broader incident and alert prose. A strong reviewer checks both directions: from the target advisory to the identifiers and score, then from those identifiers back to the same vulnerability, weakness type and scoring source.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Authoritative sources
CVE.org, MITRE CWE and FIRST CVSS maintain the systems discussed here. Third-party vulnerability databases can enrich or rescore records. Verify identity and vector rules against the governing source. Treat the vulnerability description as translatable, the CVE/CWE identifier or CVSS vector as protected, and the mapping or score provenance as something to verify after export. This prevents a correct token from being attached to the wrong security record.
Before release, ask what the field represents: vulnerability instance, weakness class, score, vector, product, exploit evidence or remediation state. The target should make that scope visible rather than relying on code shape.
Reference verification route
For vulnerability identity, use the official CVE Program and CVE Record guidance. For weakness classification, use MITRE CWE. For severity scoring and current syntax, use FIRST’s CVSS v4.0 resources. Third-party databases can enrich these records, but translation should preserve the governing identifiers and state whose score or interpretation is being cited.