Red hat is working around evolving errata as explained in The future of Red Hat security data. To summarize:

• OVAL v1 was deprecated in mid-2023
• OVAL v2 will continue until the end of 2024 - but el8 and el9 ovals will continue receiving advisories until EOL
• CVRF was replaced with CSAF (VEX formatted files), see this blog post
• Introduction of VEX formatted files per CVE, see this blog post

Our (short) tentative plan, and assuming that we're not generating CSAFs for now, we need to:

• Start pulling information from Red Hat errata website
• Since OVAL cacher is passing away, our new service needs to ensure that:
  • The payload data is sent over to API in the same (or similar) way
  • The DB/API should not need any adjustments (only errata_type if we're also bringing non-security advisories)
  • If we need to pull things from both sides (website and security data API), all the logic must live in the service
  • Given that we'll no longer getting OVALs, generate required OVAL-specific data before sending over to web_server. Take special attention to "modular erratas"
• When we're sending everything right from the new service, and before OVAL is finally deprecated, we must ensure that inserting erratas from both OVAL cacher and the new service results in the same data in DB. This way, we ensure that all our errata data is as consistent as it is now, this is: db, pulp, resulting errata generated data (updateinfo, OVAL, errata.json, etc)

When security advisories processing is already working, we also want to start pulling non-security advisories from red hat errata website. This involves:

• Adding a switch in public-errata-parser so non-security erratas are also processed and sent to web server
• Adding a is_security field to NewErrataParser
• Non-security erratas should be treated exactly the same as security ones, with the exception that non-security erratas won't be included in AlmaLinux OVAL. We can make use of the is_security field to filter non-security records