-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Files uploaded via arcade log commands aren't included in SDL scans by 1ES #15094
Comments
This changes required for this are non-trivial (and somewhat unknown at this point). Also, fixing this will not run SDL tooling over the binaries that .NET typically ships. Binskim does not unpack archives. .NET deals in archives. |
I don't think this is blocking because solving it will not solve the issue at hand |
Would it work if instead of uploading via the log command the PushToBuildStorage task would copy the assets to some location that we later upload via |
I don't think we want every artifact loose coming out of the pipeline. For runtime that might be a 100G of data in addition to the normal set of data. That is not a good workaround IMO. The other problem is that using PublishPipelineArtifact doesn't work with the way we publish today. Maybe we could get away with PublishBuildArtifacts, but today we join all artifacts together in PackageArtifacts and BlobArtifacts. The downstream Maestro publishing only knows how to go and find those. The current setup is built on the logging commands. When you pass -publish to your build leg, it figures out what artifacts are to be published (based on msbuild project properties and What makes this especially non-trivial to solve is that you may need to change hundreds of branches to switch. Let's say you wanted to use build artifacts still. So the -publish switch creates a manifest and stages a PackageArtifacts, BlobArtifacts, and AssetManifests dir with the contents. You then need to go and add an explicit upload step to all the pipelines to upload this data. This might be possible in templates, but I'm not sure it will cleanly apply everywhere. If you want to use pipeline artifacts, then things get hairy, because all jobs would have to have a unique artifact name, and you'd need to propagate that through the system. It would have to end up in the BAR for publishing to work. This probably requires changes to the DB, for instance. |
Arcade uploads assets via AzDO log commands here:
arcade/src/Microsoft.DotNet.Build.Tasks.Feed/src/PushToBuildStorage.cs
Lines 302 to 319 in 7808236
The problem is that 1ES PT doesn't see these and so it doesn't inject running the SDL on these artifacts. The 1ES team is aware and will fix it at some point:
Not sure if we can wait until 1ES addresses it or if we need to do some stop-gap solution for now to be compliant.
The text was updated successfully, but these errors were encountered: