Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Question about product risk assessments #407

Open
rjb4standards opened this issue Feb 6, 2022 · 31 comments
Open

Question about product risk assessments #407

rjb4standards opened this issue Feb 6, 2022 · 31 comments
Labels
question

Comments

@rjb4standards
Copy link

I’m working to implement VEX (both CSAF and CDX) as part of SAG-PM’s risk assessment and the deeper I look into the VEX model, the more I question its viability/scalability/efficiency. Let me explain and please tell me if I’m off base.

I assume that VEX objects are “born” when a new vulnerability is reported and a Company issues the VEX containing status (affected or not) for each product the company offers. For example Microsoft’s VEX for a given CVE would list over 1000 products based on product name and versions that are supported. Each new vulnerability results in another VEX file listing every product/status. I’m basing this on my observations of how Siemens issues VEX’s today:
https://cert-portal.siemens.com/productcert/csaf/ssa-661247.json

Now a customer acquires Siemens (Industrial Edge Management OS (IEM-OS) version 1.4.41) and wants to ask the question:

Are there any known vulnerabilities in “Siemens/Industrial Edge Management OS (IEM-OS)/1.4.41”, before installing?

A risk assessment solution, like SAG-PM, MUST download each VEX document produced by Siemens and examine the product tree and vulnerability/status tree for intersections under the known affected status branch in order to determine which CVE’s the Siemens/Industrial Edge Management OS (IEM-OS)/1.4.41 product may be vulnerable to. This could require the downloading and examination of “lots” of VEX files in order to answer this one question. Theoretically there is the potential for a VEX file per reported CVEID that would each have to be examined to answer the question. I base this on my understanding from analyzing Siemens use of VEX, per the example at the link above. There is no upper bound as to the number of VEX files that can be produced as this depends on the discovery of new vulnerabilities,

Are my analysis and assumptions correct that a risk assessment would require the downloading of every VEX file issued by a software vendor in order to answer the question posed above?

Thanks,
Dick Brooks
@tschmidtb51
Copy link
Contributor

@rjb4standards I guess that questions is more for the VEX group than the CSAF TC...

Let me answer that from a CSAF point of view: Your assumption is correct. PSIRTs, at least at the moment, usually work event-driven. The trigger of such an event is usually a vulnerability report (or a 3rd party security advisory). That could be external (an external security researcher found something) or internal (product pen-testing found something) or through dependency monitoring (a vulnerability in a 3rd party software was discovered/ a security advisory released). Therefore, security advisories are usually vulnerability-based.

Note: The CSAF standard does not require CSAF documents to be vulnerability-centric - they can also be product-centric (all known/investigated vulnerabilities for one product). IMHO, that is currently not requested by customers, therefore nobody produces that.

@santosomar, @tolim, @mprpic: Correct me, if I'm wrong.

@rjb4standards
Copy link
Author

Thomas, thanks for confirming my understanding based on the materials I was able to locate and analyze. I was not able to locate any actual VEX artifacts that contained a complete vulnerability analysis for a software product. I've recently confirmed with Steve Springett that CycloneDX VEX does indeed support the use case presented as a question in the original posting and have added CDXVEX to the list of viable Vulnerability Reporting Options within the open-source Vendor Response File (VRF) used by software vendors to communicate SBOM and other evidence data to customers for NIST SP 800-161 and Executive Order 14028: https://github.com/rjb4standards/REA-Products/blob/master/SAGVendorSchema.xsd https://github.com/rjb4standards/REA-Products/blob/master/SAGVendorResponseSAMPLE.xml

Thanks for your quick response. Please let me know if CSAF VEX does produce a solution to the use case presented and I'll happily add the CSAF solution as a viable option to the open-source VRF Vulnerability Reporting options.

@tschmidtb51
Copy link
Contributor

tschmidtb51 commented Feb 7, 2022 •
edited

@rjb4standards I might have been not clear enough about that: CSAF can convey that information. You can create a single CSAF document per product listing all statements that where ever made about that product. It is not a limit in CSAF.

However, as IMHO this format is not requested by customers from their vendors today, PSIRTs are not compiling that information. Therefore, you didn't find examples.
If you see a market there, nobody prevents you to offer that as a service for your customers.

