Add Guardian SDL pipeline after internal builds - #649
Conversation
| to disable "BA3001.EnablePositionIndependentExecutable.Options". | ||
| --> | ||
| <Properties Type="PropertiesDictionary"> | ||
| <!-- Go doesn't build PIE executables by default: https://github.com/microsoft/go/issues/104 --> |
There was a problem hiding this comment.
In case it makes a difference, windows defaults to PIE since go1.19: golang/go#35192
There was a problem hiding this comment.
Hmm, the commit that closed the issue actually says it's in go1.15, is there something else in go1.19 that ends up enabling it?
But either way, I last touched this file for go1.16 or go1.17, so I'll try a fresh run without this exception and see what happens.
There was a problem hiding this comment.
Wops, I meant 1.15.
There was a problem hiding this comment.
BinSkim sees that the Windows binaries are PIE, but it complains about the Linux binaries. (Every arch.) I added a note to #104 and I'll add some more detail to this comment. I think the exception has to stay for now--I haven't been able to find a way to filter a rule for some files and not others.
https://dev.azure.com/dnceng/internal/_build/results?buildId=1905501&view=results
* Add Guardian SDL pipeline after internal builds * Guardian README.md: note Microsoft internal auth * Update PIE exception note (cherry picked from commit ebceed2)
* Add Guardian SDL pipeline after internal builds * Guardian README.md: note Microsoft internal auth * Update PIE exception note (cherry picked from commit ebceed2)
Add SDL validation stage to our internal (official) builds, based on Arcade. See https://github.com/dagood/go/blob/dev/dagood/sdl-stage/eng/compliance/Guardian/README.md
My initial implementation was to include SDL validation as a stage in the internal rolling pipeline, but it added 25 minutes (not including queue time) to the completion time--nearly doubling the build's total time. Instead, I changed SDL validation into a new pipeline that triggers automatically after each internal rolling build. This keeps the extra time out of our servicing release critical path, while still running validation on every build so we know as soon as possible when there's some compliance/security issue detected. (I'll configure AzDO to send an email notification when this pipeline fails. I haven't seen any flakiness yet in my test runs, but we'll see how this goes.)
A bonus of moving this build out of the main rolling build pipeline is that if it is flaky, or if it returns a false positive, we can continue the release without having to retry the build or otherwise work around the fail status.
Example run: https://dev.azure.com/dnceng/internal/_build/results?buildId=1898747&view=results
eng/common/templates/job/execute-sdl.yml.