All committers have signed the CLA.

@SealSagish i found one problem with affected[].ranges[].events in feed file.
let's look on seal-cups/CVE-2023-32360.json:

  "affected": [
    {
      "package": {
        "ecosystem": "redhat:8",
        "name": "seal-cups"
      },
      "ranges": [
        {
          "type": "ECOSYSTEM",
          "events": [
            {
              "fixed": "1:2.3.3op2-16.el9+sp2"
            },
            {
              "introduced": "1:2.3.3op2-16.el9"
            }
          ]
        }
      ],
      "database_specific": {
        "type": "RPM"
      }
    },

events are in reverse order (and we get error in trivy-db parsing).
docs say: These events objects represent a “timeline” of status changes for the affected package..
So correctly "timeline is :found bug(introduced) ->fix bug` (fixed).
for this case:

          "events": [
            {
              "introduced": "1:2.3.3op2-16.el9"
            },
            {
              "fixed": "1:2.3.3op2-16.el9+sp2"
            }

can you take a look?
perhaps other files have similar issue

For example, if the ecosystem is Red Hat, it must be Red Hat:<CPE> as defined here.
Currently, the OSV advisories distributed by Seal Security do not seem to follow the OSV specification for other ecosystems either (cbl-mariner, Oracle Linux, etc.).

In that case, wouldn’t it make more sense to define a custom ecosystem like Seal and then define the ecosystem however you like, such as Seal:Red Hat:7 instead? What do you think?

As for the ecosystems, I think changing the advisory to adhere the OSV conventions will be a better choice here. I don't see much benefit to adding the Seal: prefix to our ecosystems because we already look at the scope of Seal.
I see 2 paths forward for the advisory from here.
We can either

1. list ecosystems in the advisory according to our own DB structure with a seal modifier to distinguish it, although, we dump the files into the seal/ directory and so we have a complete context of being seal.
2. Change the listed ecosystems in our advisory to fit OSV's schema to make a fully OSV compatible advisory.

I lean towards the second option myself. What do you think?

There are two problems with the second way:

• You need to use the Red Hat product stream in CPE. So you need to use a specific product (e.g. rhel_aus / enterprise_linux / etc.). You can't just use RedHat:8.
• You still need to add other Red Hat–based images into the OSV system.

Instead of handling the case with CPE and creating multiple PRs, @knqyf263 suggested to create one new seal ecosystem (with one PR) with your specific format for each base ecosystem (Red Hat, Ubuntu, etc.).

Yes, as @DmitriyLewen mentioned, the current OSV specification may not fit Seal Security’s use case (Red Hat is one such example). Moreover, proposing undefined ecosystems such as CBL-Mariner to the OSV community through PRs takes time. If you define your own format without properly aligning with the existing one (e.g., cbl-mariner:1), it may eventually require breaking changes in the future after OSV defines the ecosystem in a different way.

On the other hand, if it is Seal’s own ecosystem, you are free to decide the format. In fact, a company called Echo has already added theirs to OSV.
ossf/osv-schema#394

We talked internally and decided to create proprietary ecosystems in the advisory
E.g -
currently - seal-cups or version 1:2.3.3op2-16.el9 has the following ecosystems - cbl-mariner:2.0, Oracle Linux:6, redhat:7, redhat:8...

We plan on changing that to a single ecosystem - Seal:Red Hat:9 according to the el version of the package.

Similarly, debian/ubuntu and alpine linux will get the Seal:Debian and Seal:Alpine ecosystems.

Great!
When you have the new ecosystems ready, let us know and I’ll update the logic in Trivy-db PR.

Hey @DmitriyLewen, I updated our advisory and the test data to contain the new ecosystems as discussed

what is the license of that data?

The advisory data is MIT license

Hi @DmitriyLewen. Do you have an estimate of when we can continue with the review?

@SealSagish This PR looks good to me
I am currently testing and updating related PRs (trivy and trivy-db) to make sure we didn’t miss anything.

UPD:
Also you need to sign CLA - #364 (comment)

Hello @SealSagish
I found that the feed doesn't have Red Hat 8 advisories:

➜ grep -rh "Red Hat" | sort -u                          
        "ecosystem": "Seal:Red Hat:6",
        "ecosystem": "Seal:Red Hat:7",
        "ecosystem": "Seal:Red Hat:9",

Is this expected?

Hello @SealSagish I found that the feed doesn't have Red Hat 8 advisories:

➜ grep -rh "Red Hat" | sort -u                          
        "ecosystem": "Seal:Red Hat:6",
        "ecosystem": "Seal:Red Hat:7",
        "ecosystem": "Seal:Red Hat:9",

Is this expected?

This is expected, as of now all our EL8 libraries are fully sealed (no vulns). In the future, as new vulnerabilities will be discovered for those and other seal built libraries, it will be added automatically.

@SealSagish This PR looks good to me I am currently testing and updating related PRs (trivy and trivy-db) to make sure we didn’t miss anything.

UPD: Also you need to sign CLA - #364 (comment)

Signed

@SealSagish can you fix linter errors?

I'm currently reviewing PRs. Please wait a moment.