Developers spend on average 50% of their time fixing bugs and addressing technical debt. Tools, development environments, and new languages promise to reduce this; however, they can inadvertently increase the time developers spend fixing bugs.
“The cost of debugging, testing, and verification is estimated to account for 50-75 percent of the total budget of software development projects, amounting to more than $100 billion annually.”
-Devon H. O’Dell, Tech Lead, Fastly, published by Association for Computing Machinery.
Developers time should be spent writing code and pushing new features, not fixing security bugs.Our mission at Reshift is to make security easier for developers to secure their code earlier on in the software development life cycle.
One of the ways we are doing this is by focusing on optimizing scanning speed for our new JavaScript scanner. We are prioritizing JavaScript as it’s one of the most popular programming languages, yet there are a lack of security tools to support JavaScript developers.
Historically, static code analysis was perceived as slow and unscalable, with scans taking up to several hours. Obviously, this is not practical in today’s fast-paced development environments. Static code analysis uses code, data flow graphs, and other structures to find vulnerabilities in the analyzed code. These captured relationships between code constructs have a tendency to grow exponentially with the number of lines in a project, leading to prohibitively long scan times.
Untyped languages like JavaScript exacerbate the problem by removing many type-related constraints on the dataflow graph structure, greatly increasing the number of edges between nodes.
As we started building Reshift to enable developers to scan their own code, scanning speed was very important for us to nail down. The following outlines the design decisions we took to build a tool that is optimized for scanning speed as much as it is optimized for coverage and accuracy.
1. The Choice of Datalog
Datalog is a declarative logic programming language that is syntactically a subset of Prolog. Its declarative nature makes Datalog more suitable for writing customizable program analyzers than a general-purpose programming language. This allows us to tweak and tune Reshift for emerging analysis targets. Additionally, Datalog offers a much easier language to mechanically optimize than something like C++ or Java.
2. Futamura Projections
Futamura Projections is a technique to produce a new program that runs faster than the originals while being guaranteed to behave in the same way. This means that we can produce executables that are optimized for exactly the scanning function they need to achieve. Reshift synthesizes a native parallel C++ program from a logic specification. This synthesis is performed by several applications of the Futamura Projects, producing a highly optimized executable.
3. Consistent Benchmarking and Improvements
We built our CI pipeline to optimize for scanning performance. Our CI performance benchmark consists of scans of multiple active open source Javascript projects. This allows us to quickly identify current bottlenecks – focusing our efforts on real world problems, and regressions – making sure we are on the track of consistent progress.
We’re excited to share that our team was able to reduce Reshift’s average scanning time for our JavaScript scanner to 5 milliseconds per line of code this week, down from 10 milliseconds when we started benchmarking. In the graphs below, we compare our scan times over the past month across popular JavaScript projects.
We continue to push the limits for developer security tools and we look forward to sharing this journey with you.
