From 1a5817f3138777dcfc881b829d749570e1a7b7f0 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Mon, 9 Dec 2024 16:18:07 -0500 Subject: [PATCH 01/25] add an adopter interview --- .../in-toto-adopter-interview-chainguard.md | 0 .../in-toto-adopter-interview-github.md | 92 +++++++++++++++++++ ...-toto-adopter-interview-lockheedmartins.md | 0 projects/in-toto/in-toto-graduation-dd.md | 0 4 files changed, 92 insertions(+) create mode 100644 projects/in-toto/in-toto-adopter-interview-chainguard.md create mode 100644 projects/in-toto/in-toto-adopter-interview-github.md create mode 100644 projects/in-toto/in-toto-adopter-interview-lockheedmartins.md create mode 100644 projects/in-toto/in-toto-graduation-dd.md diff --git a/projects/in-toto/in-toto-adopter-interview-chainguard.md b/projects/in-toto/in-toto-adopter-interview-chainguard.md new file mode 100644 index 000000000..e69de29bb diff --git a/projects/in-toto/in-toto-adopter-interview-github.md b/projects/in-toto/in-toto-adopter-interview-github.md new file mode 100644 index 000000000..51f6e1a6b --- /dev/null +++ b/projects/in-toto/in-toto-adopter-interview-github.md @@ -0,0 +1,92 @@ +# In-toto Adopter Interview - GitHub +Interviewee: Zach Steindler, Principal Eng at GitHub +Interview date: Oct 7, 2024 + +## Organization Intro + +### Can you give us an overview of your organization and what it does? + +GitHub is a website where people work on code together. Very popular in OSS for people to share code and build artifacts. Also used widely by enterprise. + +## Motivation + +### Compared with other products in this space (proprietary and open), what drew you to the project? + +There are primiarly 2 things that drew us to the project: + +- We started using in-toto when we added build provenance. In-toto collects source projects to write specifications. +- In-toto use cases were attractive to us. There aren’t really other projects out there as an alternative that has lots of other projects using it. + +## Usage Scenario + +### How does your organization use the project and how long have you used it? + +GitHub owns npm, we released npm provenance in 2022 which uses in-toto. We use the in-toto framework to create publish attestation. Last year we released github artifact attestation, so anything you build with github can have build provenance. We also use SBOM and use in-toto to represent it. + +### What version is used and what is your update cadence with the project? + +We maintain our own version of custom predicate. We are currently up-to-date and we update as needed. + +### Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + +It has been pretty smooth. There are docs around how to produce custom predicates. There are docs on how to produce build provenance. Libraries are relatively straightforward to use. Can’t think of any challenges we had! + +### Did you find the information in the repo valuable to your implementation? What specifically? + +Yes! Pretty good docs for in-toto attestation repo, SLSA(Supply Chain level for software artifacts) repo, very good repo. + +### Has your implementation of the project provided measurable value? + +Tens of thousands of people make use of npm provenance and github artifact attestation. + +### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +Yes! For GitHub releases, we plan to make it immutable by leveraging in-toto attestation. Besides that, nothing concrete. We always keeping track of new attestation released from in-toto. + +## Perception + +### What is your perception in terms of the project’s: + +#### Community openness + +Very open, I participated in the slack channel in CNCF, and have created issues/PRs that have been resolved. + +#### Governance + +Don’t think I attended any meeting. Some of the PRs have been reviewed by the Governance/steering committee, they were prompt and thorough in review. + +#### Community growth potential + +Could be biased, we are definitely invested in the ecosystem and believe in the growth of it. + +#### Maintainer diversity and ladder + +Multiple Xs of diversity. There is some diversity in terms of gender and people’s background (industry & academic & non profit OSS foundation). + +#### Maintainer response + +Couple of PRs made by me were handled well. Things are resolved in a reasonable amount of time. + +### How are you participating in the project community? + +Yes but not recently. About 6 months ago, I attended some community meetings and submitted PRs. + +### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome? + +So far, I have good experience with PRs. + +## Project Strengths + +### In your opinion, what are the overall strengths of the project? + +Community discussions are great and how they bring them (industry & academic & non profit OSS foundation). Really thinking ahead and anticipating needs before people need them. Continue to be an active community. + +## Project Improvements + +### Is there something you feel that holds the project back from reaching its ultimate potential? + +Not really. Struggle to come up with an answer. Only worry is if there are lots of layoffs, would people have time to contribute in-toto? + +### In your opinion, what can the project do better? + +Continue to think about where the industry is headed and anticipate the needs. They have demonstrated the ability to do so so far. diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md new file mode 100644 index 000000000..e69de29bb diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md new file mode 100644 index 000000000..e69de29bb From ea877b219d41801b834103ccad3fbbd6226cce8d Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Mon, 9 Dec 2024 22:43:13 -0500 Subject: [PATCH 02/25] DD doc --- .../in-toto-adopter-interview-github.md | 1 + ...-toto-adopter-interview-lockheedmartins.md | 107 ++++++ projects/in-toto/in-toto-graduation-dd.md | 323 ++++++++++++++++++ 3 files changed, 431 insertions(+) diff --git a/projects/in-toto/in-toto-adopter-interview-github.md b/projects/in-toto/in-toto-adopter-interview-github.md index 51f6e1a6b..90e5a9657 100644 --- a/projects/in-toto/in-toto-adopter-interview-github.md +++ b/projects/in-toto/in-toto-adopter-interview-github.md @@ -1,4 +1,5 @@ # In-toto Adopter Interview - GitHub + Interviewee: Zach Steindler, Principal Eng at GitHub Interview date: Oct 7, 2024 diff --git a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md index e69de29bb..23320ab41 100644 --- a/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md +++ b/projects/in-toto/in-toto-adopter-interview-lockheedmartins.md @@ -0,0 +1,107 @@ +# In-toto Adopter Interview - GitHub + +Interviewee: Ian Dunbar-hall, Head of Open Source Program Office, Lockheed Martins +Interview date: Sept 3, 2024 + +## Organization Intro + +### Can you give us an overview of your organization and what it does? + +[Lockheed Martins](https://www.lockheedmartin.com/en-us/contact.html) is a leading aerospace and defense company. + +## Motivation + +### Compared with other products in this space (proprietary and open), what drew you to the project? + +I recall it was at KubeCon either 2020 or 2021, and I went to the contribfest for the in-toto project. The project solves a foundational need in our space, securing software supply chain, which is very critical to our customers for delivering high quality products. Without it, it has resulted in very bad outcomes, Solarwinds, or Crowdstrike incidents, for example. + +## Usage Scenario + +### How does your organization use the project and how long have you used it? + +For the in-toto specification, we don’t directly work with specification but consume it as part of libraries. + +For the in-toto subprojects (application or libraries), we started to use the libraries in our OSS projects in Jan 2023. We have also incorporated in-toto attestation for corporate networks for any OSS projects that come to internal & external use. Basically any time when we consume any OSS projects, we check on the following: +- Is the OSS project approved for use in our company? +- How do we know if someone maliciously modified it in the corporate network? +- Can we still adopting it for products we are delivering to our customers? + +### What version is used and what is your update cadence with the project? + +We update the libraries fairly regularly, whenever any core library gets updated. +Specification changes are also adopted as part of the library update. We don’t implement the spec ourselves. + +### Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + +Overall, a really positive experience! +- Well organized oss projects, very strong community behind it. +- Very large enterprises and universities are involved. Easy to get support. +- Well beyond community compared with other graduated projects. +- We also contributed some PR and got good feedback/reviews. Testify donated a subproject under in-toto (command line client to create attestation) and we use it to create attestation for everything. +- Lots of end users and vendors. + +### Did you find the information in the repo valuable to your implementation? What specifically? + +Yes, without a ton of background, we were able to quickly incorporate the in-toto python libraries. Slack/community meetings are both helpful. Easy to get technical recommendations. Docs are quite good for such a complex problem. + +### Has your implementation of the project provided measurable value? + +Yes. The in-toto capabilities in our products were demo-ed frequently. We are writing a white paper around how to use in-toto across public sectors for supply chain security via the public sector of the CNCF end user groups. + +### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +- Need to drive more adoptions within the company. +- We are working on the SBOMit project within OpenSSF, which is built on top of in-toto: + * https://github.com/sbomit/specification + * [Bomctl](https://github.com/bomctl/bomctl) will be announced as a sandbox project as part of OpenSSF this thurs which also uses in-toto. + +## Perception + +### What is your perception in terms of the project’s: + +#### Community openness + +Very active community, weekly meeting for some part of the in-toto ecosystem. Variety of the people involved speak very well for the project. + +#### Governance + +Steering committee was formed and a lot of people involved know the spec well, a good technical community. + +#### Community growth potential + +Good growth and expansion. + +#### Maintainer diversity and ladder + +Totally see this growing. + +#### Maintainer response + +Nothing but quick response and feedback. + +### How are you participating in the project community? + +We have done in-toto related talks at CloudNativeSecurityCon, OpenSource Summit etc. We are pretty active in the community, being on the community calls. We are also maintaining a few other projects which are built on top of in-toto. + +### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome? + +A variety of reasons. My first one was a first time in-toto user and then I wanted to incorporate in-toto in our OSS tool, and a few other minor contributions. All were addressed timely with good feedback. Really good experience which led me to be more deeply involved. + +## Project Strengths + +### In your opinion, what are the overall strengths of the project? + +Beyond the community, and diversity of others using it, the spec is also very flexible. You can add to it, or expand it or create a unique solution with it. + +## Project Improvements + +### Is there something you feel that holds the project back from reaching its ultimate potential? + +Growing the list of attestation types of in-toto will strengthen the project more. For example, adding an OSS program approval. + +### In your opinion, what can the project do better? + +- Has done a really good job of getting people using in-toto and sometimes people don’t really realize they are using it. + * [SLSA](https://slsa.dev/) is built on top of in-toto, which is very well known. Yet people don’t realize it. + +- Needs more marketing or branding because people don’t realize it as much as they are using it. diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index e69de29bb..ddac54040 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -0,0 +1,323 @@ +# In-toto Graduation Due Diligence + +- [In-toto graduation application issue](https://github.com/cncf/toc/pull/1162/) + +Project Repo(s): http://github.com/in-toto +Project Site: https://in-toto.io/ +Communication: #in-toto on CNCF Slack Workspace + +Project points of contacts: Santiago Torres, santiagotorres@purdue.edu + +## Graduation Criteria Summary for In-toto + +### Criteria Evaluation + +Lin Sun (@linsun) conducted the due diligence of in-toto who applied for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: + +- A notable stable project with mature capabilities and a wide [adopter](https://github.com/in-toto/friends?tab=readme-ov-file#project-adopters) base. +- The project has a wide range of interest across academic and cross different industries. +- The project [integrates](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations) with various other projects in the cloud native ecosystem such as GitHub, GitLab, GUAC, Tekton, etc. +- Implementation of the steering committee to capture adopters' voice in the project development and roadmap. +- The project is not only vendor neutral but also has a very diversed set of maintainers, adopters and integrators. +- The project does an excellent job of making sure that its public meetings are accessible, with notes, and easy to find meeting links. + +The following actions were provided to the project that were considered blocking but have since been resolved: + +- Enable convenient linkage for community meeting notes. +- Updating the list of subprojects in GitHub, found from the Governancy review. +- Provide an updated roadmap document in GitHub. + +### Final Assessment + +The TOC has found the project to have satisfied the criteria for Graduation. + +### Adoption Assertion + +### Criteria + +## Application Process Principles + +### Suggested + +N/A + +### Required + +- [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** + +Presentation was given to the TAG security in July 2014. + +- [x] **TAG provides insight/recommendation of the project in the context of the landscape** + +[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation + +- [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** + +Don't see any concern with vendor-neutral for in-toto project. + +- [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** + - [x] Met during Project's application on 21-06-2024. + +Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria. + +- [X] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** + +Docs are available at https://in-toto.readthedocs.io/en/latest/index.html which includes install, API, code sample, and how to contribute etc. + +## Governance and Maintainers + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### Suggested + +- [x] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.** + +[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. + +### Required + +- [X] **Clear and discoverable project governance documentation.** + +Able to find it easily. + +- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** + +TODO: need some work here. + +- [X] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** + +Vendor neutral is clearly mentioned twice in the governance doc. Steering committee composition is also diverse at the moment. + +- [x] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** + +Documented [here](https://github.com/in-toto/community/tree/main/elections) + +- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** + +[GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. + +- [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** + +[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) + +- [x] **A number of active maintainers which is appropriate to the size and scope of the project.** + +- [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** + +The project maintains a description of different roles and their election process in its [community repository](https://github.com/in-toto/community) + +- [x] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.** + +Maintainers for subprojects have been managed by the ITSC and Sub-project maintainers as pull-requests to their corresponding MAINTAINERS.txt files (e.g., [[1, self nomination](https://github.com/in-toto/in-toto-rs/pull/89)],[[2, stepping down](https://github.com/in-toto/attestation/pull/406)],[[3, community nomination](https://github.com/in-toto/witness/pull/385)]). + +- [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** + +As an intentionally minimal security specification / framework, we deliberately do not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). + +Since reaching the incubation stage, the in-toto project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across our sub-projects, we have contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. + +The current ITSC comprises of the following +- Santiago Torres-Arias (Purdue University) +- Justin Cappos (New York University) +- Jack Kelly (Control Plane) +- Cole Kennedy (TestifySec) +- Trishank Karthik Kuppusamy (Datadog) + +We have had active contributions from an array of contributors across the CNCF landscape. One way to see this is via the substantial changes that made their way into the specification. + +Changes to the in-toto standard largely come in the form of ITEs (in-toto enhancements). There is a substantial ITE, ITE-4, that standardized non-file artifact specifications for in-toto metadata. The stakeholders in it are Github, Conda, SPDX and Google's Grafeas. + +Another significant ITE is [ITE-6](https://github.com/in-toto/ITE/blob/master/ITE/6/README.adoc). This enhancement introduced the in-toto Attestation Framework to record and disseminate software supply chain specific information like build provenance, code review results, test results, SBOMs, vulnerability scans, and more. in-toto attestations are now used by GitHub for NPM build provenance, OpenVEX, Docker buildx, scanners like Trivy that can generate signed SBOMs, Tekton Chains, Sigstore, GUAC, Witness, and Archivista. SolarWinds, in their next generated build system introduced after SUNBURST, also generate in-toto attestations. + +- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** + +TODO + +- [x] **Document agreement that project will adopt CNCF Code of Conduct.** +- [x] **CNCF Code of Conduct is cross-linked from other governance documents.** + +The CoC and the assertion of adherence is referenced in the [GOVERNANCE.md](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#code-of-conduct). + +- [x] **All subprojects, if any, are listed.** + +Subprojects are listed in the [README.md](https://github.com/in-toto/community/blob/main/README.md#subprojects) file of in-toto/community. + +- [x] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** + +Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee. + +## Contributors and Community + +Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. + +### Suggested + +- [x] **Contributor ladder with multiple roles for contributors.** + +The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) + +### Required + +- [x] **Clearly defined and discoverable process to submit issues or changes.** + +A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. + +- [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** + +Communication channels are encoded in the [website](https://in-toto.io/contact/). It contains a developer facing mailing list, a public mailng list, a slack join link, github and IRC contacts. + +- [x] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** + +Communication channels are encoded in the [website](https://in-toto.io/contact/) + +- [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** + +in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). + +- [x] **Documentation of how to contribute, with increasing detail as the project matures.** + +A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) + +- [ ] **Demonstrate contributor activity and recruitment.** + + + +## Engineering Principles + +- [x] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.** + +One of the most pressing security problems in cloud native is software supply chain security. in-toto addresses this issue by providing a secure and trustworthy means for representing all the operations within the cloud-native pipeline and verifying that they were carried out to the letter. +A good way to understand the need for in-toto in the Cloud Native space is to understand the value of signed SBOMs vs in-toto metadata + layouts. A signed SBOM indicates that some party (whose key you presumably have a reason to trust) states what the software contains. In contrast, in-toto will have signed information about the individual steps of the supply chain cryptographically linking metadata together from various parties and validating this all against the software’s policies. As a result, their protection modes would work quite differently in many cases. For example, see the following table: + + +| Attack scenario | Signed SBOM Result | In-toto layout + metadata result | +|-----------------|----------------------|----------------------------------| +| Software manipulated after software supply chain completed | Detect and reject the malicious software | Detect and reject the malicious software | +| Attacker compromises VCS and inserts malicious (unsigned) code where signatures are required |Undetected. User compromised. | Detect and reject the malicious software | +| Attacker substitutes a malicious dependency (not signed by that dependeny’s maintainer) |Undetected. User compromised. | Detect and reject the malicious software +| Attacker provides files to the build system which did not come from the VCS | Undetected. User compromised | Detect and reject the malicious software | +| Attacker containerizes / packages binaries other than the ones the build system built | Undetected. User compromised | Detect and reject the malicious software | +| Tests are not run on the software but it is (accidentally?) released to production | Undetected. User compromised | Detect and reject the malicious software | +| The legal team has not reviewed source code licenses for included libraries | Undetected. Impact varies | Detect and reject the software | + +One important thing to note about the table above is that it isn’t impossible for someone to do many of these steps and checks before signing an SBOM. If you did all of these checks, and signed the statements saying you did them to provide stronger validation, and distributed the root of trust for your signatures in a secure way, and managed situations where signing keys need to be revoked / rotated / expired, and handled trust delegation to different parties, and linked metadata between steps together, and let people write policies to reason about those steps, and let them link metadata in from dependencies to do so, and handled all of the above in scenarios where insiders can be maliciously interfering with your, system, then you would effectively reconstruct in-toto. +We are aware of some efforts, like the Zephyr project, where project members have worked to try to reconstruct some of the guarantees of in-toto and decided to live with the gaps in their security for other portions. For groups that have done this work already this does make sense to us as a viable alternative in the short term. However, we do believe that using a common, holistic approach like in-toto will be necessary as projects continually add the missing security pieces from in-toto and want to reason more and more about each other as dependencies. + +Note that in-toto is not a substitute for having appropriately secure steps in the software supply chain. For example, if you use an insecure process of building software that just curls and builds software from a website, in-toto will happily sign metadata indicating that you did the same insecure action indicated you would. + +This is why projects like SLSA and FRSCA are built as an opinionated set of steps on top of in-toto. They specify which actions they feel are more important for software supply chain security and mandate their use. + +These projects are solving different problems at different levels. In-toto allows you to capture information about your steps, ensure policies about them are applied, handle trust of keys, etc. Frameworks like SLSA and FRSCA use in-toto as a mechanism to capture and enforce a specific set of policies that result in more secure supply chains. + +- [x] **Document what the project does, and why it does it - including viable cloud native use cases.** + +https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and many integrations with other projects in the ecosystem. + +- [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** + +Roadmap for project with pointers to subproject ROADMAPs are encoded in a [ROADMAP.md file](https://github.com/in-toto/community/blob/main/ROADMAP.md) + +- [x] **Roadmap change process is documented.** + +Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/ROADMAP.md) outlines how and when the community-wide rodamap is updated (usually once a year). Each sub-project may also have their own ROADMAP that aligns to subproject-wide SLAs + +- [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** + +The [friends](https://github.com/in-toto/friends) repository outlines how Cloud-native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud-native CI/CD platforms, as well as social coding platforms and distributed buildsystems. + +- [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** + + - [x] Release expectations (scheduled or based on feature implementation) + - [x] Tagging as stable, unstable, and security related releases + - [ ] Information on branch and tag strategies + - [ ] Branch and platform support and length of support + - [x] Artifacts included in the release. + - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. + +in-toto has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. + +All implementations follow semver to communicate their feature support, as well as backwards and forwards compatiblity. + +- [x] **History of regular, quality releases.** + +A history of releases is [kept on our changelog](https://github.com/in-toto/in-toto/blob/develop/CHANGELOG.md) + +## Security + +Note: this section may be augemented by a joint-assessment performed by TAG Security. + +### Suggested + +- [x] **Achieving OpenSSF Best Practices silver or gold badge.** + +[in-toto achieves a gold OpenSSF Best Practice badge](https://www.bestpractices.dev/en/projects/1523?criteria_level=2) + +### Required + +- [x] **Clearly defined and discoverable process to report security issues.** + +Repositories describe the disclosure process using a [SECURITY.md file](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) + + +- [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** + +GitHub teams are used to provide granular access to different repositories within the organization. Protected branches are used to avoid pushes to master. Dependabot, and secret scanning is also added to all implementation repositories. + +- [x] **Document assignment of security response roles and how reports are handled.** + +Disclosure is handled by the ITSC. In addition, GitHub private vulnerability reporting is used (and has been successfully used before) to handle disclosures on implementations. + +- [x] **Document Security Self-Assessment.** + +in-toto was the [first project to carry out a security self-assessment](https://github.com/cncf/tag-security/commit/06b71c4db99ba07107cba6cf8f6fc6d4461fce82) with TAG security, and aided in developing the current process. + +- [x] **Third Party Security Review.** + +See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). + +- [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** + +The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). As of 31st of July, 2023, there are only 23 projects in the world to have such a distinction. The only other CNCF project with a Gold Badge is the [TUF project (a graduated security project)](http://theupdateframework.io). + +According to the OpenSSF Best Practices website, the in-toto project received its initial OpenSSF Best Practices badge on January 5th, 2018. + +## Ecosystem + +### Suggested + +N/A + +### Required + +- [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** + +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends) + +- [x] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** + +Many adopters and integrations are [documented](https://github.com/in-toto/friends). + +The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. + +- [ ] **TOC verification of adopters.** + +Refer to the Adoption portion of this document. + +- [x] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** + +Many integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). + +#### Adoption + +##### Adopter 1 - Lockheed Martins/Aerospace and defense company + +This adopter interview is performed in Sept 2024 and recorded a very happy adopter who also contributes to the in-toto project. Refer to the [interview summary](in-toto-adopter-interview-lockheedmartins.md) for more details. + +##### Adopter 2 - GitHub/Software company + +This adopter interview is performed in Oct 2024 and recorded a very adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. + +##### Adopter 3 - $COMPANY/$INDUSTRY + +_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ +MONTH YEAR \ No newline at end of file From 8b3213ed06fdd4b958ef97dd51c151f299b36657 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 12 Dec 2024 21:58:14 -0500 Subject: [PATCH 03/25] add chainguard interview --- .../in-toto-adopter-interview-chainguard.md | 80 +++++++++++++++++++ 1 file changed, 80 insertions(+) diff --git a/projects/in-toto/in-toto-adopter-interview-chainguard.md b/projects/in-toto/in-toto-adopter-interview-chainguard.md index e69de29bb..f97154303 100644 --- a/projects/in-toto/in-toto-adopter-interview-chainguard.md +++ b/projects/in-toto/in-toto-adopter-interview-chainguard.md @@ -0,0 +1,80 @@ +# In-toto Adopter Interview - Chainguard + +Interviewee: Billy Lynch, Staff Software Engineer at Chainguard +Interview date: Dec 12, 2024 + +## Organization Intro + +Chainguard is the safe source for open source, so everything we produce includes supply chain metadata like signatures, attestations, SBOMs, etc - in-toto is foundational spec for how we represent much of that data. + +## How long has your organization used the project? +Before I joined Chainguard, I was involved with in-toto as an attestation framework in various different projects (SLSA, Sigstore). I met many of the Chainguard founders through these open source projects and when I joined we continued to make heavy use of those projects, and as a result in-toto as well. We are heavy users of in-toto today, mostly the attestation spec. + +## What were the main motivations to adopt the project and which key features do you use today? + +The key feature is primarily the attestation format (e.g. the envelope and statement specs). In-toto provides a common format to describe attestation metadata like SBOMs and SLSA provenance so it is a nice and important compatibility layer for us. +In-toto also makes it easy for us to develop our own attestation predicates as well - this allows us to provide additional attestation data specific to how our images are built. + +## Compared with other products and projects in this space (proprietary and open) what drew you to the project? + +We were already working with the adjacent ecosystems (e.g. Sigstore, SLSA), so we wanted to stay in-line with the ecosystems we were already working with - in-toto was a natural choice for us. + +## What is the current level of usage (pre-production, production) and scale? + +We currently have over 1000 images in our catalog - we publish attestations for every image we produce which include SLSA provenance, SBOMs, and our own attestation predicate. + +## What version of the project is currently in use and what is your update cadence with the project? + +Because we were early adopters, we are still using the pre-v1 format, but I don't believe there has been much change from pre-v1 to v1 for the pieces we are using. If anything this shows that the spec has been fairly stable. :) +We can likely update to v1, but there hasn't been a strong driving force for it at the moment. + +## Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project? + +What was really nice about in-toto attestations are the existing specs and examples users can see in the repo. These are really useful for us to see what types of metadata users already exist so we don't need to reinvent the wheel. And if the existing specs don’t fit our needs, we can define our own predicate format but still be compatible with the rest of the in-toto attestation spec. + +We've used this for our own images to define an image configuration attestation, which is similar to an SBOM but contains more information about how exactly we built an image. We were able to build this on top of in-toto’s existing format which is very powerful. + +Re challenges: Not specific to in-toto, but one of the challenges in the broader ecosystem is predicate fragmentation (e.g. what kind of SBOM predicate to use). I like that in-toto doesn't try to be the one-standard-to-rule-them-all, but gives us basic building blocks to define common concepts and is flexible enough to allow different predicates and easy extensions. There are many adjacent projects working to solve these problems, and it's something we keep an eye on. + +## Did you find the information in the repo or the project docs valuable to your implementation? If so, where did you find the information and what specifically was useful? + +The spec doc in the attestation repo is very thorough! Love the examples and the detailed spec definitions. Overall the docs are very useful and helpful. + +## Did you need to engage with the community members or maintainers? If so what was the context of the engagement, which communication channels did you use and did it reach an acceptable outcome? + +Pre-Chainguard, I was helping work on the SLSA build provenance format, which often had discussions with the in-toto community for the best way to define the spec in a way that was complementary to the rest of in-toto. These conversations often happened on slack (k8s or openssf) or conferences like KubeCon or OSSummit. +We still work with the maintainers today across various projects in the ecosystem - It's been great to work with all the maintainers, both on in-toto but also adjacent projects as well! + +We still work with the maintainers today across various projects in the ecosystem - It's been great to work with all the maintainers, both on in-toto but also adjacent projects as well! + +## Has your implementation of the project provided measurable value? Such as reducing manual activities, faster integrations, supported federation/multi-cloud, ease of use, cost savings, etc. + +SBOM and attestations have increasingly become table stakes, particularly for users in regulated environments. Having standard ways to lay out this information with the artifacts we produce is very useful to us. This helps improve the supply chain security for our users by enabling transparency into our artifacts. + +## If the project were to be archived now or in the future, what level of difficulty would your organization experience to remove it from your environments? If that were to happen, would you fork and maintain the project to keep functionality, step into a maintainership role within the project, or something else? + +Because the spec already exists, even if the maintenance stops, the spec is still there for us to use. The existing spec has been fairly stable for us, and we don't anticipate that changing. + +In the event there did need to be a V2 version of the spec, we would likely be interested in being involved to help shape that spec, or at the very least keeping an eye on things and be part of the community. + +## Is there something you feel that holds the project back from reaching its ultimate potential? + +In many ways, I like where the project is today, at least for attestations. It serves as a common baseline and doesn’t try to be too prescriptive about predicates. + +There are complementary projects that are often intertwined with in-toto such as DSSE (Dead Simple Signing Envelope) and SLSA, but are different enough that I'm fine with them being independent and letting them grow separately. Similar groups of maintainers often contribute across these various projects, so there's been a strong ecosystem behind them making sure they work together well. + +## In your opinion, what could the project improve? + +More examples in the wild are always appreciated! In the attestation repo, there are folders detailing all the common predicates, these are super interesting to look at and check out how others are using in-toto. + +## What are the overall strengths of the project? + +In-toto helps define the fundamentals for attestations, but they aren't too prescriptive about exact predicate formats and what data needs to be included. This helps give a common baseline for supply chain metadata, but still gives the flexibility for projects and companies to define their own custom types to fit their needs. + +It's also been great to see the cross-industry and academic collaboration for in-toto and other related projects - it's a large community effort. + +## Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc. + +Honestly, I'm fairly happy with where things are! I'm sure there will continue to be discussions about various predicate types and the best ways to represent supply chain attestation data, but that isn't necessarily specific to in-toto. + +There may be more predicate types we end up using, or creating ourselves in the future! From 58cb496c1bf7a0eecbacce967f60559f3c8ba95c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 12 Dec 2024 22:00:32 -0500 Subject: [PATCH 04/25] add 3rd adopter --- projects/in-toto/in-toto-graduation-dd.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index ddac54040..7f38d05be 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -299,7 +299,7 @@ Many adopters and integrations are [documented](https://github.com/in-toto/frien The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. -- [ ] **TOC verification of adopters.** +- [x] **TOC verification of adopters.** Refer to the Adoption portion of this document. @@ -315,9 +315,8 @@ This adopter interview is performed in Sept 2024 and recorded a very happy adopt ##### Adopter 2 - GitHub/Software company -This adopter interview is performed in Oct 2024 and recorded a very adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. +This adopter interview is performed in Oct 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. ##### Adopter 3 - $COMPANY/$INDUSTRY -_If the Adopting organization needs to remain anonymous, stating the industry vertical is sufficient._ -MONTH YEAR \ No newline at end of file +This adopter interview is performed in Dec 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-chainguard.md) for more details. From 2b0000ace6bde521929e79f46112a24da0965960 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:44:43 -0500 Subject: [PATCH 05/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 80 +++++++++++------------ 1 file changed, 39 insertions(+), 41 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 7f38d05be..a5eb0b2d6 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -23,9 +23,10 @@ Lin Sun (@linsun) conducted the due diligence of in-toto who applied for Graduat The following actions were provided to the project that were considered blocking but have since been resolved: -- Enable convenient linkage for community meeting notes. - Updating the list of subprojects in GitHub, found from the Governancy review. - Provide an updated roadmap document in GitHub. +- Document the release process. +- Provide instructions of onboarding & offboarding members/roles in the community. ### Final Assessment @@ -80,19 +81,19 @@ Note: this section may be augmented by the completion of a Governance Review fro Able to find it easily. -- [ ] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** +- [X] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** -TODO: need some work here. +Confirmed with the team the [Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is up to date. - [X] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.** Vendor neutral is clearly mentioned twice in the governance doc. Steering committee composition is also diverse at the moment. -- [x] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** +- [X] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** Documented [here](https://github.com/in-toto/community/tree/main/elections) -- [ ] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** +- [X] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. @@ -129,20 +130,17 @@ Changes to the in-toto standard largely come in the form of ITEs (in-toto enhanc Another significant ITE is [ITE-6](https://github.com/in-toto/ITE/blob/master/ITE/6/README.adoc). This enhancement introduced the in-toto Attestation Framework to record and disseminate software supply chain specific information like build provenance, code review results, test results, SBOMs, vulnerability scans, and more. in-toto attestations are now used by GitHub for NPM build provenance, OpenVEX, Docker buildx, scanners like Trivy that can generate signed SBOMs, Tekton Chains, Sigstore, GUAC, Witness, and Archivista. SolarWinds, in their next generated build system introduced after SUNBURST, also generate in-toto attestations. -- [ ] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** - -TODO - -- [x] **Document agreement that project will adopt CNCF Code of Conduct.** -- [x] **CNCF Code of Conduct is cross-linked from other governance documents.** +- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** +- [X] **Document agreement that project will adopt CNCF Code of Conduct.** +- [X] **CNCF Code of Conduct is cross-linked from other governance documents.** The CoC and the assertion of adherence is referenced in the [GOVERNANCE.md](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#code-of-conduct). -- [x] **All subprojects, if any, are listed.** +- [X] **All subprojects, if any, are listed.** Subprojects are listed in the [README.md](https://github.com/in-toto/community/blob/main/README.md#subprojects) file of in-toto/community. -- [x] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** +- [X] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee. @@ -152,29 +150,29 @@ Note: this section may be augmented by the completion of a Governance Review fro ### Suggested -- [x] **Contributor ladder with multiple roles for contributors.** +- [X] **Contributor ladder with multiple roles for contributors.** The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) ### Required -- [x] **Clearly defined and discoverable process to submit issues or changes.** +- [X] **Clearly defined and discoverable process to submit issues or changes.** A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. -- [x] **Project must have, and document, at least one public communications channel for users and/or contributors.** +- [X] **Project must have, and document, at least one public communications channel for users and/or contributors.** Communication channels are encoded in the [website](https://in-toto.io/contact/). It contains a developer facing mailing list, a public mailng list, a slack join link, github and IRC contacts. -- [x] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** +- [X] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** Communication channels are encoded in the [website](https://in-toto.io/contact/) -- [x] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** +- [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). -- [x] **Documentation of how to contribute, with increasing detail as the project matures.** +- [X] **Documentation of how to contribute, with increasing detail as the project matures.** A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) @@ -184,7 +182,7 @@ A contribution guide is placed at the toplevel [community repository](https://gi ## Engineering Principles -- [x] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.** +- [X] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.** One of the most pressing security problems in cloud native is software supply chain security. in-toto addresses this issue by providing a secure and trustworthy means for representing all the operations within the cloud-native pipeline and verifying that they were carried out to the letter. A good way to understand the need for in-toto in the Cloud Native space is to understand the value of signed SBOMs vs in-toto metadata + layouts. A signed SBOM indicates that some party (whose key you presumably have a reason to trust) states what the software contains. In contrast, in-toto will have signed information about the individual steps of the supply chain cryptographically linking metadata together from various parties and validating this all against the software’s policies. As a result, their protection modes would work quite differently in many cases. For example, see the following table: @@ -209,29 +207,29 @@ This is why projects like SLSA and FRSCA are built as an opinionated set of step These projects are solving different problems at different levels. In-toto allows you to capture information about your steps, ensure policies about them are applied, handle trust of keys, etc. Frameworks like SLSA and FRSCA use in-toto as a mechanism to capture and enforce a specific set of policies that result in more secure supply chains. -- [x] **Document what the project does, and why it does it - including viable cloud native use cases.** +- [X] **Document what the project does, and why it does it - including viable cloud native use cases.** https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and many integrations with other projects in the ecosystem. -- [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** +- [X] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** Roadmap for project with pointers to subproject ROADMAPs are encoded in a [ROADMAP.md file](https://github.com/in-toto/community/blob/main/ROADMAP.md) -- [x] **Roadmap change process is documented.** +- [X] **Roadmap change process is documented.** Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/ROADMAP.md) outlines how and when the community-wide rodamap is updated (usually once a year). Each sub-project may also have their own ROADMAP that aligns to subproject-wide SLAs -- [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** +- [X] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** The [friends](https://github.com/in-toto/friends) repository outlines how Cloud-native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud-native CI/CD platforms, as well as social coding platforms and distributed buildsystems. -- [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** +- [X] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** - - [x] Release expectations (scheduled or based on feature implementation) - - [x] Tagging as stable, unstable, and security related releases - - [ ] Information on branch and tag strategies - - [ ] Branch and platform support and length of support - - [x] Artifacts included in the release. + - [X] Release expectations (scheduled or based on feature implementation) + - [X] Tagging as stable, unstable, and security related releases + - [X] Information on branch and tag strategies + - [X] Branch and platform support and length of support + - [X] Artifacts included in the release. - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. in-toto has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. @@ -248,34 +246,34 @@ Note: this section may be augemented by a joint-assessment performed by TAG Secu ### Suggested -- [x] **Achieving OpenSSF Best Practices silver or gold badge.** +- [X] **Achieving OpenSSF Best Practices silver or gold badge.** [in-toto achieves a gold OpenSSF Best Practice badge](https://www.bestpractices.dev/en/projects/1523?criteria_level=2) ### Required -- [x] **Clearly defined and discoverable process to report security issues.** +- [X] **Clearly defined and discoverable process to report security issues.** Repositories describe the disclosure process using a [SECURITY.md file](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) -- [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** +- [X] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** GitHub teams are used to provide granular access to different repositories within the organization. Protected branches are used to avoid pushes to master. Dependabot, and secret scanning is also added to all implementation repositories. -- [x] **Document assignment of security response roles and how reports are handled.** +- [X] **Document assignment of security response roles and how reports are handled.** Disclosure is handled by the ITSC. In addition, GitHub private vulnerability reporting is used (and has been successfully used before) to handle disclosures on implementations. -- [x] **Document Security Self-Assessment.** +- [X] **Document Security Self-Assessment.** in-toto was the [first project to carry out a security self-assessment](https://github.com/cncf/tag-security/commit/06b71c4db99ba07107cba6cf8f6fc6d4461fce82) with TAG security, and aided in developing the current process. -- [x] **Third Party Security Review.** +- [X] **Third Party Security Review.** See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). -- [x] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** +- [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). As of 31st of July, 2023, there are only 23 projects in the world to have such a distinction. The only other CNCF project with a Gold Badge is the [TUF project (a graduated security project)](http://theupdateframework.io). @@ -289,21 +287,21 @@ N/A ### Required -- [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** +- [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends) -- [x] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** +- [X] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** Many adopters and integrations are [documented](https://github.com/in-toto/friends). The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. -- [x] **TOC verification of adopters.** +- [X] **TOC verification of adopters.** Refer to the Adoption portion of this document. -- [x] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** +- [X] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** Many integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). From d79c1a8eb19923541c19e48436a2c465d9e9dbc2 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:57:35 -0500 Subject: [PATCH 06/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index a5eb0b2d6..4edafe8a8 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -176,9 +176,9 @@ in-toto community meetings are scheduled on the first friday of each month at 11 A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) -- [ ] **Demonstrate contributor activity and recruitment.** +- [X] **Demonstrate contributor activity and recruitment.** - +Constant contributor activity observed on devstats, and based on community meeting notes, meetings are well attended. There has been recruitments at KubeCon and other conferences including but not limited to project booth, presenting a KubeCon NA keynote and other talks related to in-toto. ## Engineering Principles From 01af7957636c4770b2243cce93000ba3e1a8acce Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Tue, 7 Jan 2025 21:58:25 -0500 Subject: [PATCH 07/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 4edafe8a8..d48392fcd 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -315,6 +315,6 @@ This adopter interview is performed in Sept 2024 and recorded a very happy adopt This adopter interview is performed in Oct 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-github.md) for more details. -##### Adopter 3 - $COMPANY/$INDUSTRY +##### Adopter 3 - Chainguard/Software company This adopter interview is performed in Dec 2024 and recorded a very happy adopter who has great expereience interacting with the in-toto community. Refer to the [interview summary](in-toto-adopter-interview-chainguard.md) for more details. From d69791e61819bc4ee8fe38907456dcf965f07c37 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 17:17:52 -0500 Subject: [PATCH 08/25] Update in-toto-graduation-dd.md WIP update to emily's comment Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index d48392fcd..a35d907bd 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -12,7 +12,7 @@ Project points of contacts: Santiago Torres, santiagotorres@purdue.edu ### Criteria Evaluation -Lin Sun (@linsun) conducted the due diligence of in-toto who applied for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: +Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: - A notable stable project with mature capabilities and a wide [adopter](https://github.com/in-toto/friends?tab=readme-ov-file#project-adopters) base. - The project has a wide range of interest across academic and cross different industries. @@ -28,13 +28,18 @@ The following actions were provided to the project that were considered blocking - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. -### Final Assessment +### Adoption Evaluation: -The TOC has found the project to have satisfied the criteria for Graduation. +The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martins and more. Every adopter I interviewed is quite happy with in-toto. Highlight some of the strength I heard: +- "Beyond the community, and diversity of others using it, the spec is also very flexible. You can add to it, or expand it or create a unique solution with it." +- "Community discussions are great and how they bring them (industry & academic & non profit OSS foundation). Really thinking ahead and anticipating needs before people need them. Continue to be an active community." +- "It's also been great to see the cross-industry and academic collaboration for in-toto and other related projects - it's a large community effort." -### Adoption Assertion +Only 1 adopter suggested 1 minor improvement, which is increased marketing effort. The other adopters seem quite happy with in-toto today. -### Criteria +### Final Assessment + +The TOC has found the project to have satisfied the criteria for Graduation. ## Application Process Principles @@ -46,20 +51,20 @@ N/A - [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** -Presentation was given to the TAG security in July 2014. +Presentation was given to the TAG security in July 2014, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). TODO: add a link to the presentation - [x] **TAG provides insight/recommendation of the project in the context of the landscape** -[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation +[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation: - [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** -Don't see any concern with vendor-neutral for in-toto project. +No issues were found during due diligence, both code and documentation are vendor neutral. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industries as well. - [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** - [x] Met during Project's application on 21-06-2024. -Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisifies the Due Diligence Review criteria. +I met with the project lead and went over the expectation and requirements for graduated project, as recorded [here](https://github.com/cncf/toc/pull/1162#issuecomment-2190111991). - [X] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** From ca18b03ef157d200c0ad83e048ed3ce4daa6c58c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 17:31:39 -0500 Subject: [PATCH 09/25] Update in-toto-graduation-dd.md more updates Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 38 ++++++++++++++++++++--- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index a35d907bd..cefda7df8 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -51,7 +51,7 @@ N/A - [X] **Give a presentation and engage with the domain specific TAG(s) to increase awareness** -Presentation was given to the TAG security in July 2014, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). TODO: add a link to the presentation +[Presentation](https://zoom.us/rec/share/H4AeeCUzrh7dVDzv7udMJmK-jWHvENmyWmcZvG4-1rZbVWUTn7RAByqKSfG3g9ya.OJnqcezJAXcGMce0?startTime=1721235498000) was given to the TAG security in July 2014, which was recorded in this [issue](https://github.com/cncf/tag-security/issues/1290). - [x] **TAG provides insight/recommendation of the project in the context of the landscape** @@ -59,7 +59,7 @@ Presentation was given to the TAG security in July 2014, which was recorded in t - [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** -No issues were found during due diligence, both code and documentation are vendor neutral. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industries as well. +No issues were found during due diligence, both code and documentation are vendor neutral. Vendor neutral is clearly mentioned twice in the governance doc. Based on the community meeting minutes, [contributor stats](https://intoto.devstats.cncf.io/d/5/companies-table?orgId=1&var-period_name=Last%20year&var-metric=contributions) and what adopters say about the project, in-toto is very diverse. It is one of the projects that started in academic and attracted a good range of interest from industries as well. - [x] **Review and acknowledgement of expectations for graduated projects and requirements for moving forward through the CNCF Maturity levels.** - [x] Met during Project's application on 21-06-2024. @@ -76,9 +76,9 @@ Note: this section may be augmented by the completion of a Governance Review fro ### Suggested -- [x] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.** +- [ ] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.** -[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. +[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. There is very few changes to it since it was created in Feb, 2023. ### Required @@ -104,10 +104,38 @@ Documented [here](https://github.com/in-toto/community/tree/main/elections) - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) +[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: + + Santiago Torres + Email: santiagotorres@purdue.edu + GitHub username: @SantiagoTorres + + Lukas Puehringer + Email: lukas.puehringer@nyu.edu + GitHub username: @lukpueh + + Justin Cappos + Email: jcappos@nyu.edu + GitHub username: @JustinCappos + + Marina Moore + Email: mm9693@nyu.edu + GitHub username: @mnm678 + + Sebastien Awwad + Email: sebastien.awwad@nyu.edu + GitHub username: @awwad + + Aditya Sirish A Yelgundhalli + Email: aditya.sirish@nyu.edu + GitHub username: @adityasaky + +In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** +For the current cadence of changes in the project and backlog of work, the project has sufficient active maintainers to sustain its current and future momentum. Adopters I spoke to are all happy with either contributing to in-toto or getting support from the in-toto community. + - [x] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).** The project maintains a description of different roles and their election process in its [community repository](https://github.com/in-toto/community) From 74081884d584ed2325483078e026d1780df13105 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 17:56:10 -0500 Subject: [PATCH 10/25] Update in-toto-graduation-dd.md more updates Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 35 ++++++++++++----------- 1 file changed, 19 insertions(+), 16 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index cefda7df8..6fadce370 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -30,12 +30,13 @@ The following actions were provided to the project that were considered blocking ### Adoption Evaluation: -The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martins and more. Every adopter I interviewed is quite happy with in-toto. Highlight some of the strength I heard: +The adopter interviews reflect the in-toto project is in use for the level which the project applied, which is CNCF graduation. It has a good range of adopters across different industries and vendors, including GitHub, DataDog, SLAS, Solarwinds, Lockheed Martins and more. Every adopter I interviewed is quite happy with in-toto. Highlight some of the project strengths I heard during adopter interviews: + - "Beyond the community, and diversity of others using it, the spec is also very flexible. You can add to it, or expand it or create a unique solution with it." - "Community discussions are great and how they bring them (industry & academic & non profit OSS foundation). Really thinking ahead and anticipating needs before people need them. Continue to be an active community." - "It's also been great to see the cross-industry and academic collaboration for in-toto and other related projects - it's a large community effort." -Only 1 adopter suggested 1 minor improvement, which is increased marketing effort. The other adopters seem quite happy with in-toto today. +Only 1 adopter suggested 1 minor improvement, which is increased marketing effort. Other adopters seem happy with in-toto today. ### Final Assessment @@ -104,7 +105,7 @@ Documented [here](https://github.com/in-toto/community/tree/main/elections) - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -[Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: Santiago Torres Email: santiagotorres@purdue.edu @@ -146,9 +147,9 @@ Maintainers for subprojects have been managed by the ITSC and Sub-project mainta - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** -As an intentionally minimal security specification / framework, we deliberately do not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). +As an minimal security specification / framework, the project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). -Since reaching the incubation stage, the in-toto project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across our sub-projects, we have contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. +Since reaching the incubation stage, the project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across sub-projects, the project has contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. The current ITSC comprises of the following - Santiago Torres-Arias (Purdue University) @@ -157,14 +158,14 @@ The current ITSC comprises of the following - Cole Kennedy (TestifySec) - Trishank Karthik Kuppusamy (Datadog) -We have had active contributions from an array of contributors across the CNCF landscape. One way to see this is via the substantial changes that made their way into the specification. - -Changes to the in-toto standard largely come in the form of ITEs (in-toto enhancements). There is a substantial ITE, ITE-4, that standardized non-file artifact specifications for in-toto metadata. The stakeholders in it are Github, Conda, SPDX and Google's Grafeas. +- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** -Another significant ITE is [ITE-6](https://github.com/in-toto/ITE/blob/master/ITE/6/README.adoc). This enhancement introduced the in-toto Attestation Framework to record and disseminate software supply chain specific information like build provenance, code review results, test results, SBOMs, vulnerability scans, and more. in-toto attestations are now used by GitHub for NPM build provenance, OpenVEX, Docker buildx, scanners like Trivy that can generate signed SBOMs, Tekton Chains, Sigstore, GUAC, Witness, and Archivista. SolarWinds, in their next generated build system introduced after SUNBURST, also generate in-toto attestations. +On Jan 7, 2025, Justin Cappos walk through this with me during a screen sharing session where he confirmed that code and doc ownership in Github are assigned properly. -- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** - [X] **Document agreement that project will adopt CNCF Code of Conduct.** + +The project has CNCF CoC [recorded](https://github.com/in-toto/community/blob/main/CODE-OF-CONDUCT.md), which says "The in-toto community abides by the Cloud Native Computing Foundation's code of conduct." + - [X] **CNCF Code of Conduct is cross-linked from other governance documents.** The CoC and the assertion of adherence is referenced in the [GOVERNANCE.md](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#code-of-conduct). @@ -175,11 +176,13 @@ Subprojects are listed in the [README.md](https://github.com/in-toto/community/b - [X] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.** -Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee. +Subproject leadership is encoded in a subproject-level MAINTAINERS.txt file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/MAINTAINERS.txt)). Sub-project maturity is encoded in the project's README.md file (e.g., [in-toto-rs](https://github.com/in-toto/in-toto-rs/blob/master/README.md)). Add/remove processes are handled by the in-toto steering committee as described [here](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#onboarding-and-offboarding-all-roles). ## Contributors and Community -Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy. +Governance Review from TAG Contributor Strategy is performed in Oct 2024. + +The team rated the review as "Mostly Satisfactory". The steering committee style governance is perceived favorable, along with the project's transparency in different areas such as public documentation, record, and communications. Refer to the [full review](https://github.com/cncf/tag-contributor-strategy/pull/740/files) for details. ### Suggested @@ -191,7 +194,7 @@ The contributor ladder is encoded in the [GOVERNANCE.md document](https://github - [X] **Clearly defined and discoverable process to submit issues or changes.** -A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. +A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) file. - [X] **Project must have, and document, at least one public communications channel for users and/or contributors.** @@ -199,15 +202,15 @@ Communication channels are encoded in the [website](https://in-toto.io/contact/) - [X] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** -Communication channels are encoded in the [website](https://in-toto.io/contact/) +Communication channels are encoded in the [website](https://in-toto.io/contact/). Non-public communication channels are described in in-toto's [security disclosure process](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md). - [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** -in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). +The in-toto community meetings are scheduled on the first friday of each month at 11AM et, and is displayed in the [CNCF public calendar](https://tockify.com/cncf.public.events/monthly?search=in-toto). - [X] **Documentation of how to contribute, with increasing detail as the project matures.** -A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) +A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) - [X] **Demonstrate contributor activity and recruitment.** From 5b1706982e3d73ce1bd8beaeb0f1e05feecf4de4 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 21:49:50 -0500 Subject: [PATCH 11/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 6fadce370..2d3ae3ba3 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -188,13 +188,13 @@ The team rated the review as "Mostly Satisfactory". The steering committee style - [X] **Contributor ladder with multiple roles for contributors.** -The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) +The contributor ladder is encoded in the [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md). ### Required - [X] **Clearly defined and discoverable process to submit issues or changes.** -A contribution guide is placed at the toplevel [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) file. +A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). A security disclosure process is encoded on the a separate [SECURITY.md](https://github.com/in-toto/community/blob/main/SECURITY.md) file. - [X] **Project must have, and document, at least one public communications channel for users and/or contributors.** @@ -202,7 +202,7 @@ Communication channels are encoded in the [website](https://in-toto.io/contact/) - [X] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.** -Communication channels are encoded in the [website](https://in-toto.io/contact/). Non-public communication channels are described in in-toto's [security disclosure process](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md). +Communication channels are encoded in the [website](https://in-toto.io/contact/). Non-public communication channels are described in in-toto's [security disclosure process](https://github.com/in-toto/community/blob/main/SECURITY.md). - [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** @@ -210,7 +210,7 @@ The in-toto community meetings are scheduled on the first friday of each month a - [X] **Documentation of how to contribute, with increasing detail as the project matures.** -A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md) +A contribution guide is placed at the top level [community repository](https://github.com/in-toto/community/blob/main/CONTRIBUTING.md). I observed a few additional updates to the contribution guide this year, related to the newly added reference documentation policy and some refinement for it. - [X] **Demonstrate contributor activity and recruitment.** @@ -292,7 +292,6 @@ Note: this section may be augemented by a joint-assessment performed by TAG Secu Repositories describe the disclosure process using a [SECURITY.md file](https://github.com/in-toto/in-toto/blob/develop/SECURITY.md) - - [X] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)** GitHub teams are used to provide granular access to different repositories within the organization. Protected branches are used to avoid pushes to master. Dependabot, and secret scanning is also added to all implementation repositories. @@ -325,21 +324,21 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends) +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). - [X] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** -Many adopters and integrations are [documented](https://github.com/in-toto/friends). +Adopters are [documented](https://github.com/in-toto/friends). The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. - [X] **TOC verification of adopters.** -Refer to the Adoption portion of this document. +The project's adopter interviews reflect the appropriate level of adoptions demonstrating maturity of a graduation level project. Refer to the Adoption portion of this document for more details. - [X] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** -Many integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). +Integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). #### Adoption From 5d537bf3c72432b098d90b7dc16b0e853a5de35b Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 21:57:57 -0500 Subject: [PATCH 12/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 2d3ae3ba3..61e1eef3f 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -324,11 +324,11 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 2 issues to add [Lockhead Martins](https://github.com/in-toto/friends/issues/56) and [Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopters to submit PRs to resolve it. - [X] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** -Adopters are [documented](https://github.com/in-toto/friends). +Adopters are [documented](https://github.com/in-toto/friends) which includes at least 3 indepdendent adopters. Adopter interviews also showed 3 independent adopters. All adopters I interviewed are using in-toto for production. The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation. From a65522f139cb0f9d01da3f0f572c878e62e47120 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:15:07 -0500 Subject: [PATCH 13/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 61e1eef3f..ace7c9dd4 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -338,7 +338,7 @@ The project's adopter interviews reflect the appropriate level of adoptions demo - [X] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.** -Integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations). +Integrations are [documented](https://github.com/in-toto/friends?tab=readme-ov-file#project-integrations), including a good range of popular projects/platforms such as GitHub, GitLab, GUAC, Jenkins, Sigstore etc. #### Adoption From 83eb7f734dfdc054663f29d0743d27b19048a599 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:19:29 -0500 Subject: [PATCH 14/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 23 +---------------------- 1 file changed, 1 insertion(+), 22 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index ace7c9dd4..15c2728cd 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -220,28 +220,7 @@ Constant contributor activity observed on devstats, and based on community meeti - [X] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.** -One of the most pressing security problems in cloud native is software supply chain security. in-toto addresses this issue by providing a secure and trustworthy means for representing all the operations within the cloud-native pipeline and verifying that they were carried out to the letter. -A good way to understand the need for in-toto in the Cloud Native space is to understand the value of signed SBOMs vs in-toto metadata + layouts. A signed SBOM indicates that some party (whose key you presumably have a reason to trust) states what the software contains. In contrast, in-toto will have signed information about the individual steps of the supply chain cryptographically linking metadata together from various parties and validating this all against the software’s policies. As a result, their protection modes would work quite differently in many cases. For example, see the following table: - - -| Attack scenario | Signed SBOM Result | In-toto layout + metadata result | -|-----------------|----------------------|----------------------------------| -| Software manipulated after software supply chain completed | Detect and reject the malicious software | Detect and reject the malicious software | -| Attacker compromises VCS and inserts malicious (unsigned) code where signatures are required |Undetected. User compromised. | Detect and reject the malicious software | -| Attacker substitutes a malicious dependency (not signed by that dependeny’s maintainer) |Undetected. User compromised. | Detect and reject the malicious software -| Attacker provides files to the build system which did not come from the VCS | Undetected. User compromised | Detect and reject the malicious software | -| Attacker containerizes / packages binaries other than the ones the build system built | Undetected. User compromised | Detect and reject the malicious software | -| Tests are not run on the software but it is (accidentally?) released to production | Undetected. User compromised | Detect and reject the malicious software | -| The legal team has not reviewed source code licenses for included libraries | Undetected. Impact varies | Detect and reject the software | - -One important thing to note about the table above is that it isn’t impossible for someone to do many of these steps and checks before signing an SBOM. If you did all of these checks, and signed the statements saying you did them to provide stronger validation, and distributed the root of trust for your signatures in a secure way, and managed situations where signing keys need to be revoked / rotated / expired, and handled trust delegation to different parties, and linked metadata between steps together, and let people write policies to reason about those steps, and let them link metadata in from dependencies to do so, and handled all of the above in scenarios where insiders can be maliciously interfering with your, system, then you would effectively reconstruct in-toto. -We are aware of some efforts, like the Zephyr project, where project members have worked to try to reconstruct some of the guarantees of in-toto and decided to live with the gaps in their security for other portions. For groups that have done this work already this does make sense to us as a viable alternative in the short term. However, we do believe that using a common, holistic approach like in-toto will be necessary as projects continually add the missing security pieces from in-toto and want to reason more and more about each other as dependencies. - -Note that in-toto is not a substitute for having appropriately secure steps in the software supply chain. For example, if you use an insecure process of building software that just curls and builds software from a website, in-toto will happily sign metadata indicating that you did the same insecure action indicated you would. - -This is why projects like SLSA and FRSCA are built as an opinionated set of steps on top of in-toto. They specify which actions they feel are more important for software supply chain security and mandate their use. - -These projects are solving different problems at different levels. In-toto allows you to capture information about your steps, ensure policies about them are applied, handle trust of keys, etc. Frameworks like SLSA and FRSCA use in-toto as a mechanism to capture and enforce a specific set of policies that result in more secure supply chains. +This is documented well at the project's readme, under a section that describes how [in-toto differentiates in the cloud native landscape](https://github.com/in-toto/community/blob/main/README.md#how-is-in-toto-differentiated-in-the-cloud-native-landscape---what-does-it-do-differently-and-why). - [X] **Document what the project does, and why it does it - including viable cloud native use cases.** From cc13d22921aa32927682ea5aa77dd0b0877fec4d Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:20:35 -0500 Subject: [PATCH 15/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 15c2728cd..8a2723a26 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -56,7 +56,7 @@ N/A - [x] **TAG provides insight/recommendation of the project in the context of the landscape** -[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation: +[Very strong support](https://github.com/cncf/toc/pull/1162#issuecomment-2236636343) from TAG security on in-toto's CNCF graduation. - [X] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** From dcc0e2a35e06dc91fc74dbaf42f0309df3ba302c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:26:54 -0500 Subject: [PATCH 16/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 8a2723a26..4beeb022a 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -85,7 +85,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [X] **Clear and discoverable project governance documentation.** -Able to find it easily. +I was able to find it easily. - [X] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.** @@ -97,7 +97,7 @@ Vendor neutral is clearly mentioned twice in the governance doc. Steering commit - [X] **Document how the project makes decisions on leadership roles, contribution acceptance, requests to the CNCF, and changes to governance or project goals.** -Documented [here](https://github.com/in-toto/community/tree/main/elections) +Election process of the steering committee is documented [here](https://github.com/in-toto/community/tree/main/elections). [Decision making](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#decision-making) and [change process](https://github.com/in-toto/community/blob/main/GOVERNANCE.md#change-review-process) are also documented. - [X] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** From 307252253a24b0065c91b673b56c876f51b11152 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:27:41 -0500 Subject: [PATCH 17/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 4beeb022a..b679ea93d 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -79,7 +79,7 @@ Note: this section may be augmented by the completion of a Governance Review fro - [ ] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.** -[Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. There is very few changes to it since it was created in Feb, 2023. +The [Governance doc](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) is clear. There is very few changes to it since it was created in Feb, 2023. ### Required @@ -101,7 +101,7 @@ Election process of the steering committee is documented [here](https://github.c - [X] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).** -[GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. +The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVERNANCE.md) shows various project roles and how decisions are made. - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** From 73f4c36daf3dc7691f43f3a1098285981da5f948 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:30:51 -0500 Subject: [PATCH 18/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index b679ea93d..867596484 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -160,7 +160,7 @@ The current ITSC comprises of the following - [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.** -On Jan 7, 2025, Justin Cappos walk through this with me during a screen sharing session where he confirmed that code and doc ownership in Github are assigned properly. +On Jan 7, 2025, Justin Cappos walk through this with me during a screen sharing session where he confirmed that code and doc ownership in Github are assigned properly with two primary groups (maintainers and steering members). The project's code and doc ownership appear to match the documented governance roles for the project. - [X] **Document agreement that project will adopt CNCF Code of Conduct.** From 853436512dfe9f65fef426739b44a361b4f27145 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Wed, 8 Jan 2025 22:36:18 -0500 Subject: [PATCH 19/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 867596484..0be174d07 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -105,7 +105,7 @@ The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVE - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. Details below: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active: Santiago Torres Email: santiagotorres@purdue.edu @@ -119,14 +119,6 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: jcappos@nyu.edu GitHub username: @JustinCappos - Marina Moore - Email: mm9693@nyu.edu - GitHub username: @mnm678 - - Sebastien Awwad - Email: sebastien.awwad@nyu.edu - GitHub username: @awwad - Aditya Sirish A Yelgundhalli Email: aditya.sirish@nyu.edu GitHub username: @adityasaky From ed699429fa5fa7fd0748fc4716df89f96a861613 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 9 Jan 2025 09:56:51 -0500 Subject: [PATCH 20/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 0be174d07..0eeac05ce 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -27,6 +27,8 @@ The following actions were provided to the project that were considered blocking - Provide an updated roadmap document in GitHub. - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. +- Move inactive maintainers to emeritus maintainers. +- Update list of adopters to be accurate. ### Adoption Evaluation: @@ -105,7 +107,7 @@ The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVE - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active and worked with the project to move the inactive maintainers to emeritus maintainers: Santiago Torres Email: santiagotorres@purdue.edu @@ -295,7 +297,7 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 2 issues to add [Lockhead Martins](https://github.com/in-toto/friends/issues/56) and [Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopters to submit PRs to resolve it. +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 1 issue to [add Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopter to submit a PR to resolve it. - [X] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** From 2b7a1bd3165f419a40c27e6fb29cca2daf11baf2 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 9 Jan 2025 09:58:03 -0500 Subject: [PATCH 21/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 0eeac05ce..1f35818c3 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -283,8 +283,7 @@ See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). - [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** -The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). As of 31st of July, 2023, there are only 23 projects in the world to have such a distinction. The only other CNCF project with a Gold Badge is the [TUF project (a graduated security project)](http://theupdateframework.io). - +The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2). According to the OpenSSF Best Practices website, the in-toto project received its initial OpenSSF Best Practices badge on January 5th, 2018. ## Ecosystem From 175459d476b40426d1785f89775e8c0531d7ff09 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Thu, 9 Jan 2025 22:11:42 -0500 Subject: [PATCH 22/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 1f35818c3..1fc9e5cff 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -28,7 +28,7 @@ The following actions were provided to the project that were considered blocking - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. - Move inactive maintainers to emeritus maintainers. -- Update list of adopters to be accurate. +- Added a few missing adopters. ### Adoption Evaluation: @@ -107,7 +107,7 @@ The [GOVERNANCE.md document](https://github.com/in-toto/community/blob/main/GOVE - [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.** -In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active and worked with the project to move the inactive maintainers to emeritus maintainers: +In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAINTAINERS.txt) shows maintainers from Purdue University and New York University. I've confirmed the following maintainers are still active and worked with the project to move the two inactive maintainers to emeritus maintainers: Santiago Torres Email: santiagotorres@purdue.edu @@ -125,7 +125,7 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: aditya.sirish@nyu.edu GitHub username: @adityasaky -In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog. +In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** @@ -141,11 +141,11 @@ Maintainers for subprojects have been managed by the ITSC and Sub-project mainta - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** -As an minimal security specification / framework, the project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). +As an minimal security specification / framework, the in-toto project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). Since reaching the incubation stage, the project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across sub-projects, the project has contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. -The current ITSC comprises of the following +The current ITSC comprises of the following: - Santiago Torres-Arias (Purdue University) - Justin Cappos (New York University) - Jack Kelly (Control Plane) @@ -218,7 +218,7 @@ This is documented well at the project's readme, under a section that describes - [X] **Document what the project does, and why it does it - including viable cloud native use cases.** -https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and many integrations with other projects in the ecosystem. +https://in-toto.io/in-toto/ & https://github.com/in-toto/friends explain well what the project does and its integrations with other projects in the ecosystem. - [X] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.** @@ -230,7 +230,7 @@ Roadmap text [current roadmap](https://github.com/in-toto/community/tree/main/RO - [X] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.** -The [friends](https://github.com/in-toto/friends) repository outlines how Cloud-native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud-native CI/CD platforms, as well as social coding platforms and distributed buildsystems. +The [friends](https://github.com/in-toto/friends) repository outlines how cloud native applications and integrations use in-toto and how the in-toto architecture aligns with its goals. Further, in-toto is published as a [peer-reviewed paper](https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias) which outlines how it can be used in cloud native CI/CD platforms, as well as social coding platforms and distributed buildsystems. - [X] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:** @@ -296,7 +296,7 @@ N/A - [X] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)** -Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). Opened 1 issue to [add Chainguard](https://github.com/in-toto/friends/issues/55) to the list, pending the adopter to submit a PR to resolve it. +Adoptions are documented in the [in-toto friends repository](https://github.com/in-toto/friends). As part of the review, I worked with the project lead to add a few missing adopters to the list. - [X] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)** From ad9f9a3c9b0048912cab9f485ef4006ac12c3d0a Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Fri, 10 Jan 2025 09:39:30 -0500 Subject: [PATCH 23/25] Update in-toto-graduation-dd.md Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 1fc9e5cff..e0133e294 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -12,7 +12,7 @@ Project points of contacts: Santiago Torres, santiagotorres@purdue.edu ### Criteria Evaluation -Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria implementations are noteworthy to call out: +Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduation. The project has completed the criteria that show its maturity at the applied level. The following criteria are noteworthy to call out: - A notable stable project with mature capabilities and a wide [adopter](https://github.com/in-toto/friends?tab=readme-ov-file#project-adopters) base. - The project has a wide range of interest across academic and cross different industries. From cc0e57b18f4fceb189cca31719ca9287cfb4b96c Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Fri, 10 Jan 2025 17:06:38 -0500 Subject: [PATCH 24/25] Update in-toto-graduation-dd.md adding more info related to audit and maintainers Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index e0133e294..2b2896a5c 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -21,14 +21,15 @@ Lin Sun (@linsun) conducted the due diligence and adopter interview for Graduati - The project is not only vendor neutral but also has a very diversed set of maintainers, adopters and integrators. - The project does an excellent job of making sure that its public meetings are accessible, with notes, and easy to find meeting links. -The following actions were provided to the project that were considered blocking but have since been resolved: +The following actions were provided to the in-toto project that were considered blocking but have since been resolved: - Updating the list of subprojects in GitHub, found from the Governancy review. - Provide an updated roadmap document in GitHub. - Document the release process. - Provide instructions of onboarding & offboarding members/roles in the community. - Move inactive maintainers to emeritus maintainers. -- Added a few missing adopters. +- Added a few missing adopters. +- 1 High severity issue along with a few outstanding issues that were found from the security audit in 2023 have been addressed. ### Adoption Evaluation: @@ -125,7 +126,7 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: aditya.sirish@nyu.edu GitHub username: @adityasaky -In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. +Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** @@ -141,7 +142,7 @@ Maintainers for subprojects have been managed by the ITSC and Sub-project mainta - [x] **Project maintainers from at least 2 organizations that demonstrates survivability.** -As an minimal security specification / framework, the in-toto project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). +As an minimal security specification / framework, the in-toto project does not have a high degree of feature additions in the project. Effort comes on either the implementations, such as the Go implementation (used by tools like Trivy and Tekton), the Python reference implementation (used by Datadog), the Java implementation (used by the Jenkins plugin and Rabobank), and the specification (where all implementations coordinate for interoperability). The graduation application is only for the in-toto project itself which is the framework/specification. Since reaching the incubation stage, the project has switched its governance model to use a steering committee. The first in-toto Steering Committee (ITSC) was voted on by the in-toto community and comprises five members from organizations spanning industry and academia. The ITSC has oversight over all in-toto sub-projects such as the specification, the Attestation Framework, and implementations maintained by the community written in Python, Go, Java, and Rust. Each sub-project has its own set of maintainers recorded in a CODEOWNERS or MAINTAINERS file in its repository. Across sub-projects, the project has contributors from a diverse set of organizations like Google, Kusari, New York University, Purdue University, Verizon, Intel, and TestifySec. @@ -241,7 +242,7 @@ The [friends](https://github.com/in-toto/friends) repository outlines how cloud - [X] Artifacts included in the release. - Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out. -in-toto has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. +The in-toto project has multiple implementations with varied release cadences depending on the involved stakeholders. For example, the Python implementation offers a feature-stable offering, which focuses on releasing bug-fix releases, whereas the golang implementation provides a "sandbox" for new and experimental features. As such, each subproject manages their own release cadence. All implementations follow semver to communicate their feature support, as well as backwards and forwards compatiblity. @@ -279,7 +280,7 @@ in-toto was the [first project to carry out a security self-assessment](https:// - [X] **Third Party Security Review.** -See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). +See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). The project has resolved the majority of findings from the security audit and created issues for resolution of any outstanding. All issues related to the in-toto framework or specification have been resolved. - [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** From 2c015bb8a61360e78d354d6d6631c8eb0dfe5292 Mon Sep 17 00:00:00 2001 From: Lin Sun Date: Mon, 13 Jan 2025 17:13:44 -0500 Subject: [PATCH 25/25] Update in-toto-graduation-dd.md address more comments on active maintainers and security audit. Signed-off-by: Lin Sun --- projects/in-toto/in-toto-graduation-dd.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/projects/in-toto/in-toto-graduation-dd.md b/projects/in-toto/in-toto-graduation-dd.md index 2b2896a5c..b14899a26 100644 --- a/projects/in-toto/in-toto-graduation-dd.md +++ b/projects/in-toto/in-toto-graduation-dd.md @@ -126,7 +126,7 @@ In-toto's [Maintainer list](https://github.com/in-toto/in-toto/blob/develop/MAIN Email: aditya.sirish@nyu.edu GitHub username: @adityasaky -Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. +Given the in-toto project's scope is the in-toto framework and specification, the maintenance effort is low and the current list of maintainers appears to be sufficient. The maintainers also have a few active sub-project maintainers in the core maintainer pipeline if needed to promote one of them. The adopter interviews appeared to indicate activity/health of maintainership where the community has been very responsive to questions or any issues raised by adopters. In addition, in-toto has a very diverse [steering committe members](https://github.com/in-toto/community/blob/main/STEERING-COMMITTEE.md), including members from TestifySec, ControlPlane and Datadog, in addition to members from Purdue and NYU. - [x] **A number of active maintainers which is appropriate to the size and scope of the project.** @@ -282,6 +282,8 @@ in-toto was the [first project to carry out a security self-assessment](https:// See the in-toto [Security Audit ‘23](https://in-toto.io/security-audit-23/). The project has resolved the majority of findings from the security audit and created issues for resolution of any outstanding. All issues related to the in-toto framework or specification have been resolved. +The witness implementation still has a few [outstanding issues](https://github.com/in-toto/witness/issues/268) to be resolved. This DD doc focuses on the in-toto framework and specification, thus we consider the issues related to the witness implementation out of scope. + - [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** The in-toto project has a [Gold CII (now OpenSSF) Best Practices Badge](https://bestpractices.coreinfrastructure.org/en/projects/1523?criteria_level=2).