At Fullstory, we weave security into the fabric of everything we do, from writing code to deploying applications, always with the goal of keeping our clients' data safe. A key part of our security toolkit is Arnica, chosen for its use of Semgrep—a tool that changes the game in how we secure our code and protect data.
Why Semgrep?
Semgrep is a powerful tool for static code analysis that enables us to identify and fix issues in our codebase. Now, I know what you are thinking, dear reader: "Ah, this is when you launch into a sales-oriented pitch about how a SAST tool is magically solving all of our automated static code analysis problems." That is not the case. Semgrep is more than just a tool; it’s a change in how we approach security. Semgrep allows our security engineers to actively participate in improving our SAST checks, moving beyond merely reacting to findings. This has been a significant shift from wishing our SAST engine could better catch specific issues to making it happen.
Static analysis might not sound as exciting or intriguing as uncovering exploits through reverse engineering or other zero-knowledge techniques. We want to picture a faceless, hooded hacker in a dark corner illuminated only by the glow of a monitor, going through disassembled code to find a heap overflow that will uncover a zero-day exploit bug. On the other hand, we tend to see code analysis as a task we leave off to some SAST tool - the tool spits out a large list of issues for an engineer to go through and validate and, in some cases, assign to developers to do the triaging. Yet, static analysis can be incredibly effective at finding and fixing bugs and vulnerabilities. However, traditionally, teams have relied on various SAST tools with limited room for customization.
Semgrep changes this paradigm by allowing the security engineer (and developers) to not only optimize existing SAST checks by way of updating existing static analysis rules but also by allowing them to write completely new checks that take into consideration the coding practices and patterns of the engineering organization they serve. This makes SAST work exciting, as it is possible to discover new vulnerabilities in code by writing rules in a simple, YAML-based syntax that is very well described in the Semgrep documentation. We can use Semgrep to quickly write rules that apply to all of our technologies, whether it be Rust, Go, TypeScript, or even configuration files written in YAML.
Contributions to the Semgrep ecosystem
Choosing Arnica for our SAST needs because of its use of Semgrep was a deliberate decision. It wasn’t just about adopting a new tool; it was about embracing a platform that allows for continuous improvement and customization of our security processes. This is how we see the future of automated static analysis—deeply customizable and continuously improving, allowing us to develop and integrate precise checks that identify vulnerabilities that conventional tools do not consider.
In line with our commitment to security and community, we’ve made several contributions to the Semgrep ecosystem. Our team has worked to develop and optimize rules and share them with the community. In doing so, we have helped improve security practices industry-wide. Some of our recent contributions include improvements to the following rules:
Anonymous-race-condition (recently deprecated after Go updated loop variables are handled in Go 1.22)
These contributions are just a part of our efforts to not only enhance our security but also to give back to the community. In the future, we will be open-sourcing a set of custom Semgrep rules that we have developed over time.
Our commitment to continuous improvement
When we identify a need to update or add a rule, it’s often based on real-world use cases within our environment, such as accounting for safe patterns we use, recognizing internal sanitizer functions, or generally improving rule accuracy to reduce false positives. New rules are added as we analyze our services or respond to bug reports, reflecting our proactive stance on security beyond just the basics.
Importantly, many of the rules we run go outside the OWASP top 10. This is because we believe software correctness and security go hand-in-hand. It can be easy to dismiss, for instance, a simple nil-dereference or a possible race condition bug. However, by identifying such patterns in code, we can prevent a whole array of issues, such as data being missed due to race conditions or possible application panics that could lead to downtime. All in all, software correctness leads to safer customer data.
Advancing application security
Our path with Semgrep and Arnica isn't just about beefing up Fullstory’s defenses; it's about rethinking how application security should be tackled. Engaging deeply with our tools and the wider community doesn't only make our client data more secure; it's our way of helping ensure a safer digital world for everyone.
This commitment reflects our core belief at Fullstory: by continually seeking out and applying the best security practices, we not only protect our clients today but also lay the groundwork for more secure digital experiences in the future.