Again: The limit here is not CSAF, but customer requests. @santosomar, @tolim, @mprpic: Correct me, if I'm wrong about the customer requests.

@rjb4standards
Copy link
Author

Thanks Thomas. If someone is willing to produce a CSAF VEX that answers this question, then I will be happy to add this to the list of viable vulnerability reporting options in the VRF, just like was done for CDXVEX. The VRF Vulnerability info URL is intended to answer this question:

What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level?

This is representative of the question being asked for NIST C-SCRM risk assessments today before any attempt to install product P. The question may be specific to NIST C-SCRM use cases and may not be applicable to other use cases.

@mprpic
Copy link
Contributor

mprpic commented Feb 7, 2022

@rjb4standards Thomas is correct, CSAF is just a delivery vehicle of information, not an evaluator of different parts of information to answer a question. There are several scanning solutions that implement exactly this and as far as I know are implemented in the way you suggest: construct an internal database of all vulnerability information from disparate sources and provide APIs that compute answers to questions like "is component X in product Y affected or fixed".

There is also a spec for assessment of vulnerabilities: https://oval.cisecurity.org/, but it's a bit limited in the way it can assess a system's component state.

@rjb4standards
Copy link
Author

Thanks, Martin. I think CSAF is a well engineered solution for the purpose it was designed for. Thanks for sharing your insights.

@JasonKeirstead
Copy link

Interested in @sparrell input on this thread.

@rjb4standards Am i correct based on above thread that the only actual gap here is not in the standard itself, but for a VEX example using CSAF to be provided?

@rjb4standards
Copy link
Author

rjb4standards commented Feb 8, 2022 •
edited

Good question @JasonKeirstead Siemens has provided an excellent use case with Log4j. I would be interested in a VEX that can answer this question:

Are there any known vulnerabilities in “Siemens/Industrial Edge Management OS (IEM-OS)/1.4.41”, before installing?

or More generically:

What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level?

Before any attempt to install a software product by a consumer.

This question in not theoretical, it's what the 2/4/2022 NIST Guidance is attempting to address via "software vendor attestations" along with other objectives, i.e. adherence to SDLC practice and policies and much more,

@JasonKeirstead
Copy link

@rjb4standards
Agree - and I think CSAF is made to communicate that kind of information.

The part I am starting to think is missing however, is the negative assertion. Because until recently PSIRT teams never needed to communicate a negative assertion, it wasn't really considered with CSAF. However, negative assertion (this software is not susceptible to CVE X) is just as important in VEX as positive assertions. So this would need to be opened as a workstream in CSAF to address it.

Also, Log4J highlighted the need for PSIRT teams to communicate out negative assertions to the public - so CSAF needs this anyway.

@rjb4standards
Copy link
Author

@JasonKeirstead we are in agreement that software vendors need to show that they have examined each component in an SBOM for vulnerabilities and report the results, positive and negative, as part of the software vulnerability attestation, per the 2/4/2022 NIST guidelines.

@tschmidtb51
Copy link
Contributor

The part I am starting to think is missing however, is the negative assertion. Because until recently PSIRT teams never needed to communicate a negative assertion, it wasn't really considered with CSAF. However, negative assertion (this software is not susceptible to CVE X) is just as important in VEX as positive assertions. So this would need to be opened as a workstream in CSAF to address it.

@JasonKeirstead The product status not_affected was already part of CVRF CSAF 1.2. So, IMHO it has been considered.... However, I agree that this was not used widely. Nevertheless, there were VEX documents published in CSAF by different companies telling that their products where not affected.

The TC is, most likely, implementing the work of the VEX subgroup in terms of the "not affected" part. The ongoing discussions are also part of this repo...

The assertion part, which was described by @rjb4standards, could be implemented in CSAF as a specific profile....

@rjb4standards
Copy link
Author

rjb4standards commented Feb 8, 2022 •
edited

@tschmidtb51 Thomas, just to be clear; the attestation requirements are coming from NIST and were not initiated by me. I was examining CSAF as a means to address the NIST attestation requirements, ref: https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/software-supply-chain-security-guidance-1

@tschmidtb51
Copy link
Contributor

