[REFACTOR]: Consolidate service into component

[stevespringett]

Refactor: Unify services as a component type for improved schema consistency

Summary

This proposal seeks to refactor the separate service object definition into the existing component model by introducing service as a new component type. This architectural change would provide greater uniformity across the CycloneDX specification, reduce schema duplication, and simplify tooling implementations.

---

Background and Motivation

Currently, CycloneDX maintains two parallel object definitions for inventorying assets:

1. Components — used for software libraries, applications, firmware, devices, cryptographic assets, ML models, data, and other tangible or logical artifacts.
2. Services — used for microservices, APIs, function-as-a-service (FaaS), and other network or intra-process services.

Whilst these objects share numerous properties (e.g., bom-ref, group, name, version, description, licenses, externalReferences, properties), they are defined separately in the schema. This separation creates several challenges:

• Duplication: Common properties are duplicated across both definitions, increasing maintenance burden.
• Inconsistent capabilities: Components support identity mechanisms, evidence, pedigree, and hashes, whilst services do not — despite services often benefiting from such capabilities.
• Tooling complexity: Implementations must handle two distinct object types when traversing BOMs, complicating parsers, validators, and analytical tools.
• Dependency graph ambiguity: The dependency object already references both components and services interchangeably, implying conceptual parity.

---

Current State Analysis

Shared properties between component and service:

Property	Component	Service
bom-ref	✓	✓
group	✓	✓
name	✓	✓
version	✓	✓
description	✓	✓
licenses	✓	✓
externalReferences	✓	✓
properties	✓	✓
releaseNotes	✓	✓
patentAssertions	✓	✓

Service-specific properties requiring accommodation:

• provider — analogous to manufacturer/supplier
• endpoints — URI endpoints for the service
• authenticated — indicates whether authentication is required
• x-trust-boundary — indicates whether using the service crosses a trust boundary
• trustZone — the name of the trust zone
• data (serviceData) — data flow direction and classification

Component-only properties that services would gain:

• Identity: purl, cpe, swid, omniborId, swhid, etc
• Provenance: pedigree, evidence
• Classification: scope, mime-type, copyright

---

Proposed Changes

1. Add service to the component type enumeration:

   "type": {
     "enum": [
       "service"
     ],
     "meta:enum": {
       "service": "A service including microservices, function-as-a-service (FaaS), APIs, and other types of network or intra-process services."
     }
   }

This change would additionally leverage #718 to support provider and #638