I happened to notice a process running for a split second: /usr/libexec/gkovverride. Little Snitch was asking if it should have access to connect to Apple. This appears to be a new Yosemite thing, as others aren’t seeing it in older versions of OSX. Naturally, my curiosity took over and I had to take a closer look at this binary. A brief skim through the disassembly makes it appear that gkoverride is invoked by the Security framework, and takes hashes of binaries in question (via the commandline), then sends the hashes to Apple, waits for a response, then returns a yes/no response (via stdout) presumably as to whether the binary should be allowed to run.
I poked around some of gkovverride’s caches, and also found mention of Google Chrome. I’ve never used Chrome, but the cache seemed to have Google’s public key identifier (which they use to sign the binary, I assume) in it. I haven’t had time to hunt down when gkoverride specifically gets invoked, but this occurred during a package installation. I’ll have to disassemble Security framework for more details. So upon an initial glance, it looks as though gkoverride may get triggered when new binaries are installed or initially run, to see if they’ve been white/blacklisted. What bothers me about this is that OSX seems to be sharing hashes of your binaries with Apple, and calling home. What bothers me more is that Apple likely now has a complete inventory of binaries I’ve installed on my machine, identified by the same IP address that my iCloud and other accounts connect from; therefore, personally identifiable.