in-toto.adoc

in-toto CNCF Incubating Project Proposal

Name of Project: in-toto

Description:

in-toto is a framework to secure software supply chains in and outside of the cloud.

Current cloud native deployments build software using a complex process that is vulnerable to attack. Building software involves a software supply chain comprised of version control systems, build servers, CI/CD systems, test frameworks, localization, etc. that must all be honest or else the software may be tampered with. in-toto is the first framework to provide cryptograpically verifiable, full-system provenance of all the artifacts (e.g., source code files, executables, documentation, pictures, etc.) within the supply chain. As a result, in-toto is able to defend against malicious parties that tamper with a company’s software.

Current CNCF Ecosystem Integrations:

• TUF:

  • Datadog has integrated TUF and in-toto into their pipeline. We intend to standardize this approach as a best-practices document within our organization.

• Kubernettes:

  • kubectl plugin: There is a kubectl plugin that you can use to scan containers running in pods to check that they pass in-toto verification. more here

  • Admission webhook: in-toto can also be set up as an admission controller to verify the ingress of any containers. more here

Sponsors from TOC: Michelle Noorali

Preferred maturity level: sandbox

Unique identifier: in-toto

Current Core Maintainers:

1. Santiago Torres-Arias

2. Justin Cappos

3. Lukas Puhringher

License: Apache License v 2 (ALv2)

Code Repositories:

The following code repositories contain all of the available components for in-toto

1. reference implementation

2. specification documents

3. governance documents

4. Java implementation

5. Go implementation

6. kubectl plugin

7. Admission controller webhook

8. Admission controller webhook

9. Jenkins CI official plugin

External Code Dependencies
External dependencies of in-toto are listed below:

component	Software	License	Project Page
reference-implementation	attrs	MIT	https://attrs.readthedocs.io/en/stable/
reference-implementation	python-dateuril	BSD	https://labix.org/python-dateutil
reference-implementation	six	MIT	https://six.readthedocs.io/
reference-implementation	pathspec	MPL-2.0	https://github.com/cpburnz/python-path-specification
reference-implementation	pycryptodome	BSD	https://www.pycryptodome.org/en/latest
reference-implementation	pynacl	Apache 2.0	https://github.com/pyca/pynacl/
reference-implementation	subprocess32	PSFLv2	https://github.com/google/python-subprocess32
java implementation	Bouncy Castle	MIT	https://www.bouncycastle.org/
java implementation	Gson	Apache 2.0	https://github.com/google/gson/
jenkins plugin	google-http	Apache 2.0	https://developers.google.com/api-client-library/java/google-http-java-client/
jenkins plugin	jedis	MIT	https://github.com/xetorthio/jedis
admission webhook	kubewebhook	Apache 2.0	https://github.com/slok/kubewebhook
admission webhook	k8s.io/*	Apache 2.0	https://github.com/kubernetes/k8s.io
kubectl plugin	k8s.io/*	Apache 2.0	https://github.com/kubernetes/k8s.io

Committer information:

• Initial commiters:

  • Santiago Torres-Arias (NYU)

  • Justin Cappos (NYU)

  • Lukas Puehringher (NYU)

  • Ofek Lev (DataDog)

  • Joey Pabalinas (NYU)

  • Sebastien Awwad (NYU)

• Total committers:

  • 13 on the reference implementation

  • 16 total over all repositories

Users of Note:

Datadog has a detailed integration document where they describe their usage of in-toto and TUF to deliver end-to-end verified agent integration wheels

Communication channels: in-toto currently uses three communication channels:

1. Slack team: #in-toto @ https://securesystemslab.slack.com/
   

2. Mailing list: [email protected]

3. irc channel: [email protected]

Website/Blog:

The website is currently a 301 to in-toto.github.io: https://in-toto.io

Blogposts related to in-toto are currently published in NYU’s secure systems’s lab blog. https://ssl.engineering.nyu.edu/blog/

Release Cadence:

in-toto’s release process for the reference implementation has a strict adherence with semver. The release schedule is as follows:

• 2 months of feature develoment

• 1 one month of feature freeze

• 1 month of release candidacy

Other code repositories will follow semver as they mature. Specifications and other repositories follow the release code published in the enhancement documents https://github.com/in-toto/ITE

Statement on alignment with CNCF mission:

The cloud-native ecosystem has evolved into an incredibly rich and featureful set of applications that are built using a complex set of tools. Ensuring applications are built correctly and without tampering is paramount for cloud security. Furthermore, vulnerability scanners, static analyzers, buildfarms, code review systems, etc. need a way to have their outcomes validated before applications are shipped. in-toto’s architecture provides cryptographically verifiable methods to ensure compliance and security for all tools, hence protecting cloud applications.

in-toto aligns with the CNCF mission statement by:

• being-container transparent: when designing in-toto, we considered the nature of all toolchains involved in contemporary applications. As such, in-toto can be used in and out of the cloud interchangably. Furthermore, in-toto can be used in hybrid cloud setups.

• Helping to enforce cloud native best practices: in-toto layouts are a great place to locate cloud native policy information. With it, parties can judge and verify that a project is, in-fact, running a correct process in their cloud native pipeline. Our admission webhook can be used to enforce the admission of pods, daemonsets and statefulsets that strictly followed the layout assigned to them.