Introduction

1. Configure Custom Fields

Project administrators configure custom fields at the project level to capture safety metadata. Example fields are:

• Safety relevance class
• Safety analysis reference
• Component owner

Field Details

Safety Relevance Class

• Field type: Dropdown
• Purpose: Classifies a component based on its role in a safety-critical function.

Example Values

• safety_critical
• safety_adjacent
• non_safety

Example Interpretations

• safety_critical — Component operates in a safety-critical execution domain.
• safety_adjacent — Component supports or interacts with a safety-critical function.
• non_safety — Component has no safety relevance.

Safety Analysis Reference

• Field type: Free text
• Purpose: Records the identifier of the document or analysis supporting the classification.

Example Values

• TARA ID
• HARA ID
• Risk register entry
• Design review identifier
• System architecture reference
• Internal safety assessment

Component Owner

• Field type: Free text
• Purpose: Identifies the individual or team responsible for maintaining the metadata.

2. Classify Components

Component owners review each inventory item and populate the configured fields.

For each component:

• Select a safety relevance class.
• Enter a safety analysis reference (if applicable).
• Record the responsible component owner.

You should revisit classifications when:

• System architecture changes.
• Safety analyses are updated.
• Components take on new roles.
• Organizational policies change.

3. Generate a CycloneDX Report

After populating metadata, generate a CycloneDX report for the project. The report can include:

• Component PURL
• Safety relevance class
• Safety analysis reference
• Component owner

The exported data reflects the current metadata at the time of report generation.

4. Export Safety Metadata Using CycloneDX Properties

Safety metadata is included using the CycloneDX properties extension mechanism. The following is an example.

"properties": [
  {
    "name": "safetyRelevance:safety_relevance_class",
    "value": "safety_critical"
  },
  {
    "name": "safetyRelevance:safety_analysis_ref",
    "value": "TARA-2024-BR-007"
  },
  {
    "name": "safetyRelevance:component_owner",
    "value": "Platform Security Team"
  }
]

Downstream tools may process these properties differently depending on their implementation.

After completing these steps, you’ll have safety relevance metadata attached to your component inventory and included in CycloneDX exports. This helps you:

• Add context to vulnerability data.
• Support audits and governance workflows.
• Improve risk prioritization.

Disclaimer

• Safety relevance classification is customer-defined.
• Revenera Code Insight does not determine whether a component is safety-critical or validate safety compliance.
• Classification decisions remain the responsibility of your organization.

Common Use Cases

You can use this approach in scenarios such as:

• Automotive cybersecurity and safety engineering.
• Medical device software inventories.
• Industrial control systems.
• Aerospace and defense software assurance.
• Internal governance and audit reporting.

Key Considerations

• Metadata is maintained manually by project teams.
• Classification schemes are organization-specific.
• CycloneDX tools may handle custom properties differently.
• Consistent naming improves interoperability.
• Review metadata regularly as systems evolve.

Frequently Asked Questions

Do all components require a safety analysis reference?
No. You can decide when references are required. Many teams only require them for safety-critical or safety-adjacent components.

Can safety relevance values be customized?
Yes. The listed values are examples. You can define your own based on governance requirements.

Does Revenera automatically determine safety relevance?
No. This metadata is managed manually by your team.

Are safety properties part of the CycloneDX standard?
CycloneDX supports extensibility through the properties mechanism, allowing you to include custom metadata.

How often should classifications be reviewed?
Review frequency depends on your organization, but updates are typically made when architecture, analysis, or policies change.