Follow-up mail to indicate also to administration, that I submitted the form a few moments ago. @Mike: Please kindly send the GitHub handle / username you like to use for maintaining to Chet. Thanks. Initial maintainers are the officers of the TC: Aaron, Mike, and Stefan Until the JIRA ticket (tracking the creation of the repo) shows up I hereby provide the description given in the form as well as the purpose statement that will end up as part of the README.md file in the
https://github.com/oasis-tcs/ohdf repo (@Chet: I bluntly ignored the suggested fewer than 300 characters hint because having visited a lot of these repositories I am convinced that the more specific and significant TC provided content on the landing page and only a minimal needed boilerplate the better ...): # - - - 8< - - - Description: The purpose of this repository is to support version control for Work Product artifacts developed by members of the OASIS Heimdall Data Format (OHDF) TC, including prose specification editing and secondary artifacts like meeting minutes, productivity code, etc. The TC's proposal and approval is available online per [email to the TC mailing list](
https://lists.oasis-open.org/archives/ohdf/202304/msg00014.html )) and in the JIRA request form. # - - - 8< - - - Finally the initial purpose statement cooked up from charter and public TC page: # - - - 8< - - - Purpose statement: The OHDF TC's goal is to develop a common format for exchanging normalized security data between cybersecurity tools. A standard vendor-agnostic data format will support cybersecurity product interoperability without having to create customized integrations. Security tools typically generate data in unique formats that require multiple dashboards and utilities to review. This leads to a time-consuming process for completing security assessments, data in disparate locations and inconsistent semantics of data elements across formats. In addition, few security tools provide context to relevant compliance standards for comparison across security tools. OHDF provides a common data exchange format that: - Enables the consistent integration, aggregation, and analysis of security data from all available sources - Preserves data integrity with original source data - Maximizes interoperability and data sharing - Facilitates the transformation and transport of data between security/management processes or technologies - Allows for the mapping and enrichment of security data to relevant compliance standards (GDPR, NIST SP 800-53, PCI-DSS, etc.) The TC will update OHDF as industry needs evolve. Numerous stakeholders and adopters can benefit from the work of the OHDF TC: - For Commercial and Vendor Cybersecurity Partners, OHDF defines a standardized, interoperable target format that vendor tools can consume across their customer base consistently and that is easily managed within the product lifecycle. - For the Open Source Community, OHDF enables easy integration with commercial solutions without the need for direct partnerships. - For Government Agencies, OHDF can streamline business processes by having a standard, open source, machine-readable format for all security data. - For Academia, OHDF offers a structured way to communicate and enhance research findings throughout the security community. - For Corporate and Federal CISOs/CIOs, OHDF can increase visibility across the enterprise by taking advantage of normalized security data in a standard format that supports risk information interoperability from a broad range of inputs to support security risk decision-making. - For Security Engineers, OHDF can reduce resource requirements for multiple security data types by standardizing formatting across disparate security tools. - For Risk Managers, OHDF can improve decision making by using a standardized format to facilitate automation, standardize communication requirements, and inform risk-based analysis. - For DevSecOps/Software Engineers, OHDF can streamline CI/CD processes by leveraging a standardized format to collate/aggregate normalized security data to support automated and continuous security processes. # - - - 8< - - - All the best, Stefan On Mon, Apr 24, 2023, at 21:35, Stefan Hagen wrote: Dear TC members, this mail to the TC mailing list just confirms that the motion from 2023-04-14 to request a git repository from TC administration was seconded and carried on 2023-04-21 20:00 UTC. I will submit a request for creation of a GitHub git TC repository from OASIS. All the best, Stefan On Fri, Apr 14, 2023, at 23:58, Mike Fraser wrote: Seconded Mike Fraser VP and Field CTO of DevSecOps @ Sophos From: Stefan Hagen <
stefan@hagen.link> Sent: Friday, April 14, 2023 1:31 PM To:
ohdf@lists.oasis-open.org <
ohdf@lists.oasis-open.org> Cc: Mike Fraser <
Mike.Fraser@Sophos.com>; Aaron L Lippold <
alippold@mitre.org> Subject: Motion to request a GitHub TC repository for Specification Work Products Dear TC members, I hereby submit the following motion and request that if seconded and no objection received per this list before one week has passed on 2023-04-21 20:00 UTC to automatically carry. No sophospsmartbannerend Dear TC members, I hereby submit the following motion and request that if seconded and no objection received per this list before one week has passed on 2023-04-21 20:00 UTC to automatically carry. Note: For seconding this motion it is sufficient to reply to this message on the TC list and add the word second or seconded . The Secretary or Co-Chairs usually state the result per mail to this list when the period has passed. I, Stefan Hagen, hereby move that the TC requests from OASIS administration the creation of the Github repository
https://github.com/oasis-tcs/ohdf to manage spec related work products like schema files, specification prose, test files, minutes of meeting, issues, peer reviews, IANA requests and others. I further move, that the initial maintainers shall be Aaron Lippold and Stefan Hagen. When this motion carries, the secretary will submit the relevant form such that OASIS administration can create the repository and enable the maintainers access. PS: We can always add or change maintainers later easily. All the best, Stefan. Stefan Hagen, Emmetten, Nidwalden, Switzerland. orcid:
https://orcid.org/0000-0003-4206-892X read:
https://stefan-hagen.website write:
stefan@hagen.digital