How do people translate a CycloneDX software bill of materials quickly without breaking security evidence? Start by separating explanatory component descriptions from the identifiers and relationships that security tools use to recognise software. Translate user-facing summaries in a governed report or approved descriptive field workflow, but preserve package names, versions, package URLs, BOM references, hashes, licence identifiers and dependency relationships. Compare the original and localized artifacts structurally, and never replace a signed or authoritative SBOM merely to improve its reading language.
A CycloneDX SBOM is not just a shopping list of software names. It is structured evidence about components, their identities and their relationships in a product. CycloneDX 1.6 provides JSON and other serializations with fields whose strings serve very different purposes. Some strings are explanatory prose; others are machine keys. Translating both categories the same way can make a component harder to match to a vulnerability notice or confuse the provenance of a software release.
This article walks through an offline, audit-friendly translation process for a fictional school learning application. It explains the schema and descriptive boundaries, shows a minimal JSON example, diagnoses failures involving package identity and dependency graphs, provides a changed-context exercise and describes QA for multilingual stakeholder reports. The goal is to help learners and procurement reviewers understand technical evidence without claiming that a language-localized summary changes whether software is secure, licensed or supported.
Define who needs the translated SBOM information
A software developer, procurement officer, school administrator and security auditor may ask different questions about the same component. Developers need exact dependency identifiers and versions; administrators need to understand a library’s purpose; procurement teams may need licences and product support implications; auditors need traceability to the released build. Ask which decision the translated material must support before editing anything. For many nontechnical readers, a supplementary localized explanation is more useful and safer than altering the raw SBOM file.
If the receiving security scanner expects an untouched CycloneDX JSON document, treat that document as an input artifact, not a translation workspace. Produce a sidecar report keyed by stable component references, with clearly distinguished explanation and evidence fields. This preserves the scanner’s ability to process the original, while a bilingual person can interpret the results. A sidecar is not a universal CycloneDX localization standard; it is an application-level document that must be labelled as such. The distinction protects interoperability.
Understand the core SBOM object model
CycloneDX documents have a declared format and specification version and may list components, services, metadata, dependencies and other relevant relationships. A component may have a name, version, type, package URL, hashes, external references, licences and descriptive text. A BOM reference can connect an object to other references inside the same document. These fields do not all carry ordinary words. Their relationships are central to what makes the SBOM useful for automated analysis.
The package manager may identify an npm package by a namespace, name and version, while the SBOM’s description gives a broad account of what it does. A translator can explain the description in another language without changing the actual package. If the package name is localized into a friendlier term inside the structured identity fields, a vulnerability scanner may not find the original package. The translated output looks better to a human but becomes less useful for its principal machine consumer.
Pin the CycloneDX schema version
CycloneDX evolves, and available fields or constraints can differ between specification releases. This article uses the 1.6 JSON schema as a concrete reference, not an assertion that every future implementation exposes the same structure. Inspect the actual document’s specVersion, validate with the matching schema and check which format your downstream tools accept. Do not label a file as 1.6 after introducing fields copied from a later draft without testing compatibility. A translation task should not silently become a schema migration.
Version pinning is also an ownership matter. A vendor may distribute an authoritative SBOM for a particular software release. A school receiving that artifact should not rewrite its specification version to make local tools accept it. If a scanner cannot read the supplied version, use a supported conversion step with a documented output and preserved source. Keep conversion QA separate from translation QA so a missing dependency or changed reference cannot be blamed on a word choice.
Establish an immutable source artifact
Store the exact original SBOM with the software release identifier, acquisition source, date, original filename and checksum. If it is digitally signed or accompanied by verification metadata, preserve that evidence and verify it using the supplier’s prescribed process. Keep the raw artifact read-only. For localization, parse it into an internal representation and extract approved descriptive fields into a translation register. If a localized artifact is ever produced, it must have its own identity and provenance rather than masquerading as the original bytes.
This approach is important because a JSON serializer can change property order, spacing or escaping even when the component relationships remain equivalent. Such differences may be irrelevant for semantic comparisons but may invalidate a detached checksum or a signature over the original representation. The test plan must specify what is being preserved: exact original bytes for evidence and selected semantic fields for any derived view. A translated summary can be accurate without being a cryptographic substitute for the supplier’s original SBOM.
Classify text before extracting it
Create an explicit allowlist for natural-language descriptions intended for stakeholders. A component description can often be translated for a report, but a product name, group, package URL or unique reference must normally remain as supplied. Some components also include copyright notices, licensing information, supplier names and external links. These require their own rules; a notice written by a rights holder should not be paraphrased as though it were optional editorial copy. Classify each text field by role, owner and allowed transformation.
A useful register contains the component’s original BOM reference, package URL if present, source field, source value, language, draft translation, security meaning and reviewer. Record whether a string is from the vendor, imported from a package registry or authored by the receiving organisation. This provenance affects trust. If a vendor states a library handles authentication, the translated description should not upgrade that statement into a promise of security certification. Translators can explain what a component claims to do, but cannot create new supplier attestations.
Read an illustrative CycloneDX JSON object
The small example below is a fictional CycloneDX 1.6 SBOM fragment. Its package and version are not claims about a real published dependency. It is syntactically valid JSON showing a natural-language description beside identity fields. A full release SBOM may include additional metadata, hashes and dependency declarations. The example demonstrates which information would be protected if a school needs a localized component explanation.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"version": 1,
"components": [
{
"type": "library",
"bom-ref": "pkg:npm/example-school-calendar@1.0.0",
"name": "example-school-calendar",
"version": "1.0.0",
"purl": "pkg:npm/example-school-calendar@1.0.0",
"description": "A calendar display library used by a school application."
}
]
}
In a bilingual report, the description might be translated for parents or auditors while the package URL and version remain exactly as recorded. Do not assume a CycloneDX 1.6 description field inherently supports several tagged language variants in one field. If the application needs multiple languages, use a separately defined sidecar mapping or another explicitly supported integration. Adding invented keys such as a custom translations object without respecting extension mechanisms can make the JSON fail schema validation and confuse consumers.
Protect package names and package URLs
A package URL, commonly shortened to PURL, encodes package identity according to the package-url specification. Its ecosystem type, namespace, name, version and qualifiers can have precise meaning. Those components are not translated language phrases, even if a package name resembles an ordinary word. A translated description may say that a package manages calendars, but the PURL must continue to identify the same distribution artifact in the same ecosystem.
For example, replacing example-school-calendar with a target-language phrase inside a pkg:npm/... PURL could make it refer to a nonexistent or different package. Even changing punctuation, case or URL encoding without understanding the package ecosystem can be risky. Security matching often depends on precise identity. Keep the PURL byte-for-byte stable for a metadata-only translation, and compare it before and after any derived serialization. Explain its human meaning outside the identifier instead of modifying the identifier itself.
Preserve BOM references and graph edges
A BOM reference is used to refer to components or other objects within the CycloneDX document. A dependency relationship can point to those references. If a translator changes one reference to match a translated label but does not update every edge, the graph may contain broken pointers. Even if the pointers are updated consistently, the identity change can make historical comparisons difficult. The safest rule for text-only localisation is not to touch references or dependency arrays at all.
This is why a graph-level QA check matters. Record the set of component references and the directed dependency relationships before and after. Compare them as sets or normalized structures rather than rely only on a visual JSON diff. A component can have a correct translated description while the dependsOn entry accidentally points to another package. That error can distort impact analysis: an auditor might believe a vulnerable library is not connected to a product when it actually is.
Distinguish names, labels and descriptions
An ordinary user may call a software package ‘calendar helper’, but the supplier’s package name may be an exact machine name. Treat the human nickname as a display label in the supplementary report, not a replacement for the package’s authoritative name. Likewise, a description such as ‘renders calendar events in a student portal’ should not be treated as proof that the package stores student data or meets a particular privacy standard. The sentence describes purpose at a chosen level of detail; it is not a security assessment.
A strong localized component table places the fixed identifier beside the translated explanation. Readers can learn both the function and the traceable identity. This is particularly valuable in schools, where a procurement committee may not recognize a JavaScript package name but still needs to ask developers which component is responsible for a feature. Do not hide technical names to make the report seem friendlier. Familiar labels and precise identifiers can coexist without one corrupting the other.
Treat licence identifiers as controlled assertions
Software licences can be represented through identifiers, expressions or other structures that have legal and technical meaning. A licence identifier such as an SPDX license ID is not a natural-language noun to translate. A reader-friendly report may explain a licence family in the target language, but that explanation must not replace the actual declared licence or suggest rights the original does not grant. Where obligations are uncertain, consult the licence text and appropriate legal guidance instead of inventing a simplified promise.
A particularly risky mistake is changing one declared licence to a different identifier because the names sound similar in translation. Permissive, copyleft and commercial licensing conditions are not interchangeable. Also distinguish a component’s declared licence from an automated tool’s guess or a file-level licence finding. Translators should preserve evidence level and uncertainty. Saying ‘licensed under X’ in a localized summary is an assertion about rights; if the SBOM only reports an ambiguous or concluded result, the explanation must preserve that limitation.
Preserve hashes and integrity metadata
Hashes identify specific bytes under a defined algorithm, and they are not phrases to localize. A checksum for a package archive should not be rewritten to match a translated description. If a bilingual report shows a hash, display it intact, preferably in a format that supports copying and verification. A translator should never ‘correct’ a strange-looking hash value, substitute an alphabetic symbol or insert spaces into the machine field to make it easier to read.
There are two different checksums to consider: the hash recorded inside the SBOM about some software artifact, and the hash of the SBOM document itself if an organization uses one for provenance. Editing the SBOM’s descriptive text may leave the software hash unchanged but alter the document hash. That is expected for a newly derived representation and must be recorded honestly. The original authoritative document should remain available so auditors can confirm which bytes a supplier actually attested to.
Translate claims with their uncertainty intact
A component description may use limited phrases such as ‘intended for’, ‘may support’, ‘optional’ or ‘experimental’. These words carry real uncertainty. Turning ‘may support encrypted connections’ into ‘provides guaranteed secure communication’ is an unsafe expansion. A translation should preserve modal verbs, constraints, deployment conditions and caveats. Ask whether the text describes a component’s capability, the receiving application’s configuration or a verified security control. Those are separate concepts.
The same applies to support status. A vendor saying ‘maintenance mode’ is not automatically declaring a package abandoned or free from defects. An issue fix released in a newer version does not prove the installed version has it. In a classroom procurement context, one overconfident translated sentence could influence whether a school adopts software used by children. Review capability claims with technical staff who can read the relevant package evidence; fluency alone cannot establish operational truth.
Do not confuse vulnerability information with component descriptions
SBOMs support vulnerability analysis, but a plain component description is not a vulnerability assessment. CycloneDX can be used with related security information, including formats for communicating vulnerability and exploitability information. If such data are present, translating a status explanation requires its own controlled scope. Do not rewrite a vulnerability identifier, exploitability state or analysis response because it looks like a word. An error here can cause a real security finding to disappear from a report or seem more serious than it is.
A component may be present yet not exploitable in a particular configuration, or may require further analysis. Translate the explanatory rationale carefully and keep the evidence source and timestamp visible. Never infer ‘safe’ from ‘no known vulnerability listed’, because the absence of a finding is not a guarantee. If a security team has not approved an exploitability claim, label the translated text as a description of the source report rather than an independently verified risk verdict.
Recognize supplier versus local commentary
A component description imported from a supplier’s SBOM has a different authority from a procurement note written by a school. Keep them in separate columns or records. If an administrator adds ‘used in attendance scheduling’, that is a statement about the local system’s deployment, not necessarily something the upstream package maintainer asserted. Presenting this in the same unlabelled field as supplier prose blurs accountability and makes later security review difficult.
For every added explanatory sentence, identify who wrote it, the evidence source and the date it was reviewed. A translation register can contain source wording and approved translation, while a local-analysis register contains school-specific interpretation. Do not allow a translation-memory system to blend the two. Good provenance enables a future reader to distinguish ‘the supplier says this library parses dates’ from ‘our development team uses it for timetables’. Both may be true, but only one comes from the source SBOM.
Make a separate localization sidecar when useful
A sidecar can be a simple internal JSON or table mapping stable BOM references to localized descriptions, with a schema controlled by the organization. Such a structure should not pretend to be a CycloneDX standard extension unless it complies with an actual documented extension mechanism. A field might record target language, component reference, translated description and reviewer. Keep the file clearly labelled as a human-explanation resource associated with a specific SBOM checksum.
The sidecar has practical advantages. It can contain English, Chinese and Malay explanations without changing the supplier’s SBOM bytes. It can be updated for reader clarity without claiming a new software build. It also allows a viewer to fall back to the original description when a translation is missing. But the sidecar needs its own QA: it must never map a translation to a reference from the wrong SBOM version, and should flag orphaned entries when components are added or removed.
Manage version changes and reused phrases
A package can retain its name while its version changes, and the new version may have different functions, dependencies, licences or risks. A translation approved for version one should not be carried automatically into version two without checking the source description and relevant release evidence. Translation memory saves time when the same phrase genuinely means the same thing, but it must not override the new document’s component identity and context.
Build a version-aware key using a stable component reference plus the release context, with package URL or other authoritative identity where available. When the original SBOM changes, compare both descriptions and protected fields. A version change with identical descriptions may need only a quick meaning check; a changed dependency graph might require more substantial technical review even if not a single human word changed. The translation workflow should be able to distinguish these cases instead of treating every repeated phrase as evergreen.
Test JSON parsing and CycloneDX schema rules
Parse the original and any derived CycloneDX JSON with a standards-compliant JSON parser. A missing comma or unescaped quotation mark in a translated description can invalidate the entire document. Then validate against the exact pinned CycloneDX schema. For an illustrative sidecar, validate it against its own clearly stated schema, not against the CycloneDX schema. Keep tests separate so success in one format does not get misrepresented as compliance with another.
An easy mistake is inserting an extra object with translated labels where a schema expects a string. Another is using arbitrary property names not recognized by a strict schema. Some ecosystems provide flexible property mechanisms, but that does not mean every custom field will be interpreted by scanners or displayed as intended. Avoid inventing schema capabilities. If the target product has a documented localization extension, verify its contract and test the resulting artifact. Otherwise prefer a separate reader layer.
Compare protected fields programmatically
Before accepting a localized derived SBOM, extract package names, versions, PURLs, hashes, licence identifiers, external references, BOM references and dependency relationships into a normalized invariant record. Do the same for the derived file and compare them. A JSON string comparison is inadequate because object key order can change, but structured comparison can be exact for important field values. Treat any unexpected difference as a blocker until its owner explains why it changed.
The comparison should account for optional and absent fields without inventing defaults. A missing hash is not a zero hash; a missing licence does not mean public domain; an omitted dependency relationship may represent incomplete data rather than no dependency. Translation should not add false certainty by turning omissions into explicit claims. When a source lacks an attribute needed by a reviewer, record the gap and request additional evidence. The right answer is often to explain uncertainty plainly rather than complete the structure by guesswork.
Run dependency-graph regression checks
Graph tests reveal mistakes that a simple list comparison can miss. Count the component vertices and declared dependency edges, check that every referenced object resolves where expected, and compare the graph’s relationships before and after. If a component appears under multiple references, inspect the source model rather than merging them on translated display names. Two similarly named libraries can be different versions, different builds or different packages. Their machine identifiers must determine the relationship.
A change in graph topology can alter vulnerability impact analysis. If an application depends on a component through an indirect chain, removing one edge in a translated report might make the path invisible to a stakeholder. A localized visualization may simplify how a graph is drawn, but its underlying evidence should remain accessible. State when a diagram omits transitive details for readability. Never present a simplified drawing as a complete substitute for the machine dependency relationships.
Review legal notices and proprietary descriptions
Some component descriptions quote upstream documentation or contain protected marks. The translator needs appropriate permission to reproduce or adapt the text in a public report. A licence declaration inside an SBOM does not automatically grant rights to rewrite all upstream documentation; copyright and attribution obligations may still apply. Use short original explanations where justified, preserve marks and review any quoted language under the organization’s publishing rules. Keep a source citation for each imported description.
This matters when a school distributes a technology procurement guide to parents or students. A local summary explaining ‘this package displays calendars’ may be appropriate, while copying an entire proprietary product description and translating it could raise separate content rights questions. The easiest safe route is to keep the original technical evidence and write an independent, limited explanation of the package’s role in the specific system. Readers need clarity, not an unauthorized translation of a vendor’s brochure.
Design a bilingual procurement review
A translated SBOM report should give readers a way to move from friendly prose to inspectable evidence. Display the component’s unchanged name and version, the localized purpose statement, licence status as reported, supplier or source where known, and a reference back to the original SBOM record. Explain terms such as direct dependency, transitive dependency and package URL in a glossary rather than altering machine keys to sound familiar. The report becomes a teaching instrument without corrupting the security artifact.
When showing a list of components, do not sort or merge them solely by translated names if those names are nonunique. Two packages can both become ‘date utility’ in ordinary Chinese or Malay, yet differ materially in support and vulnerability status. Use stable keys for grouping and filtering, then show explanatory names as secondary text. A viewer that conflates components through linguistic similarity undermines the very reason an SBOM exists: accurate composition and traceability of software ingredients.
Diagnose mismatches through layered tests
If a localized report shows a component as missing, begin by checking the source SBOM and the sidecar mapping. The source may genuinely omit it; the sidecar may refer to a different release; or the viewer may filter by the wrong language code. If a scanner fails on a modified SBOM, inspect JSON syntax, schema compliance, reference integrity and unsupported added fields before changing the translated sentence. Each error category has a distinct cause and repair path.
Do not respond to a schema error by deleting arbitrary components until the file validates. That can create a formally acceptable but incomplete SBOM. Instead restore a known good baseline and reapply only the approved descriptive patch or sidecar mapping. When a vulnerability tool reports a different result after localization, compare the exact machine artifact and scanner configuration. A language change should not itself alter software exposure; a changed result is evidence of a pipeline issue or a separate data update needing investigation.
Test reading quality without losing qualifiers
Human review should ask whether the explanation enables correct decisions. Give a bilingual technical reviewer a set of questions: Is this component a library or application? Does the description state what it does or promise a security outcome? Are limitations such as ‘optional’ or ‘experimental’ preserved? Can the reviewer identify the exact package and version from the translated report? If readers can understand the prose but cannot reconnect it to the machine component, the localization is incomplete.
Use a short confusion test with near-neighbour packages. Show two calendar libraries with different versions and ask the reviewer to distinguish them using the translated report. If the localized descriptions merge them into the same generic phrase without identifiers, revise the presentation. Good translation removes unnecessary language barriers without removing distinctions the receiving task depends on. That rule applies equally to components with similar names, different vendors or subtly different licence assertions.
Transfer exercise: an online examination portal
A school receives a CycloneDX SBOM for an online examination portal. The source contains a browser date library at version 4.2.0 with a fixed PURL and a bom-ref used by two dependency edges. A localization script changes the package name to a Chinese phrase, leaves one dependency pointing at the original BOM reference, and replaces the licence identifier with an English paraphrase. The rendered report looks understandable. Which changes are unacceptable, and what should the bilingual report show instead?
The correct repair restores the package name, PURL, BOM reference, licence identifier and both original dependency edges. The Chinese phrase belongs in an approved explanatory field or sidecar attached to the same component reference. The report should show the fixed identity and version beside the translated function, and should explain the licence only as commentary while retaining the source assertion. Run syntax, schema and graph checks, compare all protected values, and ensure a security reviewer can still trace the date library through both dependency paths.
Build a pre-release checklist
Confirm the exact software release and CycloneDX specification version; preserve and hash the original SBOM; verify any existing signatures; classify fields by owner; and approve only genuine reader-facing descriptions for translation. Build stable reference mappings, translate with cautious technical language and check licences, support claims and risk qualifiers. Keep locally written explanation separate from supplier assertions. If a localized machine artifact is required, validate it with a declared schema and keep its provenance distinct from the original.
Before handoff, parse JSON, validate the applicable CycloneDX version, compare package identities, hashes, licences and dependency edges, and test the actual viewer or stakeholder report. Review one direct and one transitive dependency, one missing optional field, one uncertain security statement and one component with a confusingly similar translated name. Archive the source, localization sidecar or derived file, QA results and reviewer decisions. A concise evidence trail saves more time in a later audit than a large unstructured translation log.
Interpret component type without guessing responsibility
A component’s type helps classify how it is represented in the BOM, but does not by itself explain every role it plays in an application. A library may be bundled into a web interface, used only in a build pipeline or present in a test environment. Translating a component description as ‘required by all students’ because its type says library is an unsupported inference. Examine the dependency context and the source documentation before describing its deployment. For procurement readers, separate what is known from the SBOM from what the local development team confirms about actual runtime use.
This distinction also affects exposure discussions. A dependency required only in development is not necessarily reachable in production, and a runtime component may still be inactive under a particular configuration. The translator must not infer a risk state from the component’s display category. A careful report can say ‘listed as a library in the supplied BOM’ and separately note an approved explanation of its role. That language may sound less dramatic, but it is more useful to an auditor who needs to trace the claim back to evidence.
Preserve external references and source locations
An SBOM may point to repositories, documentation, issue trackers, distribution sites and other external references. These URLs can help verify the meaning of a description, but they are also identity-bearing links whose path, query and version information may matter. Do not translate a URL segment or replace an official repository link with a locally translated article and then imply the two are equivalent. The latter may be a useful support document, but it needs its own label and provenance rather than taking over the original source reference.
During QA, resolve a sample of important references without blindly contacting private infrastructure. Confirm that a link is of the declared kind and reaches the intended resource. If a supplier reference no longer resolves, record the problem; do not silently invent a replacement URL. A translated report may add an explanatory internal link to help readers understand a topic, yet it should keep the supplier reference available for audit. Human comprehension and machine evidence work best when both routes remain visible.
Plan fallback for incomplete component descriptions
Not every component in an SBOM will have a meaningful natural-language description. Some records contain only a name, version and a few identifiers. A translation system should not invent a function from the package name, because names can be historical, playful or misleading. Mark the description as absent or unverified and offer a link to authoritative documentation where appropriate. If a technical reviewer writes a local explanation, distinguish it from translated supplier text and give it a review date.
Fallback design matters in multilingual dashboards. An English description may be available for one library but not another, and a default-language sentence may appear in an otherwise Chinese report. Prefer a visible fallback policy, such as showing the original description with a language indicator, to silently manufacturing fluent prose. Reviewers should know whether each statement is an exact source translation, an approved local summary or a missing-data notice. Those distinctions protect trust even when complete coverage is impossible.
A final stakeholder report should distinguish an SBOM’s coverage from the complete security posture of a product. The component list may omit runtime infrastructure, externally hosted services or particular build-time inputs depending on its generation scope and available evidence. A translated introduction saying ‘the following components are recorded in the supplied SBOM’ is safer than ‘this is every software component that exists’. Discuss known coverage limitations with the supplying team and label any additions from local inventory as separate evidence. Readers need to understand where the record begins and ends before drawing conclusions about supply-chain risk.
Limits and summary
Translating descriptions in an SBOM does not validate the software, establish vulnerability status, grant licence rights or certify supplier claims. CycloneDX 1.6 defines structured data fields, not an automatic multilingual interpretation service for every viewer. Different CycloneDX releases, integrations and BOM types may impose further constraints, so each workflow needs explicit schema and tool compatibility checks. If a signed supplier document must remain authoritative, preserve it unchanged and deliver translations as clearly labelled companion material.
Translate CycloneDX information quickly by preserving its evidentiary structure and moving ordinary language into a controlled layer. People should be able to understand what a component is used for while automated systems can still identify the exact package, version and relationships. Accuracy in both layers is more valuable than fluency in one. That is how a school, business or research team can make software supply-chain records comprehensible across languages without eroding their trustworthiness.
Frequently asked questions
1. Can I translate the name of a CycloneDX component?
For an identity-preserving translation, do not replace the authoritative package name. Put a friendly localized label or explanation in a separately governed display layer.
2. What is a PURL and why must it stay fixed?
A package URL identifies software in a defined ecosystem. Editing it as if it were prose can break dependency matching and security analysis.
3. Does a component description inherently support several languages in CycloneDX 1.6?
Do not assume it does. Use documented integration rules or a separate language-labelled explanation table when multiple localized descriptions are needed.
4. Can I translate an SPDX licence identifier?
No. Preserve its controlled identifier or expression. Any natural-language explanation should remain separate and faithful to the actual licence evidence.
5. Does changing a description invalidate a supplier’s SBOM signature?
It can change the signed bytes or the document checksum. Preserve the original signed artifact and label any translated derivative appropriately.
6. Why compare dependency edges after localization?
BOM references connect components. An accidental edit can break references or hide relationships that vulnerability analysis depends on.
7. Is a valid JSON document automatically a valid CycloneDX SBOM?
No. JSON parsing only checks syntax. Validate against the correct CycloneDX schema and check semantic integrity separately.
8. Can a translated report say software is secure if it has no listed vulnerabilities?
No. Absence of a reported vulnerability is not proof of safety. Preserve evidence and uncertainty instead of amplifying claims.
9. How can we present the same SBOM in English and Chinese?
Keep the source SBOM authoritative and build a bilingual viewer or controlled sidecar keyed to stable component identities, with appropriate provenance and testing.
10. What should a reviewer test first?
Check that localized explanations connect to the correct component name, version and reference, then verify licences, risk qualifiers and unchanged relationships.
Authoritative sources
- CycloneDX official specification repository
- CycloneDX 1.6 JSON schema
- CycloneDX official project and capabilities
- Package URL specification
- SPDX licence identifier list