Hi everyone, I’d like to give a summary on the state of discussion here @ NixCon. Disclaimer: Discussion is still in progress. But I’d like to share at what we have arrived so far to get opinions from the broader community.
General thoughts
- We do not necessarily need to maintain our own scanning engine. There quite a few scanners around e.g., Trivy or Grype. Focus should be on providing data as a software bill of materials (SBOM) in a compatible format like in CycloneDX or SPDX) and make the actual scanner pluggable.
- We should definitely not try to maintain our own vulnerability database (like DSA) because we don’t have the manpower to do that. We should rather rely on scanners combining several existing data sources like NVD or OSV.
- Identifying packages is hard. There are many formats around, each with their individual strengths and weaknesses: CPE, purl, SWID, OSV ecosystem/name, just to name a few. CPE seems to be the most widely used, but is particularly poorly suited for open source ecosystems.
What needs to be done to get scanning done
- A decent SBOM generator which scans some Nix artifact (see below) and produces an SBOM containing package identifiers in an acceptable quality.
1.1 The SBOM generator should be able to scan a top-level expression (anything which produces a result symlink when run)
1.2 The SBOM generator should be able to perform a static scan of nixpkgs (without requiring to instantiate anything) and emit one or many SBOMs for distribution-wide scanning.
Requirements (1.1) and (1.2) might result in different operating modes of the same piece of software or different pieces of software. - In cases where there is no fixed upstream version available or updating is not a good option, we need to provide a list of applied patches so vulnerability scanners know about the fix. Don’t know which format is appropriate. Some people suggest OVAL, but that looks ugly to me.
SBOM and fix list should be generated automatically on Hydra for each relevant architecture and release.
What needs to be done to help maintainers fix stuff
Should we continue to create GitHub issues or not?
- Pro: This is where developers look anyway.
- Con: There is little overview of the overall state of the security effort. I also regularly hit GitHub rate limits.
An alternative would be a security dashboard like broken.sh (apparently not up anymore). Perhaps it will be necessary to generate both tickets and provide some dashboard.
Interacting with the security infrastructure must be straight-forward for maintainers. In the best case, no manual action should be necessary at all. If manual action would be necessary (e.g., recording applied fixes), it should be obvious and easy.
It also should be obvious and easy to fix package miscategorizations, e.g. when an pkg is associated to an incorrect purl.
In the past, vulnerabilities often got fixed on the go, e.g. while doing regular package updates. It would be nice to close obsolete issues automatically.
There is probably at lot more about the issue, but I hope this will get everyone started. Please feel free to share your ideas! 