Modernizing SAST rules maintenance to catch vulnerabilities faster

Snyk Code separates itself from the majority of static code analysis tools by generating and maintaining rule sets for its users — helping them combat common and newly discovered threats. A recent Hub article described a new Javascript vulnerability called prototype pollution, which allows attackers to modify, or “pollute”, a Javascript object prototype and execute a variety of malicious actions.

In this post, we’ll use the example of prototype pollution to walk through how the rule maintenance features of Snyk Code help developers and security professionals protect their application. We won’t explore prototype pollution in depth in this post, but if you’d like to learn more about it, I recommend taking this Snyk learn lesson or reading the above mentioned Hub article.

The traditional approach to maintaining rule sets

The quality of a static application security testing (SAST) tool — and more broadly, of static code analysis tools — is largely determined by the quality of its rule set. Simply put, the tool transforms the source code into a data structure and uses these rules to search for malicious patterns. In most modern scanners, rules are written in a somewhat uncommon style called logical programming.

Writing and maintaining rule sets is not an easy task. It requires intimate knowledge of logical programming, as well as the language and libraries being scanned. After the rules have been written, the process of debugging them creates another challenge. They must be tested on real code before being used in production, which can easily take hours. As a result, research1 has shown that developers seldom change the configuration. While there are some cases where custom rules make sense, in the majority of cases, the tool should simply work.

Note: There are some very limited cases where custom rules make sense (if you are such a case, let us know). In the majority of cases, the tool should “simply work” — no tinkering from the user-side necessary!

Snyk Code modernizes rule maintenance

Snyk Code has a different approach. We see the rule set as part of the product and do not ask our customers to maintain these rules to make the tool usable. In an industry that believes “custom rules” are a necessary capability of a SAST tool, Snyk offers a simplified solution to its users. Our security experts take responsibility to build and maintain the rule set using the powerful and fast engine on huge numbers of open source projects as test and training set. Snyk’s “humans-in-the-loop” constantly monitor and oversee the results, and act as quality control so the customers do not have to.

One of the Snyk engineers working on rule maintenance is Alessio Della Libera, a security researcher who joined Snyk roughly a year ago. When asked about Snyk Code’s unique approach, he described it as “[...] a kind of loop. Start changing something and checking the changes against the results from the data set takes a few minutes. Being able to iterate so fast is super helpful.”

Digging deeper

The training set of open source projects are constantly monitored and updated according to scan findings and feedback from users. During this monitoring, Libera became aware that one of our existing rules did not behave according to our requirements.

After making changes to the rule and testing it, two results stood out. The open source project called appwrite.io contained a copy of the litespeed.js library. According to their website, “Appwrite is a self-hosted solution that provides developers with a set of easy-to-use and integrate REST APIs to manage their core backend needs”. Snyk Code reported the same issue on both the library via the marketplace and the project itself.

On a running instance of appwrite.io (while running on mywebsite.com for example) an attacker can call mywebsite.com/auth/signup?__proto__[polluted]=yes. Using the developer tools in the browser, you can check the JavaScript state and you will find that there is now a member called polluted with the value yes. While exploiting this issue, Libera found that malicious websites could use this vulnerability to trigger a cross-site scripting (XSS) attack.

Informing the maintainers

After informing the project maintainers at Appwrite, they quickly released patches to cover the  appwrite/server-ce package and litespeed.js package. Since the application is widely used, a CVE was also published in the National Vulnerability Database.

After the vulnerability had been resolved, the maintainers at Appwrite offered Libera a gift card, which he asked to have donated for the benefit of the open source community. All in all, we can only applaud Appwrite’s handling of the security issue. By taking it seriously and working with the community to solve the problem, they helped keep open source secure.

Summary

By constantly developing and maintaining the rule sets that power Snyk Code, Snyk ensures consistent growth in coverage accuracy. We make sure to constantly scan for new issue patterns and implement them while maintaining existing rules. To us, the rule set is part of the product — and our responsibility to build and maintain.

Try Snyk Code for free today, and see how our developer-centric security platform helps you write high quality code more efficiently than ever.

1 Beller, M., Bholanath, R., McIntosh, S., & Zaidman, A. (2016). "Analyzing the state of static analysis: A large-scale evaluation in open source software". 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering, SANER 2016, 1, 470–481. https://doi.org/10.1109/SANER.2016.105