Caesar, standards, and SAST: The road to SARIF
A quick history lesson
Ancient Rome’s road system was one of its great achievements. The first significant Roman highway was built in 325 BC, and about 275 years and a quarter million miles of roadway later, Julius Caesar identified a serious bug in the whole enterprise: Transport was often slowed in developed areas, because the diverse construction of carts, chariots, and other vehicles created a confused set of rut ways that slowed all traffic.
In 44 BC, borrowing a great idea from the Corinthians, Julius Caesar issued an edict that set standard wheel and axle dimensions for all vehicles traveling state-maintained roads. It’s not a stretch to cite this use of standards as a pillar of Rome’s further expansions for the next two centuries.
Fast forward 2000 years: Standards in software
Early in my career, I worked on small team working on a small project, a static analysis checker called FxCop that shipped in the CLR (.NET) 1.0 SDK. The Windows team asked us to integrate FxCop, and the provincial was summoned to Rome. I spent the next 12 months earning a degree in what it means to work at ‘Windows scale,’ carving new channels or updating our tool to conform to existing mechanisms to get our results where they needed to go. Due to the importance of the project, we aligned ourselves with the Windows schedule to address issues as they materialized.
After this, I started work on another static analysis project (a JavaScript and HTML checker) while my friends in Visual Studio kept working with Windows, with the directions reversed: This time Windows would contribute its own C++ checker (PREfast) back into the VS IDE. Now, Visual Studio was not a Windows-sized organization, but large enough that I was curious how these two groups would manage to reconcile two completely different ship cycles.
They invited me to see several demos of the work and I was floored by it. The VS user experience showed the benefit of multiple rapid design iterations. In parallel, Windows had somehow batched up and seamlessly contributed many analysis improvements on their own schedule. When I dug into the root causes of this success, I had my Julius-Caesar-at-the-Isthmus-of-Corinth moment: The only point of contact between VS and the Windows checker, other than launching the scanner, was the log file produced by the tool. If the format of this file didn’t change, if all relevant data continued to be put in its place as specified, Visual Studio and Windows could bolt together two entirely distinct, out-of-sync engineering processes with minimal coordination and slowdowns.
And so, I learned an early lesson in standards, how consensus on something very small can enable (in fact may be required to enable!) something very large.
Behold, SARIF
This insight was the opening chapter in the design of the ‘Static Analysis Results Interchange Format’ (SARIF), an OASIS standard that enables (and is indeed required!) for at-scale Static Analysis Security Testing (SAST) in the DevOps environment.
SARIF divides the static analysis world into producers (tools) and consumers (viewers, build systems, work item filers). The consumers are like the Roman road system: They are the fixed channels that send tool results to users in their coding environment, build output, a work item, or an SDL compliance dashboard. The tools send their results throughout the user experience empire by shipping them in carefully specified ‘vehicles,’ output files that are precisely specified, entirely consistent, and highly suited to purpose.
In its simplest form, SARIF is a web-friendly JSON file that captures lists of results, such as compiler errors that might appear in an IDE error list or on the command line. Producers can optionally provide additional data to assist in investigating problem reports, such as rule help or execution paths that demonstrate a particular vulnerability. Here’s a minimal example:
{
"version": "2.1.0",
"runs": [
{
"tool": {
"driver": {
"name": "CodeScanner",
"semanticVersion": "2.1.0"
}
},
"results": [ { "message": { "text": "This is a minimal, valid SARIF file." } } ]
}
]
}
Join me soon for part two of this blog post, where I plan to strain this analogy further, add more Microsoft history on what motivated SARIF’s design and implementation, the push for (and value of) broad adoption, and what’s next for the format.
Want to come work with us? Check out https://aka.ms/1esjobs for open positions.
Light
Dark
0 comments