TAC to define 3-5 year technical vision

[rhaning]

The TAC is to define the Technical Vision for OpenSSF for the next 3-5 years. An annual roadmap (#37) of detailed work will be created separately.

Timeline:

• Review Draft at TAC meeting December 15
• Review Final at TAC meeting January 12
• Press Release Final January 15 (to be confirmed)

Guidelines/ideas for defining the vision:

1. Aspirational and motivational.
2. Incorporate current work being done in OpenSSF and also broad enough to incorporate future, related works.
3. What has changed in 3-5 years because the OpenSSF exists?

Working Group categorization:

1. Educate – Best Practices
2. Inform - Identifying Security Threats, Vulnerability Disclosure, Digital Identity Attestation
3. Protect – Vulnerability Disclosure , Digital Identity Attestation, Security Tooling, Securing Critical Projects

[david-a-wheeler]

This may be useful: What Is a Vision Statement?.

[david-a-wheeler]

Per the TAC meeting, it may be useful to look at the charter (adding more technical meat but still aspirational): https://github.com/ossf/foundation/blob/main/Review%20Copy%20Only%20-%20Not%20for%20Execution_OpenSSF%20Participation%20Agreement%20and%20Charter%20(rev.%202020%2011-10-2020).pdf

[david-a-wheeler]

Per the 2020-12-01 TAC meeting, the plan is to put proposed text in this issue & discuss it here in this issue. Final version will go into a document file on GitHub (e.g., TAC README.md or its own vision.md file); the final version will not be a Google docs document.

[kaywilliams]

I created rough draft vision as a starting point for discussion. I am copy pasting below, but I also created a google doc here, in case people want to put comments in the doc or experiment with revisions. (Sorry, I know we discussed keeping all iteration in the GitHub issue, but it felt unnatural to me.)

---

OpenSSF Technical Vision

We envision a future where participants in the Open Source Software ecosystem focus on delivering high quality products and services, with security handled naturally and automatically in the background. Aspects of this vision include the following:

• Security administrators (from project maintainers to government regulators) can specify security policy in a manner that can be easily automated.
• Developer tool providers can consume security policy and automate conformance across the developer workflow (from code commits to distribution).
• Developers can be informed when manual action is needed to remediate projects that have fallen out of conformance.
• Auditors can observe all actions (automated and manual) taken within the full supply chain of a software product.
• Consumers and researchers can identify security issues and have this information flow backwards through the supply chain to someone who can address the issue.
• Developers can provide notifications about product defects, mitigations, quality and supportability and have this information flow forward across the ecosystem system to all consumers.

<need a closing sentence?>

[JonZeolla]

Left some redlines in the doc

[kaywilliams]

Accepted, thanks @JonZeolla

[kaywilliams]

In the TAC meeting on Dec 15, we discussed the following next steps:

• Electronic Vote - due by January 8
• Kay to discuss with Ryan to kick off vote after 1st of the year

[kaywilliams]

Resolved with this merge.

#47