President Biden’s Executive Order shows that every company needs an immutable Software Bill of Material (SBOM)

Zero-Trust infrastructures and SBOM are important to comply with the 2021 Cyber Security Executive Order!

We believe that every company producing software needs to track the bill of material of its software (Software Bill of Material – SBOM or BOM). But it shouldn’t just be tracked somewhere and stored in an archive system, it should be actively used. To make that possible, you need a solution that stores your BOM including its full history for every build immutably and tamper-proof – so it can become your single source of trust.

With the 2021 Cyber Security Presidential Executive Order that has just been signed, it becomes very clear that companies need to enhance the software supply chain security as one of the efforts to eventually improve the nation’s cybersecurity. That requires an auditable software bill of material using zero-trust technologies.

Not just the SolarWinds hack made clear that a vulnerable software pipeline quickly becomes a threat to every user of that software.

The massive increase of software packages being built, distributed, and used must be tracked and it needs to be transparent what packages are used in running workloads. Many packages come with many vulnerabilities and third-party binaries, and open-source projects are pulled from potentially untrusted sources.

It is important to mention that there is an obligation to disclose data and software breaches when companies become aware of it. The more information has been collected – and that includes a complete bill of material, recorded pipeline jobs, and the software approval process -, the better it is for further investigation and to get back to a normal business as fast as possible.

CodeNotary provides the platform and the integration required to record a fully searchable and comprehensive catalog or inventory of all your software components including its dependencies and vulnerability check results for internally developed, third-party, and open-source code.

What is a Bill of Material / Software Bill of Material or BOM/SBOM?

You can think of bill of materials (BOM) as a complete list of all software artifacts that have been used in the build process to produce a software product. That includes the name, version and ideally the unique checksum for all of your internal components, third-party, and open-source code.

The bill of material should be combined with vulnerability or dependency scanner results that were produced within your software pipeline. Storing all of that data tamper-proof including an immutable history makes your BOM easy to use and trustworthy without the fear of having an attacker changing your BOM as well.

You need to keep in mind that many projects in the open-source world exist because of developers that solved a specific problem and shared the software with the community. You cannot expect that every project maintainer spends his spare time in making the code secure and bulletproof.

Therefore, when using these projects, all the quality and security issues are inherited and will be part of the software that you produce and distribute based on these. That puts a risk to your software and everyone who is using your software, i. e. your customers or internal departments. In the SolarWinds case, over 18,000 customers were affected, and some have no idea that they still use malicious code.

You can’t really blame the software developers themselves as they might be unaware of the vulnerabilities in dependencies within the code they reuse.

An immutable SBOM is not just a list of software artifacts stored in the company archive. It’s a process that continuously gathers all used software with its dependencies, including versions and known vulnerabilities. CodeNotary provides command line tools to integrate into CI/CD pipelines (GitHub, GitLab, Jenkins, CircleCI, TravisCI and many more) and GitHub actions to automate the process of collecting the software build dependencies that ultimately leads to a BOM. Our solution CodeNotary Immutable Ledger also stores that information as transactions in an immutable and cryptographically verifiable ledger. These transactions include as well artifact metadata, vulnerability scanner reports, and the involved parties (CI/CD tool, QA engineer, vulnerability server aso.).

Next to a code to binary integration, CodeNotary also provides a binary to dependency integration for Go and Java applications.

It’s the only tamper-proof and auditable solution on the market that provides a full immutable history of everything that has happened.

That way you know who did what when and where it is currently used – and you can prove it!

Software Supply Chain Attacks

Every software delivery relies on a supply chain, like any other industry, to make sure that all components are used in the right way, at the right time and in the correct version. The supply chain also covers everything that can affect your delivery of the software.

Therefore, the software supply chain is everything that goes into your code or affects it, from development, the CI/CD pipeline, until it’s ready to be used or deployed into production. If you run your own workloads in production, then the software supply chain doesn’t stop with the runtime but goes beyond to cover patches and rolling updates as well.

A good supply chain provides reports and information about code, binaries, other components, where they come from and what version or license has been used. Don’t forget the security related part and the software component review for security issues, vulnerabilities, compatibilities, approved versions, and compliance.

Who, when, where for everything that made up your software.

The software bill of material is not the only but a very important part of your software supply chain.

The attack surface

Most of the software supply chain is automated in today’s software development process and is mainly protected using reviews, approval processes, vulnerability scanners, and digital certificates.

That automation of the CI/CD pipeline is one of the most exploited attack surfaces and was also used in the SolarWinds hack.

