Secure and reliable development with Go
summary
Talk lists concrete changes: a first‑party vulnerability database plus a proposed Go audit that uses static analysis to report only relevant vulnerabilities; native fuzzing integrated into go test that writes failing inputs into testdata so crashes reproduce; gopls as a single IDE backend and Delve adding DAP for editor debugging; pkg.go.dev adding version timelines and surfacing SemVer stability and vuln info; modules, checksum DB and mirrors give reproducible builds; sandboxing recommendation is process isolation (gVisor).
AI-written summary · about
chapters (13)
- 0:00Start
- 2:30How does Go provide dependency management?
- 4:01How do I choose dependencies for my project?
- 5:54What are some new things coming to Go that help with end-to-end security?
- 9:13How long do you think it will be before the new go fuzzing proposal uncovers bugs in
- 10:32Are there any plans to limit what dependencies can do? For example, declaring that a dependency package can't make network calls or execute child processes?
- 12:16How to be sure that the public Go library that I use is secure and don't contains backdoors or something else?
- 14:33Will there be a way to seed fuzzing or trace the seed for a fuzz so errors can be repeated?
- 19:22Does Go have a debugger? What are upcoming new features for debugging?
- 21:27Will fuzzing be more than just type registries with candidate values per type? What kind of smarts are in furning!
- 24:41Why do Go modules require SemVer (semantic versioning)?
- 27:24How often do you have to deprecate older crypto libraries? Do these deprecations break
- 28:56What is one thing you would recommend checking out for Go?
related talks
24mGoing Secure with Go
24m"Finding Dependable Go Packages"
25mExploring Some Essential Security Checks for Any Open Source Go Project
51mKeynote | State of the Go Nation
05mLightning Talk: Improving The Security Of Your Go Applications
28mKeynote: The State Of Go
24mVulnerability Management for Go
28mState of the Go Nation!