Overview

Introduction

Argos provides a framework to protect the integrity of a software supply chain. It provides a REST API and client libraries in order to protect the integrity of artifacts produced by a software supply chain.

It does so by verifying that each step in the chain is carried out as planned, by authorized systems or personnel, and that the product is not tampered with in transit.

It allows a project owner to create a layout. A layout lists the sequence of steps of the software supply chain, and the functionaries authorized to perform these steps.

When a functionary performs a step it gathers information about the related files and sends it to the Argos Notary Service in a link metadata file. As a consequence link files provide the required evidence to establish a continuous chain that can be verified against the steps defined in the layout

The layout, signed by the project owners together with the links, signed by the designated functionaries for a particular supply chain run, can be verified by the service.

This Overview is a short description of the system. A complete definition can be found in other parts of the documentation.

System overview

Involved actors

In the context of Argos Notary, a actor has duties and has to perform a set of actions.

In the description of the actors that follows, it is important to remember that the framework has been designed to allow a large amount of flexibility for many different use cases. Given that every project uses a very specific set of tools and practices, this is a necessary requirement for Argos Notary.

There are three different kind of actors in the framework:

  • Project Owner: defines the layout of a software supply chain.
  • Functionary: performs a step in the supply chain and provides a signed link as a record that such a step was carried out.
  • Client: Performs verification on a set of end products by requesting a validation of the set on the Argos Notary Service.

Layouts and links are signed with the private RSA key of the actor.

Components

Argos Notary has three types of components

  • Argos Notary Service: An integrated service to store and manage all Argos Notary objects
  • Artifact Collectors: Services to collect Artifacts in the same as domain as the Artifact store, e.g. Git, Maven...
  • Deployment Verifiers: Extensions on Deployment Mechanisms to validate end products to deploy.

Workflow example

To exemplify the working of the system, we will describe a simple scenario.

Consider a project owner, Alice, and her five functionaries, Diana, Bob, Carl, Build and Client. Alice wants Diana to write a Python script (foo.py). Then, Alice wants Build to package the script into a tarball (foo.tar.gz). This tarball will be sent to the client, Client, as part of the end product. Client wants to deploy this target file, foo.tar.gz.

Alice will create a layout object that will be used by the Argos Notary Service during the release request to make sure of the following:

  • That Bob and Carl approved the script which was written by Diana
  • That the script written by Diana was input for the packaging of the tarball done by Build.
  • That the tarball end product is approved by Alice.

In order for the Argos Notary Servive to do this, it will need four link objects and the layout: first, Alice’s layout, describing the requirements listed above. Then, 2 link objects signed by Bob and Carl which correspond to the approval of Diana’s action of writing a script, and a link object signed by Build for the step of packaging the script. Finally, there should be a link object, including the target file (foo.tar.gz) artifact, signed by Alice to approve the all end products.

When the Argos Notary Service releases this end product on behalf of Alice, it will perform the following checks:

  1. The layout exists and is signed with a trusted key (in this case, Alice's).
  2. All end product artifacts match with the expected end products in the layout.
  3. Every step in the layout has at least as much as needed corresponding link objects signed by the intended functionaries, as described in the layout.
  4. All the materials and products listed in the link object match, as specified by the layout. This will be used to prevent packages from being altered without a record (missing artifacts in the link object), or tampered with while in transit. In this case, the products reported by Bob should match the materials reported by Build and so on.

If all of these verifications pass, the Argos Notary Service creates and stores a Release Dossier and returns the valid response on the request.

If Client wants to verify the validity of the target file it requests a verification of the hash in combination with optionally the domain of the Supply Chain. For this request the Argos Notary Service checks the availabillity of the Release Dossier with the hash of the target file with optionally the domain.

Workflow1. the workflow for this example

Acknowledgement

Argos Notary is an implementation of or at least inspired by the in-toto specification. This is the reason some parts of this documentation are the same as that specification. We couldn't completely refer to that specification because there also large differences. We are absolutely gratefull for the inspiration we got from their work.