Sbomit application

README.md

@@ -72,6 +72,7 @@
 | Package Analysis       | https://github.com/ossf/package-analysis         | [Meeting Notes](https://docs.google.com/document/d/1GFslP6elYCx27TUitdigDr1gsOItYkL0Vq7hTB9y4Lo/edit) | Securing Critical Projects WG   | TBD        |
 | Package Feeds          | https://github.com/ossf/package-feeds            | [Meeting Notes](https://docs.google.com/document/d/1GFslP6elYCx27TUitdigDr1gsOItYkL0Vq7hTB9y4Lo/edit) | Securing Critical Projects WG   | TBD        |
 | Repository Service for TUF | https://github.com/vmware/repository-service-tuf | TBD | Securing Software Repositories WG | Sandbox |
+| SBOMit                 | https://github.com/sbomit                        | [Meeting Notes](https://docs.google.com/document/d/1-nHXMqvWNzgOxAq08O8Wu2BTHz0U60yBoAklrJAMaRc/edit?usp=sharing) | Security Tooling WG             | Sandbox    |
 | Scorecard              | https://github.com/ossf/scorecard                | [Meeting Notes](https://docs.google.com/document/d/1b6d3CVJLsl7YnTE7ZaZQHdkdYIvuOQ8rzAmvVdypOWM/edit?usp=sharing) | Best Practices WG               | TBD        |
 | Security Insights Spec | https://github.com/ossf/security-insights-spec   | [Meeting Notes](https://docs.google.com/document/d/14_ILDhSK3ymKqUTQeQBRgJKgfiy_ePoGZIe8s7p3K5E/edit?usp=sharing) | Identifying Security Threats WG | TBD        |
 | Security Metrics       | https://github.com/ossf/Project-Security-Metrics | [Meeting Notes](https://docs.google.com/document/d/14_ILDhSK3ymKqUTQeQBRgJKgfiy_ePoGZIe8s7p3K5E/edit#heading=h.apj7ueyomk4r) | Identifying Security Threats WG | TBD        |

process/project-lifecycle-documents/SBOMit_sandbox_stage.md

@@ -0,0 +1,60 @@
+## Application for creating a new project at Sandbox stage
+
+### List of project maintainers
+
+  * Justin Cappos, NYU, justincappos
+  * Ian Dunbar-Hall, Lockheed Martin, idunbarh
+  * Cole Kennedy, TestifySec, colek42
+  * Marina Moore, NYU, mnm678
+  * Trishank Kuppusamy, Datadog, trishankatdatadog
+
+### Mission of the project
+
+SBOMit's goal is to provide SBOMs to end users with minimal effort that provide cryptographic validation of the steps performed in the software 
+supply chain.  This differs from other SBOM efforts in that the data in the SBOM is validated cryptographically using [in-toto](in-toto.io) 
+link metadata and layouts, which provides a strong threat model while providing a robust set of guarantees about the SBOM's accuracy.  
+
+Specific goals include:
+
+ * Maintain compatibility with existing SBOM formats (could generate existing SBOMs), and ideally operable with SPDX, CycloneDX, and similar efforts
+ * Define use cases and outcomes (end user ux) including machine readable
+ * Emphasize usability / on-boarding for users.  Acknowledged as critical by many stakeholders.
+ * Cryptographic verification that exactly the steps in the verifiable SBOM were performed
+ * Threat model of an attacker that can compromise any part of the software supply chain (e.g., Section 2.2 of https://www.usenix.org/system/files/sec19-torres-arias.pdf )
+ * Define which pieces of the Verifiable SBOM are cryptographically verifiable
+ * Be applicable anywhere (not just cloud native)!
+ * Utilize in-toto delivered bundle for distribution of a single file
+ * Optionally enabling the capture of reasonable information about the runtime environment of the supply chain steps including pre-build, post-build, and all other portions
+ * Optionally enabling the capture of the output of scanning tools, etc. that may make inferences.  Note that these may be based upon incomplete and / or incorrect information, but surfacing this information may be useful.
+ * Provide a clear specification that other groups can implement for Verifiable SBOMs
+ * Provide exemplars of the tooling needed to generate and process Verifiable SBOMs
+ * Enable users of Verifiable SBOMs to be able to understand clearly what steps were performed, possibly via plug-ins through things like Testify, SLSA, FRSCA, etc.
+ * Multi-language tooling
+
+Non-Goals:
+ * Picking a winning SBOM format (SPDX, CycloneDX, etc.)
+ * Recursing into components like the packages inside of a container image when the build process does not otherwise do so.
+ * Knowing that an individual action is actually a good security practice  
+ * Assertions about the quality of the implementation of the tool / security processes describing how the SBOM or artifact came to exist
+
+
+
+
+### IP policy and licensing due dilligence
+
+When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF).
+
+  * See [#191](https://github.com/ossf/tac/issues/191) for LF IP Review
+  * Our reference implementations will use the Apache 2.0 license
+  * Our specification uses [Community Specification License 1.0](https://github.com/SBOMit/specification/blob/main/LICENSE.md)
+  * Our website uses [Creative Commons Attribution 4.0 International](https://github.com/SBOMit/website/blob/main/LICENSE.md)
+
+### Project References
+
+| Reference          | URL  |
+|--------------------|------|
+| Repo               | https://github.com/SBOMit |
+| Website            | https://sbomit.dev/       |
+| Contributing guide | TODO |
+| Roadmap            | TODO |
+| Demos              | N/A  |