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.

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

Vulnerabilities do not have "title", "published", "modified" fields #410

Closed
carlosthe19916 opened this issue Jun 17, 2024 · 5 comments
Closed

Comments

@carlosthe19916
Copy link
Member

carlosthe19916 commented Jun 17, 2024

Similar to #280

For each Vulnerability obtained through GET /api/v1/vulnerability there should be metadata that help users to understand the context of each element. E.g. title, date published, date modified.

image

@ctron
Copy link
Contributor

ctron commented Jun 26, 2024

It looks like the reason for this is:

let vulnerability = self.graph.ingest_vulnerability(identifier, (), &tx).await?;

When no "vulnerability" is found, then a new one will be created, but without any information.

@ctron
Copy link
Contributor

ctron commented Jun 26, 2024

Digging into this issue the situation seems as follows:

  • Ingesting any source, like CSAF, will result in "vulnerabilities in the context of an advisory" to have a title and additional information
  • If no "vulnerability" itself exists, it will create one, but leave the other information empty
  • When the "CVE" importer runs, that information is taken (creates or fills in) this information

So running the CSAF importer and the CVE importer is required. To my understanding, the order is not important.

@carlosthe19916
Copy link
Member Author

IMO these are the problems:

  • I am sure I ran the "cve" importer and the "csaf" importer and yet I saw no new data available title|published|modified in the /api/v1/vulnerability endpoint. I do not have a reliable way (step1, step2, stepN) to make the required data appear
  • If So running the CSAF importer and the CVE importer is required is true. Then I strongly believe we should rethink/reformulate the definition of a importer. An importer should be self sufficient. I feel that this is a broader discussion than the title of this issue and can be discussed separately

@carlosthe19916
Copy link
Member Author

I might be missing something but this is still an unsolved issue

@carlosthe19916
Copy link
Member Author

Closing this in favor of #626

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants