From 815124a0fef4c70ab6e120942afc4e58981f1e15 Mon Sep 17 00:00:00 2001 From: Patrice Chalin Date: Thu, 21 Nov 2024 14:00:14 -0500 Subject: [PATCH] [docsy] Add About page to hold funding + disclaimer Signed-off-by: Patrice Chalin --- content/en/_index.md | 6 ++-- content/en/about.md | 33 +++++++++++++++++++ content/en/docs/getting-started.md | 4 +-- .../docs/{system-overview.md => overview.md} | 32 ++++++++---------- hugo.yaml | 20 +++++++++-- 5 files changed, 68 insertions(+), 27 deletions(-) create mode 100644 content/en/about.md rename content/en/docs/{system-overview.md => overview.md} (95%) diff --git a/content/en/_index.md b/content/en/_index.md index e73bc7f..cc9007e 100644 --- a/content/en/_index.md +++ b/content/en/_index.md @@ -28,15 +28,13 @@ integrations {{% blocks/lead color="primary" %}} -in-toto is designed to ensure the integrity of a software product from -initiation to end-user installation. It does so by making it transparent to the -user what steps were performed, by whom and in what order. +{{% param whatIsInToto %}} {{% /blocks/lead %}} {{% blocks/section color="dark" type="row" %}} -{{% blocks/feature icon="fa-solid fa-lock" title="Software supply chain protection" url="/docs/system-overview/" %}} +{{% blocks/feature icon="fa-solid fa-lock" title="Software supply chain protection" url="/docs/overview/" %}} **Supply chain compromises are becoming a frequent occurrence. in-toto can help you protect your software supply chain.** {{% /blocks/feature %}} diff --git a/content/en/about.md b/content/en/about.md new file mode 100644 index 0000000..2fa7532 --- /dev/null +++ b/content/en/about.md @@ -0,0 +1,33 @@ +--- +title: About in-toto +linkTitle: About +menu: { main: { weight: 10 } } +--- + +{{% blocks/cover title="About in-toto" height="auto" %}} + +{{% /blocks/cover %}} + +{{% blocks/section color="white" %}} + +{{% param whatIsInToto %}} + +To learn more, see [What is in-toto](/docs/what-is-in-toto/) and +[System overview](/docs/overview/). + +## Governance + +The in-toto project is managed by the [Linux Foundation] under the [Cloud Native +Computing Foundation][CNCF]. Contributors and maintainers are governed by the [CNCF +Community Code of Conduct][CoC]. For details, see [Governance]. + +## Funding + +{{% param funding %}} + +[CNCF]: https://cncf.io +[CoC]: https://github.com/cncf/foundation/blob/master/code-of-conduct.md +[Governance]: https://github.com/in-toto/community/blob/main/GOVERNANCE.md +[Linux Foundation]: https://www.linuxfoundation.org + +{{% /blocks/section %}} diff --git a/content/en/docs/getting-started.md b/content/en/docs/getting-started.md index 2c791e1..4a3364b 100644 --- a/content/en/docs/getting-started.md +++ b/content/en/docs/getting-started.md @@ -1,10 +1,8 @@ --- -title: Getting Started +title: Getting started weight: 2 --- -## Introduction - in-toto provides a framework to protect the integrity of the software supply chain. It does so by verifying that each task in the chain is carried out as planned, by authorized personnel only, and that the product is not tampered with diff --git a/content/en/docs/system-overview.md b/content/en/docs/overview.md similarity index 95% rename from content/en/docs/system-overview.md rename to content/en/docs/overview.md index 8002d8b..04994ce 100644 --- a/content/en/docs/system-overview.md +++ b/content/en/docs/overview.md @@ -1,13 +1,9 @@ --- -title: 'System Overview' -description: - 'An overview of the in-toto framework, detailing its components and workflow - for software supply chain security.' +title: Overview +description: Overview of the in-toto framework weight: 3 --- -## System Overview - The main goal of in-toto is to provide authentication, integrity and auditability guarantees for the supply chain that created a final product that a client will install. @@ -44,7 +40,7 @@ viewpoint of an operating system’s package manager. This is an error-free case additional inspection steps. If verification is successful, installation is carried out as usual. -### 2.1 Involved parties and their roles +## 2.1 Involved parties and their roles In the context of in-toto, a role is a set of duties and actions that an actor must perform. @@ -66,7 +62,7 @@ In addition, there are third-party equivalents of the above roles, which are managed by the sublayout mechanism, described in section 2.1.3. We will elaborate on these roles in depth now. -#### 2.1.1 Project owner +### 2.1.1 Project owner As previously stated, the project owner sets the required steps to be performed in the supply chain. For each step, its requirements, and the specific public @@ -74,7 +70,7 @@ keys that can sign for evidence of the step are included to ensure compliance and accountability. In addition, the layout file will contain the definition of inspection steps to be carried out when verifying the final product. -#### 2.1.2 Functionaries +### 2.1.2 Functionaries Functionaries are intended to carry out steps within the supply chain, and to provide evidence of this by means of link metadata. @@ -88,7 +84,7 @@ supply chain a sublayout. In this case, a subset of the steps to be performed are defined by such a functionary, who adopts the role of a project owner for this sublayout. -#### 2.1.3 Clients +### 2.1.3 Clients Clients are users or automated tools who want to use the product. @@ -101,7 +97,7 @@ by the layout for this inspection step. A client will likely not interact with the in-toto framework directly, as it should be integrated into system installation tools, or package managers. -#### 2.1.4 Third-party sublayouts +### 2.1.4 Third-party sublayouts Sublayouts allow a functionary to further define steps within the supply chain. When a functionary defines a sublayout, instead of carrying out the next step, @@ -114,7 +110,7 @@ example, a package maintainer for a Linux distribution will likely trust all the steps in the version control system as a sublayout defined by upstream developers of each package. -### 2.2 in-toto components +## 2.2 in-toto components A in-toto implementation contains three main components: @@ -132,7 +128,7 @@ A in-toto implementation contains three main components: of the reference implementation, the tool performing this operation is "in-toto-verify". -### 2.3 System workflow example +## 2.3 System workflow example To exemplify how these roles interact, we will describe a simple scenario. We provide more specific scenarios in section 5.3, after we have presented a more @@ -193,7 +189,7 @@ For example, a project may want to impose a review policy on the VCS. Thus, it requires in-toto to validate additional accompanying link and layout metadata to verify the review policy was followed. -### 3.1 Contents +## 3.1 Contents The final product must contain at least these three files: @@ -205,7 +201,7 @@ More complex and robust supply chain layouts will contain more pieces of link metadata, as well as additional sublayout files. Additional metadata (e.g., a signed git commit log) can also be provided to be used during inspection phases. -#### 3.1.1 Supply chain Layout +### 3.1.1 Supply chain Layout The supply chain layout specifies each of the different steps and its requirements, as well as the public keys used by functionaries to sign the link @@ -214,7 +210,7 @@ metadata for steps within the chain. The layout will also specify how each piece of link metadata will be verified, and how the chain steps are interconnected via their materials and products. -#### 3.1.2 Link metadata +### 3.1.2 Link metadata Link metadata is a statement that a step was carried out. Each piece of link metadata will be used by the framework to ensure that the contents of materials @@ -227,13 +223,13 @@ chains. in-toto supports such scenarios by not directly associating link metadata with a specific layout. Multiple layouts, therefore, can use the same link metadata during their respective verifications. -#### 3.1.3 Target files +### 3.1.3 Target files Target files are the files clients will install and use in their systems. For example, a target file could be an installation disk image, which will be bundled with link metadata for each step performed to create the target file. -#### 3.1.4 Additional metadata files +### 3.1.4 Additional metadata files Additional metadata files can be shipped within the final product for verification. In this case, inspection steps that utilize this metadata can be diff --git a/hugo.yaml b/hugo.yaml index f5897d4..23ed33c 100644 --- a/hugo.yaml +++ b/hugo.yaml @@ -26,8 +26,23 @@ imaging: languages: en: languageName: English + languageCode: en-US params: description: A framework to secure the integrity of software supply chains + whatIsInToto: | + in-toto is designed to ensure the integrity of a software product from + initiation to end-user installation. It does so by making it transparent to the + user what steps were performed, by whom and in what order. + funding: | + This research was supported by the US [National Science Foundation][NSF] + (NSF), the Defense Advanced Research Projects Agency (DARPA) and the Air + Force Research Laboratory (AFRL). Any opinions, findings, and + conclusions or recommendations expressed in this material are those of + the authors and do not necessarily reflect the views of NSF, DARPA and + AFRL. The United States Government is authorized to reproduce and + distribute reprints notwithstanding any copyright notice herein. + + [NSF]: https://www.nsf.gov markup: goldmark: @@ -44,10 +59,11 @@ params: logo: /img/logo.png copyright: authors: >- - in-toto Authors | Docs [CC BY - 4.0](https://creativecommons.org/licenses/by/4.0) + in-toto Authors | [CC BY 4.0](https://creativecommons.org/licenses/by/4.0) + | [Funding](/about/#funding) | from_year: 2020 github_repo: &repo https://github.com/in-toto/in-toto.io + privacy_policy: https://www.linuxfoundation.org/legal/privacy-policy ui: showLightDarkModeMenu: true