Re: Call for documented auditing norms for CF code, plugins, and extensions
Dr Nic Williams <drnicwilliams@...>
Thanks for reference to info on signing windows plugins/clis. I'll try to get this added into plugins managed by Stark & Wayne soon
From: Bret Mogilefsky <bret.mogilefsky(a)gsa.gov>
Sent: Wednesday, September 27, 2017 4:40:51 AM
Subject: [cf-dev] Call for documented auditing norms for CF code, plugins, and extensions
TL;DR: The CFF should start to incorporate practices that make it easier for consumers and integrators of CF core components and community code to understand and characterize the security risks of using code from various sources.
This is a bit of a rant, and it starts from considering the security of plugins... Bear with me.
We’re finding government users of cloud.gov<https://cloud.gov> are unable to use unsigned Windows binaries in locked-down machines. (When a Windows binary is signed, it’s easier for admins in locked-down environments to whitelist either by individual signature or by publisher.) The CF CLI itself is signed, but the plugins generally aren’t. This makes it harder for users in those environments to be productive with CF, particularly when it comes to productivity plugins like cflocal or cf-service-connect. The docs team took care of adding signing instructions to plugin docs right away when I asked<https://github.com/cloudfoundry-incubator/cli-plugin-repo/issues/165>, which I really appreciate... Yay!
However, a bunch of problems remain even if you're not a Windows user... Totally aside from the fact that plugin authors are responsible for buying code-signing certs individually (which dissuades them from sharing in the first place), plugin code generally gets no security audit (or at least there's no consistent auditing that we can all see). So an organization whitelisting a plugin binary essentially either requires either supreme levels of trust in the security operations of the individual plugin author, or performing their own audit.
This problem goes much wider than plugins, and really covers anything that the community produces and shares. It was really difficult to get cloud.gov<http://cloud.gov> through the FedRAMP<https://www.fedramp.gov/about-us/about/> Joint Authorization Board<https://www.gsa.gov/technology/government-it-initiatives/fedramp/about-fedramp/governance/joint-authorization-board-jab>'s assessment. We had to persuade the technical reviewers that yes, it's an acceptable level of risk to incorporate all of this upstream open source code into a government project despite no published information about who was responsible for the security of the upstream CFF code we consume and what processes they follow. I know anecdotally from conference discussions that quite a lot of scrutiny and scanning happens on core components, but it's just plain invisible from outside. And we know that there's a lot of other community-provided stuff that makes its way into any decent deployment that doesn't go through that same process. It's a ton of code, from a ton of authors! This is a case where the "many eyes make all bugs shallow" benefit to open source security, despite all the commercial entities contributing to and benefiting from Cloud Foundry, makes it a pretty hard sell.
To turns lemons into lemonade: This is an area where the foundation can add a ton of value for the entire community using CF, and cut out redundant work that prevents more widespread adoption of CF in highly secure or regulated environments.
So here's my request to the foundation and community: I'd like to ask that membership in one of the three main CF GitHub orgs start to mean something as far as "this thing gets vetted security-wise". I'd also like the plugin registry and extensions listings which cover a broader range of stuff to start segregating "stuff that gets vetted" from "stuff that doesn't get vetted".
Here are some concrete suggestions for what that could look like:
* Explicitly document the kind of vetting core CF components go through (whether human or automated) before they get released so people can refer to it from compliance documentation. I'm hoping this is an easy thing to do.
* Have the CF extensions bot<https://www.cloudfoundry.org/introducing-cf-extensions-github-bot-hub-project/> automatically set up snyk.io<http://snyk.io> (or alternative tools; just picking a CFF member company here!) to run scans on source repositories and make the link to the latest report available alongside the listing of the extension/plugin.
* Have someone employed by CFF to regularly inspect new scan findings on results for any "official" repository under github.com/cloudfoundry*/*<http://github.com/cloudfoundry*/*>, and file issues or make private reports when they think vulnerabilities should be addressed.
* Have a human security inspection be a condition of a repo climbing out of cloudfoundry-incubator.
* Build and host official CFF releases of extensions/plugins for anything that's made it out of cloudfoundry-incubator into the main GitHub orgs. (And sign anything that's a Windows binary with the same key used for the CF CLI.)
* Segment official releases from community releases in any listing to make it clearer where risk lies.
Thanks for reading this far, and if there's a better venue for this conversation to proceed with the right people, please let me know!
product lead on cloud.gov<https://cloud.gov> at 🇺🇸 USG>GSA>FAS>TTS>18F