A few months ago, I introduced the concept of an SBOM(Software Bill of Materials) and how you could integrate this in your Azure DevOps Pipelines.
A quick fix
Last week I noticed that the builds where I was using this approach started to fail. Here is the error I got:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\b\2\_work\_temp\f7a4bfef-55b7-46ca-bc35-5fa4674dc781.ps1'"
Encountered error while running ManifestTool generation workflow. Error: The value of PackageSupplier can't be null or empty.
##[error]PowerShell exited with code '1'.
Finishing: Generate sbom
Turns out that an updated version of the Microsoft sbom-tool was released. In this version a new required parameter was introduced;
-ps <package supplier>
So I opened the failing pipelines and added this extra argument:
# Write your PowerShell commands here.
Invoke-WebRequest -Uri "https://github.com/microsoft/sbom-tool/releases/latest/download/sbom-tool-win-x64.exe" -OutFile "$(Agent.TempDirectory)/sbom-tool.exe"
$(Agent.TempDirectory)/sbom-tool generate -b $(Build.ArtifactStagingDirectory) -bc $(Build.SourcesDirectory) -pn Example -pv 1.0.0 -nsb https://sbom.mycompany.com –ps PackageSupplierName -V Verbose
The SBOM .NET Tool
This would have been a really short post if this was the only thing I wanted to talk about. While investigating the issue above I noticed the following in the documentation:
There is now a dotnet global tool for generating the SBOM.
Time to throw out the exe and use the SBOM .NET tool instead!
I removed the original Powershell task and introduced 2 new tasks:
The first task will download and install the SBOM global tool:
The second task will invoke the installed SBOM tool:
This will produce exactly the same results as the original Powershell task:
