Static analysis lessons from big tech co’s

Software is eating the world - Marc Andreeseen

In 2018 and 2019, Google and Facebook released their research outputs of lessons learnt from scaling static code analysis in their respective companies. Their articles were titled Scaling Static Analyses at Facebook and Lessons from Building Static Analysis Tools at Google, respectively

These companies build software that is used by hundreds of millions of people daily, with code bases that are hundreds of thousands if not millions lines of code. The tools mentioned and used in these respective companies may not yet be Open Sourced, but the lessons shared can be applicable to most companies building their own software.

Given my current role of working with multiple engineering teams with multiple products, a few points in these Google and Facebook articles occasionally resurface in my mind every now and then. These aren’t ground breaking ideas.

Below are a few points that continue to be impressed upon me even after months of having last read those articles:

Static analysis tools can be powerful

Static code scanning is great but can be annoying when it comes to high number of false positives. These high false positive are often justification for inaction by engineering teams - and rightly so.

Work on reducing false positive cases before they are surfaced to engineering teams. For teams that have highly configured and tested static analysis tools, these can prove to be powerful enablers of security with engineering teams.

Focus on developer teams and their tool/workflow integrations

This means that static scan dashboards and outputs must feed into engineering workflows instead of requiring engineers to go out of their way to login into your separate bug dashboard/system.

Know & focus on bugs that matter

Not all bugs matter. Enable and empower engineers to address bugs that matter by using data from production to determine which those are (e.g. exploitable bugs from pentests and bug bounties). Not every bug is important enough to address as a matter of urgency.

Mental effort of context switch

If a developer is working on one problem, and they are confronted with a report on a separate problem, they must then swap out the mental context of the first problem and swap in the second, and this can be time consuming and disruptive. Try to minimize this.

Report often, report early

Report bugs to developer teams early to get optimum fix rate. In one of the articles, the engineering teams, responding to a query from the security team, reported that issues found and flagged during compile time were deemed to be more important issues compared to issues found in checked-in code.

The lessons learnt from big tech companies who have more mature processes, tools and experiences make for good reading for almost everyone in security and developers/engineering teams themselves.