Developing Secure Systems BoF
- need a way to inform anyone creating custom deployments about their security choices
- requirement for database mapping CVEs to git commits
- there is no independent way to verify whether vendor has fixed a given vuln.
- is the CVE applicable or not?
- there is a 6 month tail to get through customers' change control
- components which require users (eg OpenSSH) definition needs to contain uid info
- need definitions to include specification for uid
- reference systems default syntax
- create local user, in sudo, with random password.
- add fail2ban
- put definitions in /baserock? but size constraints, so use git shallow clone?
- can use git's capabilities for signing
- no process/documentation for keeping your definitions so you know what you deployed from. again put deploy signature in /baserock
- need to validate integrity of the update system itself
- need to validate provenance/integrity of source. lorry should check signatures and integrity, and trove should use debian tarball mirrors, rather than upstream?
- git pinning/certificate pinning to ensure history stays trusted. how to clean up when upstream is compromised?
- reference systems should be secure by default
- need a point of publication for vulnerabilities
- difference between an upgrade and install, need to restart patched services
- need upgrades which don't depend on btrfs