Skip to content

Skip components with no matching primary in hierarchical merge - #338

Open
arpitjain099 wants to merge 1 commit into
interlynk-io:mainfrom
arpitjain099:fix/hierarchical-merge-no-primary
Open

Skip components with no matching primary in hierarchical merge#338
arpitjain099 wants to merge 1 commit into
interlynk-io:mainfrom
arpitjain099:fix/hierarchical-merge-no-primary

Conversation

@arpitjain099

Copy link
Copy Markdown

metadata.component is optional in CycloneDX, and buildPrimaryComponentList only records a primary for BOMs that have one. The hierarchical branch of combinedMerge then does this:

var newPc int
...
for i, pc := range priCompList {
    if pc.BOMRef == newPcId {
        newPc = i
        break
    }
}

if priCompList[newPc].Components == nil {

newPc stays 0 when nothing matches, and priCompList[newPc] is indexed unconditionally. Two effects:

  • merging BOMs that all lack metadata.component leaves priCompList empty, so this panics with index out of range [0] with length 0
  • merging a mix, one BOM with a primary and one without, silently nests the second BOM components under the first BOM primary, which is the wrong parent rather than a crash

Hierarchical merge is the default (config.go sets HierarchicalMerge: true), so plain sbomasm assemble over component-only SBOMs hits it.

The existing log.Error("hierarchical merge: old product does not have any component.") fires just before, but it only substitutes an empty oldPc and execution continues into the index.

This tracks whether the lookup actually matched and skips that BOM contribution with an error log when it did not, rather than defaulting to entry 0.

Test merges two component-only SBOMs through the real combinedMerge. It panics on main with the error above and passes with the change. go test ./pkg/assemble/... is green.

buildPrimaryComponentList only records a primary for a BOM that has
metadata.component, so merging BOMs without one leaves the list empty
while the loop still indexed priCompList[newPc] with newPc defaulting
to 0. That panicked with index out of range on an all-orphan merge, and
with a mix of BOMs it silently nested the orphan components under an
unrelated primary.

Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant