feat: allow Layer 2 catalogs to extend other catalogs without specifying ids

[jpower432]

Description

This PR adds extends to the Layer 2 Catalog schemas to allow extension of catalog without specifying granular ids.

Schema Changes

Schema Changes Made

• No schema changes
• Layer 1 schema (layer-1.cue) changes
• Layer 2 schema (layer-2.cue) changes
• Layer 3 schema (layer-3.cue) changes
• Layer 5 schema (layer-5.cue) changes

Schema Change Details

<!-- If applicable, provide a brief summary or example of schema changes -->

• ThreatCatalogs can extend multiple "parent" Catalogs
• ControlCatalogs can extend multiple "parent" Catalogs
• ArtifactMapping remarks are optional

Testing

• Unit tests added/updated
• Manual testing performed
• Test data updated (if applicable)

Related Issues

Reviewer Hints

Example content:

metadata:
  id: ACME-CC
  version: "1.0.0"
  description: |
    Organization-specific control catalog that extends the FINOS CCC
    base controls with additional internal requirements.
  author:
    id: acme-security
    name: ACME Security Team
    type: Human
  mapping-references:
   - id: CCC.Core
     title: Common Cloud Controls Core
     version: v2025.10
     url: https://github.com/finos/common-cloud-controls/releases/download/v2025.10/CCC.Core_v2025.10.yaml
     description: |
        Foundational repository of reusable security controls, capabilities,
        and threat models from FINOS Common Cloud Controls.
    - id: OSPS
      title: Open Source Project Security Baseline
      version: 2026.02.19
      url: https://baseline.openssf.org/versions/2026-02-19.html
      description: |
        Security criteria for open source projects organized by maturity
        level and category.
title: ACME Cloud Control Catalog

extends:
  - reference-id: FINOS-CCC
    remarks: Inherits all base cloud controls.
  - reference-id: OSPS-BASELINE

Self-review checklist

• This PR has content that was created with AI assistance.
  • I have read and followed the Generative AI Contribution Policy.
• I have the experience and knowledge necessary to answer maintainer questions about the content of this PR, without using AI.

---

[jpower432]

@eddie-knight I prematurely marked this as ready for review. Did some rethinking on it. ArtifactMapping made more sense and I think the Catalogs should be able to extend multiple parent Catalogs.

[iMichaela]

@jpower432 - What is the vision for capturing the gap-analysis for each catalog?

A more interesting problem to think of is the transitive mapping ...
A transitive relation on a set is a binary relation where, if an element A is related to B and B is related to C, then A is related to C. BUT what is the A -to- C relation when A-to-B and B-to-C are known ...

[jpower432]

@jpower432 - What is the vision for capturing the gap-analysis for each catalog?

A more interesting problem to think of is the transitive mapping ... A transitive relation on a set is a binary relation where, if an element A is related to B and B is related to C, then A is related to C. BUT what is the A -to- C relation when A-to-B and B-to-C are known ...

Thanks for the question, @iMichaela. Definitely agree that is an interesting problem to solve for.

In this instance (Layer 2), the Controls are self-contained and extending or importing a Catalog at Layer 2 is an additive, compositional process. Because the guideline-mappings (to Layer 1 Guidance Catalogs) are defined as attributes of the Control itself (in Layer 2 Control Catalog), the relationship is preserved when a catalog is resolved or flattened. When a Catalog uses extends (added in this PR) or imported-controls, it’s pulling in those self-contained technical Controls as-is and their existing mappings. I see this resolution process becoming a factor when these are imported into and reviewed as part of a Layer 3 Policy.

Does that clarify how we are maintaining those deeper-level references?

If so, this allows the gap analysis to become an analysis of that fully resolved state. Since the controls are only aggregated, the gap analysis functions as a check for any missing references to guideline IDs to provide a baseline view of Guidance Catalog coverage.

EDITED - in #304 we want to explore the nuanced quality of those mapping relationships

I'd be curious to hear your thoughts on how this might eventually export back into the OSCAL Control Mapping Model if you think this is in scope.

[iMichaela]

@jpower432 - What is the vision for capturing the gap-analysis for each catalog?
A more interesting problem to think of is the transitive mapping ... A transitive relation on a set is a binary relation where, if an element A is related to B and B is related to C, then A is related to C. BUT what is the A -to- C relation when A-to-B and B-to-C are known ...

Thanks for the question, @iMichaela. Definitely agree that is an interesting problem to solve for.

In this instance (Layer 2), the Controls are self-contained and extending or importing a Catalog at Layer 2 is an additive, compositional process. Because the guideline-mappings (to Layer 1 Guidance Catalogs) are defined as attributes of the Control itself (in Layer 2 Control Catalog), the relationship is preserved when a catalog is resolved or flattened. When a Catalog uses extends (added in this PR) or imported-controls, it’s pulling in those self-contained technical Controls as-is and their existing mappings. I see this resolution process becoming a factor when these are imported into and reviewed as part of a Layer 3 Policy.

Does that clarify how we are maintaining those deeper-level references?

If so, this allows the gap analysis to become an analysis of that fully resolved state. Since the controls are only aggregated, the gap analysis functions as a check for any missing references to guideline IDs to provide a baseline view of Guidance Catalog coverage.

EDITED - in #304 we want to explore the nuanced quality of those mapping relationships

I'd be curious to hear your thoughts on how this might eventually export back into the OSCAL Control Mapping Model if you think this is in scope.

@jpower432 - Thank you for the explanation. The reason for my question is rooted in the eventual "conversion" to OSCAL. The OSCAL model allows for one mapping-collection (a mapping artifact) to have multiple sets of mappings with distinct sources and targets. For each mapping we provision though explicit a source-gap-summary and a target-gap-summary, with a structure similar to un-resolved profile, to optimize the information processing by tools (no parsing of a set of mapping if a control is listed in a gap, but more than anything to detect errors (omitted controls).

Now - I have been thinking of control mapping and their applicability to profiles , when a control is tailored... I've been thinking of mapping use in the implementation layer when relations can be tighten based on implementation... So, I would love to learn more from this team on teh vision of using such mapping in the implementation and assessment/certification process.