ANZ Banking Group is using a security control created by Google called binary authorization to prevent unauthorised code and container images from being deployed to production.

Binary authorization has been in public beta since it was announced at last year’s Google Cloud Next conference, though it is expected to move into general availability soon.
The bank’s tech area lead for omnichannel platform engineering, Mike Berry, revealed at this year’s Google Cloud Next conference in San Francisco that ANZ is using two public beta tools to secure services and applications running in the cloud.
ANZ first revealed details about its adoption of containerisation and automated code deployment last year.
Berry built on this at last week’s Google conference by briefly discussing how security is wrapped into those processes.
ANZ is using Google services both to try and catch security errors very early in the process of building a new containerised app, and then to ensure only approved code and container images are pushed to production.
Berry said that ANZ is using vulnerability scanning features in Cloud Build, which is Google’s managed continuous integration and continuous delivery (CI/CD).
Vulnerability scanning - part of the Container Analysis API - is used to provide “quick feedback on potential threats and identify issues as soon as your containers are built,” Google said last year.
“Our source code moves into Cloud Build and does all the usual things we do in the build, but at the same time we run that vulnerability scan,” Berry sad.
“If that vulnerability scan fails, then instantly we have a ‘red’ build and a developer can go in, have a look at that and find out what the issue is.
“It'll highlight for you the severity and which package is impacted so you can go in and do the patching or remediation - whatever is required - and fix it.”
Berry said that running vulnerability scanning early was designed to avoid slowdowns later in the process.
“When you find these things as they occur and fix them straight away, that helps us keep up our velocity as we're working on development,” he said.
Berry said that ANZ has also adopted a related security control, binary authorization.
Google said last year that “vulnerability scanning is integrated with binary authorization”, the latter of which it described as a “supply-chain security” tool “that ensures only trusted container images are deployed on Kubernetes Engine without any manual intervention.”
“Scanning for vulnerabilities is one process we have, but we have lots of other security tools and test processes,” Berry said.
ANZ saw binary authorization as a way to enforce security policies for which code and container images are allowed into production.
It does this by automatically checking whether the code or image has passed internal checks set for various stages of deployment.
“Binary authorization sees your image comes in and it looks for an attestation that's attached to it,” Berry said.
“So it's a way to attach a certificate to say ‘this has passed our policies and we have a certificate to prove that this image is OK with us’.”
Berry said binary authorization was effective not just as a way to enforce security policies but also to demonstrate enforcement to internal audit teams.
“Imagine you have an internal audit team that come to you and say, 'we need to understand your controls and policies, so what we're going to do is set up a meeting for a couple of hours, and we're going to read documentation together and understand how the your policies work',” Berry said.
“You're like, ‘that sounds like a lot of fun, but how about we do a demo? I've got an image here that has been approved by nobody, been tested by nobody and I don't even know where it came from, and I'm going to deploy it to production.”
“You press the deploy button, and you show your audit team 'Look, this cannot be deployed to production'.
“We don't just talk about security here, we enforce our security. And so we make sure these things can move through because they're approved.”
Berry said binary authorization could be used to enforce multiple security policies and to ensure code or container images passed multiple attestors.
“Imagine in one cluster you're like 'all that has to happen here is we need a peer review and then you can deploy to this cluster'.
“But for the production cluster, maybe you want a peer review, maybe you want it to pass a certain phase of testing, and maybe you want to add [the approval of] a team or even a person,” he said.