nix-security-tracker
nix-security-tracker copied to clipboard
Nix-Security-WG
Web service for managing information on vulnerabilities in software distributed through Nixpkgs
In addition to #8, it seems clear that we cannot pass the opportunity to grab the treasure of information that is `env` inside of a derivation. It contains the following...
- [ ] Cron for ingesting the bulk CVE - [ ] Cron for cloning nixpkgs somewhere and maintaining up-to-date?
This is easier for an overview, don't have to click through.
Required for https://github.com/Nix-Security-WG/nix-local-security-scanner/issues/51 In CVEs the data could look something like this: ```json "metrics": [ { "other": { "content": { "text": "low" }, "type": "Textual description of severity" } },...
The package is https://github.com/westes/flex , but the advisory is for https://flex.apache.org/ (cpe `cpe:2.3:a:apache:flex:*:*:*:*:*:*:*:*`) Here, looking at the pname seems insufficient to reliably match the package. Possible solution: #136
Repology records CPE bindings (https://repology.org/security/recent-cpes), which could for example tell us that CVE-2015-1773 should be associated with `apache-flex-sdk` instead of with the `flex` lexer generator
Possible ideas to improve local tool performance include: * #118 * #117 * #132 * #131
Instead of placing it on disk as 231006 files, we might want to cache a 'processed' blob in a single file. This might be faster to ingest. Format could range...
When we cache the results of webservice calls per advisory id, if in subsequent runs we don't encounter new advisories we could skip the call to the ws entirely.
Seems like a mostly invalid report, let's try and use #32 for that when the online tool is deployed
Metadata
Owner
Metadata
Web service for managing information on vulnerabilities in software distributed through Nixpkgs