@rjb4standards Thanks for the clarification.

@rjb4standards
Copy link
Author

I will be happy to add a new CSAF profile to the open-source Vulnerability Disclosure Report format, like I did for CDXVEX, if a CSAF solution is produced to answer the generic question:
What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level?

@tolim
Copy link
Contributor

tolim commented Feb 11, 2022

@rjb4standards, to your question:

Are there any known vulnerabilities in “Siemens/Industrial Edge Management OS (IEM-OS)/1.4.41”, before installing?

We are using our own internal content management system to produce the Siemens CSAF advisories. So the answer is at our fingertips, but it is not directly available to you due to the CSAF interface you are accessing. And this interface depends on the way how we group vulnerabilities and products in each published advisory. Depending on the use case (and the question asked), we could, at the extreme cases, produce one advisory per product (with all known vulnerabilities), or one advisory per vulnerability (with all known affected/unaffected products). However, the grouping is currently done in the 'traditional' way that is influenced by the vulnerability handling and advisory publication process inside the company.

So what is the best way now to group vulnerabilities and products when publishing advisories as vendor?
I think that we will never cover all possible use cases for consumers. So we could go into three directions:

  • Always publish advisories in multiple formats to cover the use cases in highest demand
  • Keep the advisories as they are and rely on external tools to structure the information as needed
  • Offer an API that allows consumer to define the required structure and download the vulnerability information

As we are coping with a quite complex ecosystem involving OSS creators, vendors, national CERTs as distributors, many different variants of users, etc., I think we need to gather some experience with CSAF/VEX/SBOMs before taking the next step. Please comment, I am looking forward to your opinions!

@rjb4standards
Copy link
Author

Tobias, thanks for providing these insights. You nailed it; we're dealing with a complex ecosystem.
I've focused squarely on the consumer side of the supply chain where questions like this are being asked:

What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level?

I looked at using CSAF VEX to answer this question and it became obvious that I would have to download every single VEX and examine the product/status materials to answer the question, which I determined was too inefficient and a better solution was needed. I developed the open-source SBOM Vulnerability Disclosure Report (SBOM VDR) to answer this one question that my customers as asking. SBOM VDR is like a CARFAX for SBOM, providing up to the second status, provided by a software vendor, of the vulnerability status associated with a specific SBOM. We are in the process of adding support for CycloneDX VEX to our vulnerability assessment step, which currently processes SBOM VDRs. We will also support whatever SPDX decides to use for vulnerability reporting, which is being discussed presently for the SPDX version 2.3 release. We will also support whatever CSAF produces to answer this question directly, without having to download every VEX that's been produced. I'm not bashing CSAF VEX, it's well engineered for the use case it supports, but it was not designed for the particular use case I'm working on.

@JasonKeirstead
Copy link

Not to sound like a broken record - but the issue here from my perspective, is not the CSAF format itself, it is how it is often being produced & level of detail contained. If it is indeed true that CSAF can not be used for VEX, then it also can't be used for PSIRT because the world is being mandated to evolve to have PSIRTs output SBOM+VEX. So there is an intrinsic issue here IMO

@rjb4standards
Copy link
Author

rjb4standards commented Feb 11, 2022 •
edited

@JasonKeirstead I found that CSAF VEX is effective and efficient at answering the question,

Given Vulnerability V, which products from Supplier S are known to be exploitable by V and which are not?

But not this question:

What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level?

I hope someone with deeper knowledge of CSAF VEX will confirm/correct this.

@JasonKeirstead
Copy link

@rjb4standards Aren't those the same information - just in the latter case you would query a database and output it?

IE this discussion to me is not about data formats it is about how you are querying the database.

@rjb4standards
Copy link
Author

@JasonKeirstead it's conceivable that a dynamically produced vulnerability report can be produced, as Tobias is already doing internally when a new vulnerability is reported. CSAF VEX, as it is currently being used today to report on product status per vulnerability event is not conducive to answering the second question. It appears the CycloneDX VEX is able to answer both questions and I'm anticipating that SPDX's solution, under development for V 2.3, will also be able answer both questions.

@rjb4standards
Copy link
Author

