These days,
several companies
worldwide are joining forces
to support the new version
of the OASIS Static Analysis Results Interchange Format (SARIF).
SARIF,
in a nutshell,
is a standardized format for the output of static analysis tools.
In this post,
we will give you a quick overview of it.

Before taking a closer look at SARIF,
what is OASIS?
OASIS Open is a non-profit organization
in which individuals and entities around the world come together
to collaborate in the transparent development of open code and standards
for technologies such as cybersecurity,
IoT and cloud computing.
Five years ago,
OASIS Open issued a call for participation in a new technical committee (TC)
to its members and interested parties:
the SARIF TC.
The primary purpose of this group was to “define a standard output format
for static analysis tools.”

As you know,
many tools use the static analysis technique
to assess the quality and security of software.
(At Fluid Attacks,
for example,
we use our SAST tool for vulnerability detection.
SAST stands for Static Application Security Testing.)
It’s called “static”
because the software under evaluation is not running
at that time.
When developers utilize several of these tools
to get different perspectives on the analyzed code,
they end up aggregating the results delivered
to have an overall picture of the software quality.
Tools producing results in various formats complicate this task.
Hence the value of defining a standard output format.

“Clearly,
people involved in static analysis appreciate the need for interoperability,
and they are committed to making it happen with SARIF,”
said Laurent Liscia,
CEO of OASIS Open,
back in 2017.
The first version
of the OASIS SARIF standard
was released in March 2020
after receiving by ballot
the affirmative consent of all members involved.
The standard was named SARIF v2.1.0
to recognize Microsoft’s previous efforts and pre-standard versions.
Following this release,
discussions resumed again in March 2021 at the TC
on a possible new version of the standard.

As Larry Golding,
co-editor of the SARIF specification,
comments in the introduction
of the tutorial to the standard,
the multiple output formats
of the thousands of static analytic tools
bring with them problems such as the following:

• It’s necessary to learn how to read all of them.

• There’s no standard method to view and interact with all the tool outputs
  in the development environment (e.g., Visual Studio Code).

• There’s no standard method to convert the outputs into bugs
  in issue-tracking systems (e.g., GitLab, GitHub).

• There’s no standard method to create metrics
  (e.g., number of bugs in a software component).

SARIF,
a JSON-based format,
emerges as a solution to all these headaches.
So,
let’s say you have several static analysis tools to assess your code
and identify programming and style errors,
non-compliance with legal requirements,
and security vulnerabilities,
among other things.
Suppose these tools,
although each has its own output format,
offer you the possibility of converting results into other formats.
Either with a formatter plugin
or with an external utility for report format conversion,
you could bring the results obtained in all your tools
into the unified SARIF format.
From there,
already knowing this type of file,
you could make a straightforward integration
and examination of your information.

For example,
you can achieve something like this
with the Microsoft SARIF Viewer extension for Visual Studio.
It can automatically convert more than 10 log file formats to SARIF
and integrates with the Visual Studio environment
to show you a user-friendly list of results with their respective details.
Among the details you might see,
apart from the name of the tool and the scanned files,
are the following:

• Information about the violated rule

• The severity of the violation

• The location of the flaw and code paths leading to it

• Suggestions for fixing the flaw

According to Golding,
the messages in the results are a requirement in SARIF.
But “a good message
not only explains what was wrong:
it also explains why the flagged construct is considered questionable,
provides guidance for remedying the problem,
and explains when it’s ok to ignore the result.”
Regarding the levels of seriousness of the results,
in SARIF,
we typically see the values “error,” “warning” and “note.”
These values allude to problems ranging from severe to minor
(or simple opportunities to improve the code).
The locations,
on the other hand,
are optional since their being reported will depend on each case.
For instance,
following Golding,
if a tool gives you the result
that your C# program doesn’t have a Main entry point,
it would not have to mention a specific location.

This is just a glimpse of what you might discover in a SARIF file.
(By the way,
on the SARIF website,
you can upload,
view and explore your SARIF files.)
Relying on this common format
when using multi-vendor tools for your software assessment
can undoubtedly mean time and effort savings
as well as better comparison and analysis of the results.
Results that you receive,
needless to say,
to improve the quality and security of your software.

An increasing number of companies are joining OASIS Open
to contribute to generating creative ideas
in favor of more secure software development.
As mentioned above,
there has been a whiff of a transformation of this standard since last year.
Cartey and Keaton,
OASIS SARIF TC co-chairs,
recently said that
“The next major version
of SARIF will expand our ability
to aggregate data and detect vulnerabilities in some exciting new ways.
We look forward to the contributions of the companies that are joining now,
and we welcome others.”

If what you want is a broad introduction to SARIF,
we invite you to review the aforementioned tutorial.
For the complete documentation,
you can visit SARIF’s repository on GitHub.

*** This is a Security Bloggers Network syndicated blog from Fluid Attacks RSS Feed authored by Felipe Ruiz. Read the original post at: https://fluidattacks.com/blog/oasis-sarif/