Validate SBOM for .NET Repos using Arcade main

[epananth]

• If your repo is using Arcade from the ‘.NET Eng – latest’ channel and using Arcade’s ([jobs.yml]) template to build, you should just need the latest arcade update to get SBOM generation automatically added to your pipelines. • If your repo is not using Arcade’s templates, or not using Arcade at all, you will need to manually add the SBOM generation task manually to every build job that creates or modifies assets. You can follow the steps outlined here to use a helper template that we’re providing through Arcade.

• Action required by 2/25/2022- SBOM validation for repos using Arcade main: We need to make sure all repositories are generating SBOMs as part of their official builds, and that those SBOMs meet certain initial requirements. Follow the steps outlined here to validate the generated SBOMs, and update status below when you have completed the work. Note that if two people are editing the issue, one of the changes might get lost, so double check that your information is recorded appropriately.

• For repositories that produce assets released via the .NET release pipeline or if your repo name is in the list here, your builds are automatically retained. • For repositories that have their own release process, you can follow the steps outlined here

Status	Description
✔️	Results verified. Good to go!
❌	Did not work

Repository	Owner	Status	Does this need sbom?	Notes
Nuget.BuildTasks	@MiYanni			Spl case, gets arcade update and inserts only to VS
ASP.Net Classic nuget packages	@StephenMolloy			New case, has not been updated in a few years (added 3/8 to this list)
aspnet-AspNetWebHooks	@dougbu	❌	N/A	we haven't built this in ages
aspnet-AspNetWebStack	@dougbu	❌		we do not have a pipeline to build this; currently builds on TeamCity
AzureSignalR-samples	@Y-Sindo	❌	N/A	No pipeline
aspnet-Benchmarks	@sebastienros	❌	N/A	No pipeline
aspnet-SignalR-Client-Cpp	@BrennanConroy	❌	N/A	Ships as code
dotnet-project-system	@MiYanni	✔️	Spl case, inserts to VS
dotnet-project-system-tools	@MiYanni	✔️		Update done, need to verify
microsoft-dotnet-framework-docker	@mthalman	❌	N/A	N/A - only produces Windows Docker images, SBOM only supports Linux Docker images
microsoft-go	@dagood	❌		Not part of .NET
microsoft-go-images	@dagood	❌		Not part of .NET
microsoft-go-infra	@dagood	❌	N/A	No pipeline: source is the asset. Not part of .NET
microsoft-go-infra-images	@dagood	❌		Not part of .NET
dotnet-diagnostictests	@hoyosjs	❌		Test only repo does not require SBOM generation
SignalR-SignalR	@BrennanConroy	✔️		Working on arcade udpate
dotnet-insertions-client	@bekir-ozturk
dotnet-roslyn-tools	@JoeRobich	✔️		https://github.com/dotnet/roslyn-tools/pull/1171
dotnet-source-indexer	@alexperovich	❌	N/A	Is a website
dotnet-arcade-extensions	@riarenas	✔️
dotnet-aspnetcore	@dougbu			https://github.com/microsoft/dropvalidator/issues/397
dotnet-crank	@sebastienros	✔️	Uses arcade release/6.0	Created on 2/21
dotnet-deployment-tools	@NikolaMilosavljevic	✔️		working on it
dotnet-diagnostics-internal-components	@hoyosjs			Look for successful build
dotnet-efcore	@dougbu	✔️		has manifests for jobs that never publish and list everything in the artifacts/ folder
dotnet-emsdk	@lewing/@akoeplinger	✔️
dotnet-fsharp	@brettfo/@kevinransom	✔️	Needs arcade update
dotnet-interactive	@colombod	✔️		Needs arcade update
dotnet-interactive-window	@tmat	✔️
dotnet-iot	@joperezr	❌	N/A	Spl repo uses arcade but is not microsoft owned
dotnet-llvm-project	@akoeplinger			(https://github.com/microsoft/dropvalidator/issues/368)
dotnet-machinelearning-assets	@ericstj	✔️		arcade update is flowing?
dotnet-machinelearning	@ericstj	✔️
dotnet-maui	@antonfirsov			arcade update is flowing?
dotnet-microsoft.maui.graphics	@mjbond-msft		arcade update is flowing?
dotnet-msbuild	@rainersigwald	✔️		Needs arcade update
dotnet-optimization	@DrewScoggins			Need work
dotnet-razor-compiler	@dougbu	✔️
dotnet-razor-tooling	@NTaylorMullen	✔️		Needs arcade update
dotnet-roslyn	@JoeRobich	✔️		Still needs update to reference SBOM from VS Component manifests
dotnet-roslyn-debug	@tmat			arcade update is flowing?
dotnet-roslyn-sdk	@JoeRobich	✔️		https://github.com/dotnet/roslyn-sdk/pull/970
dotnet-sdk	@marcpopMSFT	✔️
dotnet-source-build	@MichaelSimons	❌	N/A	No source/build in main
dotnet-source-build-reference-packages	@MichaelSimons	❌	N/A	Does not produce shippable packages
dotnet-source-build-utilities	@MichaelSimons	❌	N/A	Internal non-shipping source-build tooling
dotnet-sourcelink	@tmat	✔️
dotnet-spark	@suhsteve			Needs arcade update
dotnet-symuploader	@hoyosjs			Not sure
dotnet-templating	@vlada-shubina	✔️		Needs arcade update
dotnet-test-templates	@Haplois	✔️		Needs arcade update
dotnet-try-convert	@jmarolf	✔️		last update was in oct 21st
dotnet-upgrade-assistant	@sunandabalu	✔️		arcade update taken on 2/16
dotnet-wcf	@HongGit	✔️		Needs arcade update
dotnet-windowsdesktop	@dreddy-work	✔️		Needs update
dotnet-winforms-designer	@Shyam-Gupta	✔️		Verified that SBOM is getting generated correctly
dotnet-winforms		✔️
dotnet-winforms-datavisualization	@RussKie			last update was in dec 31st
dotnet-wpf-int	@singhashish-wpf			Needs arcade update
Microsoft-clrmd	@leculver			Needs arcade update
dotnet-docker-tools	@mthalman		N/A	N/A - Doesn't produce anything shipped to customers
microsoft-vstest	@Evangelink
Nuget.Client	@zivkan	✔️
vs-code-coverage
dotnet-arcade	@epananth	✔️
dotnet-arcade-services	@epananth	✔️
dotnet-arcade-validation	@epananth	✔️
aspnet-AspLabs	@dougbu	✔️		has manifests for jobs that never publish and list everything in the artifacts/ folder
aspnet-AspNetKatana	@Tratcher			Repo does not use Arcade; builds on TeamCity and will move to Azdo in future, they are working on this and will add sbom in future
dotnet-ef6	@dougbu	✔️		hasn't released in ages and may never again /cc @ajcvickers; oddly configured, does not create a MergedManifest.xml
dotnet-runtime-assets	@lewing	✔️
dotnet-command-line-api	@vlada-shubina	✔️
dotnet-diagnostics	@hoyosjs	✔️
dotnet-dotnet-monitor	@jander-msft	✔️
dotnet-helix-machines	@epananth	✔️
dotnet-helix-service	@epananth	✔️
dotnet-hotreload-utils	@akoeplinger	✔️
dotnet-HttpRepl	@tlmii	✔️
dotnet-icu	@lewing	✔️
dotnet-installer	@marcpopMSFT	✔️
dotnet-linker	@sbomer	✔️
dotnet-metadata-tools	@tmat	✔️
dotnet-msquic	@wfurt	✔️
dotnet-performance	@wfurt	✔️
dotnet-release	@epananth	✔️
dotnet-roslyn-analyzers	@JoeRobich	✔️
dotnet-runtime	@agocke	✔️	https://github.com/microsoft/dropvalidator/issues/397
dotnet-Scaffolding	@deepchoudhery	✔️
dotnet-source-build-externals	@MichaelSimons	✔️
dotnet-symreader	@tmat	✔️
dotnet-symreader-converter	@tmat	✔️
dotnet-symreader-portable	@tmat	✔️
dotnet-symstore	@hoyosjs	✔️
dotnet-tye	@philliphoff	✔️
dotnet-winforms-designer	@dreddy-work	✔️
dotnet-wpf	@singhashish-wpf	✔️
dotnet-xharness	@epananth	✔️
dotnet-xliff-tasks	@epananth	✔️
microsoft-reverse-proxy	@MihaZupan	✔️
dotnet-cli-lab	@joeloff	✔️		Internal build with changes succeeded, waiting to merge PR

[dougbu]

I would appreciate more context here

1. How urgent are the "Needs arcade update" items❔ ASP.NET-related repos tend to take Arcade updates ~weekly.
2. What is the point of creating an SBOM in a repo like aspnet/AspLabs which ships one package on a very irregular basis❔ We're moving that source from AspLabs to aspnetcore in any case.
3. I don't know much about aspnet-AspNetKatana @Tratcher is this yours❔
4. aspnet-AspNetWebStack is a special case. We have an internal repo for security fixes but no AzDO pipeline. Plan is to migrate builds from TeamCity to AzDO before the end of the year. Not sure how we'd create an SBOM using the current infrastructure. Suggestions❔
5. @ajcvickers should you own dotnet-ef6❔ Or is it time to declare we'll never do another EF6 release and kill that repo and associated pipelines❔

[mmitche]

I would appreciate more context here

1. How urgent are the "Needs arcade update" items❔ ASP.NET-related repos tend to take Arcade updates ~weekly.
2. What is the point of creating an SBOM in a repo like aspnet/AspLabs which ships one package on a very irregular basis❔ We're moving that source from AspLabs to aspnetcore in any case.
3. I don't know much about aspnet-AspNetKatana @Tratcher is this yours❔
4. aspnet-AspNetWebStack is a special case. We have an internal repo for security fixes but no AzDO pipeline. Plan is to migrate builds from TeamCity to AzDO before the end of the year. Not sure how we'd create an SBOM using the current infrastructure. Suggestions❔
5. @ajcvickers should you own dotnet-ef6❔ Or is it time to declare we'll never do another EF6 release and kill that repo and associated pipelines❔

1. We'd like to have SBOMs generated in main by end of next week. You probably already got the update in main though (it got checked in froday
2. Microsoft wants SBOMs for all of its supply chain, even for repos that are only providing artifacts for other repos. Since asplabs ships to customers, it should have an SBOM
3. ...
4. This one can be skipped then.
5. Up to you folks there.

[dougbu]

Since asplabs ships to customers, it should have an SBOM

Agree that's the current state. It however shouldn't ship anything in the future, given the move to dotnet/aspnetcore. Right @dotnet/aspnet-build @JamesNK❔

[JamesNK]

The gRPC source is moving from asplabs to aspnetcore. It won't ship from there anymore.

However, I think it is valuable to have a place where our product team can have experiments that can be published to NuGet to get feedback.

[dougbu]

However, I think it is valuable to have a place where our product team can have experiments that can be published to NuGet to get feedback.

That makes it a very weird case from an SBOM perspective because the pipeline build more than we'd ever release.

[mmitche]

However, I think it is valuable to have a place where our product team can have experiments that can be published to NuGet to get feedback.

That makes it a very weird case from an SBOM perspective because the pipeline build more than we'd ever release.

You could argue that about any of the .NET core repos. There will be thousands of SDK builds that never get released. The SBOM generation itself is pretty cheap, so I don't see a huge issue here

[lewing]

I have even less context here, what is needed beyond an arcade update?

[epananth]

@Lewing : If your repo is using Aracade's (job.yml/jobs.yml) template to build, SBOM generation is already in place for this scenario. So once you get an arcade update (https://github.com/dotnet/arcade/blob/main/Documentation/SBOMGenerationGuidance.md#repositories-using-arcades-jobsyml-templates)

You should be able to review SBOM (please take a look here on how to verify)(https://github.com/dotnet/arcade/blob/main/Documentation/SBOMGenerationGuidance.md#reviewing-generated-sboms-for-correctness)

In case you are NOT using (jobs.yml or job.yml) in your repo to build, you will need to follow these steps (https://github.com/dotnet/arcade/blob/main/Documentation/SBOMGenerationGuidance.md#repositories-not-using-arcades-jobsyml-templates) to generate SBOM in your repo

I also sent an email regarding this, Please let me know if this helps.

[Y-Sindo]

Regarding to repo AzureSignalR-samples, we use it as a place for samples only and there is no pipeline for the repo.

[MihaZupan]

Package name and version: After the packages section, the last entry should mention the correct name and version for the software that the SBOM is about. The name property should read as ".NET 7.0.0" for main branches, and ".NET 6.0.0" for .NET 6 release branches.

Is the name expected to be .NET 7.0.0 even for projects that don't ship as part of .NET (microsoft/reverse-proxy)?

[mthalman]

I updated the notes for microsoft-dotnet-framework-docker and dotnet-docker-tools that SBOM generation is not applicable to them.

[sebastienros]

dotnet/crank has "Has latest arcade update but still does not have sbom generated" comment. My response to this is it's using arcade release/6.0 apparently, and I saw the changes with SBOM just got pushed there. So I believe dotnet/crank will get it when there is a new release of that branch?

aspnet/benchmark doesn't have a pipeline. We are not shipping anything from this repository, it's just a set of benchmarks applications and scripts.

[Tratcher]

3. I don't know much about aspnet-AspNetKatana @Tratcher is this yours❔

Yes, that's mine. That repo doesn't use Arcade yet. We might consider switching to Arcade when we move it from TeamCity to Azdo.

[vlada-shubina]

I checked dotnet/templating and SBOM is generated in internal build from main branch. The file is very big but I checked that key outputs are present.

[epananth]

Regarding to repo AzureSignalR-samples, we use it as a place for samples only and there is no pipeline for the repo.

I will update the list. thanks for confirming

[dagood]

dotnet-diagnostictests

I don't know this repo, so I've changed the owner from myself to ❓

[epananth]

Package name and version: After the packages section, the last entry should mention the correct name and version for the software that the SBOM is about. The name property should read as ".NET 7.0.0" for main branches, and ".NET 6.0.0" for .NET 6 release branches.

Is the name expected to be .NET 7.0.0 even for projects that don't ship as part of .NET (microsoft/reverse-proxy)?

For now all the repos using arcade main to use package name as .NET 7.0.0

Package name and version: After the packages section, the last entry should mention the correct name and version for the software that the SBOM is about. The name property should read as ".NET 7.0.0" for main branches, and ".NET 6.0.0" for .NET 6 release branches.

Is the name expected to be .NET 7.0.0 even for projects that don't ship as part of .NET (microsoft/reverse-proxy)?

Yes, we want everyone who uses arcade main to use .NET 7.0.0 as package name

[BrennanConroy]

How do we handle repos that a. Don't use .NET at all b. Don't ship a physical package Specifically talking about aspnet-SignalR-Client-Cpp which is fully C++ and ships as code (i.e. you compile it yourself).

[epananth]

dotnet/crank has "Has latest arcade update but still does not have sbom generated" comment. My response to this is it's using arcade release/6.0 apparently, and I saw the changes with SBOM just got pushed there. So I believe dotnet/crank will get it when there is a new release of that branch?

aspnet/benchmark doesn't have a pipeline. We are not shipping anything from this repository, it's just a set of benchmarks applications and scripts.

dotnet-crank- Yes we have PR (https://github.com/dotnet/arcade/pull/8479) merged for release/6.0, you should get an update soon.

Thanks for confirming

[MichaelSimons]

@epananth - I am having some troubles with dotnet-source-build-reference-packages and am wondering if you can help out. I got the repo updated on the latest arcade version but the build is still not running the SBOM generation leg - https://dev.azure.com/dnceng/internal/_build/results?buildId=1619144&view=logs&s=6884a131-87da-5381-61f3-d7acc3b91d76&j=2f0d093c-1064-5c86-fc5b-b7b1eca8e66a. The build is utilizing the Arcade job template as illustrated here

[epananth]

@BrennanConroy

How do we handle repos that a. Don't use .NET at all b. Don't ship a physical package Specifically talking about aspnet-SignalR-Client-Cpp which is fully C++ and ships as code (i.e. you compile it yourself).

I will have to get back to you on this one.

[epananth]

@epananth - I am having some troubles with dotnet-source-build-reference-packages and am wondering if you can help out. I got the repo updated on the latest arcade version but the build is still not running the SBOM generation leg - https://dev.azure.com/dnceng/internal/_build/results?buildId=1619144&view=logs&s=6884a131-87da-5381-61f3-d7acc3b91d76&j=2f0d093c-1064-5c86-fc5b-b7b1eca8e66a. The build is utilizing the Arcade job template as illustrated here

Taking a look

[epananth]

We don't need to produce sboms for dotnet-source-build-reference-packages. Going to update the list.

[MiYanni]

@epananth dotnet-project-system doesn't use Arcade.

[epananth]

@MiYanni Updated dotnet-project-system, what about dotnet-project-system-tools?

[MiYanni]

@epananth dotnet-project-system-tools currently uses Arcade. We've merged the Arcade update to do SBOM generation. I'll review it for correctness as I finish implementing SBOM manually for dotnet-project-system.

[zivkan]

@epananth NuGet.Client does not use Arcade, so I'm working through trying to get it all working.

MicroBuild/DevDiv requires the sbom to be included in the vsix. Taking a quick look at the docs you linked, it looks like dnceng only requires the sbom to be published as a build artifact. Is that correct? There's no requirement to embed the sbom in nupkgs promoted to BAR or published to nuget.org?

[epananth]

@epananth NuGet.Client does not use Arcade, so I'm working through trying to get it all working.

MicroBuild/DevDiv requires the sbom to be included in the vsix. Taking a quick look at the docs you linked, it looks like dnceng only requires the sbom to be published as a build artifact. Is that correct? There's no requirement to embed the sbom in nupkgs promoted to BAR or published to nuget.org?

Yes it need to be published as a build artifact, no need to publish to BAR

[Forgind]

For dotnet/msbuild: I tried to follow the steps to verify our generated SBOM is correct. I found one thing I think is a problem and two things I wanted to ask about. The license information on our packages is "NOASSERTION" instead of MIT license. I think this needs fixing? The name property of spdxVersion is .NET 6.0.0 rather than .NET 7.0.0 even though this is from main. rainersigwald said that is correct because we're shipping in SDK 6.0.300 still. I checked that Microsoft.Build.dll, Microsoft.NET.StringTools.dll, Microsoft.Build.Tasks.Core.dll, and Microsoft.Build.Conversion.Core.dll were all present in both the packages section and the files section, though I didn't verify that they were present in all flavors. We have other assemblies, but that's a representative sample. Is there something else I should verify here?

[epananth]

For dotnet/msbuild: I tried to follow the steps to verify our generated SBOM is correct. I found one thing I think is a problem and two things I wanted to ask about. The license information on our packages is "NOASSERTION" instead of MIT license. I think this needs fixing? The name property of spdxVersion is .NET 6.0.0 rather than .NET 7.0.0 even though this is from main. rainersigwald said that is correct because we're shipping in SDK 6.0.300 still. I checked that Microsoft.Build.dll, Microsoft.NET.StringTools.dll, Microsoft.Build.Tasks.Core.dll, and Microsoft.Build.Conversion.Core.dll were all present in both the packages section and the files section, though I didn't verify that they were present in all flavors. We have other assemblies, but that's a representative sample. Is there something else I should verify here?

1) License information is part of the tool. I don't think we have access to change it. But I will talk to SBOM folks to more info on that. 2) About the Package version, AFAIK we are going for .NET 7.0.0 for arcade main and arcade release/6.0 will use .NET 6.0.0, I already merged that PR (https://github.com/dotnet/arcade/pull/8479), you should already have an arcade update for that. 3) At this point we are not concerned about overreporting. Make sure you are able to verify that all your build outputs and dependencies are present in the manifest.

Let me know if this helps, we can chat offline if you have any other questions

[hoyosjs]

RE: dotnet/symreader, dotnet-symreader-portable, and dotnet-symreader-converter. These are repos I don't really own. I think @tmat is the person who's familiar with those.

RE: dotnet-diagnostics-internal-components. @BillHiebert, do you know if the repo is still in use and who's looking at it?

RE: dotnet/symstore, dotnet/diagnostics, and dotnet-symuploader. Symuploader was the only one missing the arcade update - somehow automerge suddenly needs a reviewer in the internal repo and no one was paying attention. I've noticed that the SBOM has a ton of non-prod assets (all our test, which is more than product bits, and it includes assets from legs that don't produce assets - even logs that we generate per test. This makes it hard to validate things). Also: All licenses are NOASSERTION, all download locations are NOASSERTION too. The files section doesn't have any of the nupkgs generated, only the files that would go in the packages. For package name, I see "Package name and version" being .NET 7; we ship out of band. That name is fine for all intents and purposes from our perspective. If all these are fine, feel free to mark those three as done.

RE: dotnet-diagnostictests. It's a test-only repository. It does not produce any shipping bits.

[BillHiebert]

@hoyosjs - that repo is still in use as it is where the hot reload components live.

[epananth]

@hoyosjs

1) We are not concerned about overreporting at this point, so we want to include everything for now. 2) All licenses are NOASSERTION, all download locations are NOASSERTION - we do not have an option to change this for now, I am going to talk to SBOM folks and get back on this. 3) Files section does not have nupkgs - can you point the build to me?

I will update the owners in the issue.

[hoyosjs]

I see what was going on - we generate assets in completely different legs where we pack them. I was looking at a manifest that generated the binaries but hadn't packed them yet I believe. I have verified the leg that does pack + sign and they look to be there. Sorry for the false alarm

[dougbu]

This process is annoying for a pipeline (like aspnetcore-ci-official) with 8 different jobs producing assets. I'll need to update my validation script to handle the number of files here.

I would appreciate the following changes before we have to do this again:

1. At a minimum, publish the SBOM files to a single artifact with appropriately unique names
   • This is required even if the files are kept separate (see (2)) because the number of artifacts is unweildy
2. Better to merge build-specific manifest.spdx.json files into a single one, akin to MergedManifest.xml
3. Some type of validation e.g. a comparison w/ a fake merged manifest in PR validation would be ideal

[dougbu]

Oh, I forgot: The SBOM generation fails on Linux MUSL x64 but produces an empty artifact named after the job. Please either shut it off on that platform or find a way to fix the bug. In the meantime, we can skip CG on that platform; can we skip SBOM generation too❔

[dougbu]

Most of my comments above were based on aspnetcore-ci-official. In other news, AspLabs-ci-official and efcore-ci-official seem to produce SBOM files and artifacts in jobs that list mostly test results and obj/ files in the SBOM files. The jobs also produce packages and those are listed but only the Windows job in either build would ever be used to ship anything. How should I handle this extreme over-reporting?