FYI: information on SPDX Version 2.3 is available here: https://github.com/spdx/meetings/blob/master/general/2022-02-03.md

@tolim
Copy link
Contributor

tolim commented Feb 11, 2022

What is the vulnerability status of product P, version V from Supplier S at time(t) at the SBOM component level?

This question can definitely be answered by CSAF: product P in version V and all its SBOM components are listed as individual full product names with their corresponding relationship (e.g. "default_component_of"). The document then references from one or multiple vulnerabilities with product status 'known_affected' to the components.
If a listed component is not affected by any known vulnerability, we have multiple options: no reference from any vulnerability to that component (note: this would not adhere to profile VEX but to other CSAF profiles), or references from all listed vulnerabilities using product status 'known_not_affected'.

@sparrell
Copy link

sparrell commented Feb 11, 2022 via email

@rjb4standards
Copy link
Author

rjb4standards commented Feb 11, 2022 •
edited

@tolim I agree with this conclusion: (note: this would not adhere to profile VEX but to other CSAF profiles), I'll add the CSAF profile that answers the second question to the list of options for vulnerability reporting to the open-source vendor response file (VRF) option for vulnerability reporting, and will code in support for this method within SAG-PM.

@rjb4standards
Copy link
Author

rjb4standards commented Feb 11, 2022 •
edited

@sparrell I refer you to @tolim to provide the clarity you seek: #407 (comment)

The Siemens product was provided as an example and is not contained as a specific item in NIST documents. Perhaps I should have been clearer to indicate that the question I was posing is simply an example of the question people are beginning to ask. My apologies for the confusion.

@rjb4standards
Copy link
Author

FYI: for those interested, I was able to create a CDX VEX with the help of Steve Springett; an example is provided here, for those interested in seeing what a CDX VEX looks like:
https://github.com/rjb4standards/REA-Products/tree/master/CDXVEX

@tschmidtb51
Copy link
Contributor

@rjb4standards Sorry for the long radio silence. It was on my list but I wasn't able to reply earlier.

Please find an excerpt for the CSAF VEX below (it just lists the first 2 vulnerabilities to avoid a long blob here but still show the example):

