Expand Community Mandate from OVAL to SCAP

[wmunyan]

Abstract

We propose broadening the scope of our community mandate to include XCCDF and other community-driven security automation standards initiatives interoperable with and/or closely-related to OVAL that our community chooses to work on.

Additional context

What, exactly would this change entail from a practical perspective?

• We would change our name from the “OVAL Community” to the “SCAP Community”
• We would also change URLs and other names from “OVAL” to “SCAP” (e.g. GitHub repos, “The SCAP Leadership Board”, etc.)
• We would migrate XCCDF and other OVAL/SCAP-related projects from various other locations to our GitHub repo and mailing lists
• Our governance model would be applied to the XCCDF project managed within our community and other similar projects TBD
• We would create a new website reflecting our broader mission that adds coverage of XCCDF and other projects to our existing OVAL coverage
• Going forward, new projects (such as those currently being done under the SCAPv2 initiative) could be conducted within our community

Why make this change?

To a large extent, this change is not a change at all. The communities working on XCCDF and other closely-related initiatives are—for the most part—the same folks that work on OVAL in our community. And the projects are tightly interrelated. Most OVAL authors, tooling vendors, and consumers work with OVAL and XCCDF—often as co-dependent parts of the same project! Many OVAL consumers use XCCDF and don’t even know the difference… it’s all "SCAP" to them.

Centralizing these closely-related initiatives under one community is expected to have many benefits:

• For Standards Developers
  • This will consolidate work currently splintered across multiple projects, mailing lists, etc.
  • This will facilitate making enhancements that impact multiple, related standards
  • This will provide a common set of tools and governance model for these closely related projects
• For Current Content Authors & SCAP End Users
  • This will provide a common place to learn about OVAL, XCCDF and other related standards
  • This will better support enhancement requests that impact multiple, related standards
• For OVAL/SCAP Adoption
  • This consolidation of community efforts should yield a more vibrant, center of activity for our family of security automation standards, better representing and communicating their maturity, utility and widespread adoption

How would this change be effected?

Phase I: Change Name & Merge Repositories

The following changes would be moved through the OVAL Governance Process and, if adopted, be effected by the appropriate Area Supervisor:

1. Change “OVAL-Community” GitHub organization name to “SCAP-Community” (this will migrate all users, issues, etc.)
2. Create “new" “OVAL-Community” GitHub organization and put a description in that directs people to our new “SCAP-Community” organization. This will ensure that references to our old repos continue to work and aren’t overwritten by a new owner of OVAL-Community.
3. Move "scapcommunity" repos to SCAP-Community organization and put note in "scapcommunity" to visit the new "SCAP-Community"
4. Change “OVAL” to “SCAP” in website, documentation as appropriate

Phase II: New Website to Reflect Broader Mission

Once Phase I is completed, interested parties will collaborate to draft a new website reflecting the broader mission of our community. The new website will be created following the OVAL Governance process as follows (see OVAL Governance Process for details):

1. A GitHub Issue will be created describing the site including the proposed technology (GitHub pages, wiki, etc.), theme and organization. The community will use this ticket to discuss these choices.
2. Interested parties will collaborate on branch in a fork of this repo to create a new site. The parties will provide occasional updates to the community via the mailing list so we can all preview the site and provide feedback.
3. When the site is ready, a Proposal (a pull request) will be created so that it can be adopted via the current Governance Process

Questions? Concerns? Applause?

Please weigh in below (in this Issue), if you have any feedback. And, feel free to reach out on the mailing list as well!

(Full props to @DavidRies for his contributions to this effort)

[DavidRies]

From Charles Schmidt (on mailing list):

Thank you for putting this together. One question - will all the old links to OVAL pages, repos, issues, etc. continue to work after the change? I would imagine that we would want to avoid breaking any existing links out there in the course of the transition. We probably also want to make sure that those who do online searches for OVAL still get directed to the same resources, even after those resources are part of a larger umbrella.

[djhaynes]

This seems reasonable to me, but, I would be curious to hear what others think.

[DavidRies]

Have we sent a link to this Issue to the OVAL Board and other OVAL Community mailing lists?

[DavidRies]

I've had some feedback that while it might make sense to expand our mandate to include XCCDF and the initiatives currently being considered by the SCAPv2 working groups, it probably does not make sense to include some of the SCAP component specifications that have existing organized communities such as CVE (https://cve.mitre.org/working_groups.html).

I don't think this proposal is intended to include any specifications that already have a healthy community of their own. I suggest we itemize these and explicitly exclude them from the expanded mandate.

[DavidRies]

Here is a list of related specifications, communities and initiatives that I think would make sense to include under our expanded mandate IF there is interest from our community AND from those working on them:

• XCCDF
• ARF
• SCAP constructs
• SCAP source data stream
• SCE
• OCIL
• SCAPv2 Content Authoring working group
• SCAPv2 OVAL/XCCDF Repository working group

AI & CPE are less closely-related and don't seem to be under active development, but could be included as well.

The following would NOT be included (they already have a home and/or are not closely related in my opinion):

• SWID
• TMSAD
• CVE