Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Security Build Definition#20873

Merged
ravimeda merged 14 commits intodotnet:masterfrom
ravimeda:sec_ext
Jun 16, 2017
Merged

Security Build Definition#20873
ravimeda merged 14 commits intodotnet:masterfrom
ravimeda:sec_ext

Conversation

@ravimeda
Copy link
Copy Markdown
Member

@ravimeda ravimeda commented Jun 9, 2017

Introducing build definition that will run security tools required to comply with Security Development Lifecycle (SDL). The build definition puts together VSTS extensions that run the tools, analyze logs, and upload results to Trust Services Automation that creates workitems for identified security issues.
List of tools included in this definition are:

  1. BinSkim - validates compiler/linker settings and other security-relevant binary characteristics. https://github.com/Microsoft/binskim
  2. APIScan - determines whether or not the software complies with the API Usage Standard of the Interoperability Policy.
  3. CredScan - index and scan for credentials or other sensitive content.
  4. PoliCheck - scan code, code comments, and content for words that may be sensitive for legal, cultural, or geopolitical reasons.

Approach followed in this build is:

  1. Get NuGet packages corresponding to the specified official build.
  2. Extract packages to $(Build.SourcesDirectory)\security
  3. Run BinSkim and APIScan on the extracted packages
  4. Get sources corresponding to the official build. This means checkout at the SHA listed version.txt
  5. Run CredScan and PoliCheck on the sources.

Running this build identified the following issues https://msazure.visualstudio.com/defaultcollection/One/_workitems?tempQueryId=f4c69d04-1a80-4fef-ad4b-8f0dd0a8af04

@morganbr @weshaggard @chcosta @dagood PTAL
Cc @gkhanna79

Edit 6/12: Described the approach for the build, and updated the query link.
Edit 6/12: Fixed type "Trust Services Automation"

@chcosta
Copy link
Copy Markdown
Member

chcosta commented Jun 9, 2017

image
#Resolved

"scriptName": "",
"arguments": "$(Build.SourcesDirectory) $(PB_CloudDropAccountName) $(PB_CloudDropAccessToken) $(PB_CloudDropContainer)",
"workingFolder": "$(Build.SourcesDirectory)",
"inlineScript": "param($SrcDir, $account, $token, $container)\n$syncCmd = Join-Path \"$SrcDir\" \"sync.cmd\"\n$p = Start-Process $syncCmd -ArgumentList \"-ab -- /p:CloudDropAccountName=$account /p:CloudDropAccessToken=$token /p:ContainerName=$container\" -PassThru -NoNewWindow -ErrorAction Stop -Wait -Verbose \nWrite-Host \"Exit Code: $($p.ExitCode)\"\n\n\n",
Copy link
Copy Markdown
Member

@chcosta chcosta Jun 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of inline scripts, any reason these can't be done with BuildTools? #Resolved

Copy link
Copy Markdown
Member Author

@ravimeda ravimeda Jun 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Copy Markdown
Member Author

@ravimeda ravimeda Jun 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a lot of inline scripts, any reason these can't be done with BuildTools?

This particular script is simply running sync.cmd, which is similar to how other build definitions do. But for other inline scripts such as extract packages, yes, having something in BuildTools such as an MSBuild target that can be used cross-plat is better choice. I can log an issue to track that work. What do you guys say? #Closed

Copy link
Copy Markdown
Member

@chcosta chcosta Jun 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need an inline script to run a command? Why not just run the command from a command window the same way a dev would? #Resolved

@morganbr
Copy link
Copy Markdown

morganbr commented Jun 9, 2017

@ravimeda this looks like a good start. Some of the BinSkim issues suggest you need to fix a couple things:

  1. You need to ensure symbols for the product are on BinSkim's symbol path. Errors like bug 1229205 Missing Symbols for mscordaccore.dll prevent BinSkim from properly scanning those binaries.
  2. Lots of dlls being scanned aren't part of the product. In particular, I see lots of errors for api-ms-*, which are part of the Windows SDK, not the product.

