Like any other industry, software delivery – from development to deployment – depends on a chain of participants and associated workflows. And, as with every other industry, our trust in the final product – be it organic food, a pharmaceutical or a high-end apparel item – depends on the trust we have in the reliability of the participants in the supply chain involved.

It’s much the same for software. Just as the supply chain for physical goods needs to ensure the authenticity of the sources of a manufactured product and that these have remained untampered from production to consumption, the pipeline from development to deployment of a software product has to ensure that no steps introduce security vulnerabilities. This is particularly true for enterprise level software, especially in highly regulated industries such as banking where additional safeguards are needed to avoid costly security breaches resulting in loss of data, decreased consumer confidence and financial penalties.

A typical bank’s IT environment uses a variety of toolsets, various open source software, and both on-premises and cloud infrastructure. In their search for increased business agility, the banking sector has also joined the trend towards microservice-based software development using Agile and DevOps, which has considerably quickened the pace of code release and deployment through continuous integration and continuous delivery (CI/CD) workflows.

But with this decentralization and automation of the software supply chain, centralized corporate governance of a bank’s software development policies and best practices can often get compromised. In fact, this accelerated pace of software development and delivery requires even closer adherence to corporate governance to ensure that quality, security and compliance with banking regulations are not sacrificed to achieve deployment velocity. 

Tools such as Grafeas and Kritis were designed to automate this adherence to corporate governance while ensuring the agility and throughput of the CI/CD pipeline. These tools track metadata on every aspect of the software development and delivery workflows, and centralize the enforcement of corporate policies. 

A heavily regulated industry such as banking can directly benefit from these tools, as this article will illustrate.

What is a Software Supply Chain?

A typical software supply chain is illustrated in the following figure, and follows these steps:

• writing and checking-in code, and building images (containers, binaries, etc.) all in a development environment;
• testing and verifying these, as well as other quality assurance steps done in environments without live traffic;
• static code analysis for identifying software security vulnerabilities and checking against corporate best practices; and
• finally deploying the code to servers in a data center or the cloud.

From a governance perspective, it is essential to have visibility into what happens to a piece of code as it progresses along this pipeline – the software supply chain.

This is particularly important when open source software or other 3rd party software is introduced into the pipeline. These can be a source of vulnerabilities, and an alert organization should be particularly alert of it. In fact, most organizations have developed internal policies on externally sourced software, in addition to their in-house standards for development practices. To mitigate against unfettered access to open source software, many organizations develop a repository of approved external software with specific versions white-listed. But even then, such approval needs to be periodically verified given the potential for new vulnerabilities emerging.

Auditing and governance of software practices are also made harder because most IT shops employ a variety of programming languages, tools and frameworks. The trend towards continuous integration and continuous delivery (CI/CD) using containerized microservices can also lead to (usually unintentional) shortcuts where corporate policies and standards for software development are not followed. And the possibility of using both on-premise and cloud deployments add to potential operational breaches.

The new tools, Grafeas and Kritis, ensure that there is a centralized repository of corporate policies, and that software at each stage of the development and delivery workflows are verified against these. We shall explain below how these tools work together to automate the adherence to corporate governance at scale.

How Grafeas and Kritis Fit In

Grafeas is a metadata repository for the entire CI/CD pipeline, as the following figure shows.

You can store anything in Grafeas that you feel is important about any aspect of your software supply chain, such as metadata about builds, deployments and vulnerabilities of images, binaries and packages. For instance, let’s say you scanned a container and its packages for security vulnerabilities. The result of that scan is written into Grafeas. Later, you can record if that container is deployed in production.

As each stage in the pipeline completes, a piece of metadata is created in Grafeas to attest to its successful completion – called a binary attestation, which is simply a yes (allowed) / no (not allowed) decision. These attestations are digitally signed by attestation authorities in your organization, who are responsible for ensuring the integrity of the pipeline.

Kritis springs into action when it is time to deploy a container into a production environment, as schematically shown in the figure above. Kritis is a piece of software that is integrated into the Kubernetes runtime engine and acts as an admission controller during pod creation. Its job is to ensure that various IT policies have been followed before allowing the container to be deployed. For instance, an enterprise might have a policy that a container should have undergone a particular set of security scans. Kritis queries Grafeas to check what attestations are associated with this code and only admits it if the above-mentioned scan policy is fulfilled. Such attestation verification avoids accidental deployment of untrusted code such as an in-development image which is mistakenly thought of as tested, or a 3rd party component which is not on an enterprise’s whitelist of allowed software. This becomes particularly critical these days when so much of the CI/CD pipeline is automated.

Such attestations need not be cast in stone. There can be freshness policies, so that attestations are no longer valid after a time. Or it might happen that a security vulnerability is discovered in an open source package used by a deployed containerized application. Kubernetes can then remove those containers and then the new ones are deployed only after Kritis verifies that these have passed a scan for the new vulnerability.

One can readily believe that a typical enterprise running thousands of containers with hundreds of thousands of images – Google alone claims to launch several billion containers each week – can readily benefit from a process that automates the auditing of deployed code against company standards for software development and policies for secure software deployment. Grafeas and Kritis fulfill these goals, the former by storing trusted attestations of various process steps and the latter by verifying adherence to corporate policies for any piece of deployed code.

Having used these solutions internally for a number of years, both Grafeas and Kritis have been open sourced by Google and have active development communities on GitHub.

The Takeaway

Grafeas and Kritis address a problem which most enterprises face, especially in a highly-regulated sector such as Banking – how to enforce internal policies for their software development. They allow for an efficient and automated governance process by codifying the steps to track development and deployment metadata and enforcing policies based on these. These solutions provide the reassurance that an enterprise’s software release process is audited and followed in today’s increasingly “high velocity” automated build and deployment environment.

We hope you enjoyed this blog on Kritis and Grafeas, and the real impact it can have on the development processes within a banking organization.

As a technology consultancy with strong implementation expertise in the banking sector, reach out to us if you’d like to talk further about your compliances challenges within software delivery and how we can help resolve them. Consult with us today.