If the attacker (internal, external, intentionally or by accident) adds software components or changes the process that leads to a malicious software release, the damage is done. Using digital certificates only protects the software integrity, but not the authenticity or the level of security.

The moment that software is distributed into the runtime or to other customers, the damage spreads like wildfire.

How can a SBOM help?

A SBOM can help in 3 ways:

  • complete understanding of what’s built into your software
  • act on security, license, or compliance changes of any of your used software
  • present and past view

If someone actively embeds malicious components in your software, having a complete and tamper-proof catalog of your whole build process including all components used, still enables you to detect the bad code delayed or for forensic purposes.

But many vulnerabilities are simply part of approved and good software components that are detected way after you started using them. In these cases it’s crucial that a software component that suddenly is marked critical by your vulnerability scanner can be detected everywhere it has been used before.

Having a reliable and trustable (ideally using a Zero-Trust technology) bill of material, puts you in the position to trace back everything that has been used in the past, in the current build process, or is already running as a workload. Suddenly a newly detected vulnerability can be the basis for revoking software components close to real-time.

When reading all the news about recent software supply chain attacks, one big question remains:

Where to start?

Quick introduction CodeNotary Immutable Ledger 2.2

CodeNotary Immutable Ledger is the only solution that combines a complete immutable and cryptographically-verifiable data ledger with an integration to protect the full software lifecycle, software supply chain and application workload. Every timestamped notarization transaction consists of a user or machine identity, the unique digital artifact identity, the trust level (trusted, untrusted, unsupported), and metadata. As every historic transaction is an immutable version, the platform is fully auditable.

The integration with any CI, CI/CD, and DevOps tool is easy using our APIs and/or command-line tools.


CodeNotary can cover the whole supply chain and instead of signing the final binary, the file is being notarized or authenticated by every step of the workflow. Multiple persons or machines with different logins are involved and all of them are constantly aware of the status of an object in the supply chain. With CodeNotary it would be almost impossible to tamper software products as seen in the Sunburst attack.


When integrating the CodeNotary solution into your CI/CD pipeline, you gain 4 main benefits:

  1. Tamperproof history of all digital artifacts (single artifact and bill of material of the build)
  2. Machines and people can notarize and authenticate every individual artifact inside or outside your premises
  3. Notarization can be done for every individual artifact using different states (Trusted, Untrusted, Unsupported)
  4. Authentication can be done publicly by anyone with internet access (i. e. to check the current state of the download or build)

The CI/CD protection can uniquely identify:

  • git repositories (source code)
  • CI/CD CI/CD pipelines (Jenkins, CircleCI, GitLab, TravisCI, GitHub Actions and many more)
  • Container images
  • Files and folders (i. e. configuration files, build files, CI/CD recipes, installer binaries and many more)

CodeNotary Immutable Ledger 2.2 incorporates new features targeted at protecting CI/CD pipelines:

  • VCN command line tool integrates with CI/CD pipelines, including an automatic collection of the whole pipeline environment for better artifact search
  • Arbitrary files, eg. security scanner reports, can be attached (immutable) to the notarized artifact
  • GitHub actions for notarization and authentication are available for automatic artifact and Git repository processing based on PRs or releases
  • Identities (API keys) can be rotated and revoked programmatically
  • VCN takes into account revoked keys when authenticating assets
  • User interface improvements, especially in the CI/CD pipeline and artifact query view
  • Multi-ledger query API keys to find artifacts across separated teams

Integrating CodeNotary in your software pipeline to get a BOM

The most straightforward way of integration is the software build pipeline itself.

We at CodeNotary recommend a strategy where every step verifies the input and notarizes its output. In combination with a proper identity management, you can secure your pipeline in a way that unapproved software cannot be introduced into a build process.

In the build process itself, all used dependencies and requirements are notarized by the build process identity and the produced software build is notarized including all used requirements as well. That way you automatically create a BOM without any additional effort.

Adding your vulnerability checker results to this notarization as well in our immutable ledger based platform (uses immudb in its core) provides you with a fully auditable SBOM including an immutable history of past vulnerability or dependency checker results.


You can read more about it here:

Generating a bill of material from binary code using CodeNotary

Many of your software is already built, so you only have the binary code, but not the sources from the date of the build. As dependencies can be updated quite often, even builds between Monday and Tuesday can already differ when it comes to the bill of material.

Therefore, having access to the source code or the build protocol doesn’t help – you need to read the dependencies out of existing binary code.

At CodeNotary, we already have working integrations for Go and Java to gather dependencies including their unique fingerprint by checking existing software binaries to recreate a BOM.