For the future, can SBOM generation be disabled in jobs that do not produce a manifest XML file❔

[dougbu]

To get a reasonable comparison between the SBOM files and asset manifests, I adjusted my script to exclude files named *-ci* and include non-shipping files from asset manifests. I suggest all but dotnet-aspnetcore should be checked off but leave that decision to you @epananth.

Results

• aspnet-AspLabs looks fine though there's a lot of useless information in the extra SBOM files
• dotnet-aspnetcore is missing a few shipping assets due to the inability to produce SBOM files on Linux MUSL x64
• dotnet-ef6 looks fine
• dotnet-efcore looks fine though there's a lot of useless information in the extra SBOM files
• dotnet-razor-compiler looks fine

More details

aspnet-AspLabs

``` text *asplabs.xml --> manifest.asplabs*.json [-] MergedManifest.xml ```

dotnet-aspnetcore

``` text *aspnetcore.xml --> manifest.aspnetcore*.json [-] aspnetcore-runtime-7.0.0-preview.3.22117.6-linux-musl-x64.tar.gz [-] aspnetcore-runtime-7.0.0-preview.3.22117.6-linux-musl-x64.tar.gz.sha512 [-] aspnetcore-runtime-internal-7.0.0-preview.3.22117.6-linux-musl-x64.tar.gz [-] aspnetcore-runtime-internal-7.0.0-preview.3.22117.6-linux-musl-x64.tar.gz.sha512 [-] MergedManifest.xml [-] Microsoft.AspNetCore.App.Runtime.linux-musl-x64.7.0.0-preview.3.22117.6.nupkg [-] Microsoft.AspNetCore.App.Runtime.linux-musl-x64.7.0.0-preview.3.22117.6.symbols.nupkg [-] Microsoft.SourceBuild.Intermediate.aspnetcore.7.0.0-preview.3.22117.6.nupkg [-] Microsoft.SourceBuild.Intermediate.aspnetcore.7.0.0-preview.3.22117.6.symbols.nupkg ```

