Improve Security with Codenotary’s Community Attestation Service (CAS)

When it comes to keeping your infrastructure and application secure, it’s critical for your team to know what’s going into each deployment of the product—and for unwanted or dangerous software components to be blocked from ever reaching production. Unless your team has visibility into what assets are actually deployed in your application environment, it’s impossible to defend against emerging vulnerabilities!

Codenotary’s Community Attestation Service (CAS) provides your organization with the tools necessary to be proactive about the security of your software supply chain.

Trust, then Verify Everything

By signing your source code, container images, and infrastructure orchestration playbooks with CAS, then authenticating those signatures before deploying any given asset, your DevOps engineers have a reliable mechanism for keeping untrusted software out of your deployments. This additional layer of trust in your deployment pipeline ensures your team won’t inadvertently deploy untrusted code—or dependencies with known vulnerabilities—by preventing the deployment of any assets that haven’t been notarized and authenticated.

Vulnerability management isn’t the only area, however, where CAS can help shift your team’s posture from a reactive stance, where problems are detected as they arise, to a proactive one, preventing errors before they can occur.

From your users’ perspective, downtime is downtime, regardless of the cause! The adverse effects of a simple deployment mistake (e.g., building the wrong release of the source code, using a dependency known to be broken, or deploying incompatible versions of container images) can be just as significant for your customers and your organization as many types of security vulnerabilities.

If your developers are using CAS to track trusted assets, after they successfully deploy a new version of the application, the obsolete assets from the previous release can be marked as Unsupported with a single command, preventing their use in future deployments:


❯ cas unsupport –hash 899f82d8925d0659b628ab403a44a433bcd97a06

Your assets will not be uploaded. They will be processed locally.

❯ cas unsupport --hash 899f82d8925d0659b628ab403a44a433bcd97a06

Your assets will not be uploaded. They will be processed locally.

UID:		166147161902677980
Kind:		apk
Name:		busybox
Hash:		899f82d8925d0659b628ab403a44a433bcd97a06
Timestamp:	2022-08-25 23:51:29.31755798 +0000 UTC
Metadata:	hashtype="SHA1"
		version="1.35.0-r17"
SignerID:	pdbquzoltrRlcmVnZy5pbw==
Apikey revoked:	no
Status:		UNSUPPORTED

The increased trust your team has in the security and reliability of your release processes is an invaluable benefit of the Community Attestation Service, but notarization of your organization’s own assets is far from the only benefit.

Keep Tabs on Your Upstream Software Supply Chain

Broken runtimes and dependencies with critical vulnerabilities can wreak havoc on your infrastructure and your users’ experience, but CAS can help your ops team ensure known-bad assets never see the light of day.

By creating a notarized Software Bill of Materials (SBOM) with CAS when you build your Docker images, you can record the dependencies underpinning your application and detect any unwanted components before they’re used in production.

To illustrate, if a critical vulnerability is discovered in a version of an application dependency, that specific asset could be preemptively Untrusted through CAS:

Your assets will not be uploaded. They will be processed locally.

❯ cas untrust --name SOME_BAD_ASSET --hash 01463ebc7128aceff9c75f425f1

Your assets will not be uploaded. They will be processed locally.

UID:		1661475432123405651
Name:		SOME_BAD_ASSET
Hash:		01463ebc7128aceff9c75f425f1
Timestamp:	2022-08-24 00:55:39.873005651 +0000 UTC
SignerID:	pdbquzoltrRlcmVnZy5pbw==
Apikey revoked:	no
Status:		UNTRUSTED

Then, future attempts to authenticate any SBOM containing an Untrusted dependency will fail:

❯ cas authenticate --bom docker://some_new_image:latest

Resolving dependencies...
Authenticating dependencies...
 100% |███████████████████████████████████████| (91/91, 24 it/s)
adduser@3.118                   ca22aec2cb78ba7e2459cbcaff5 Trusted
coreutils@8.30-3                15c0928087598d9aa52f14d11f0 Unknown
. . .
SOME_BAD_ASSET@1.2.3            01463ebc7128aceff9c75f425f1 Untrusted
. . . 
util-linux@2.33.1-0.1           157007410d05b53ece689f9e2a9 Unknown

And, of course, any attempts to notarize the SBOM which contains an Untrusted dependency will fail with a clear error:

❯ cas notarize --bom docker://debian:buster

Resolving dependencies...
Authenticating dependencies...
 100% |███████████████████████████████████████| (91/91, 15 it/s)
Dependency SOME_BAD_ASSET@1.2.3 trust level is Untrusted
Error: some dependencies have insufficient trust level and cannot be automatically notarized

CAS gives you a centralized mechanism for tracking your software assets—and you won’t have to manage a complicated signing key architecture or run your own Certificate Authority.

It’s All Tamperproof!

All of this is backed with immudb the open source, immutable database by Codenotary, which tracks your assets and their metadata in an immutable (append-only) database.

❯ cas inspect docker://app_image:1.2.3

Extracted info from: docker://app_image
Kind:		docker
Name:		docker://app_image:1.2.3
Hash:		cea8b06eb77...8dca859181b5
Metadata:	architecture="amd64"
		platform="linux"
		docker={
		    "Id": "sha256:cea8b06eb77...8dca859181b5",
		    "RepoTags": [
		        "app_image:1.2.3"
		    ],
		    "RepoDigests": [
		        "app_image@sha256:bc41182d7ef...852a8d9730fc2ad"
		    ],
		    . . .
		}

no filter is specified. At maximum last 10 items will be returned
no signer ID provided. Full history of the item is returned
current signerID
3 notarizations found for "cea8b06eb77...8dca859181b5"

UID:		166147831001
Kind:		docker
Name:		docker://app_image:1.2.3
Hash:		cea8b06eb77...8dca859181b5
Timestamp:	2022-08-26 01:26:36.561831001 +0000 UTC
. . .
Status:		UNTRUSTED

UID:		16614771625653
Kind:		docker
Name:		docker://app_image:1.2.3
Hash:		cea8b06eb77...8dca859181b5
Timestamp:	2022-08-16 11:26:02.56539093 +0000 UTC
. . .
Status:		UNSUPPORTED

UID:		16614655050644
Kind:		docker
Name:		docker://app_image:1.2.3
Hash:		cea8b06eb77...8dca859181b5
Timestamp:	2022-08-05 22:11:45.064486291 +0000 UTC
. . .
Status:		TRUSTED

When issues arise, immutable audit logs assist with pinpointing the root cause, providing a record of timestamps, signatures, and any other metadata that is needed to track your software assets.

Have a look at the CAS documentation, and get started improving the security and reliability of your teams’ deployments today!

Use Case - Tamper-resistant Clinical Trials

Goal:

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.).

Implementation:

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

Goal:

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.

Implementation:

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

Goal:

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, …)


Implementation:

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

Goal:

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.

Implementation:

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

Goal:

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.

Implementation:

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.

Subscribe to our newsletter