You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The endpoints enlisted have a maximum response limit. The /search endpoint has the highest upper response limit of 100 while others have only 8. A humongous 450789 advisories are listed separated with pagination, and considering the maximum response limit to be 100, a huge number(nearly 4.5k) of API calls will have to be made(huge network overhead) in order to fetch all the advisories.
How shall we proceed with this importer considering this constraint? Should we use a suitable alternative source?
Hey @Samk1710, we need to clarify the time frame for the rate limit first (e.g., is it 100 requests per minute, per hour, or per day?). We should also avoid using the search endpoint. The main task is to iterate over the advisories and ingest the data into our database. (The network API calls aren’t a problem, but we should use them wisely.)
If we have a better alternative source that provides the same data with appropriate license, we should use it
Hey @ziadhany
To fetch all the advisories from the EUVD dataset we would need to iterate over the /search endpoint about 4,500 times (using size=100, which is the max response limit) during the initial run of the importer.After that, we can switch to an incremental approach with far fewer calls.
The date based incremental approach would be:
--Track when we last fetched advisories (last_fetched_date).
--On each run, query the API for records published or updated after that date.
--Process them, then update last_fetched_date
We can expect the initial ingestion to take roughly 3-5 hours, and then regular incremental imports going forward.
Do let me know about your thoughts on this. Thanks a lot!
I don't think we need last_fetched_date. The importer can simply run and pull all the data by iterating over the /search endpoint with fromDate/toDate (or fromUpdatedDate/toUpdatedDate). No switching is necessary, if we can fetch everything each time the importer runs.
There is a major issue to consolidate the advisories into AffcetedPackage especially because the Enisa feed has no unified or structured versioning in "product_version" field.
Activity
ziadhany commentedon May 14, 2025
EUVD API Documentation: https://euvd.enisa.europa.eu/apidoc
Samk1710 commentedon Nov 17, 2025
Can I take up this issue?
ziadhany commentedon Nov 17, 2025
@Samk1710 Yes, sure, you can start working on that.
Samk1710 commentedon Nov 18, 2025
The endpoints enlisted have a maximum response limit. The /search endpoint has the highest upper response limit of 100 while others have only 8. A humongous 450789 advisories are listed separated with pagination, and considering the maximum response limit to be 100, a huge number(nearly 4.5k) of API calls will have to be made(huge network overhead) in order to fetch all the advisories.
How shall we proceed with this importer considering this constraint? Should we use a suitable alternative source?
Do let me know. Thank you.
ziadhany commentedon Nov 19, 2025
Hey @Samk1710, we need to clarify the time frame for the rate limit first (e.g., is it 100 requests per minute, per hour, or per day?). We should also avoid using the search endpoint. The main task is to iterate over the advisories and ingest the data into our database. (The network API calls aren’t a problem, but we should use them wisely.)
If we have a better alternative source that provides the same data with appropriate license, we should use it
Samk1710 commentedon Nov 21, 2025
Hey @ziadhany
To fetch all the advisories from the EUVD dataset we would need to iterate over the /search endpoint about 4,500 times (using size=100, which is the max response limit) during the initial run of the importer.After that, we can switch to an incremental approach with far fewer calls.
The date based incremental approach would be:
--Track when we last fetched advisories (last_fetched_date).
--On each run, query the API for records published or updated after that date.
--Process them, then update last_fetched_date
We can expect the initial ingestion to take roughly 3-5 hours, and then regular incremental imports going forward.
Do let me know about your thoughts on this. Thanks a lot!
ziadhany commentedon Nov 22, 2025
@Samk1710
I don't think we need
last_fetched_date. The importer can simply run and pull all the data by iterating over the /search endpoint withfromDate/toDate(orfromUpdatedDate/toUpdatedDate). No switching is necessary, if we can fetch everything each time the importer runs.https://euvdservices.enisa.europa.eu/api/search?fromDate=2023-01-14&toDate=2023-02-14&page=1&size=100
https://euvdservices.enisa.europa.eu/api/search?fromDate=2023-01-14&toDate=2023-02-14&page=2&size=100
Samk1710 commentedon Nov 25, 2025
Hey @ziadhany @AyanSinhaMahapatra
Could we gather any updates on the license of EUVD?
Samk1710 commentedon Nov 26, 2025
#2046
Hey, I've raised a PR. Would look forward to review and improvements. Thank you!
Samk1710 commentedon Apr 28, 2026
Currently we have a mirror repo at https://github.com/aboutcode-org/aboutcode-mirror-euvd
There is a major issue to consolidate the advisories into AffcetedPackage especially because the Enisa feed has no unified or structured versioning in
"product_version"field.See the advisories below:
Due to this major inconsistency, it becomes quite difficult to parse and map these to a PURL.