Response received from IANA. i pinged Michael and Larry and asked them how they'd like to proceed.
=====
Review:
FWIW, the main difficulty here is separating the security considerations of
static analysis tools themselves - which are outside the scope of this
registration - from those of this specific format.
Lots of notes below.
> Members of the OASIS Static Analysis Results Interchange Format (SARIF)
> Technical Committee wish to register a media type associated with the SARIF
> Version 2.1.0 OASIS Standard.
> This request was sent to the media-types mailing list for comment on 09 April
> 2020 (see: https://mailarchive.ietf.org/arch/msg/media-types/dYcLl3hit3UIfVxyvmSBROq_o0A/).
> No comments were received.
> Questions on the specification and this request can be submitted to Chet Ensign (chet.ensign@oasis-open.org) or, for technical details, to Michael Fanning (mikefan@microsoft.com) and Laurence Golding (v-lgold@microsoft.com). They are tasked by the OASIS SARIF TC to provide any information you request.
> Best regards,
> /chet ensign
> OASIS Open, Inc.
> —
> Type name: application
> Subtype name: sarif+json
> Required parameters: N/A
> Optional parameters: N/A
> Encoding considerations: UTF8 only
This needs to begin by saying "binary". The note about being UTF-8 only should
appear after that.
> Security considerations:
Since Sarif files are in JSON format, they inherit the security issues
of JSON. There should be a note here to that effect.
The specific points listed below are very good, however, this needs to start
with a general discussion of the security considerations of the format as a
whole, which necessarily leads to some discussion of privacy and integrity.
Something like:
The Sarif provides the means to capture the results of static analysis tools.
Such analysis may include information about software vulnerabilities. As such,
Sarif file content may be extremely sensitive, requiring external privacy
and integrity protection.
Even when the analysis results themselves are not sensitive, Satif files
may have other security issues:
And then move on to your list.
> - The use of absolute paths in analysis result location URIs might reveal
> sensitive information about the machine on which the scan was performed.
> - The use of the hostname component in analysis result location URI might
> reveal the network location of the machine on which the scan was performed.
Run information can also be present, and it can include details about when
analysis runs are performed. An attacker might be able to leverage this to
avoid getting caught doing something naughty...
Similarly, information about analysis processing failing with an error might be
used to know when it is safe to make some kind of change. It might even be
leveraged to attack the analysis process itself.
> - The use of raw HTML in message strings expressed in Markdown might allow
> arbitrary code execution (for example, through javascript: links).
> - The use of deeply nested constructs in Markdown message strings might lead
> to stack overflow in some Markdown implementations.
This seems a little specific. It might be useful to mention that there may
be other Markdown issues that could be exploited.
> - Certain properties of the SARIF object model might reveal information about
> the machine on which a scan was run. (The specification allows such properties
> to be omitted or "redacted".)
> - Certain properties of the SARIF object model (such as the command line that
> invoked the analysis tool) can contain arbitrary commands which might damage a
> machine on which they are run.
There doesn't seem to be any discussion of artifacts, file references, or web
responses here. I suggest something like:
Sarif files can contain artifacts, references to external artifacts,
file references, and web responses. Such content can be of any type, and may
include compressed material, with all its associated issues.
Not very well worded, but you get the idea.
> Interoperability considerations: N/A
> Published specification:
> Static Analysis Results Interchange Format (SARIF) Version 2.1.0. Edited by
> Michael C. Fanning and Laurence J. Golding. 27 March 2020. OASIS Standard.
> https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html. Latest
> stage: https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html.
> Applications that use this media type:
> The following list is not exhaustive:
> - Static analysis tools
> - Static analysis results visualization tools (viewers)
> - Bug filing tools
> - Defect databases
> - Compliance systems
> Fragment identifier considerations: N/A
> Additional information:
> Deprecated alias names for this type: N/A
> Magic number(s): N/A
> File extension(s): .sarif, .sarif.json
> Macintosh file type code(s): N/A
> Person & email address to contact for further information:
> Michael C. Fanning (mikefan@microsoft.com), Laurence J. Golding (
> v-lgold@microsoft.com), and Chet Ensign (chet.ensign@oasis-open.org)
> Intended usage: LIMITED USE
I can understand why you'd say LIMITED USE here - only certain very specific
tools would ever use this format - but generally speaking when registrations
say "LIMITED USE" they mean that the format is intended for general use within
it's realm of applicabiity. While this is entirely your call, I think
"COMMON" is actually more appropriate.
> Restrictions on usage: N/A
> Author:
> OASIS Static Analysis Results Interchange Format (SARIF) TC (
> https://www.oasis-open.org/committees/sarif/)
> Change controller:
> OASIS Open (https://www.oasis-open.org/)
> Provisional registration? (standards tree only): No
=====
1) See some initial details:
https://lists.oasis-open.org/archives/sarif/201805/msg00170.html
2) Larry Golding to describe the MIME type in the spec
https://github.com/oasis-tcs/sarif-spec/issues/182