Software Supply Chains Require Immutable Databases

The positive outcome of attacks on software supply chain is that more IT organizations are aware of the need for an immutable datastore that ensures the integrity of the software development life cycle. The bad news is that more cybercriminals are now aware of how vulnerable the platforms relied on to build applications are, largely because the platforms are not using a reliable, tamper-proof data store. The probability that more software supply chains will be compromised in the weeks and months ahead has never been higher.

The open source software development community is rallying to address this flaw via an Alpha-Omega project based on signatures to sign code and open source Rekor software, which is a tamper-resistant ledger of metadata based on the Google Trillian data store that can be used to create immutable record atop a MySQL, MariaDB or Redis database.

As laudable as that effort is, however, it will be years before those efforts bear any fruit, and it is layering more software on infrastructure to ensure zero trust integrity of a software supply chain.

A simpler approach would be to use an existing open source immudb database, which is built on a zero trust model that doesn’t need to rely on any additional software. History of the data stored is preserved and can’t be changed. Data in immudb comes with cryptographic verification at every transaction to ensure that there is no tampering possible and that it is always possible to view the history of the data to see what changes were made and when they were made.

The immudb database is uniquely capable of supporting billions of software artifacts generating notarizations/authentications at the level of scale typically required in enterprise-class application development and deployment environments.

Rather than waiting for a critical mass of maintainers of open source projects to eventually integrate signatures, Rekor and Trillian within their development environments, an organization can employ immudb to take control of their own application development and deployment destiny starting today.

A Short History of immudb

At its core, immudb is database with built-in cryptographic proof and verification that is written in the modern Go programming language. When changes are made, multiple instances with different timestamps are created to provide the complete history of that record’s changes.

Designed to operate both as a key-value or relational (SQL) database, immudb can store a variety of common data types, verification checksums or JSON objects.

Finally, immudb can be deployed as a full database server with replicas or be easily embedded as a lightweight database into an application.

Open source immudb has already been downloaded more than 12 million times thanks in part to rising awareness for the need to keep track of updates to software development projects, and it is now one of the fastest growing open source projects. In terms of percentage increase in GitHub stars, immudb ranked higher in the fourth quarter of 2021 than any other project based on a list compiled by Runa Capital. Organizations that have already deployed immudb include Samsung, Shopify, Siemens, Pfizer, the National Institute of Standards and Technology (NIST), the Indian Ministry of Public Housing, the government of Israel and several large banks.

The Trouble with Software Development

Software development today is based on the aggregation of software components that tend to lack distinct boundaries between them. Developers reuse those components across multiple applications so any issue with one component, such as the Log4j logging tool, is easily propagated across multiple applications. Many of those components are created by a small number of contributors and maintainers of open source projects that have limited cybersecurity expertise.

In fact, many of those contributors and maintainers don’t necessarily feel it’s their job to focus on security. Rather, the onus for security is on the vendors and IT organizations that reuse that code without contributing anything meaningful back to the project either in terms of financing or simply helping open source maintainers find and remediate vulnerabilities.

As a result, it has become relatively simple for malware to infect the components of an application, and once discovered, it can take months for organizations to find and remediate it. In the meantime, no one knows for sure when malware might be activated or for how long it may have been exfiltrating data.

The Need for Immutability

The only way to effectively combat those threats is to employ an immutable database that makes it impossible to update code without the maintainers of an application code base knowing about it. Just as important, IT organizations need to be able to roll back changes anytime malware is discovered in an application component.

As noted in an executive order issued by the Biden administration, federal agencies are required to proactively secure their software supply chains as clear evidence that a reliable means for guaranteeing the provenance of software components is nothing less than critical now in the wake of a series of recent high-profile breaches.

At Codenotary, we already use immudb at the core of a notarization and verification service for open source artifacts and containers that makes it possible to track the provenance of software components. It is designed from the ground up to be integrated with the continuous integration/continuous delivery (CI/CD) platform that DevOps teams employ to build and deploy applications using those artifacts.

Our service can also be employed to generate and verify a software bill of materials (SBOM) that will soon be required by not only every U.S. federal agency, but any organization that is committed to securing their software supply chain using a zero trust approach to managing access to software components.

Conclusion

Waiting for someone else to fix a problem never produces an optimal result. It’s clear that organizations need to be absolutely certain that their software supply chains are secure sooner than later. The immudb database is the only option that makes it possible to achieve that goal today in a way that is simple to implement across a software supply chain.

Eventually, there may be other approaches to making software supply chains secure. The issue, of course, is that given the sophistication of the cyberattacks being launched against those software supply chains, no one can afford to wait any longer.