Shift Risk Left: Security Considerations When Migrating Apps to the Cloud
2 likes357 views
The document discusses the need for integrating security into the development pipeline for cloud-native applications, emphasizing that traditional security models cannot support the anticipated growth in application volume. It advocates for early feedback and automation in security processes, suggesting that developers and operations teams should collaborate effectively to manage security risks. The piece also highlights the importance of persistent knowledge regarding security vulnerabilities and the necessity of compliance ownership within customer-facing organizations.
Shift Risk Left: Security Considerations When Migrating Apps to the Cloud
- 1. <—Shift Risk Left Security Cloud Native Environments
- 2. Introduction • Tony Hansmann (@997unix), Platform Architect at Pivotal • Recently broke off a twenty year relationship with the pager • Ops persons who accidentally landed at Pivotal, Agile Dev Central • Trying hard to automate Ops away for the F500 • Security, Compliance, and Risk Management are the frontiers of Ops
- 3. • “Cloud” == getting compute resources from an API • “Cloud Native” == App dev model that assumes APIs for all resources • Apps get easier to push (46x between low and high perf orgs DORA 2017). • We expect app counts to grow 2-4x other next five years • The standard model of App security won’t support this app volume Cloud Native, is that a real thing?
- 4. • The Left here is the path-to-prod pipeline • Devs are the beginning of that pipeline and we believe they need feedback as soon as possible • The security/change approval process is a big impediment to Cloud Native adoption (or it causes such a big slowdown, there is no point in going cloud) We buy “Security is a process, not a destination”
- 5. • The worst feeling for an Ops persons is a failure they “should have” known about • Black Duck gives Pivotal a huge advantage by making huge swaths of security trivially knowable • How are the F500 going to “know” about their hundreds of apps that don’t have dev teams behind them? • We’re going to also have to know decade-over-decade • Knowing is a key capability, there’s no way off this wheel • Security is going to Visit you, the only questions is on who’s terms will they visit you? Security and Knowability
- 6. Black Duck integration with PCF Meta-buildpackDeveloper buildpacks droplet BLOB STORE PCF DEV Operator PCF STAGING PCF PROD Continuous Integration (CI) Concourse, Jenkins, Bamboo, Team City, TFS/VSTS decorators cf push cf push cf push Black Duck Service Broker (cf bind) Black Duck CI Integrations QA
- 7. • Our fellows who have suffered security breaches often knew all about their exposure - knowing is not enough • You’re going to need CI/CD at a minimum • If you’re a Dev, help Ops and Security by adding Black Duck to your pipelines • If your in Ops or Security, learn your CI/CD system to partner with devs • Have policy in-place for what each team does in the event of CVE and then tie it off with executives • Risk compounds: if CI is red, take care of it vs. “assessing it as an acceptable risk.” It’s not sustainable across hundreds of apps When you encode you policy, you don’t have to talk to anyone when it’s green
- 8. • We run an industrialized Black Duck pipeline • All upstream and Cloud Foundry produced components are run through a Black Duck Pipeline • Alerts are filtered and fed to a clearing house app (Davos - Pivotal internal) where they are vetted and Tracker stories are assigned to dev teams (there are 66.) • It is a closed loop systems, Davos get a notification when the story is accepted • We run this over the last 3 ‘minor’ release (1.10, 1.11, 1.12) Pivotal PCF Engineering Use Case
- 9. • Advocate from the “Shift Risk Left” perspective • Any automation is a win. Value compounds over time • Build visibility at the Dev level: If a Dev knows the first day they’ve got out of date, risky, or dead project, that’ll solve a lot of issues • Advocate for a policy enforcement processes like Netflix Conformity Monkey • If security is process, long-term compliance means apps have to have owners. It can’t be Ops, it needs to be customer facing org • Advocate for a “Library update” test-set which allows Ops/Sec to test library update without bothering Devs • Security teams create and consult on compliance pipelines Advocating for this model
- 10. Questions
- 11. Resources • Concourse OSS Continuous Integration/Delivery system • DORA 2017 State of DevOps Report • CI Conformity Graphic (no ref, but please visit Martin Fowler for more info) • Conformity Monkey image, @garrethbowle • Question Mark graphic
- 12. Security in Cloud Native Environments <— Shift Risk Left
- 13. Tony Hansmann (@997unix), Platform Architect at Pivotal