CNCF技術監視委員会（TOC）は、in-totoプロジェクトをCNCFインキュベーションプロジェクトとして受け入れた。in-totoプロジェクトは、ソフトウェアのビルド・配信プロセス全体（「サプライチェーン」）を悪意のある攻撃者から暗号によって保護することを目的としている。
in-totoプロジェクトは「ソフトウェアサプライチェーンの整合性を暗号によって保証するフレームワーク」だ。フレームワークのコアアーキテクチャは、3つの設計原則に基づいている。それは、侵害に対する回復力、チェーン内におけるエンドツーエンドでの存在の保証、どこにでも採用できる十分な表現力である。in-totoは2019年にCNCFサンドボックスに参画して以降、2020年にバージョン1.0をリリースした。そして、安定性の実現、SPIFFEのサポート、より表現力のあるエビデンス収集、さまざまな言語での実装に重点を置いてきた。in-totoはさまざまな組織の本番環境に採用されている。
ソフトウェア成果物のビルド・リリースプロセスには、複数のステップ（in-totoはそれをサプライチェーンと呼ぶ）がある。攻撃者がいずれかのステップにアクセスできるようになった場合、そのステップの出力を制御できてしまう。in-totoの目標は、チェーン内のステップを保護するのではなく、チェーン自体を暗号で検証することである。重要なことは、各ステップには、攻撃対象領域が異なるさまざまなインフラストラクチャやソフトウェアが含まれる可能性があるということである。最近のレポートによると、ソフトウェアサプライチェーン攻撃は2020年と比較して2021年に3倍になった。
CNCFのセキュリティテクニカルアドバイザリーグループ（TAG）は、昨年の論文で安全なソフトウェアサプライチェーンを作り出すための4つの原則を示した。それは、すべてのステップでの信頼の確立と検証、自動化、チェーンの各ステップでのスコープと各アクターの役割の明確さ、相互認証である。TAGが論文で述べているように「in-totoには、リンクを分析して、レイアウトで設定された制約を満たしていることを保証するための検証ワークフローが含まれている」。
オリジナルのin-totoの開発者の1人Santiago Torres-Arias氏は、USENIX Security 2019の講演で、in-totoプロジェクトの背景にある設計原則について詳しく説明した。最初の原則である侵害に対する回復力は、役割を分離し、失効とキーローテーションを第1の基本として維持することによって実現される。in-totoの2番目の設計原則は、コードの最初の行がコミットされた瞬間からエンドユーザーがソフトウェアをインストールしたり、使ったりするまでのパイプライン全体をカバーする包括的なツールになることである。これは、可能な限りツールにとらわれず、パイプラインとのシームレスな統合を目指すことで実現される。3番目の設計原則は、どこにでも採用できるように十分な表現力を持つことである。
in-totoのアーキテクチャは、ソフトウェアサプライチェーンのステップとコントロールする権限のあるアクターの両方を検証可能な形で定義できることをベースとしている。アーティファクトがそのチェーンを流れるときに、アーティファクト同志が強くバインドされる。in-totoでは「レイアウト」、公開鍵、「アーティファクトルール」を備えたDSLが使われる。レイアウトはアクターを定義するものである。アーティファクトルールは、アーティファクトがサプライチェーンのステップにどのように関連するかが記述されるものである。ワークフロー全体は通常、プロジェクトオーナーによって署名される。プロジェクトオーナーは、プロジェクトのガバナンスに応じて、セキュリティチームあるいは個人となる。in-totoは、攻撃者がソースコードリポジトリ、CI/CDシステム、コンテナオーケストレータ、サーバ間通信チャネル、開発者キーなどのコアインフラストラクチャを侵害する可能性があることを前提としている。そのような状況になった場合は、セキュリティのグレースフル・デグラデーション（品質低下を最小限に抑えた代替手段）が提供される。
in-totoプロジェクトは、Datadog、kubesec、SolarWinds、rebuilderdなど多くの組織の本番環境で採用されている。このプロジェクトはGitHubでホストされている。