SBOM VDR - Githubissues

Hi @rjb4standards, here is rough draft, how an SBOM VDR could look like in CSAF:

{
  "document": {
    "category": "sbom_vdr",
    "csaf_version": "2.0",
    "publisher": {
      "category": "vendor",
      "name": "Reliable Energy Analytics",
      "namespace": "https://reliableenergyanalytics.com"
    },
    "title": "SBOM VDR on PowerToys (Preview)",
    "tracking": {
      "current_release_date": "2022-01-12T20:17:38.464608+00:00",
      "id": "SBOM-VDR-2022-0001",
      "initial_release_date": "2022-01-12T20:17:38.464608+00:00",
      "revision_history": [
        {
          "date": "2022-01-12T20:17:38.464608+00:00",
          "number": "1",
          "summary": "Initial version."
        }
      ],
      "status": "final",
      "version": "1",
      "generator": {
        "date": "2022-03-24T15:42:17.598Z",
        "engine": {
          "version": "1.12.1",
          "name": "Secvisogram"
        }
      }
    }
  },
  "product_tree": {
    "branches": [
      {
        "category": "vendor",
        "name": "Microsoft",
        "branches": [
          {
            "category": "product_name",
            "name": "PowerToys (Preview)",
            "branches": [
              {
                "category": "product_version",
                "name": "0.15.2",
                "product": {
                  "product_id": "CSAFPID-0001",
                  "name": "Microsoft PowerToys (Preview) 0.15.2",
                  "product_identification_helper": {
                    "sbom_urls": [
                      "https://raw.githubusercontent.com/rjb4standards/REA-Products/master/UseCaseVDR117/PToysSBOM.spdx"
                    ],
                    "x_generic_uris": [
                      {
                        "namespace": "https://spdx.github.io/spdx-spec/document-creation-information/#65-spdx-document-namespace-field",
                        "uri": "dns:softwareassuranceguardian.com#SPDXRef-Package-43c51b08-cc7e-406d-8ad9-34aa292d1157"
                      }
                    ]
                  }
                }
              }
            ]
          }
        ]
      }
    ],
    "full_product_names": [
      {
        "product_id": "CSAFPID-0002",
        "name": "0.svg",
        "product_identification_helper": {
          "x_generic_uris": [
            {
              "namespace": "https://spdx.github.io/spdx-spec/document-creation-information/#65-spdx-document-namespace-field",
              "uri": "dns:softwareassuranceguardian.com#SPDXRef-e94f7cf7-cb3a-442a-8ced-2a8d4bb1f3e3"
            }
          ]
        }
      }
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2003-0630",
      "product_status": {
        "under_investigation": [
          "CSAFPID-0002"
        ]
      },
      "notes": [
        {
          "category": "description",
          "text": "Multiple buffer overflows in the atari800.svgalib setuid program of the Atari 800 emulator (atari800) before 1.2.2 allow local users to gain privileges via long command line arguments, as demonstrated with the -osa_rom argument.",
          "title": "CVE description"
        }
      ],
      "references": [
        {
          "summary": "NVD - CVE-2003-0630",
          "url": "https://nvd.nist.gov/vuln/detail/CVE-2003-0630"
        }
      ],
      "scores": [
        {
          "products": [
            "CSAFPID-0002"
          ],
          "cvss_v2": {
            "vectorString": "AV:L/AC:L/Au:N/C:C/I:C/A:C",
            "baseScore": 7.2,
            "version": "2.0"
          }
        }
      ]
    }
  ]
}

Note: I left out the ones which came back empty - as CSAF doesn't try to produce a full SBOM. It just lists findings, unknowns (or non-findings with the known_not_affected). A profile could have the convention that every item not listed in the CSAF is hasn't listed anything at that time.

I'm curious about the added value of searching for index.html in the NVD - but I guess that is a different topic...

Hi Thomas,

Thanks for providing the reference example.

SAG-PM does not discriminate – all components listed in an SBOM are subjected to a NIST NVD scan. Components that return lots of CVE results, i.e. index.html, are shown in the SBOM VDR with the count of CVE’s identified and a warning that the number of CVE’s exceeds a runtime set maximum number of CVE to insert on the SBOM VDR.

This information is very timely as I’m presently working on SPDX change for V 2.3 that will provide access to an independently updated SBOM VDR artifact.

I’ll check out the CSAF VEX example and let you know if I have any questions/comments.

Thanks for sending this along.

Thanks,

Dick Brooks

https://reliableenergyanalytics.com/products Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com/ http://www.reliableenergyanalytics.com

Email: @.> @.

