dloez / kerberus Goto Github PK

If OSV returns that a dependency has a vulnerability with a version that fixes that vulnerability, store the versions that fixes the vulnerability on the dependencyvulnerability model used to link dependencies and vulnerabilities.

The web application should be able to list project dependencies obtained from /projects/1/dependencies.

We need to retrieve the level of each vulnerability from OSV, this should be done in the collect_vulnerabilities Huey task.
Also, calculate the number of each vulnerability levels and the total so we can serve that data without needing to recalculate it once again for each serve.

To implement the collection of vulnerabilities using OSV, we need to:

• Implement Huey in Django
• Get vulnerabilities from OSV
• Create vulnerabilities model
• Create a relationship between vulnerabilities and dependencies
• #4
• #20
• #26
• #27
• #28
• Schedule periodic executions of Huey task to collect vulnerabilities
• Check performance

Additional issues related to vulnerabilities:

• #19

The OSV query to get vulnerabilities from NPM dependencies is not getting its vulnerabilities. This can be reproduced by triggering the collect of vulnerabilities with the NPM dependencies created by the command create_ingest.

1. Delete all linked vulnerabilities from the dependency.
2. Check if the vulnerability exists in database.
3. If it exists, create a relationship with the dependency with fixed versions.
4. if it does not exist, create vulnerability and a relationship between dependency and vulnerability with fixed versions.

Create commands to:

• Create project by given name
• Add x amount of dependencies to given project

Similar to /projects/{id}/dependencies, create:

• /projects/{id}/vulnerabilities

[
  {
    "osv_id": "string",
    "cve_id": "string",
    "severity_overall_score": "float",
    "severity_overall_score_string": "string",
    "fix_available": "boolean"
  }
]

• /projects/{id}/vulnerabilities/{id}

{
  "osv_id": "string",
  "cve_id": "string",
  "severity_overall_score": "float",
  "severity_overall_score_string": "string",
  "affected_project_dependencies": [
    {
      "name": "string",
      "version": "string",
      "ecosystem": "string",
      "fixed_versions": ["string"]
    }
  ]
}

• /projects/{id}/dependencies/{id}/vulnerabilities

[
  {
    "osv_id": "string",
    "cve_id": "string",
    "severity_overall_score": "float",
    "severity_overall_score_string": "string",
    "fixed_versions": ["string"]
  }
]

Currently, the behavior of collect_vulnerabilities Huey task, can cause to have vulnerabilities with no linked dependencies which should be deleted from the database. The task should also be periodically scheduled.

Check #26
The total amount of vulnerabilities needs to be pre populated.

Current behaviour when merging using devcontainers on vscode:

Currently the create_ingest creates not real dependencies that will not be useful for testing purposes, we need to have real dependencies that can be queried on OSV for vulnerabilities. Maybe just a few real ones can be added just to get some real vulnerabilities?

When a new issue is created, it needs to be labeled with "needs triage". The label "needs-triage" is set until a contributor analyses the issue and assigns the correct labels. If the issue is about a feature that will not be worked on in the near future, the "wontfix" issue would be assigned and the issue would be closed, avoiding the issue being kept in the project workflow.
When an issue is labeled with "needs triage", we need to assign it the status "New" in the project "Kerberus". The issue will be then analyzed and assigned with the correct labels, then it could be moved into the "Backlog" status where the issue can be designed, estimated, assigned, etc before being moved into "Ready". Issues would then be moved into "In Progress" when they are being developed, "In review" during testing and "Done" after the issues have been tested and merged.
PRs can also follow the above workflow.

Tasks that needs to be done to be able to use this workflow:

• Automatically assign "needs triage" label to new issues
• Issues assigned with the "needs triage" label need to be added to the project with the "New" status
• Check labels and project status

When calling /projects/summary the id is missing.

Bazel is reporting that the cargo-bazel-lock.json file is not updated. This can be fixed by running bazel with CARGO_BAZEL_REPIN=true and pushing the updated cargo-bazel-lock.json.

This could be documented on CLI README and referenced on the general README.