The path to code provenance at uber

The landscape of Uber applications and services moves and evolves quickly. At our scale, where a one-in-a-million ride happens 10 times every day and production code changes thousands of times a day, scaling security at the rate of business is criti...

The landscape of Uber applications and services moves and evolves quickly. At
our scale, where a one-in-a-million ride happens 10 times every day and production code changes thousands of times a day, scaling security at the rate of business is critical.

Fundamentally we must assure, across our multitude of services and engineering teams, that all production code meets defined security requirements, including compliance obligations. An important piece of this is providing documented assurance that code is authored/reviewed/approved by the appropriate parties and that code running in production is one and the same.

We will share some specific examples and use cases from our Uber’s product security team that can be applied in other environments including:
- deploying hooks for developers to sign commits (and enforcement of signatures before building container images)
- making security a first-class citizen in our build pipelines to harden and sign builds (and integrations with our container orchestration framework to ensure that our build/image artifacts have been appropriately hardened and vetted to be run within our infrastructure)
- improvements to our container runtime security, in order to efficiently detect and block any unauthorized code (including runtime anomaly detection and a process for remediation of newly-blacklisted packages)
- deploying security policies around third-party dependencies (and how we hook into the SDLC in order to warn and enforce when something is out of policy compliance)

We'll talk through integration pain points, key takeaways, infrastructure-specific challenges we faced, surprising discoveries, and issues/questions we've tackled along the way.