Dependencies • "operating system" provided by "operations" • packaging and release engineering provider by OS vendors • "yum install your-package" • Requires operations to update
of problems here • Limited selection • Generally "out of date" • Security fixes only • Do not normally include stability fixes. • Definitely not feature updates
(Product) • Provides full install of Ruby (including the executable) • Near impossible to get a client's ruby install to be "correct" • Chef (the company) is responsible for security for its components
VM • Mostly done by product vendors, and not (normally?) done by internal enterprise deployments • And of course cloud providers, provide a blank slate (but thats a different story). • But recently, "community OSs" have become popular.
• Dockerfile creates a container that provides all system requirements • "Docker…. , liberating developers from infrastructure" (from their press release) • "Community OS"
Builds" • Only says the Dockerfile and the resulting container are consistent. • Big whoop. • Unlikely any Dockerfile creates a reproducible build over time (since it involves network resources).
lang • Golang produces a single static binary that provides all code requirements • Dependencies are manually managed by developers • Third party code frequently un-versioned • By default directly pulls from HEAD on github for other modules • No shared libraries
Ops should not care about what version of some python module is installed. They can focus on operations and operating systems • Turns operations into platform and in-house consultancy (ideally) • Devs starts taking responsibility for how their code is packaged and run. • Clear separation of duties (or perhaps responsibilities) Love it
Old OS Model • Kinda nice! • "are we secure in our components?" is mostly a "apt-get/yum upgrade" invocation. • Actual work is outsourced (and centralized) to the OS Vendor, or the ops team
Model • Uhhh, now what • AMIs, docker containers and golang binaries are opaque • By inspection not clear what components are used, nor what versions. • Are they outdated? Insecure? Obsoleted?
• Security has to get involved with how software is made and deployed. • Demand fast, reliable deployment pipeline mechanism • (how fast and how often you deploy is your policy) • If anything, you need to be able to patch quickly
• Automation? Checking latest version of components. • What does "latest version" even mean? • Building manifests and bill of materials? And Displaying Them? • Alerting on manifest changes • ??? this is a work in process ???
Can Help • Sonatype • Black Duck • I have no first hand experience with any of them • I assume not all use cases here are covered as it really depends how software is built, packaged and deployed.
ngalbreath
pauli
kwappa
yokawasa
ktc_wada
egmc
tomorrowkey
lycorptech_jp
hamadakoji
hirotomotaguchi
taishin
osyoyu
matsuihidetoshi
rmw
eitanlees
trallard
ufuk
jponch
addyosmani
chrislema
mongodb
eileencodes
vanstee
geoffreycrofte
geeforr
