API design and use case scenarios for VulnerableCode

[sbs2001]

I want to know all possible ways, VulnerableCode will be utilised, so we can start coming up an API design for the REST API.

[haikoschol]

For a list (or tree) of dependencies, expressed as Package URLs, return a list of vulnerabilities (and pointers to further information) that affect those dependencies.

[sbs2001]

For a list (or tree) of dependencies, expressed as Package URLs, return a list of vulnerabilities (and pointers to further information) that affect those dependencies.

That makes sense, a SBOM utility like cyclonedx can directly query for vulnerability status.

My question is should a single request contain a list of purls or require multiple requests each containing a distinct purl ? Both of these approaches will get the job done in this scenario.

[sbs2001]

Add a cve-search except it won't be limited to CVEs, various advisory ids like RHSA should be searchable
check #9 .

[haikoschol]

For a list (or tree) of dependencies, expressed as Package URLs, return a list of vulnerabilities (and pointers to further information) that affect those dependencies.

My question is should a single request contain a list of purls or require multiple requests each containing a distinct purl ? Both of these approaches will get the job done in this scenario.

I don't have a strong opinion on this and would go with whatever is easier to implement.

[sbs2001]

@haikoschol @pombredanne how does this look ?

The endpoint would be api/packages/

The parameters would be our regular purl's field

for example the response for api/packages/?name=openssl&version=1.1.0j&type=generic would be.

   {
            "package_url": "pkg:generic/openssl@1.1.0j",
            "vulnerable_to": [
                {
                    "vulnerability": "CVE-2019-1552"
                },
                {
                    "vulnerability": "CVE-2019-1563"
                },
                {
                    "vulnerability": "CVE-2019-1547"
                },
                {
                    "vulnerability": "CVE-2019-1543"
                }
            ],
            "resolved_to": [
                {
                    "vulnerability": "CVE-2018-0734"
                },
                {
                    "vulnerability": "CVE-2018-0735"
                }
            ]
        }
    ]

We could add a hyperlink to the view which has details of the vulnerability

[pombredanne]

I am sure we can find a better name than "resolved_to" and "vulnerable_to" somehow that does not feel evident as names...
Also why not exposing first and mostly a purl rather than the purl fields?

[sbs2001]

@pombredanne

I am sure we can find a better name than "resolved_to" and "vulnerable_to"

Consider them as placeholders for now.

Also why not exposing first and mostly a purl rather than the purl fields?

That works too, are there any pros and cons of using one over another?

[pombredanne]

That works too, are there any pros and cons of using one over another?

a purl has been designed as a single simple string... exposing its parts is fine for query but that would not be the primary entry point IMHO

[sbs2001]

@pombredanne

I'm torn between the 2 options of using string vs fields for a purl.

exposing its parts is fine for query but that would not be the primary entry point IMHO

How about wrapping the fields like this

 {
            "package": {
                              "name": "openssl",
                              "type": "generic",
                              "namspace": null,
                              "version":"1.1.0j" ,
                              "package_url": "pkg:generic/openssl@1.1.0j",....
                              },
            
            "vulnerable_to": [
                {
                    "vulnerability": "CVE-2019-1552"
                },
                {
                    "vulnerability": "CVE-2019-1563"
                },
                {
                    "vulnerability": "CVE-2019-1547"
                },
                {
                    "vulnerability": "CVE-2019-1543"
                }
            ],
            "resolved_to": [
                {
                    "vulnerability": "CVE-2018-0734"
                },
                {
                    "vulnerability": "CVE-2018-0735"
                }
            ]
        }
    ]

[sbs2001]

I'm pretty sure the endpoint is wrong. We are getting packages + vulnerabilities , the url should denote that

[sbs2001]

The vulnerability-package search would give response like

[
    {
        "package":{

            "name": "foo",
            "type": "deb",
            "version": "bar",
            "namespace": "ubuntu",
            "packageurl": "pkg:deb/ubuntu/foo@bar"
        },

        "vulnerabilities":[
            {
                "cve_id": "CVE-2002-1568",
                "href": "/vulnerabilities/1"
            }

            {
                "cve_id": "CVE-2002-1569",
                "href": "/vulnerabilities/2"
            }

        ]
    },

    {
        "package":{
            
            "name": "tar",
            "type": "deb",
            "version": "ball",
            "namespace": null,
            "packageurl": "pkg:deb/foo@bar"
        },

        "vulnerabilities":[
            {
                "cve_id": "CVE-2002-1578",
                "href": "/vulnerabilities/17"
            }

            {
                "cve_id": "CVE-2002-1579",
                "href": "/vulnerabilities/3"
            }

        ]
    }
]