That allows customers to find all used dependencies (name, version, checksum) by simply running our command line tool with the –bom flag and the binary and immediately notarizing them in one step. Alternatively, all used dependencies can be authenticated, to find out if any of them should not be used anymore.



Independently of the new Executive Order and government regulations at the state and federal level that are moving towards more due diligence in the software supply chain, it’s in the interest of every single company to know the 3 W’s (Who, When, Where) when it comes to application development, deployment, distribution, or runtime.

CodeNotary is not simply providing a SBOM for your software supply chain, it also securely and immutably tracks every single step in your software pipeline. It’s crucial to have an immutable and absolutely tamper-proof ledger to record every build, the SBOM, and the trust level for every single artifact over time.

That way, you can prove and query the present and the past whenever you need to know if and how you’re affected by new vulnerabilities or supply chain attacks.

We have an online trial that you can use to start protecting your software supply chain: CodeNotary CNIL Online

CNIL Metrics & Logs

Self-Hosted performance monitoring and compliant log analysis for VMware vSphere, container and much more.


Built on the fastest immutable ledger technology. Open Source and easy to use and integrate into existing application.

Codenotary Cloud

Trusted CI/CD, SBOM and artifact
protection with cryptographic proof.
One CLI to manage all.

Subscribe to Our Newsletter

Get the latest product updates, company news, and special offers delivered right to your inbox.

Subscribe to our newsletter

Use Case - Tamper-resistant Clinical Trials


Blockchain PoCs were unsuccessful due to complexity and lack of developers.

Still the goal of data immutability as well as client verification is a crucial. Furthermore, the system needs to be easy to use and operate (allowing backup, maintenance windows aso.).


immudb is running in different datacenters across the globe. All clinical trial information is stored in immudb either as transactions or the pdf documents as a whole.

Having that single source of truth with versioned, timestamped, and cryptographically verifiable records, enables a whole new way of transparency and trust.

Use Case - Finance


Store the source data, the decision and the rule base for financial support from governments timestamped, verifiable.

A very important functionality is the ability to compare the historic decision (based on the past rulebase) with the rulebase at a different date. Fully cryptographic verifiable Time Travel queries are required to be able to achieve that comparison.


While the source data, rulebase and the documented decision are stored in verifiable Blobs in immudb, the transaction is stored using the relational layer of immudb.

That allows the use of immudb’s time travel capabilities to retrieve verified historic data and recalculate with the most recent rulebase.

Use Case - eCommerce and NFT marketplace


No matter if it’s an eCommerce platform or NFT marketplace, the goals are similar:

  • High amount of transactions (potentially millions a second)
  • Ability to read and write multiple records within one transaction
  • prevent overwrite or updates on transactions
  • comply with regulations (PCI, GDPR, …)


immudb is typically scaled out using Hyperscaler (i. e. AWS, Google Cloud, Microsoft Azure) distributed across the Globe. Auditors are also distributed to track the verification proof over time. Additionally, the shop or marketplace applications store immudb cryptographic state information. That high level of integrity and tamper-evidence while maintaining a very high transaction speed is key for companies to chose immudb.

Use Case - IoT Sensor Data


IoT sensor data received by devices collecting environment data needs to be stored locally in a cryptographically verifiable manner until the data is transferred to a central datacenter. The data integrity needs to be verifiable at any given point in time and while in transit.


immudb runs embedded on the IoT device itself and is consistently audited by external probes. The data transfer to audit is minimal and works even with minimum bandwidth and unreliable connections.

Whenever the IoT devices are connected to a high bandwidth, the data transfer happens to a data center (large immudb deployment) and the source and destination date integrity is fully verified.

Use Case - DevOps Evidence


CI/CD and application build logs need to be stored auditable and tamper-evident.
A very high Performance is required as the system should not slow down any build process.
Scalability is key as billions of artifacts are expected within the next years.
Next to a possibility of integrity validation, data needs to be retrievable by pipeline job id or digital asset checksum.


As part of the CI/CD audit functionality, data is stored within immudb using the Key/Value functionality. Key is either the CI/CD job id (i. e. Jenkins or GitLab) or the checksum of the resulting build or container image.

White Paper — Registration

We will also send you the research paper
via email.

CodeNotary — Webinar

White Paper — Registration

Please let us know where we can send the whitepaper on CodeNotary Trusted Software Supply Chain. 

Become a partner

Start Your Trial

Please enter contact information to receive an email with the virtual appliance download instructions.

Start Free Trial

Please enter contact information to receive an email with the free trial details.