SARIFはすべてのコードスキャナーに単一のアラートファイルという共通言語を与えた

静的解析には典型的な「ツール乱立」問題があった。セキュリティ、品質、コンプライアンスの各スキャナーは有用な問題を検出するものの、それぞれが独自の出力形式を用いていた。それらを一つのワークフローに集約するには、カスタムアダプターが必要となり、文脈情報も失われていた。

SARIFの巧みな点は、結果をポータブルなオブジェクトとして定義したことにある。OASIS標準によれば、SARIFログはJSONであり、1回以上の解析実行からの結果を含むことができ、ルール、成果物、位置、メッセージ、フィンガープリント、フローデータを保持できる。

GitHubはこの形式を実運用可能なものにした。GitHubのコードスキャンのドキュメントでは、チームがGitHub外部で生成されたSARIF（サードパーティ製ツールやCIシステムを含む）をアップロードし、その結果をリポジトリのアラートとして表示できる。これによりSARIFは、単なるスキーマからスキャナーの配布レールへと変わった。

スキャナーではなく検出結果を標準化する

JSONによって、ツールやプラットフォームが形式を生成・検証・保存しやすくなった。

実行とツールのメタデータにより、1つのファイルでどのスキャナーがどの検出結果を出したかを保持できる。

フィンガープリントとカテゴリは、プラットフォームがコミットをまたいでアラートを重複排除し追跡するのに役立つ。

GitHubによる取り込みが、ツールベンダーにSARIFを出力する即時の理由を与えた。

ある形式は、最初のエラーメッセージだけでなく結果のライフサイクル全体を捉えれば、断片化したツール市場を統一できる。

SARIF 2.1.0は2020年3月27日にOASIS標準となった。GitHubのコードスキャンは引き続き外部ツールからアップロードされたSARIFファイルを受け入れており、この形式はローカルスキャナー、CIシステム、ホスト型のコードセキュリティワークフローの間の実用的な橋渡しとなっている。