Tel: +1 978-696-1788

From: tschmidtb51 @.> Sent: Thursday, March 24, 2022 11:52 AM To: rjb4standards/REA-Products @.> Cc: Dick Brooks @.>; Mention @.> Subject: Re: [rjb4standards/REA-Products] SBOM VDR (Issue #3)

I'm curious about the added value of searching for https://github.com/rjb4standards/REA-Products/blob/bcf96f36f00f8cdc3e9c0b5c8f8577e96c39e06d/UseCaseVDR117/PToysVDR.xml#L82 index.html in the NVD - but I guess that is a different topic...

— Reply to this email directly, view it on GitHub https://github.com/rjb4standards/REA-Products/issues/3#issuecomment-1077778120 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFI3NDTYCBXZIZ5WR4NYD3VBSFQVANCNFSM5RRR33VQ . You are receiving this because you were mentioned.Message ID: @.***>

The CSAF "CARFAX" example shown appears to use an "implicit" model where only those components that have reported vulnerabilities are listed (like CycloneDX VEX). Correct?

Can you also show an example for an "explicit model" like SBOM VDR where each component is listed, along with the search results, i.e. 0 CVE's or too many CVE's to report

The CSAF "CARFAX" example shown appears to use an "implicit" model where only those components that have reported vulnerabilities are listed (like CycloneDX VEX). Correct?

Yes. That is usually how I would suggest to do it as you link them to the SBOM anyway.

Can you also show an example for an "explicit model" like SBOM VDR where each component is listed, along with the search results, i.e. 0 CVE's or too many CVE's to report

Doable? Yes. Listing all elements from the SBOM would duplicate it in the CSAF product_tree but that is not forbidden. Necessary? Not sure. Correct me if I'm wrong but you wanted to answer the question: What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level? This implies to me that there are vulnerabilities and components which don't have vulnerabilities could be omitted.

Personally, I would not explicit list the number of search results explicit (that would be data duplication, as we list the CVEs anyway and rather a factor for inconsistency). Note: CSAF does not limit the number of items/CVEs you can put into the vulnerabilities array. So there are never to many vulnerabilities to report. (Nevertheless, it is recommended not to have more than 100000 items in there...)

Thomas,

Some customers want the explicit model as proof that a software vendor did indeed check each component for vulnerabilities. The explicit model provides this proof. The implicit model requires the customer to “assume” the vendor checked each component for vulnerabilities.

Some customers are ok with the implicit model, others prefer visible proof that the vulnerability search occurred, which is what the explicit model provides.

Both approaches are acceptable to answer the question posed:

“What is the vulnerability status NOW, for product P, version V from Supplier S, at the SBOM component level?”

Thanks,

Dick Brooks

https://reliableenergyanalytics.com/products Never trust software, always verify and report! ™

http://www.reliableenergyanalytics.com/ http://www.reliableenergyanalytics.com

Email: @.> @.

Tel: +1 978-696-1788

From: tschmidtb51 @.> Sent: Thursday, March 24, 2022 7:47 PM To: rjb4standards/REA-Products @.> Cc: Dick Brooks @.>; Mention @.> Subject: Re: [rjb4standards/REA-Products] SBOM VDR (Issue #3)

The CSAF "CARFAX" example shown appears to use an "implicit" model where only those components that have reported vulnerabilities are listed (like CycloneDX VEX). Correct?

Yes. That is usually how I would suggest to do it as you link them to the SBOM anyway.

Can you also show an example for an "explicit model" like SBOM VDR where each component is listed, along with the search results, i.e. 0 CVE's or too many CVE's to report

Doable? Yes. Listing all elements from the SBOM would duplicate it in the CSAF product_tree but that is not forbidden. Necessary? Not sure. Correct me if I'm wrong but you wanted to answer the question: What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level? This implies to me that there are vulnerabilities and components which don't have vulnerabilities could be omitted.

Personally, I would not explicit list the number of search results explicit (that would be data duplication, as we list the CVEs anyway and rather a factor for inconsistency). Note: CSAF does not limit the number of items/CVEs you can put into the vulnerabilities array. So there are never to many vulnerabilities to report. (Nevertheless, it is recommended not to have more than 100000 items in there...)

— Reply to this email directly, view it on GitHub https://github.com/rjb4standards/REA-Products/issues/3#issuecomment-1078509560 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFI3NDR7QKT3SIQ6JGKM4LVBT5GXANCNFSM5RRR33VQ . You are receiving this because you were mentioned.Message ID: @.***>

rjb4standards / REA-Products

SBOM VDR #3