Refactor dependency handling for spdx/cdx

[viveksahu26]

Related to #598

This PR adds the following changes:

The previous dependency logic for most compliances were similar especially across profiles. Due to which it causes incorrect and misleading results. One of the most incorrect logic was checking every component for dependencies and scoring it as valid only if had at least one dependency. This causes 2 major issues:

• Not all components are expected to have dependencies. Obviously there has to be an end and that is known as leaf element.
• just assuming if a component has more than one dependency means completess, without checking composition.

And also we evaluated SBOM-level depdnecny for primary component and for Component-level depndencies separately, even although most compliance do not distinguish b/w these as independent requiements.

Because of this, the depdnency logic needed a correction and strictness for their compliance standards. So, as I started digging out more strictly with the defintion of each compliances, found that each defintion had their different motive for dependencies.

For example,

• BSI focuses on correctness, not quantity. It does not care how many dependencies a component has. If a component declares dependencies, those dependencies must be valid and present in the SBOM. A leaf component with no dependencies is perfectly valid and should score full.
• FSCT emphasizes coverage and completeness. It evaluates how thoroughly relationships are declared across the dependency graph and whether completeness is explicitly asserted, rather than simply counting dependencies.
• NTIA is centered on the primary component and its direct dependencies. It does not require evaluating dependency depth or completeness for every component in the SBOM.

Official Defintion

1. BSI (TR-03183-2 v1.1 / v2.0 / v2.1)

Dependencies on other components. Enumeration of all components on which this component is directly dependent, or which this component contains.

Key implications:

• Dependency requirements are component-scoped
• Leaf components are valid
• No SBOM-level or primary-component dependency requirement exists

2. FSCT (Framing Software Component Transparency)

Relationship means how one component is associated with other components in the SBOM. The type of relationship can vary.

- Minimum Expected:
  - Relationships declared for the Primary Component
  - Relationship completeness declared for the Primary Component
  - Relationships declared for direct Dependencies
  - Relationship completeness declared for direct Dependencies

- Recommended Practice:
  - Relationships and relationship completeness declared for all Included Components, not just direct Dependencies

- Aspirational Goal:
  - Relationships and relationship completeness declared for as many dynamic and remote
    Components as possible

Key implications:

• Maturity is driven by relationship coverage, not just certainty
• Leaf components with declared completeness are Minimum, not Recommended
• Recommended maturity requires expanding the dependency graph
  Basically, an SBOM

3. NTIA Minimum Elements

Dependency Relationship

• Characterizing the relationship that an upstream component is included in software Y.

Depth

• At minimum, all top-level dependencies must be listed
• Transitive depth is encouraged but not required

Key implications:

• NTIA focuses on primary component dependencies only
• Component-level dependency scoring is unnecessary
• No “included-in” semantics are required

3.Interlynk (Internal Profile)

• Dependency features distinguish between:
  • Dependency presence
  • Dependency completeness
• Completeness is evaluated only where dependencies are declared
• Transitive and unrelated components are intentionally ignored

What's new added ?

• Unified dependency parsing for SPDX and CycloneDX
• Removed ambiguous “included-in” heuristics where not defined by spec

Major changes

• Refactored dependency handling to use a unified, spec-agnostic relationship graph.

• Added the following methods to the document interface:

  • GetRelationships()
    Returns all relationships of all types in the SBOM. This acts as the source of truth for dependency and relationship analysis.
  • GetOutgoingRelations(compID)
    Returns all outgoing relationships for a specific component, regardless of relationship type (e.g. DEPENDS_ON, CONTAINS, etc.).
  • GetDirectDependencies(compID, relTypes...)
    Returns all direct dependencies of a component filtered by relationship type.
    For example, providing a component ID with DEPENDS_ON returns only its direct runtime/build dependencies.