net/go.book
All Parts Marketing

Further Cybersecurity Resources

"Thirty-one chapters is enough to learn to read a map. It's not enough to know every road. Here's where to keep exploring, both alongside the rest of this book and long after you've finished it."

Closing Out Part 3

Part 3 covered a lot of ground: modeling threats and recognizing common attacks, scanning and sniffing with Go, assessing vulnerabilities, building your own small security tools in Go, running a penetration test, responding to incidents, and the legal line that governs all of it — then TLS, PKI, and secure coding practices; zero trust and segmentation as architectural philosophy; IDS/IPS, SIEM, and malware analysis for detection at scale; reverse engineering, red team versus blue team, and social engineering; wireless, IoT, cloud, and container security; bug bounty work, security automation, a honeypot you built yourself, and lab-based attack simulation; and finally real-world case studies and a look at where the threat landscape is heading next — AI-assisted attacks, post-quantum cryptography, and the rest of the emerging-threats territory the previous chapter mapped out. That's a solid foundation across the full breadth of the field — but security rewards continuous learning more than almost any other area of software engineering, because the threat landscape genuinely keeps moving. This chapter is a map of where to keep going next.

Standards and Frameworks Worth Knowing

  • OWASP (Open Web Application Security Project) — the OWASP Top 10 is the most widely referenced summary of common web application weaknesses, and the broader OWASP project publishes testing guides, cheat sheets, and tools, nearly all freely available.
  • MITRE ATT&CK — a knowledge base of real-world adversary tactics and techniques, organized so defenders can map their own detection and defense coverage against known attacker behavior.
  • NIST Cybersecurity Framework and NIST SP 800-series — US government publications that are, in practice, referenced globally; SP 800-61 (incident handling) and SP 800-207 (zero trust, relevant to Chapter 5.14) are particularly useful starting points.
  • CVE and NVD (National Vulnerability Database) — the canonical public catalog of known vulnerabilities referenced throughout Chapter 5.6.
  • CVSS (Common Vulnerability Scoring System) — the scoring standard behind most severity ratings you'll encounter.

Practice Platforms

Building real skill in this field benefits enormously from hands-on, legally unambiguous practice (Chapter 5.10's point about practicing legally applies fully here):

  • Dedicated vulnerable-by-design lab platforms — environments built specifically to be attacked, ranging from single downloadable VMs to full online lab subscriptions with guided learning paths.
  • CTF (Capture the Flag) competitions — both live, time-boxed events and large archives of past challenges you can work through at your own pace.
  • Bug bounty programs — once you're comfortable with the basics, testing real production systems under an explicit, published scope is one of the best ways to calibrate your skills against real-world software.
  • Your own home lab — a couple of virtual machines on a laptop, deliberately misconfigured, teaches an enormous amount and costs nothing beyond your own time.

Go-Specific Security Resources

Sticking with the language this book teaches:

  • The Go security policy and advisory process — the Go team publishes security advisories for the standard library and toolchain; keeping a project's Go version current matters as much as keeping any other dependency current.
  • govulncheck — a Go team tool that scans a module's dependency graph against the Go vulnerability database and reports only the vulnerabilities that are actually reachable from your code, rather than every match by version alone (directly relevant to the verification step from Chapter 5.6).
  • The crypto/ and net/http package documentation — genuinely worth reading end to end at least once; the standard library's own doc comments frequently explain why an API is shaped the way it is from a security standpoint, not just what it does.
  • gopacket — the packet-capture library used in Chapter 5.5, useful well beyond security work for any protocol-level debugging.

Certifications, If You Want a Structured Path

Certifications aren't required to do security work well, but they provide a structured curriculum and, for some employers, a useful signal:

  • Practical, hands-on-exam certifications (built around live lab environments and a required written report) are generally considered the strongest evidence of applied offensive skill.
  • Broader, multiple-choice-style certifications cover wide conceptual ground efficiently and are often used as an entry point or a hiring-screen baseline.
  • Defensive and management-track certifications exist as well, covering security operations, risk management, and governance — worth considering if your interest leans toward the process discipline and blue-team side covered in Chapters 5.8 and 5.9, respectively.

Treat any certification as a supplement to hands-on practice, not a replacement for it — the skills tested in Chapters 5.4 through 5.7 of this book are built by writing and running code, not by reading alone.

Communities and Staying Current

  • Security mailing lists and advisory feeds for the software you actually run in production — timely awareness of a new vulnerability in a dependency is often more valuable than broad general knowledge.
  • Conference talks (many published freely after the fact) from major security conferences remain one of the best sources of deep, practitioner-level detail on both attack and defense techniques.
  • Local and online communities built around CTFs, bug bounties, or specific tool ecosystems — security is a field where explaining a technique to someone else is one of the fastest ways to solidify your own understanding of it.

The tools and frameworks you'll use five years from now don't exist yet. What carries forward is the habit built in this part of the book: model the threat, question the assumption, verify before you trust.

Frequently Asked Questions

Do I need a certification before I can get taken seriously in security work? No — the chapter is deliberately blunt about this: certifications are a supplement, not a prerequisite. A structured curriculum helps some people learn faster, and a certification can be a useful signal to an employer scanning resumes, but the actual skill is built the same way you built it across Chapters 5.4 through 5.7 of this book — by writing and running code against real, legally sanctioned targets.

Is it legal to practice against the vulnerable-by-design labs and CTFs mentioned here? Yes, and that's exactly why they're worth seeking out — they exist specifically to be attacked, with explicit permission baked into their design, unlike a random server you happen to find on the internet. The legal line from Chapter 5.10 is about scope and authorization, and these platforms are built to give you unambiguous scope: you own the environment, or the organizer has explicitly granted you access to it.

Why does the chapter point to govulncheck specifically instead of just "keep dependencies updated"? Because reachability matters more than raw version mismatches — govulncheck cross-references the Go vulnerability database against your module's actual dependency graph and reports only the vulnerabilities your code can actually reach, which is a far more actionable signal than a blanket "37 known CVEs in your dependency tree" report that buries the two that matter among dozens that don't apply to how you're using the library.

Why does a "further resources" chapter come at the very end of Part 3 instead of partway through? Because everything it points to — standards, practice platforms, Go-specific tooling, certifications, communities — is easiest to actually use once you've already built the hands-on skill this part teaches, from scanning and sniffing through TLS, detection, red/blue team exercises, and the case studies in the previous two chapters. Reading a list of frameworks and platforms means little in the abstract; it means a great deal once you've felt the shape of the problems they exist to solve.

Treat this chapter as a bookmark to revisit periodically, not a one-time reading list, since the specific tools it names will age but the categories (standards, practice platforms, Go-specific resources, communities) won't.

That closes out Part 3. The book continues from here into Part APIs — building the production-shaped backends, over HTTP and beyond, that everything you just learned to scan, harden, and defend actually exists to protect.