Fix: Exclude package SBOMs outside BuildDropPath from files section

[Copilot]

Problem

Package-level SBOMs (.spdx.json files) located outside the BuildDropPath were being incorrectly included in the files section of generated SBOMs. This caused validation failures when SBOMs were validated on different machines that only had the BuildDropPath directory available.

Root Cause

The FileInfoWriter.Generate() method was including all processed files in the files section regardless of their IsOutsideDropPath status. While the SbomToolManifestPathConverter correctly identified SPDX files outside the BuildDropPath and set IsOutsideDropPath = true, the FileInfoWriter still wrote these files to the files section.

Solution

Modified FileInfoWriter.Generate() to conditionally include files in the files section based on their location:

// Only include files in the files section if they are within the BuildDropPath
if (!sbomFile.IsOutsideDropPath)
{
    await result.Writer.WriteAsync((generationResult?.Document, config.JsonSerializer));
}

Key Benefits

• ✅ Files section now only contains files within BuildDropPath
• ✅ External document references still work correctly for package SBOMs
• ✅ Validation succeeds on machines with only BuildDropPath directory
• ✅ No regression - all existing tests continue to pass

Validation

Created test scenario with:

• Files in BuildDropPath (test_file.txt)
• Package SBOM in separate component path (package.spdx.json)

Before fix: Package SBOM would appear in files section, causing validation failures

After fix:

• Generated SBOM files section contains only test_file.txt
• Package SBOM appears correctly as external document reference
• Validation succeeds when run with only BuildDropPath directory

Fixes #956.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[github-actions[bot]]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[github-actions[bot]]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[pragnya17]

can you add a test that targets this fix

[Copilot]

can you add a test that targets this fix

Added comprehensive tests that validate the fix in commit 14190d8. The tests cover 4 key scenarios:

1. Files within BuildDropPath → included in files section ✅
2. Files outside BuildDropPath → excluded from files section ✅
3. SPDX files outside BuildDropPath → still processed for external references ✅
4. SPDX files within BuildDropPath → both included and recorded properly ✅

All tests pass, confirming the fix correctly excludes package SBOMs outside BuildDropPath from the files section while preserving their processing for external document references.

[github-actions[bot]]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[pragnya17]

/azp run

[github-actions[bot]]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[pragnya17]

/azp run

[github-actions[bot]]

This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:

• Changing the signature of an existing interface method
• Adding a new method to an existing interface
• Adding a required data member to a class that an existing interface method consumes

Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:

Option 1 - Publish this as a breaking change

1. Update the documentation to show the new functionality
2. Bump the major version in the next release
3. Be sure to highlight the breaking changes in the release notes

Option 2 - Refactor the changes to be non-breaking

1. Review this commit, which adds a new interface in a backward-compatible way
2. Refactor the change to follow this pattern so that existing interfaces are left completely intact
3. Bump the minor version in the next release

[DaveTryon]

/azp run