{
  "document": {
    "category": "csaf_vex",
    "csaf_version": "2.0",
    "notes": [
      {
        "category": "other",
        "text": "This artifact answers the question: What is the vulnerability status of product P, version V from Supplier S at time(NOW) at the SBOM component level?",
        "title": "Author comment"
      }
    ],
    "publisher": {
      "category": "other",
      "contact_details": "dick@reliableenergyanalytics.com",
      "name": "Reliable Energy Analytics LLC",
      "namespace": "https://reliableenergyanalytics.com"
    },
    "title": "\"CARFAX\" example",
    "tracking": {
      "current_release_date": "2022-03-21T11:00:00.000Z",
      "generator": {
        "date": "2022-03-21T10:27:46.866Z",
        "engine": {
          "name": "Secvisogram",
          "version": "1.12.1"
        }
      },
      "id": "REA-2022-0001",
      "initial_release_date": "2022-02-21T21:46:00.000Z",
      "revision_history": [
        {
          "date": "2022-02-21T21:46:00.000Z",
          "number": "1",
          "summary": "Initial version."
        },
        {
          "date": "2022-03-21T11:00:00.000Z",
          "number": "2",
          "summary": "CSAF version."
        }
      ],
      "status": "final",
      "version": "2"
    }
  },
  "product_tree": {
    "branches": [
      {
        "branches": [
          {
            "branches": [
              {
                "category": "product_version",
                "name": "1.1.8",
                "product": {
                  "name": "Reliable Energy Analytics LLC SAG-PM (TM) 1.1.8",
                  "product_id": "CSAFPID-0001"
                }
              }
            ],
            "category": "product_name",
            "name": "SAG-PM (TM)"
          }
        ],
        "category": "vendor",
        "name": "Reliable Energy Analytics LLC"
      }
    ],
    "full_product_names": [
      {
        "name": "cryptography 3.3.1",
        "product_id": "CSAFPID-0002"
      },
      {
        "name": "idna 2.10",
        "product_id": "CSAFPID-0003"
      }
    ]
  },
  "vulnerabilities": [
    {
      "cve": "CVE-2020-36242",
      "cwe": {
        "id": "CWE-787",
        "name": "Out-of-bounds Write"
      },
      "flags": [
        {
          "date": "2021-07-21T00:00:00.000Z",
          "label": "vulnerable_code_not_in_execute_path",
          "product_ids": [
            "CSAFPID-0001"
          ]
        }
      ],
      "notes": [
        {
          "category": "description",
          "text": "In the cryptography package before 3.3.2 for Python, certain sequences of update calls to symmetrically encrypt multi-GB values could result in an integer overflow and buffer overflow, as demonstrated by the Fernet class."
        }
      ],
      "product_status": {
        "known_not_affected": [
          "CSAFPID-0001"
        ]
      },
      "references": [
        {
          "summary": "NVD - CVE-2020-36242",
          "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36242"
        }
      ],
      "scores": [
        {
          "cvss_v3": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.1,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
            "version": "3.1"
          },
          "products": [
            "CSAFPID-0002"
          ]
        }
      ],
      "threats": [
        {
          "category": "impact",
          "details": "This vulnerability is exploited during file encryption. SAG-PM does not perform file encryption using this component and is most likely not vulnerable to this CVE.",
          "product_ids": [
            "CSAFPID-0001"
          ]
        }
      ]
    },
    {
      "cve": "CVE-2014-8564",
      "cwe": {
        "id": "CWE-787",
        "name": "Out-of-bounds Write"
      },
      "flags": [
        {
          "date": "2022-02-21T00:00:00.000Z",
          "label": "vulnerable_code_not_in_execute_path"
        }
      ],
      "notes": [
        {
          "category": "description",
          "text": "The _gnutls_ecc_ansi_x963_export function in gnutls_ecc.c in GnuTLS 3.x before 3.1.28, 3.2.x before 3.2.20, and 3.3.x before 3.3.10 allows remote attackers to cause a denial of service (out-of-bounds write) via a crafted (1) Elliptic Curve Cryptography (ECC) certificate or (2) certificate signing requests (CSR), related to generating key IDs."
        }
      ],
      "product_status": {
        "known_not_affected": [
          "CSAFPID-0001"
        ]
      },
      "references": [
        {
          "summary": "NVD - CVE-2014-8564",
          "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-8564"
        }
      ],
      "scores": [
        {
          "cvss_v2": {
            "baseScore": 5,
            "vectorString": "AV:N/AC:L/Au:N/C:N/I:N/A:P",
            "version": "2.0"
          },
          "products": [
            "CSAFPID-0003"
          ]
        }
      ],
      "threats": [
        {
          "category": "impact",
          "details": "This vulnerability is exploited when Elliptic curve certificates are used. SAG-PM does not perform any elliptic curve certificate functions from this component and is most likely not vulnerable to this CVE.",
          "product_ids": [
            "CSAFPID-0001"
          ]
        }
      ]
    }
    // ...
  ]
}

@tschmidtb51
Copy link
Contributor

tschmidtb51 commented Mar 21, 2022 •
edited

When using the product_identification_helper CSAF provides, you can identify each single component in an SBOM. For the example, if you want to identify the jboss-logging library which is used in Keycloak 10.0.2 you could use the following product_tree in CSAF:

  "product_tree": {
    "branches": [
      {
        "category": "vendor",
        "name": "Keycloak",
        "branches": [
          {
            "category": "product_name",
            "name": "Keycloak",
            "branches": [
              {
                "category": "product_version",
                "name": "10.0.2",
                "product": {
                  "product_id": "CSAFPID-0001",
                  "name": "Keycloak Keycloak 10.0.2",
                  "product_identification_helper": {
                    "sbom_urls": [
                      "https://raw.githubusercontent.com/CycloneDX/bom-examples/master/SBOM/keycloak-10.0.2/bom.json"
                    ],
                    "x_generic_uris": [
                      {
                        "namespace": "https://cyclonedx.org/docs/1.4/json/#serialNumber",
                        "uri": "urn:uuid:411dafd2-c29f-491a-97d7-e97de5bc2289"
                      }
                    ]
                  }
                }
              }
            ]
          }
        ]
      }
    ],
    "full_product_names": [
      {
        "product_id": "CSAFPID-0002",
        "name": "jboss-logging",
        "product_identification_helper": {
          "x_generic_uris": [
            {
              "namespace": "https://cyclonedx.org/capabilities/bomlink/",
              "uri": "urn:cdx:411dafd2-c29f-491a-97d7-e97de5bc2289/1#pkg:maven/org.jboss.logging/jboss-logging@3.4.1.Final?type=jar"
            }
          ]
        }
      }
    ]
  }

