diff --git a/README.md b/README.md index e6f4f349..10de2513 100644 --- a/README.md +++ b/README.md @@ -72,6 +72,7 @@ Diagrams with an overview of the OpenSSF, including its projects and SIGs, are a | 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 | diff --git a/process/project-lifecycle-documents/SBOMit_sandbox_stage.md b/process/project-lifecycle-documents/SBOMit_sandbox_stage.md new file mode 100644 index 00000000..3da056b7 --- /dev/null +++ b/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 |