dotnet-ef6

``` text *ef6.xml --> manifest.ef6*.json ```

dotnet-efcore

``` text *efcore.xml --> manifest.efcore*.json [-] MergedManifest.xml ```

dotnet-razor-compiler

``` text *razor-compiler.xml --> manifest.razor-compiler*.json [-] MergedManifest.xml [-] Microsoft.SourceBuild.Intermediate.razor-compiler.7.0.0-preview.3.22116.4.nupkg [-] Microsoft.SourceBuild.Intermediate.razor-compiler.7.0.0-preview.3.22116.4.symbols.nupkg ```

[dougbu]

Not sure what to do about aspnet-AspNetWebHooks. We have a pipeline but it doesn't use Arcade and only publishes to the general-testing and general-testing-symbols feeds. The repo contains legacy (desktop) ASP.NET WebHooks and we last published packages from it to NuGet in 2019. We have no plans for another release.

[dougbu]

Are we supposed to check .NET 6 as well❔

Note: aspnet-AspLabs publishes to the .NET 6 channel but uses Arcade from the .NET Eng - Latest channel. This confuses the SBOM files. They use the name .NET 7.0.0.

[epananth]

@dougbu those are great suggestions, I created an issue to look into this in future -> https://github.com/dotnet/core-eng/issues/15671