Once you have those fixed up, it'll be easier to see whether there are any other issues needing action.

What's your plan to suppress/baseline false positives, which there seem to be a lot of from CredScan and PoliCheck? #Resolved

"timeoutInMinutes": 0,
"condition": "succeeded()",
"task": {
"id": "3056813a-40e9-4b2f-8f6b-612d1bc4e045",
Copy link
Copy Markdown
Member

@weshaggard weshaggard Jun 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do all these tools already have custom vsts tasks associated with them? #Resolved

Copy link
Copy Markdown
Member Author

@ravimeda ravimeda Jun 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, each tool has a custom VSTS task referred to as Security Extension. Details at http://aka.ms/sdtvsts #Resolved

@ravimeda
Copy link
Copy Markdown
Member Author

ravimeda commented Jun 12, 2017

Thanks @morganbr Couple comments -

  1. Updated the arguments for BinSkim and APIScan through commit 63cfeca
  2. Verified that all references to api-ms-* are from the test CoreCLR run I did a few days ago. CoreFx packages do not contain any api-ms-*.
  3. I'll do a couple CoreFx test builds to ensure there are no symbol-not-found errors.
  4. I'm following up with TSA to clarify on how to suppress false positives.

@chcosta @dagood logged dotnet/buildtools#1565 to avoid custom PowerShell script to extract packages.
#Closed

@morganbr
Copy link
Copy Markdown

morganbr commented Jun 13, 2017

@ravimeda , sounds good. When you have new BinSkim results, let me know and I'll take a look. #Resolved

@ravimeda
Copy link
Copy Markdown
Member Author

ravimeda commented Jun 14, 2017

Cleared up the noise from test builds, and did a couple fresh builds. List of issues reported from these new builds is summarized in the table below:

Tool Issues
BinSkim 0
APIScan 80
CredScan 24
PoliCheck 2972

Full list of issues is at https://msazure.visualstudio.com/defaultcollection/One/_workitems?tempQueryId=94620dd6-d32e-4f1e-b2bb-1cf748f7dd51

Next steps on how we want to proceed with security builds:

  • Build will be launched manually when required. There will not be any automatic triggers. This is because the input variable for the build is the name of the container from where the NuGet packages should be restored from.
  • Prepare security build for CoreCLR and Core-Setup using similar approach.
  • In near future, we will extend Maestro to determine the latest container name for a repo, and trigger the security build passing that container name.

Cc @dleeapho #Closed

* Remove folders other than security.

* Update args for BinSkim.

* Cleanup scripts.

* Fix APIScan args.

* Update task names.

* Update PB variable name.

* Do delete .txt files. Version.txt is needed.

* Set symbolsFolder for APIScan.

* Update git checkout task.

* Add a test task that will be removed before merge.

* Add PB_Git variable.

* Update Git path.

* Revert to PB_Git.

* Remove test task.
@gkhanna79
Copy link
Copy Markdown
Member

Adding @wtgodbe to take a look as well since he has been involved in related security efforts.

picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
* Create root and windows definition.

* Include PB_ prefix.

* Remove variables whose values will be in PB.

* Remove unnecessary tasks.

* Update path property.

* Add OSX leg.

* Remove triggers.

* Remove PB variables.

* Remove OSX leg since there is no TSA support.

* Remove CodeMetrics.

* Pass official build number as PB variable.

* Invoke sync.cmd directly.

* Update arguments passed to security tools. (dotnet/corefx#11)

* Minor fixes to arguments passed, and variable names.  (dotnet/corefx#12)

* Remove folders other than security.

* Update args for BinSkim.

* Cleanup scripts.

* Fix APIScan args.

* Update task names.

* Update PB variable name.

* Do delete .txt files. Version.txt is needed.

* Set symbolsFolder for APIScan.

* Update git checkout task.

* Add a test task that will be removed before merge.

* Add PB_Git variable.

* Update Git path.

* Revert to PB_Git.

* Remove test task.


Commit migrated from dotnet/corefx@114dc02
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants