In-toto Graduation DD - TOC evaluation

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!

projects/in-toto/in-toto-adopter-interview-github.md

@@ -0,0 +1,93 @@
+# 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.

projects/in-toto/in-toto-adopter-interview-lockheedmartins.md

@@ -0,0 +1,107 @@
+# In-toto Adopter Interview - Lockheed Martins
+
+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.