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