This allows you to reference each component from the SBOM.

Note: You could also use relationships in CSAF. A profile would define the way which would be preferred.

This example is just for CycloneDX. However, each format has its own way to uniquely identify the SBOM (in this case the serialNumber + version) and a component within (bom-ref).

Edit: I updated the example to conform with the CSAF spec. sbom_urls should only be used for downloadable SBOMs. To identify components, x_generic_uris are the right place.

@tschmidtb51
Copy link
Contributor

tschmidtb51 commented Mar 21, 2022 •
edited

@rjb4standards To answer your question: Yes, CSAF can answer that question. (However, you probably have to ask specifically for that format as it is not published by vendors today - or generate it yourself and sell it to your customers ;-)).

A profile in CSAF could be defined as follows (just a rough draft - details could be discussed):

4.X Profile X: SBOM CARFAX

This profile SHOULD be used to answer the question: "What is the vulnerability status of product P, version V from Supplier S at time(NOW) at the SBOM component level?"

A CSAF document SHALL fulfill the following requirements to satisfy the profile "SBOM CARFAX":

  • The following elements MUST exist and be valid:
    • all elements required by the profile "CSAF Base".
    • /product_tree which lists all products referenced later on in the CSAF document regardless of their state.
    • for the primary component: contain a product_identification_helper/x_generic_uris element that uniquely references the SBOM this document is for
    • for each element of type full_product_name_t: contain a product_identification_helper/x_generic_uris element referencing that element in the SBOM of the primary component
    • at least one of
      • /vulnerabilities[]/product_status/fixed
      • /vulnerabilities[]/product_status/known_affected
      • /vulnerabilities[]/product_status/known_not_affected
      • /vulnerabilities[]/product_status/under_investigation
    • /vulnerabilities[]/cve
    • /vulnerabilities[]/notes

      Provides details about the vulnerability.

  • For each item in
    • /vulnerabilities[]/product_status/known_not_affected an analysis result SHALL exist as machine readable flag in /vulnerabilities[]/flags and as human readable justification in /vulnerabilities[]/threats. For the latter one, the category value for such a statement MUST be impact and the details field SHALL contain a a description why the vulnerability cannot be exploited.
    • /vulnerabilities[]/product_status/known_affected additional product specific information SHALL be provided in /vulnerabilities[]/remediations as an action statement. Optional, additional information MAY also be provide through /vulnerabilities[]/notes and /vulnerabilities[]/threats.

      The use of the categories no_fix_planned and none_available for an action statement is permitted.

    Even though Product status lists Product IDs, Product Group IDs can be used in the remediations and threats object. However, it MUST be ensured that for each Product ID the required information according to its product status as stated in the two points above is available. This implies that all products with the status known_not_affected MUST have an impact statement and all products with the status known_affected MUST have additional product specific information regardless of whether that is referenced through the Product ID or a Product Group ID.

  • The value of /document/category SHALL be sbom_carfax.
  • Each component in the SBOM that has a CVE ID MUST be listed in the product_tree and the corresponding CVE ID MUST be given in the /vulnerabilities section together with the product_status and analysis result.

Notes:

  • I cut of the /vulnerabilities[]/ids as I understood that SBOM Carfax just supports CVE-IDs not other known vulnerabilities (as VEX).

@tschmidtb51 tschmidtb51 mentioned this issue Mar 23, 2022
Closed
@rjb4standards
Copy link
Author

rjb4standards commented Jul 15, 2022 via email

@JasonKeirstead
Copy link

JasonKeirstead commented Jul 18, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@mprpic @sparrell @rjb4standards @JasonKeirstead @tolim @tschmidtb51