Is sbom-tool being deprecated?

[KalleOlaviNiemitalo]

There have been signs that Microsoft considers sbom-tool EOL/deprecated, but no official announcement. Because I have been planning to expand my use of sbom-tool in build systems, I’d like to understand whether this EOL/deprecation is real.

The description of #1457 originally included this text:

sbom-tool is in EOL/deprecation — no new properties will be added.

Also, the initial commit of that pull request contained the following text in the .features/automapper-replacement-research.md file:

> **Context:** sbom-tool is being deprecated. We need to remove the AutoMapper dependency
> with minimal changes and minimal regression risk.

On the next day though, the description was edited to remove the mention of deprecation, and another commit was added to delete the .features/automapper-replacement-research.md file.

So far, EOL/deprecation has not been announced in README.md, and no versions of the Microsoft.Sbom.DotNetTool NuGet package have been marked as deprecated. #1235 disallowing external contributions would be consistent with EOL, though.

[jeroenhabets]

Renan Luciano (@JoseRenan), Sarah Oslund (@sfoslund), Greg Villicana (@grvillic) would one of you be able to get some clarity on the sbom-tool outlook from Microsoft? Is it indeed in danger of being deprecated?

FYI: we're considering embracing this fine tool but may be forced to select an alternative.

[aetos382]

Deprecation is mentioned in #1405 (comment)

[KalleOlaviNiemitalo]

Huh. So then it might make more sense to set up my own SBOM generator using https://github.com/microsoft/component-detection and perhaps additional project-specific information. Unless that too is being deprecated…?

But I wonder what this deprecation means for the open pull requests #1530 from Microsoft and #1529 from .NET.

[ChrSchu90]

I was also looking for a solution for SBOM generation and, since there has been no official statement on this topic for almost five months, we have decided not to rely on sbom-tool going forward and will use CycloneDX instead.

Another important factor for us is support for the German BSI guideline BSI TR-03183-2. As discussed in #1531, sbom-tool currently lacks support for several metadata fields required or recommended for generating BSI-conformant SBOMs.

While cyclonedx-dotnet also still has some gaps regarding full TR-03183-2 compliance, CycloneDX seems to be the more future-proof foundation for us, especially since the BSI itself provides a CycloneDX property taxonomy for TR-03183-2.

An official statement regarding the future and maintenance status of sbom-tool would still be highly appreciated, as it would help users make an informed decision instead of having to infer the project's status from the current activity.