• At a minimum, publish the SBOM files to a single artifact with appropriately unique names

  • This is required even if the files are kept separate (see (2)) because the number of artifacts is unweildy
• Better to merge build-specific manifest.spdx.json files into a single one, akin to MergedManifest.xml
• Some type of validation e.g. a comparison w/ a fake merged manifest in PR validation would be ideal

We unfortunately do not want to to turn off sbom generation for now. We have an issue opened for Sbom folks (https://github.com/microsoft/dropvalidator/issues/368) Once that is fixed that should go away.

Most of my comments above were based on aspnetcore-ci-official. In other news, AspLabs-ci-official and efcore-ci-official seem to produce SBOM files and artifacts in jobs that list mostly test results and obj/ files in the SBOM files. The jobs also produce packages and those are listed but only the Windows job in either build would ever be used to ship anything. How should I handle this extreme over-reporting?

For the future, can SBOM generation be disabled in jobs that do not produce a manifest XML file❔

Overreporting at this stage is intentional, so we want to keep it that way for now.

thanks for confirming the list of repos. I will update the issue.

Not sure what to do about aspnet-AspNetWebHooks. We have a pipeline but it doesn't use Arcade and only publishes to the general-testing and general-testing-symbols feeds. The repo contains legacy (desktop) ASP.NET WebHooks and we last published packages from it to NuGet in 2019. We have no plans for another release.

I think we don't have to create SBOM for this, since you have no plans for another release.

Are we supposed to check .NET 6 as well❔

Note: aspnet-AspLabs publishes to the .NET 6 channel but uses Arcade from the .NET Eng - Latest channel. This confuses the SBOM files. They use the name .NET 7.0.0.

Not yet.

I will get back to you on aspnet-AspLabs

[dougbu]

@epananth thanks for your responses.

We have an issue opened for Sbom folks (https://github.com/microsoft/dropvalidator/issues/368) Once that is fixed that should go away.

I don't believe that issue really covers the problems doing SBOM generation on Linux MUSL x64 machines. Is there another issue to track for that❔

[epananth]

@dougbu I am going to run another build with better verbosity and look into that further. Will keep you posted..

[mmitche]

3. I don't know much about aspnet-AspNetKatana @Tratcher is this yours❔

Yes, that's mine. That repo doesn't use Arcade yet. We might consider switching to Arcade when we move it from TeamCity to Azdo.

@Tratcher We need determine the applicability of the EO to the repo. Can you figure out whether katana is in scope for 3/8 based on the Scope section here? https://eng.ms/docs/initiatives/executive-order/executive-order-requirements/executiveorderoncybersecurity/overview

If it is, then the TeamCity dependency will need to be removed. Is there a timeline on that?

[Tratcher]

Katana produces the Microsoft.Owin libraries used to build a variety of cloud services so it probably qualifies as a top level dependency? I don't see anything in the list that would disqualify it.

We're planning to move it off TeamCity in the next few months, but don't have a specific schedule yet. Does the deadline matter if there are no builds/releases scheduled right now? We don't expect to do a release from that repo for the next few months.

[joeloff]

@mmitche @marcpopMSFT Should we include https://github.com/dotnet/cli-lab? That's where the uninstall tool lives.

[mmitche]

@mmitche @marcpopMSFT Should we include https://github.com/dotnet/cli-lab? That's where the uninstall tool lives.

Yeah, I think so /cc @epananth

[epananth]

@mmitche @marcpopMSFT Should we include https://github.com/dotnet/cli-lab? That's where the uninstall tool lives.

Yeah, I think so /cc @epananth

Added to the list.

[zivkan]

Update on NuGet.Client:

NuGet.Client is a mono-repo that builds both our VS "extension" and the code that gets inserted into the .NET SDK. I imagine that Roslyn is in a similar position. However, NuGet.Client does not use Arcade or Helix or basically any dnceng infrastructure. For testing our VS extension, we use VSEng's DartLab, which requires us to create a "VS bootstrapper". MicroBuild's "Create VS Bootstrapper" doesn't currently (well, as of Tuesday this week) strip out the sbom from the vsman files, which the "real" VS build does, which means that NuGet's build is failing to install VS on DartLab, which means we can't get green builds to merge my change.

Additionally, NuGet.Client's builds have always pre-created/downloaded some test packages that test execution will use to validate the build. These packages are not used to build NuGet, not even build the tests, but 1ES's sbom.json generation detects these packages addinng a LOT of noise into the sbom.json file, including packages that don't have license information. Due to the short notice of this sbom requirement, we haven't had time to redesign our builds to avoid this problem. Our first implementation of sbom in our builds will contain this noise, and we'll schedule work in the future to try to improve our pipeline, but I personally and hoping that 1ES improve their sbom task to do analysis of builds to detect what's actually used, rather than just detect all packages on the CI agent.

TL;DR, I have a branch/PR with minimum changes to comply with both dnceng and VS requirements for sbom, even if the quality of the contents of the sbom.json is poor. I'm blocked on a MicroBuild pipeline task bug before I can get a green build to merge my PR.

Edit: Here's the issue tracking what's blocking us: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1487491 Looks like code has already been changed, and is just waiting for deployment, so new pipeline runs can use it.

[mmitche]

This is a good approach. The tooling will improve over time, and likely will eventually become per-package (this is my educated guess) rather than "gather everything up and mash it into one file". Get something minimal working now, and we'll iterate later.