in-toto / witness

Witness is a pluggable framework for software supply chain risk management. It automates, normalizes, and verifies software artifact provenance.

Witness

DOCS • CONTRIBUTING • LICENSE

bash <(curl -s https://raw.githubusercontent.com/in-toto/witness/main/install-witness.sh)

What does Witness do?

✏️ Attests - Witness is a dynamic CLI tool that integrates into pipelines and infrastructure to create an audit trail for your software's entire journey through the software development lifecycle (SDLC) using the in-toto specification.

🧐 Verifies - Witness also features its own policy engine with embedded support for OPA Rego, so you can ensure that your software was handled safely from source to deployment.

What can you do with Witness?

• Verify how your software was produced and what tools were used
• Ensure that each step of the supply chain was completed by authorized users and machines
• Detect potential tampering or malicious activity
• Distribute attestations and policy across air gaps

Key Features

• Integrations with GitLab, GitHub, AWS, and GCP.
• Designed to run in both containerized and non-containerized environments without elevated privileges.
• Implements the in-toto specification (including ITE-5, ITE-6 and ITE-7)
• An embedded OPA Rego policy engine for policy enforcement
• Keyless signing with Sigstore and SPIFFE/SPIRE
• Integration with RFC3161 compatible timestamp authorities
• Process tracing and process tampering prevention (Experimental)
• Attestation storage with Archivista

Demo

Quick Start

Installation

To install Witness, all you will need is the Witness binary. You can download this from the [releases] (https://github.com/testifysec/witness/releases) page or use the install script to download the latest release:

bash <(curl -s https://raw.githubusercontent.com/in-toto/witness/main/install-witness.sh)

Tutorials

Check out our Tutorials:

• Getting Started
• Verify an Artifact Policy
• Using Fulcio as a Key Provider

Media

Check out some of the content out in the wild that gives more detail on how the project can be used.

Blog/Video - Generating and Verifying Attestations With Witness

Blog - What is a supply chain attestation, and why do I need it?

Talk - Securing the Software Supply Chain with the in-toto & SPIRE projects

Talk - Securing the Software Supply Chain with SBOM and Attestation

Get Involved with the Community!

Join the CNCF Slack and join the #in-toto-witness channel. You might also be interested in joining the #in-toto channel for more general in-toto discussion, as well as the #in-toto-archivista channel for discussion regarding the Archivista project.

Background

This project was created by TestifySec before being donated to the in-toto project. The project is maintained by the TestifySec Open Source team and a community of contributors.

witness's Issues

Add option to emit stdout/errout

Currently, witness does not emit stdout and errout from the command it runs

Witness should verify the rekor log entry proof

When importing rekor log entries witness should verify the proof with the CA provided in the witness policy document.

dog food witness in pipeline

Migrated from gitlab -- original author @mikhailswift

after witness dev is a bit more stable we should dogfood it and use it in witness' ci pipeline

Azure Identity Attestation

Migrated from gitlab -- original author @colek42

Needs information on what Azure provides for this

design command options

Now, we use global variables to hold values of the command's flags, so, use a better approach to do this, in cosign, they use options package, maybe we use the similar approach in witness, please feel free to assign this to us.

• https://github.com/sigstore/cosign/blob/main/cmd/cosign/cli/options/options.go#L20
• https://github.com/sigstore/cosign/blob/main/cmd/cosign/cli/options/generate_key_pair.go#L23
• https://github.com/sigstore/cosign/blob/cfd981e8e61c79a8d292937cb893b59495f23076/cmd/cosign/cli/generate_key_pair.go#L25

cc: @colek42 @Dentrax @mikhailswift

Document crypto

Document supported key types
Add key generation examples

define attestation data format with CUE

Migrated from gitlab -- original author @colek42

unable to build project: rekor: invalid: unknown revision 1b90504cce4e

Any ideas 🤔

$ go build .
go: downloading github.com/testifysec/rekor v0.3.1-0.20211115055020-1b90504cce4e
pkg/rekor/rekor.go:6:2: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e
pkg/rekor/rekor.go:7:2: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e
pkg/rekor/rekor.go:8:2: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e
pkg/rekor/rekor.go:11:2: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e

$ go mod tidy
go: downloading github.com/testifysec/rekor v0.3.1-0.20211115055020-1b90504cce4e
github.com/testifysec/witness/pkg/rekor imports
	github.com/sigstore/rekor/pkg/client: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/rekor imports
	github.com/sigstore/rekor/pkg/generated/client/entries: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/rekor imports
	github.com/sigstore/rekor/pkg/types: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/rekor imports
	github.com/sigstore/rekor/pkg/types/intoto/v0.0.1: github.com/testifysec/[email protected]: invalid version: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/attestation/gcp-iit imports
	google.golang.org/grpc/status tested by
	google.golang.org/grpc/status.test imports
	github.com/google/go-cmp/cmp: github.com/sigstore/[email protected] (replaced by github.com/testifysec/[email protected]): version "v0.3.1-0.20211115055020-1b90504cce4e" invalid: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/attestation/git imports
	github.com/go-git/go-git/v5 tested by
	github.com/go-git/go-git/v5.test imports
	github.com/go-git/go-git-fixtures/v4: github.com/sigstore/[email protected] (replaced by github.com/testifysec/[email protected]): version "v0.3.1-0.20211115055020-1b90504cce4e" invalid: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/attestation/git imports
	github.com/go-git/go-git/v5 tested by
	github.com/go-git/go-git/v5.test imports
	gopkg.in/check.v1: github.com/sigstore/[email protected] (replaced by github.com/testifysec/[email protected]): version "v0.3.1-0.20211115055020-1b90504cce4e" invalid: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/attestation/git imports
	github.com/go-git/go-git/v5 imports
	github.com/go-git/go-git/v5/plumbing/transport/client imports
	github.com/go-git/go-git/v5/plumbing/transport/ssh tested by
	github.com/go-git/go-git/v5/plumbing/transport/ssh.test imports
	github.com/armon/go-socks5: github.com/sigstore/[email protected] (replaced by github.com/testifysec/[email protected]): version "v0.3.1-0.20211115055020-1b90504cce4e" invalid: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/attestation/git imports
	github.com/go-git/go-git/v5 imports
	github.com/go-git/go-git/v5/plumbing/transport/client imports
	github.com/go-git/go-git/v5/plumbing/transport/ssh tested by
	github.com/go-git/go-git/v5/plumbing/transport/ssh.test imports
	github.com/gliderlabs/ssh: github.com/sigstore/[email protected] (replaced by github.com/testifysec/[email protected]): version "v0.3.1-0.20211115055020-1b90504cce4e" invalid: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/attestation/git imports
	github.com/go-git/go-git/v5 imports
	github.com/go-git/go-git/v5/utils/ioutil imports
	github.com/acomagu/bufpipe tested by
	github.com/acomagu/bufpipe.test imports
	github.com/matryer/is: github.com/sigstore/[email protected] (replaced by github.com/testifysec/[email protected]): version "v0.3.1-0.20211115055020-1b90504cce4e" invalid: unknown revision 1b90504cce4e
github.com/testifysec/witness/pkg/spiffe imports
	github.com/spiffe/go-spiffe/v2/workloadapi imports
	github.com/spiffe/go-spiffe/v2/proto/spiffe/workload imports
	google.golang.org/protobuf/types/known/structpb tested by
	google.golang.org/protobuf/types/known/structpb.test imports
	github.com/google/go-cmp/cmp/cmpopts: github.com/sigstore/[email protected] (replaced by github.com/testifysec/[email protected]): version "v0.3.1-0.20211115055020-1b90504cce4e" invalid: unknown revision 1b90504cce4e

Support cosign key type

➜  kubectl git:(master) ✗ cosign generate-key-pair
Enter password for private key: 
Enter password for private key again: 
File cosign.key already exists. Overwrite (y/n)? y
Private key written to cosign.key
Public key written to cosign.pub
➜  kubectl git:(master) ✗ cat cosign.key          
-----BEGIN ENCRYPTED COSIGN PRIVATE KEY-----
REDACTED
TlIrY3c0VGs0b0lSaHNwam5hcWVuWlFHcHc9PSJ9
-----END ENCRYPTED COSIGN PRIVATE KEY-----

Github Attestation

Migrated from gitlab -- original author @colek42

Record CLOSE syscall

When a file is closed record the file and hash. This will help detect tampering between compiler stages. For example gcc stores files in /tmp/$file

Generate attestation bundle at verification time (Verification Attestations)

Migrated from gitlab -- original author @mikhailswift

During witness verify we could bundle attestations that were used to satisfy a policy. This bundle could then be signed with an expiration to be used as proof that it satisfies the policy.

Signed or unsigned the bundle could be used to re-evaluate the policy and ensure everything passes.

SLSA has a concept of a bundle that may fit this use case: https://github.com/slsa-framework/slsa/blob/main/controls/attestations.md#compound-statement

Follow symlinks in the artifact attestor.

(base) ➜  linux git:(master) ✗ ./../witness/witness run -s build -k testkey.pem --trace -o attestation.json -- \
  bash -c "make"
failed to run attestors: read /home/nkennedy/proj/linux/scripts/dtc/include-prefixes/arc: is a directory

(base) ➜  linux git:(master) ✗ ls /home/nkennedy/proj/linux/scripts/dtc/include-prefixes -al
total 8
drwxrwxr-x 2 nkennedy nkennedy 4096 Dec 10 14:25 .
drwxrwxr-x 4 nkennedy nkennedy 4096 Dec 10 14:25 ..
lrwxrwxrwx 1 nkennedy nkennedy   26 Dec 10 14:25 arc -> ../../../arch/arc/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   26 Dec 10 14:25 arm -> ../../../arch/arm/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   28 Dec 10 14:25 arm64 -> ../../../arch/arm64/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   28 Dec 10 14:25 dt-bindings -> ../../../include/dt-bindings
lrwxrwxrwx 1 nkennedy nkennedy   28 Dec 10 14:25 h8300 -> ../../../arch/h8300/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   33 Dec 10 14:25 microblaze -> ../../../arch/microblaze/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   27 Dec 10 14:25 mips -> ../../../arch/mips/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   28 Dec 10 14:25 nios2 -> ../../../arch/nios2/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   31 Dec 10 14:25 openrisc -> ../../../arch/openrisc/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   30 Dec 10 14:25 powerpc -> ../../../arch/powerpc/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   25 Dec 10 14:25 sh -> ../../../arch/sh/boot/dts
lrwxrwxrwx 1 nkennedy nkennedy   29 Dec 10 14:25 xtensa -> ../../../arch/xtensa/boot/dts

cache go mod deps

Migrated from gitlab -- original author @mikhailswift

currently no caching is happening in the pipeline. this would speed up builds.

Remote attestation interface

Migrated from gitlab -- original author @colek42

attestors that require remote attestation should follow an interface

Unable to run ./witness run -s build -k testkey.pem -o attestation.json -- \ go build .

I keep failing when I try to run the witness.

I tried cmod 777
❯ ls -l witness
-rwxrwxrwx@ 1 maorkuriel staff 18464768 Dec 9 23:31 witness

but still getting zsh: exec format error: ./witness

I also "white-listed" it in the security and privacy tab.

Any thoughts?

Add logging and verbosity options

We should make a logging interface that library code can use to make relevant logs. Using an interface will allow users to pass their own logging library and configuration instead of having competing logging libraries.

We should take a verbosity / log level argument at command run time to allow the program to print debug logs if necessary

Generate hashes for CommandRun trace attestor

Record Network syscalls

ref: https://developer.ibm.com/articles/au-tcpsystemcalls/

Unable to expand witness_$VERSION_$ARCH.tar.gz

When I have downloaded the file and run the Tar command as instructed, I get an error message.

❯ curl -LO https://github.com/testifysec/witness/releases/download/$\{VERSION\}/witness_$\{VERSION\}_$\{ARCH\}.tar.gz

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 9 100 9 0 0 3 0 0:00:03 0:00:02 0:00:01 3

❯ tar -xzf witness_${VERSION}_${ARCH}.tar.gz

tar: Error opening archive: Failed to open 'witness__.tar.gz'

CI/CD Process Tracking Issue

• create a new release with GoReleaser both for binaries and container images
• automate workflow with GitHub Actions?
• sign/verify binaries&container images GitHub Actions OIDC and keyless approach?
• Mage?
• golangci-lint?
• e2e testing?
• ko?

cc: @colek42 @Dentrax @mikhailswift

Rego implementation

Migrated from gitlab -- original author @mikhailswift

Use rego to evaluate policies

Generate Docs

https://github.com/spf13/cobra/blob/master/doc/md_docs.md

Retrieve attestations from Rekor at verification time

Migrated from gitlab -- original author @mikhailswift

Currently witness verify doesn't support loading attestations from rekor and will only load them from disk.

All attestors should have a test for the Attest function

Stress testing

Add end to end testing for the following projects

• Linux Kernel
• Kubernetes
• ElasticSearch

Create contributing guidelines and issue/pull request formats

Some requirements for contributing guidelines:

• Commit messages should include a brief summary (around 72 characters) as the first line. After a blank line a more detailed summary will follow. b8da9da for example. https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53 may be a good foundation for these rules
• We will be maintaining a linear history in the main branch. We will be using rebase merging through github. All commits on pull requests should be squashed appropriately. Multiple commits in a pull request is acceptable but each commit should meaningful and have good reason to be distinct from others in the same pull request
• PRs should link to relevant issues
• Ideally each PR will be reviewed by multiple users with merge permissions, but while we don't have a large contributor base a single review will be required.
• Adopt or create a code of conduct for contributors. https://www.contributor-covenant.org/ may be a good one to adopt.

add/check license headers

• https://github.com/google/addlicense

   - name: Install addlicense
        run: go install github.com/google/addlicense@latest
    - name: Check license headers
        run: |
          set -e
          addlicense --check -l apache -c 'The Sigstore Authors' -v *

k8s service account attestor

Establish subject naming standards

Subjects have become a bit confusing with what some of these attestors are returning. For instance:

    {
      "name": "internal-infra",
      "digest": {
        "sha256": "e0181bbb2d6ed4334fd9af9839b1ed4f1a92bd581f55840a9d7a454f6bd72b9b"
      }
    },
    {
      "name": "5cd32799ebec4597ba453c9910b1e7053330a8761ed04c018ace8dc84cb71c5f",
      "digest": {
        "sha256": "5453db6e98fc1c9c17685b08b1e746500f1854bdbc969961abbbed1526442b91"
      }
    },
    {
      "name": "https://gitlab.com/testifysec/demos/witness-demo/-/jobs/1859961652",
      "digest": {
        "sha256": "161884fb0e5e6477a351355b1d64f9d37f4322a9948100838067814eccf14cd4"
      }
    },
    {
      "name": "helloworld",
      "digest": {
        "sha256": "13fed16845d228d4adfc3bdf69058ebbacc682555ac1d88188939f44acb77aa2"
      }
    },

What are internal-infra and 5cd32799ebec4597ba453c9910b1e7053330a8761ed04c018ace8dc84cb71c5f? I know what internal-infra is due to previous knowledge but it's not clear. I have no idea what this hash is as a subject and what the subject represents. The gitlab url is more clear since it is pointing to what it represents. helloworld is a file that was built as a result of the command being run, but again not obvious.

Something I did for the git attestor was add a prefix to the subject name:

    {
      "name": "git:dc6c260dd1a3e9ff14448b81cec5f0e90b9cadb6",
      "digest": {
        "sha1": "dc6c260dd1a3e9ff14448b81cec5f0e90b9cadb6"
      }
    }

The git: is to serve as a context clue that the subject is describing a git commit hash

Maybe we should refine this and make a standard about how we format and present these subject names. Perhaps in something of a URI format like attestorname://subject-type/subject-name, though maybe this isn't ideal either. Would look something like

gcp-iit://project/internal-infra for internal-infra,

gitlab://pipeline-uri/https://gitlab.com/testifysec/demos/witness-demo/-/jobs/1859961652 but maybe if the subject is already a URL we skip this formatting

commandrun://product/helloworld for product, or even file://helloworld.

Or we could add additional fields to the subject object -- but Subjects are an in-toto standard so if we go this route we should coordinate with the in-toto community on a solution.

I'm not super sold on any of these solutions but I do think we need to come up with some ideas to prevent confusion about subjects and provide hints on how to use and reason about subjects.

Remote Attestation of TPM

Migrated from gitlab -- original author @colek42

File handler module

Consolidate file handing and hashing

• Move CalculateDigestSetFromFile from crypto to new module
• Module should contain an exported function at returns a digest set given a fd
• Should handle symlinks #29

Verify Hashes trace hashes against IMA log

Witness should check traces against IMA log to detect tampering.

• If tracing is enabled and '/sys/kernel/security/ima/ascii_runtime_measurements' is readable check against log. We should not fail, but instead, record that the file did not match what was in the IMA log.

• We should add a flag to fail if the IMA log is not available.

• There is likely to be some false positives. We will have to decide how we handle the data and if we want to exit on validation failure by default.

• Add system-level docs to enable IMA in popular distros.

Docs: Gitlab integration

I'm interested in seeing what you folks are thinking about in regards to implementing this in a Gitlab pipeline.

I'm imagining bringing the tool into the pipeline might be made complex in pipelines that run in different pre-existing containers for each job since the tool needs to be onboard for each of those jobs to run the command. Would you be recommending a before_script: on each job to install witness? In a Kubernetes scenario, is there a method to run each gitlab runner pod with a witness sidecar? Maybe there'd some sort of Cillium/eBPF type solution in the near future. I presume you guys have given it more thought than me at this point, but also know that there isn't likely a simple answer for all gitlab runner scenarios.

Doc Placeholder from the README:
https://github.com/testifysec/witness/blob/main/docs/attestor.md#gitlab

Add `.witness.yaml` file support

Migrated from gitlab -- original author @colek42

Instead of a bunch of command-line arguments witness should be able to take arguments from a .witness.yaml file.

This would make it much easier to instrument CI pipelines.

Config Refactor/Dubug

• Remove all dashes from cli args
• name key identifiers to show they are either public or private keys
• all attestation names should be lowercase
• debug key loading issues. make sure args are bound to the correct command.

Atteststions/CommandRun - Investigate possibility of splitting tracers onto multiple goroutines

A tracee may only be traced by a single tracer, where a tracer and tracee refer to OS threads. However each tracee can be traced by different tracers.

Right now the CommandRun attestation traces all tracees from a singular tracer thread. We lock the goroutine to the current OS thread to ensure no issues.

It is possible to instead spin a tracer goroutine up for each tracee running on possibly different OS threads. Each tracer goroutine would have to be locked to an OS thread. This may improve performance when tracing multithreaded workloads.

Example: Air Gapped Attestation Verification

Write an example shell script showing the verification of a software artifact over an air gap.

• Should generate CA for this example (see makefile in in-toto)

1. Look up attestations from rekor for a binary
2. Create a very basic policy
3. Sign Policy with CAC/Private Key
4. Tar attestation
   ----Air Gap---
5. Untar attestations/policy
6. Use witness verify on the binary

witness shell completions

• https://github.com/spf13/cobra/blob/master/shell_completions.md

please feel free to assign it to us 🙋🏻‍♂️

rename crypto module

Migrated from gitlab -- Original author @colek42

witness/pkg/crypto has a name collision with https://pkg.go.dev/crypto, which could cause some confusion issues

Command run strace enhancement

Migrated from gitlab -- original author @colek42

Add strace support to command run to take inventory of actual file descriptors opened by the process.

Windows Build

Migrated from gitlab -- original author @colek42

configure go-releaser to create windows build.

• ensure file pathing works on Windows, 100% coverage
• add checks to disable linux attestors

Refactor policy verify code

Migrated from gitlab -- original author @mikhailswift

May be a good companion to #7

The policy verification code is currently responsible for too much. DSSE and intoto have bled into the policy package which is not ideal. The policy package should be solely focused on verifying the attestations came from trusted functionaries and match the policy.

Generating Ed25519 key/pair with LibreSSL on mac: missing algorithm

I am running MacBook Pro M1.

When I run the command openssl genpkey -algorithm ed25519 -outform PEM -out testkey.pem I get the message that Algorithm Ed25519 not found.

I upgraded to OpenSSL 1.1.1m, and then the command ran with no issues.

It will be valuable to add it to the documentation as a pre-requisite.

Write better documentation

The root README should be updated with a project description and relevant information. it can still include the CLI documentation or we can create a separate md in a docs folder detailing the CLI.

We should also create some examples of using witness.

Example: Source to Production Attestations

Attest code from source to production

1. Attest a developer commit
2. Attest a MR Approval
3. Attest SAST
4. Attest Build Process
5. Gate Pipeline success by policy

Rework tracing data model

Right now we are just recording OPEN syscalls. We should instead track events for all opened files/sockets.

example:

name:  /var/lib/somelib.so
events: [{
        pid: 776428
        name:  OPEN
        digestSet: {}
}]

AWS Identity Attestation

Migrated from gitlab -- original author @colek42

Remote Attestation of JWT

Migrated from gitlab -- original author @colek42

Add client support for remote attestation iof JWT

Example: Log4j Mitigation

Build an example in bash showing how to use attestations to find hidden dependencies such as Log4j

• Build container with the vulnerable library
• Push/deploy container in Kubernetes
• Query rekor for all deployed containers and filter for log4j library files and hashes.