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
Within the url-updates module we should create a process that uses owasp-dependecy-check library to download and access the CVE database. Once the database is available and up-to-date, it will search for all our tools (via UrlUpdaters - maybe via an extra Interface) for CVEs and generate according security.json files.
If step 1. fails (e.g. due to rate limiting) we might to continue on the next run/day.
Mainly this should only be a problem to initially build up the entire CVE DB.
Once it is up-to-date, it will be synchronized every night so only few data/updates need to be downloaded.
Ideally, we have a hash or version or date of the CVE DB state.
Then step 2. can build the result of that hash/version/date.
If the other day step 1. gets no update and we still have the same hash/version/date, we can skip 2. since there is nothing to do (unless a new Tool/URL Updater was added to the codebase).
The text was updated successfully, but these errors were encountered:
hohwille
changed the title
create a new GitHubAction managing security.json files in ide-urls repo
CVE: create a new GitHubAction managing security.json files in ide-urls repo
Mar 26, 2025
Within the
url-updates
module we should create a process that usesowasp-dependecy-check
library to download and access the CVE database. Once the database is available and up-to-date, it will search for all our tools (via UrlUpdaters - maybe via an extra Interface) for CVEs and generate accordingsecurity.json
files.A new GitHubAction workflow will be created that runs this process every night.
It needs to keep the CVE database cached (see e.g. https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows#using-the-cache-action) so it is not lost and rebuild every night so the process will never succeed.
Further the process needs to be build robust:
security.json
filesIf step 1. fails (e.g. due to rate limiting) we might to continue on the next run/day.
Mainly this should only be a problem to initially build up the entire CVE DB.
Once it is up-to-date, it will be synchronized every night so only few data/updates need to be downloaded.
Ideally, we have a hash or version or date of the CVE DB state.
Then step 2. can build the result of that hash/version/date.
If the other day step 1. gets no update and we still have the same hash/version/date, we can skip 2. since there is nothing to do (unless a new Tool/URL Updater was added to the codebase).
The text was updated successfully, but these errors were encountered: