Editor's Note: We are hosting DevSecOps Leadership Forum virtual events. Register to hear directly from leaders in London and North America.
In this post, we cover what William Zhang, Andy Gao, and Srini Kasturi shared about their DevSecOps journey at the World Bank Group. Watch their entire AllDay DevOps presentation, linked below.
As an overview, the World Bank Group is made up of several organizations that work towards ending extreme poverty across the world and boosting shared prosperity. They work on many fronts, including water and transportation improvements. Much of their work includes processing financial transactions and handling sensitive data, and they therefore saw a need to move towards DevSecOps.
To begin the DevSecOps journey, they first moved to SaaS solutions, like Office 365 and SharePoint Online. They then began including other SaaS solutions like Saba for training. And then finally, they moved into infrastructure-as-a-service from providers like AWS and Microsoft Azure.Why was this necessary? Well, previously they needed to wait for months if not years to get necessary upgrades to their software and infrastructure. Cloud-based platforms gave them the agility they needed to stay ahead. Now when the service provider has an update, it can easily be upgraded in their systems.
Next up, they needed to start looking at applications, in addition to their infrastructure and cloud software. So where did they start on the application side? Back around 2008 or 2009, the World Bank Group embraced the idea that security fix can cost you more money when it’s done at the end of the SDLC, like with a typical waterfall model.
Screenshot from Zhang, Gao, Kasturi’s “The World Bank Group’s Cloud Journey With DevSecOps” presentation
The traditional approach wouldn’t work. Security was looked at near the end. Because of that, there’s always a desire to shift left and bring security checks earlier in the lifecycle.
The business increased the need to shift left through their cloud-based expectations, where upgrades and patches occurred not in months or years but in weeks, days, or even hours!
They would have to align with a different approach.
To start off, they identified what manual testing occurred and where they could replace it with automated testing. The longer the automated testing took or the larger the volume of testing required, the more important it could be to automate.
For example, a routine review of reports would require a lot of manual reviews, but they’d only require action in certain situations. The most significant risk decisions that took time required automation.
They also had to look at scalability and quality. For example, OWASP Zap could run millions of tests. However, that would reduce cycle time. So they needed to prioritize tests based on what had the most business value.
To meet the demands of business and security, they took up a phased approach to pave their way to automated cloud security testing.
In the first phase, they focused on the bread and butter of services. Then they expanded that to the cloud-based services.
Screenshot from Zhang, Gao, Kasturi’s “The World Bank Group’s Cloud Journey With DevSecOps” presentation
Next, once they selected a service, they had to decide what to automate. They had to look at what made sense from an architecture standpoint.
And they also had to answer a question—should they go completely left? Or should they create a loosely coupled model that can handle the churn that’s going on in the World Bank Group?
They chose to not go completely left and instead used risk-based decision making to determine what changes to make first.
With this risk-based decision making, they determined how to budget in exemptions as well as provisions. Additionally, they looked at all the decisions being made and found that those decisions needed to be automated. And now they have 400 or so security decisions being made automatically.
And here’s another learning from their journey: they found out that security also required operational support. This was no longer an 8–5 job. The DevSecOps team needed to provide extended support to assist with security issues around the clock. And finally, they realized that a better onboarding process would assist development teams to improve their security process.
For Act II, the World Bank group sought to look at infrastructure through infrastructure-as-code. They looked at the tools available in AWS to codify their security control tools.
As part of this, they combined the security stack with the application stack using AWS Service Catalog.
The security stack involves security and controls at the server level. The access stack includes ACL controls for applications. They then combined this to put them together in the service catalog. The AWS service catalog provided a guardrail, allowing others with one API call to get the data they needed securely.
After reviewing Act I and Act II, the World Bank Group looked at security-as-code. This codifies security controls and builds controls verification into DevSecOps tools and practices.
So what does the pipeline look like? One thing the World Bank Group recommends is to make sure that your pipeline matches your business process. Their pipeline includes several safeguards for improved security.
Screenshot from Zhang, Gao, Kasturi’s “The World Bank Group’s Cloud Journey With DevSecOps” presentation
Next, the World Bank Group will move towards pipeline-as-code, as well as security-as-code for SaaS platforms. They’ll also look at additional security hooks based on industry best practices.
And finally, they’ll be looking at robotics process automation, machine learning, and natural language processing for additional security improvements.