Previously in our Supply chain security for Go series, we covered dependency and vulnerability management tools and how Go ensures package integrity and availability as part of the commitment to countering the rise in supply chain attacks in recent years.
In this final installment, we’ll discuss how “shift left” security can help make sure you have the security information you need, when you need it, to avoid unwelcome surprises.
Shifting left
The software development life cycle (SDLC) refers to the series of steps that a software project goes through, from planning all the way through operation. It’s a cycle because once code has been released, the process continues and repeats through actions like coding new features, addressing bugs, and more.
Shifting left involves implementing security practices earlier in the SDLC. For example, consider scanning dependencies for known vulnerabilities; many organizations do this as part of continuous integration (CI) which ensures that code has passed security scans before it is released. However, if a vulnerability is first found during CI, significant time has already been invested building code upon an insecure dependency. Shifting left in this case means allowing developers to run vulnerability scans locally, well before the CI-time scan, so they can learn about issues with their dependencies prior to investing time and effort into creating new code built upon vulnerable dependencies or functions.
Shifting left with Go
Go provides several features that help you address security early in your process, including govulncheck and pkg.go.dev discussed in Supply chain security for Go, Part 1. Today’s post covers two more features of special interest to supply chain security: the Go extension for Visual Studio Code and built-in fuzz testing.
VS Code Go extension
The VS Code Go extension helps developers shift left by surfacing problems directly in their code editor. The plugin is loaded with features including built in testing and debugging and vulnerability information right in your IDE. Having these features at your fingertips while coding means good security practices are incorporated into your project as early as possible. For example, by running the govulncheck integration early and often, you'll know whether you are invoking a compromised function before it becomes difficult to extract. Check out the tutorial to get started today.
Fuzz testing in Go
In 2022, Go became the first major programming language to include fuzz testing in its standard toolset with the release of Go 1.18. Fuzzing is a type of automated testing that continuously alters program inputs to find bugs. It plays a huge role in keeping the Go project itself secure – OSS-Fuzz has discovered eight vulnerabilities in the Go Standard library since 2020.
Fuzz testing can find security exploits and vulnerabilities in edge cases that humans often miss, not only your code, but also in your dependencies—which means more insight into your supply chain. With fuzzing included in the standard Go tool set, developers can more easily shift left, fuzzing earlier in their development process. Our tutorial walks you through how to set up and run your fuzzing tests.
If you maintain a Go package, your project may be eligible for free and continuous fuzzing provided by OSS-Fuzz, which supports native Go fuzzing. Fuzzing your project, whether on demand through the standard toolset or continuously through OSS-Fuzz is a great way to help protect the people and projects who will use your module.
Security at the ecosystem level
In the same way that we’re working toward "secure Go practices" becoming "standard Go practices," the future of software will be more secure for everyone when they’re simply “standard development practices.” Supply chain security threats are real and complex, but we can contribute to solving them by building solutions directly into open source ecosystems.
If you’ve enjoyed this series, come meet the Go team at Gophercon this September! And check out our closing keynote—all about how Go’s vulnerability management can help you write more secure and reliable software.
No comments:
Post a Comment
You are welcome to contribute comments, but they should be relevant to the conversation. We reserve the right to remove off-topic remarks in the interest of keeping the conversation focused and engaging. Shameless self-promotion is well, shameless, and will get canned.
Note: Only a member of this blog may post a comment.