sources.allowed aborts on scanned YAML files with duplicate keys

[TSP0wni3]

Summary

supply-chain.approved-sources aborts the whole rule evaluation when a scanned YAML file contains a duplicate mapping key. Forge workflow files legitimately contain duplicate keys (GitLab CI merges repeated job-name keys when overriding included templates), so a single such file blocks the entire supply-chain check.

Classification

Bug

Version and provenance

• Hoolicy: 0.4.0
• Linux x64 release asset SHA-256: 7b2010f66f61d59b2f6e918cab9928bed32d829ea628864fcfe695c1f781b096
• Platform: Linux x86_64
• Pack: supply-chain@0.1.0 from tag v0.4.0
• The real-world pipeline file is internal; the generic fixture below reproduces the defect without it

Reproduction

Create pipeline.yml:

jobs:
  build:
    image: allowed.example.com/x:1
  build:
    image: allowed.example.com/x:2

Enable the pack with any approved registries and run:

hoolicy check

Expected and actual behavior

Expected: the file is skipped with a diagnostic (or parsed leniently), and the rule still evaluates every other file. A policy engine reading arbitrary repository content must not let one forge-specific document abort the scan.

Actual:

hoolicy: rule supply-chain.approved-sources: pipeline.yml: duplicate key "build" at 4:3 (first at 2:3)

The check exits with an error and no findings are produced.

Evidence and scope

Strict duplicate-key rejection is the right default for Hoolicy's own policy documents; the defect is applying that strictness to arbitrary scanned content. The fixture is minimal; the real file used duplicate top-level job names to override included CI templates, a pattern the forge accepts.

This issue covers scanned-content robustness. Policy-file strictness should remain unchanged.

Acceptance criteria

• A scanned YAML file with duplicate keys degrades to a per-file diagnostic (or a lenient last-wins parse) without aborting the rule.
• The rule still reports disallowed registries in other files of the same run.
• Pack fixtures cover duplicate keys, forge custom tags such as !reference, and merge anchors in scanned YAML.
• Hoolicy's own policy parsing stays strict.