├── .github └── workflows │ ├── python-app.yml │ ├── python-package.yml │ └── python-publish.yml ├── .gitignore ├── CONTRIBUTING.md ├── CREDITS.md ├── LICENSE ├── MANIFEST.in ├── README.md ├── __init__.py ├── __version__.py ├── cvrf_util.py ├── examples ├── .DS_Store ├── 1.1 │ ├── CVRF-1.1-cisco-sa-20110525-rvs4000-invalid.xml │ ├── CVRF-1.1-cisco-sa-20110525-rvs4000-notwellformed.xml │ ├── CVRF-1.1-cisco-sa-20110525-rvs4000.xml │ ├── mitre-allitems-cvrf-year-2018.xml │ ├── ms_cvrf.xml │ ├── oracle_cvrf.xml │ └── redhat_cvrf_2018.xml └── 1.2 │ ├── cvrf_example_a.xml │ ├── cvrf_example_b.xml │ ├── cvrf_example_c.xml │ ├── cvrf_example_d.xml │ └── cvrf_example_e.xml ├── requirements-dev.txt ├── requirements-test.txt ├── requirements.txt ├── schemata ├── catalog_1_1.xml ├── catalog_1_2.xml ├── common │ ├── .svn │ │ ├── all-wcprops │ │ └── entries │ ├── 1.1 │ │ ├── .svn │ │ │ ├── all-wcprops │ │ │ ├── entries │ │ │ └── text-base │ │ │ │ └── common.xsd.svn-base │ │ └── common.xsd │ └── 1.2 │ │ └── common.xsd ├── cvrf │ ├── .svn │ │ ├── all-wcprops │ │ └── entries │ ├── 1.1 │ │ ├── .svn │ │ │ ├── all-wcprops │ │ │ ├── entries │ │ │ └── text-base │ │ │ │ └── cvrf.xsd.svn-base │ │ └── cvrf.xsd │ └── 1.2 │ │ └── cvrf.xsd ├── dublincore │ └── dc.xsd ├── prod │ ├── .svn │ │ ├── all-wcprops │ │ └── entries │ ├── 1.1 │ │ ├── .svn │ │ │ ├── all-wcprops │ │ │ ├── entries │ │ │ ├── prop-base │ │ │ │ └── prod.xsd.svn-base │ │ │ └── text-base │ │ │ │ └── prod.xsd.svn-base │ │ └── prod.xsd │ └── 1.2 │ │ └── prod.xsd ├── scap │ ├── cpe-language_2.2a.xsd │ ├── cvss-v2_0.9.xsd │ ├── cvss-v3.0.xsd │ └── scap-core_0.9.xsd ├── vuln │ ├── .svn │ │ ├── all-wcprops │ │ └── entries │ ├── 1.1 │ │ ├── .svn │ │ │ ├── all-wcprops │ │ │ ├── entries │ │ │ └── text-base │ │ │ │ └── vuln.xsd.svn-base │ │ └── vuln.xsd │ ├── 1.2 │ │ └── vuln.xsd │ └── vuln.xsd └── w3.org │ └── xml.xsd ├── setup.py └── tests ├── __init__.py ├── context.py └── test_cli.py /.github/workflows/python-app.yml: -------------------------------------------------------------------------------- 1 | # This workflow will install Python dependencies, run tests and lint with a single version of Python 2 | # For more information see: https://help.github.com/actions/language-and-framework-guides/using-python-with-github-actions 3 | 4 | name: Python application 5 | 6 | on: 7 | push: 8 | branches: [ master ] 9 | pull_request: 10 | branches: [ master ] 11 | 12 | jobs: 13 | build: 14 | 15 | runs-on: ubuntu-latest 16 | 17 | steps: 18 | - uses: actions/checkout@v2 19 | - name: Set up Python 3.9 20 | uses: actions/setup-python@v2 21 | with: 22 | python-version: 3.9 23 | - name: Install dependencies 24 | run: | 25 | python -m pip install --upgrade pip 26 | pip install flake8 pytest 27 | if [ -f requirements.txt ]; then pip install -r requirements.txt; fi 28 | if [ -f requirements-dev.txt ]; then pip install -r requirements-dev.txt; fi 29 | - name: Lint with flake8 30 | run: | 31 | # stop the build if there are Python syntax errors or undefined names 32 | flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics 33 | # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide 34 | flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics 35 | - name: Test with pytest 36 | run: | 37 | pytest 38 | -------------------------------------------------------------------------------- /.github/workflows/python-package.yml: -------------------------------------------------------------------------------- 1 | # This workflow will install Python dependencies, run tests and lint with a variety of Python versions 2 | # For more information see: https://help.github.com/actions/language-and-framework-guides/using-python-with-github-actions 3 | 4 | name: Python package 5 | 6 | on: 7 | push: 8 | branches: [ master ] 9 | pull_request: 10 | branches: [ master ] 11 | 12 | jobs: 13 | build: 14 | 15 | runs-on: ubuntu-latest 16 | strategy: 17 | matrix: 18 | python-version: [3.7, 3.8, 3.9] 19 | 20 | steps: 21 | - uses: actions/checkout@v2 22 | - name: Set up Python ${{ matrix.python-version }} 23 | uses: actions/setup-python@v2 24 | with: 25 | python-version: ${{ matrix.python-version }} 26 | - name: Install dependencies 27 | run: | 28 | python -m pip install --upgrade pip 29 | python -m pip install flake8 pytest 30 | if [ -f requirements.txt ]; then pip install -r requirements.txt; fi 31 | - name: Lint with flake8 32 | run: | 33 | # stop the build if there are Python syntax errors or undefined names 34 | flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics 35 | # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide 36 | flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics 37 | - name: Test with pytest 38 | run: | 39 | pytest 40 | -------------------------------------------------------------------------------- /.github/workflows/python-publish.yml: -------------------------------------------------------------------------------- 1 | # This workflow will upload a Python Package using Twine when a release is created 2 | # For more information see: https://help.github.com/en/actions/language-and-framework-guides/using-python-with-github-actions#publishing-to-package-registries 3 | 4 | name: Upload Python Package 5 | 6 | on: 7 | release: 8 | types: [created] 9 | 10 | jobs: 11 | deploy: 12 | 13 | runs-on: ubuntu-latest 14 | 15 | steps: 16 | - uses: actions/checkout@v2 17 | - name: Set up Python 18 | uses: actions/setup-python@v2 19 | with: 20 | python-version: '3.x' 21 | - name: Install dependencies 22 | run: | 23 | python -m pip install --upgrade pip 24 | pip install setuptools wheel twine 25 | - name: Build and publish 26 | env: 27 | TWINE_USERNAME: ${{ secrets.PYPI_USERNAME }} 28 | TWINE_PASSWORD: ${{ secrets.PYPI_PASSWORD }} 29 | run: | 30 | python setup.py sdist bdist_wheel 31 | twine upload dist/* 32 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Byte-compiled / optimized / DLL files 2 | __pycache__/ 3 | *.py[cod] 4 | *$py.class 5 | 6 | # C extensions 7 | *.so 8 | 9 | # Distribution / packaging 10 | .Python 11 | build/ 12 | develop-eggs/ 13 | dist/ 14 | downloads/ 15 | eggs/ 16 | .eggs/ 17 | lib/ 18 | lib64/ 19 | parts/ 20 | sdist/ 21 | var/ 22 | wheels/ 23 | *.egg-info/ 24 | .installed.cfg 25 | *.egg 26 | MANIFEST 27 | 28 | # PyInstaller 29 | # Usually these files are written by a python script from a template 30 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 31 | *.manifest 32 | *.spec 33 | 34 | # Installer logs 35 | pip-log.txt 36 | pip-delete-this-directory.txt 37 | 38 | # Unit test / coverage reports 39 | htmlcov/ 40 | .tox/ 41 | .coverage 42 | .coverage.* 43 | .cache 44 | nosetests.xml 45 | coverage.xml 46 | *.cover 47 | .hypothesis/ 48 | 49 | # Translations 50 | *.mo 51 | *.pot 52 | 53 | # Django stuff: 54 | *.log 55 | .static_storage/ 56 | .media/ 57 | local_settings.py 58 | 59 | # Sphinx documentation 60 | docs/_build/ 61 | 62 | # Jupyter Notebook 63 | .ipynb_checkpoints 64 | 65 | # pyenv 66 | .python-version 67 | 68 | # Environments 69 | .env 70 | .venv 71 | env/ 72 | venv/ 73 | ENV/ 74 | env.bak/ 75 | venv.bak/ 76 | 77 | # mypy 78 | .mypy_cache/ 79 | 80 | # Editor files 81 | .idea/ 82 | *.swp 83 | 84 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 |
This OASIS TC TC Open Repository ( github.com/oasis-open/csaf-parser ) is a community public repository that supports participation by anyone, whether affiliated with OASIS or not. Substantive contributions (repository "code") and related feedback is invited from all parties, following the common conventions for participation in GitHub public repository projects. Participation is expected to be consistent with the OASIS TC TC Open Repository Guidelines and Procedures, the LICENSE designated for this particular repository (BSD-3-Clause License), and the requirement for an Individual Contributor License Agreement. Please see the repository README document for other details.
8 |Content accepted as "contributions" to this TC TC Open Repository, as defined below, are distinct from any Contributions made to the associated OASIS Common Security Advisory Framework (CSAF) TC itself. Participation in the associated Technical Committee is governed by the OASIS Bylaws, OASIS TC Process, IPR Policy, and related policies. This TC TC Open Repository is not subject to the OASIS TC-related policies. TC TC Open Repository governance is defined by separate participation and contribution guidelines as referenced in the OASIS TC TC Open Repositories Overview.
14 |Because different licenses apply to the OASIS TC's specification work, and this TC TC Open Repository, there is no guarantee that the licensure of specific repository material will be compatible with licensing requirements of an implementation of a TC's specification. Please refer to the LICENSE file for the terms of this material, and to the OASIS IPR Policy for the terms applicable to the TC's specifications, including any applicable declarations.
19 |Formally, "contribution" to this TC TC Open Repository refers to content merged into the "Code" repository (repository changes represented by code commits), following the GitHub definition of contributor: "someone who has contributed to a project by having a pull request merged but does not have collaborator [i.e., direct write] access." Anyone who signs the TC TC Open Repository Individual Contributor License Agreement (CLA), signifying agreement with the licensing requirement, may contribute substantive content — subject to evaluation of a GitHub pull request. The main web page for this repository, as with any GitHub public repository, displays a link to a document listing contributions to the repository's default branch (filtered by Commits, Additions, and Deletions).
25 | 26 |This TC TC Open Repository, as with GitHub public repositories generally, also accepts public feedback from any GitHub user. Public feedback includes opening issues, authoring and editing comments, participating in conversations, making wiki edits, creating repository stars, and making suggestions via pull requests. Such feedback does not constitute an OASIS TC TC Open Repository contribution. Some details are presented under "Read permissions" in the table of permission levels for a GitHub organization. Technical content intended as a substantive contribution (repository "Code") to an TC TC Open Repository is subject to evaluation, and requires a signed Individual CLA.
27 | 28 | 29 |OASIS TC TC Open Repositories use the familiar fork-and-pull collaboration model supported by GitHub and other distributed version-control systems. Any GitHub user wishing to contribute should fork the repository, make additions or other modifications, and then submit a pull request. GitHub pull requests should be accompanied by supporting comments and/or issues. Community conversations about pull requests, supported by GitHub notifications, will provide the basis for a consensus determination to merge, modify, close, or take other action, as communicated by the repository Maintainers.
35 |Questions or comments about this TC 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 repository Maintainer(s). Please send general questions about TC TC Open Repository participation to OASIS Staff at repository-admin@oasis-open.org and any specific CLA-related questions to repository-cla@oasis-open.org.
41 | 42 |This GitHub public repository ( https://github.com/oasis-open/csaf-parser ) 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.
8 | 9 | **NOTE**: The current version of this parser only supports [CVRF 1.2 (XML-based specification)](http://docs.oasis-open.org/csaf/csaf-cvrf/v1.2/cs01/csaf-cvrf-v1.2-cs01.html). It does not support the [CSAF 2.0 JSON schema](https://github.com/oasis-tcs/csaf/blob/master/csaf_2.0/json_schema/csaf_json_schema.json). To obtain information about several tools to parse, create, and validate CSAF 2.0 content go to https://csaf.io. 10 | 11 |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.
12 | 13 |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.
14 | 15 |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.
16 | 17 |Statement of Purpose for this OASIS TC Open Repository (csaf-parser) as proposed and approved [bis] by the TC:
23 | 24 |The CSAF Parser (and validator) under development in this repository is a software tool for parsing and checking the syntax of the Common Vulnerability Reporting Framework (CVRF) machine readable security advisory content. The repository contains source code and associated documentation for the tool. The CSAF Parser can be used as a command-line tool or as a Python library which can be included in other applications.
25 | 26 |[Earlier incarnations of the parser code included cvrf-util and Mike Schiffman's cvrfparse]
27 | 28 | 35 | 36 |One fairly common use-case would be to query a document and pull out the unique set of products with related fields from all vulnerabilities and save to excel file as shown below:
42 |
43 | `python cvrf_util.py --file examples/1.1/ms_cvrf.xml --schema schemata/cvrf/1.1/cvrf.xsd --cvrf-version 1.1 --output-format csv --output-file ms_cvrf.csv --vuln ProductID --include-related-product-elements --unique-products --related-product-tags all`
44 |
45 |
46 |
Where the following command line parameters were applied: | |
--file examples/1.1/ms_cvrf.xml | Specify the document we are parsing |
--schema schemata/cvrf/1.1/cvrf.xsd | Specify the schema |
--cvrf-version 1.1 | Specify the CVRF version |
--output-format csv | Specify output format to CVS |
--output-file ms_cvrf.csv | Specify the output file |
--vuln ProductID | Specify elements to parse |
--include-related-product-elements | Tell output to include related product elements |
--unique-products | Specify that we want unique product rows per vulnerability |
--related-product-tags all | Specify which related product element tags to include for each product row |
Another common example is to query a document and parse out all of the elements in each vulnerability and save to html file as shown below:
62 |
63 |
64 | `python cvrf_util.py --file examples/1.1/ms_cvrf.xml --cvrf-version 1.1 --output-format html --output-file ms_cvrf.html --vuln Vulnerability --cvrf all --prod all`
65 |
66 |
67 |
Where the following command line parameters were applied: | |
--file examples/1.1/ms_cvrf.xml | Specify the document we are parsing |
--cvrf-version 1.1 | Specify the CVRF version |
--output-format html | Specify output format to HTML |
--output-file ms_cvrf.html | Specify the output file |
--vuln Vulnerability | Specify elements to parse |
--cvrf all | Specify elements to parse |
--prod all | Specify elements to parse |
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.
84 |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.
90 | 91 |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.
92 | 93 |Current Maintainers of this TC Open Repository
94 | 95 |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 repository-admin@oasis-open.org and any specific CLA-related questions to repository-cla@oasis-open.org.
119 | 120 |