Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-18570

Automated-(ish) CVE status reporting

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • None
    • Documentation
    • None

      We're getting more and more requests for info about whether various CVEs affect WildFly, driven by various vulnerability scanners. We want to be responsive to these queries, but it's taking an increasing amount of time.

      It would be good if on wildfly.org we had a page that showed data that we knew about, as pointing to that could be a good part of any response (and can save us time re-researching things.)

      Things to report:

      CVE # with link if available
      Status – one of "Open", "Resolved", "Closed", "Won't Fix" or "Invalid"
      WFLY or WFCORE JIRA link for Resolved or Closed; maybe for "Won't Fix"
      Fix Version(s) for Resolved or Closed
      Notes – free form text

      Resolve vs Closed refer to the JIRA issue status. "Invalid" we could use for cases where scanners are misidentifying our component as matching a CPE, which is definitely a thing. We might record some of those cases to avoid having to repeatedly explain.

      I don't think we can drive this from JIRA itself (i.e. some label or special issue title format to describe a CVE.) We should however use the JIRA REST API for determining Fix Version info.

      I'm thinking the CVE, CVE link, Status, JIRA link data can be kept in a YAML file in the wildfly and wildfly-core repos. Then maybe a github action in the wildfly.org repo to periodically grab that data and if it's changed massage it into a file in the _data dir and push up a PR to update the site. Use a Jekyll layout/include to produce the html page on the site.

      We'd primarily update these yaml files as part of PRs that resolve the vulnerabilities, or when we learn of something and open issues, determine we won't fix things, or just do some research about already fixed things in response to one of these user queries. Any web page should have caveats about no guarantees about this information, that it is not a complete listing, please advise if you see anything incorrect, etc.

      I've gotten into 'how' quite a bit above but there certainly may be other ways. In general:

      1) I think wildfly.org is the best place to publish.
      2) I think complete automation is not feasible.
      3) I think the wildfly and wildfly.core repos are the place to manually record data so updates can become part of PRs that fix things.
      4) I want the part that gets the data from wildfly / wildfly-core up onto the web site to be automated except for merging a PR.

      5) Jira links are manually recorded, but once added information like Fix Version should be pulled via automation.

      EDIT: I added item 5) just above

            rchakrab Ranabir Chakraborty
            bstansbe@redhat.com Brian Stansberry
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: