oasis-open / csaf-documentation Goto Github PK

OASIS TC Open Repository: A GitHub repository for management of non-normative information about the work of the CSAF Technical Committee, including documentation

Home Page: https://oasis-open.github.io/csaf-documentation/

License: BSD 3-Clause "New" or "Revised" License

CSS 89.81% HTML 10.19%

csaf-documentation's Introduction

README

OASIS TC Open Repository: csaf-documentation

This GitHub public repository ( https://github.com/oasis-open/csaf-documentation ) was created at the request of the OASIS Common Security Advisory Framework (CSAF) TC as an OASIS TC Open Repository to support development of open source resources related to Technical Committee work.

While this TC Open Repository remains associated with the sponsor TC, its development priorities, leadership, intellectual property terms, participation rules, and other matters of governance are separate and distinct from the OASIS TC Process and related policies.

All contributions made to this TC Open Repository are subject to open source license terms expressed in the BSD-3-Clause License. That license was selected as the declared "Applicable License" when the TC Open Repository was created.

As documented in "Public Participation Invited", contributions to this OASIS TC Open Repository are invited from all parties, whether affiliated with OASIS or not. Participants must have a GitHub account, but no fees or OASIS membership obligations are required. Participation is expected to be consistent with the OASIS TC Open Repository Guidelines and Procedures, the open source LICENSE designated for this particular repository, and the requirement for an Individual Contributor License Agreement that governs intellectual property.

Statement of Purpose

Statement of Purpose for this OASIS TC Open Repository (csaf-documentation) as proposed and approved [bis] by the TC:

The purpose of this GitHub public repository is to support development of open source resources and documentation related to CSAF Technical Committee work.

The OASIS CSAF Technical Committee was chartered to make a major revision to the Common Vulnerability Reporting Framework (CVRF) under a new name for the framework that reflects the primary purpose: a Common Security Advisory Framework (CSAF). TC deliverables are designed standardize existing practice in structured machine-readable vulnerability-related advisories and further refine those standards over time.

The Common Security Advisory Framework's (CSAF) Common Vulnerability Reporting Framework (CVRF) is a language to exchange Security Advisories formulated in XML. The term Security Advisory describes any notification of security issues in products of and by providers. Anyone providing a product is considered in this document as a vendor, i.e. developers or maintainers of information system products or services. This includes all authoritative product vendors, Product Security Incident Response Teams (PSIRTs), and product resellers and distributors, including authoritative vendor partners.

Additions to Statement of Purpose

Repository Maintainers may include here any clarifications — any additional sections, subsections, and paragraphs that the Maintainer(s) wish to add as descriptive text, reflecting (sub-) project status, milestones, releases, modifications to statement of purpose, etc. The project Maintainers will create and maintain this content on behalf of the participants.

Maintainers

TC Open Repository Maintainers are responsible for oversight of this project's community development activities, including evaluation of GitHub pull requests and preserving open source principles of openness and fairness. Maintainers are recognized and trusted experts who serve to implement community goals and consensus design preferences.

Initially, the associated TC members have designated one or more persons to serve as Maintainer(s); subsequently, participating community members may select additional or substitute Maintainers, per consensus agreements.

Current Maintainers of this TC Open Repository

Stefan Hagen; GitHub ID: sdrees; WWW: Individual
Vincent Danen; GitHub ID: vdanen; WWW: Red Hat
Omar Santos; GitHub ID: santosomar; WWW: Cisco

About OASIS TC Open Repositories

Feedback

Questions or comments about this TC Open Repository's activities should be composed as GitHub issues or comments. If use of an issue/comment is not possible or appropriate, questions may be directed by email to the Maintainer(s) listed above. Please send general questions about TC Open Repository participation to OASIS Staff at [email protected] and any specific CLA-related questions to [email protected].

csaf-documentation's People

Contributors

Stargazers

Watchers

Forkers

robincover santosomar sthagen jmday msmeissn isabella232 ctron mprpic stefanfl oxisto

csaf-documentation's Issues

Explain Distribution and Discovery

One really cool thing about CSAF is the distribution and the discovery. We should add that somewhere. Maybe do a video to explain it?

Add new videos

There are some new videos available:

Add CSAF lister

Please add the CSAF lister to the website.

Vulnerability Threat Element Error

In version 1.2 (http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508771)
Section 6.11.1

It indicates that "Date" is an attribute, however in examples 61 and 62, date is added as an element.
(note also that on example 62, the opening element tag for "Date" uses a "/", which is incorrect)

Example 61: Exploit Status:

none 2011-11-26T00:00:00+00:00 CVRFPID-0000

Example 62: Exploit Status without Product ID:

proof of concept 2011-11-26T00:00:00+00:00

I'm not sure if this is incorrectly marked as being a date attribute and it should be an element, or if it's incorrectly exampled as being an element, but it should be one or the other.

Update the CSAF Documentation Website to make it more intuitive

This is a request to update the CSAF Documentation Website to make it more intuitive.

Add more tools

We already have some new tools available. They are still work in progress but already usable:

CSAF trusted provider => csaf_provider + csaf_uploader
Provider checker => csaf_checker
CVRF CSAF converter

@santosomar Could you please add them to the list?

Add CVRF becomes CSAF FAQ entry

We had and have people encountering difficulties understanding that CSAF is the new CVRf.

So, we should add an entry into the FAQ section that swiftly explains that fact.

Add How-Tos

I think we should add some How-Tos, e.g.:

How to deal with a Hotfix in the product_tree
How to use product_status

I attached a file CSAF_TC_Example_Hotfix_2021_0001.json.txt which shows both. Maybe, we could develop the story behind that and connect these two (as I have done in the file - maybe even with the revision_history).

Thoughts?

Link to OASIS site with company logos

We could have a section where we show the logos of companies which are supporting CSAF. Would that be possible (from a legal point of view)?

Update statement of purpose

The current statement of purpose does not reflect our current charter. We should update that.

Add tool "paikalta"

@sthagen provided via pypi paikalta the filename test for CSAF files. Please add that tool.

Update CSAF website with additional 2.0 resources

Update CSAF website with additional 2.0 resources (including links to tools, current prose, examples, etc.)

Update the navigation bar to be more intuitive and organized.

New tool `Trivy`

Add Trivy as new tool that can be used with CSAF

How companies can use the provider-metadata.json to describe (to machines) where their CSAF content is, etc.

Check out tool `trustification`

I came across a tool call trustification that supports CSAF. We should check what it does and whether we can display it on the tools page.

Maybe @mprpic can help here?

Additional CSAF Marketing Videos and Content

Create short videos (~ 2 minutes long) explaining the following:

Add FAQ section

It would be beneficial to add a FAQ section. Questions could be:

What is CSAF?
Which problem is addressed by CSAF?
Can I use CSAF?
Does vendor X issues CSAF documents?

What is VEX and how CSAF VEX profiles are used?

Add tool "CSAF webview"

The tool can display a CSAF file: https://github.com/csaf-poc/csaf_webview => https://csaf-poc.github.io/csaf_webview/

FAQ

Use new FAQ document from TC: https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/guidance/faq.md

Link to the Current Prose

Input from Thomas:
Please add a link to the current prose (right next to the CSAF 2.0 Draft Schema) of CSAF 2.0.

Add generator for provider-metadata.json

The SecurityTXT project provides an online generator for their file format. We should have something similar for th provider-metadata.json. Maybe we could generate that with GH-Pages or as a standalone tool?

Update link

The link should always point to the latest specification: https://docs.oasis-open.org/csaf/csaf/v2.0/csaf-v2.0.html instead of a specific CS (currently CS02).

Add video: Secure Supply Chain through Automation - with CSAF, VEX and SBOM

https://youtu.be/gsrb1qrgA50

Date: 2022-06-07

What are the differences between CVRF and CSAF?

Conflict markers in examples/README.md

Hi,

There are git conflict markers in the current master (3617676) version of examples/README.md, probably from a bad merge.

What are the different CSAF profiles?

Add a news section

Please add a sections with news about CSAF (e.g. that it is currently in Public Review).

Remove unmaintained software from the list

We should consider to remove currently unmaintained (or just CVRF supporting) software from the list of tools - or at least push them to the bottom. I guess that is the case for:

@santosomar: Thoughts?

CWE element error

Version 1.2 (http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508771)
section 6.9

The words say:

« The vuln:CWE element MUST be present zero or one time in any vuln:Vulnerability and if present it contains the MITRE standard Common Weakness Enumeration (CWE) and this value MUST match the pattern documented in section 2.2.13 Vulnerability CWE Type Model. » [CSAF-6.9-1]

The Type model says:

Vulnerability measures given as defined in the Common Weakness Enumeration (CWE) model are expected to be in a specific form to enhance interoperability.
« Any CWE value MUST be completely matched by the following regular expression:
CWE-[1-9]\d{0,5}

Which would indicate an element looking like:

CWE-601 

However the examples (examples 57 and 58) show:
URL Redirection to Untrusted Site ('Open Redirect') 

Which indicates that there is an ID Attribute that must match the type model, and the contents of the element is the name of the CWE.

I'm not sure which is correct, but it should be one or the other.

What open-source tools exist for CSAF?

Link to the schema instead of GitHub

As we have the CSD in PR we should link to https://docs.oasis-open.org/csaf/csaf/v2.0/csaf_json_schema.json instead https://github.com/oasis-tcs/csaf/tree/master/csaf_2.0/json_schema. We should also consider to add the other (aggregator and provider-metadata) schemas somewhere.

What is CSAF?

How vulnerability coordinators use CSAF?

Add links to public accessible presentations

We should add links to the public accessible presentations / videos /slides /papers about CSAF 2.0. Currently, I'm aware of the following:

Product Tree - Relationship - Question (possible Error)

in version 1.2 (http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html#_Toc493508771)
section 5.1.3

This section indicates that the prod:Relationship element would contain ONE OR MORE prod:FullProductName elements

The prod:Relationship element MUST be present with cardinality [0, ∞] in prod:Tree and if given MUST contain one or more prod:FullProductName instances. » [CSAF-5.1.3-1]

My understanding of this element is that you are creating a new FullProductName object by relating multiple other elements. This makes sense,

However, I cant figure out an example where you would define MULTIPLE FullProductName objects from that relationship.

So, from the docs, this woudl be legal.

AD Dir Services product
another AD Dir Services product

Is that the intent or is the "ONE or MORE" incorrect? and if it is correct, can you post an example of when that might be useful?

Highlights of new CSAF features

Input from Thomas:
We should add a list which highlights the new features:

Conformance targets: to be able to use COTS software
semantic versioning: see when you need to do a new run against your asset database
VEX as a profile
easy generation with online tools: like Secvisogram
enables automation through CSAF roles and requirements for distribution CSAF documents
Suite of testfiles

General suggestion - standardize on regex where requiring specific string matching.

In the models section, always include the regular expression where matching is required.
(sometimes you had "must be less than x characters long", sometimes you listed some of the items (like with the CVSS scores). It would be helpful to be able to simply copy the regex into systems instead of having to figure it out each time. (not a big deal, but if you are already there, it's a nice thing).