Boeing / config-file-validator

Cross Platform tool to validate configuration files
https://boeing.github.io/config-file-validator/
Apache License 2.0
319 stars 52 forks source link

Add SARIF Reporter #32

Open jcg-2 opened 1 year ago

jcg-2 commented 1 year ago

Description

The Static Analysis Results Interchange Format (SARIF) standard might be a more appropriate format for consideration instead of/as well as JUnit (https://github.com/Boeing/config-file-validator/issues/10)

Links

kehoecj commented 1 year ago

@jcg-2 This looks great - sounds like a great candidate for a report format.

armadi1809 commented 9 months ago

@kehoecj is this still up for grabs? If so, I would like to take a shot at it.

kehoecj commented 9 months ago

@kehoecj is this still up for grabs? If so, I would like to take a shot at it.

Thanks for volunteering! I assigned it to you

armadi1809 commented 9 months ago

Starting to work on this now! Sorry for the delay.

armadi1809 commented 9 months ago

@kehoecj Quick question, is there an example SARIF Report you would like us to follow here? If not, I suggest something like this maybe?

{
  "version": "2.1.0",
  "$schema": "http://json.schemastore.org/sarif-2.1.0-rtm.4",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "config-file-validator",
          "informationUri": "https://github.com/Boeing/config-file-validator/issues/32",
        }
      },
      "artifacts": [
        {
          "location": {
            "uri": "path/to/config-file.yml"
          }
        }, 
        {
            "location": {
              "uri": "path/to/config-file.toml"
            }
        }
      ],
      "results": [
        {
          "level": "error",
          "message": {
            "text": "This will be filled by the message from the validator for first file"
          },
        }, 
        "level": "error",
          "message": {
            "text": "This will be filled by the message from the validator for second file"
        },
      ]
    }
  ]
} 
kehoecj commented 9 months ago

I don't know much about SARIF but the structure looks good. Only question I had was the uri attribute in artifacts. Is there attribute that can be used that's more indicative of a local file?

      "artifacts": [
        {
          "location": {
            "uri": "path/to/config-file.yml"
          }
        }, 
        {
            "location": {
              "uri": "path/to/config-file.toml"
            }
        }
      ],

Also what is the version attribute supposed to represent - the version of the SARIF schema? @jcg-2 Any feedback on this?

armadi1809 commented 9 months ago

Unfortunately looks like there is no other alternatives for the uri. From the SARIF specs:

3.4 artifactLocation object
3.4.1 General
Certain properties in this document specify the location of an artifact. SARIF represents an artifact’s location with an artifactLocation object. The most important member of an artifactLocation object is its uri property (§3.4.3). If the uri property contains a relative reference (the term used in the URI standard [[RFC 3986](https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/sarif-v2.1.0-errata01-os-complete.html#RFC3986)] for what is commonly called a “relative URI”), the uriBaseId property (§3.4.4) can sometimes be used to resolve the relative reference to an absolute URI.

For the version

The sarifLog object has a required version property that must be "2.1.0". version should come first (even though JSON is insensitive to property order) so SARIF consumers such as viewers can "sniff" the version.
kehoecj commented 9 months ago

Unfortunately looks like there is no other alternatives for the uri. From the SARIF specs:


3.4 artifactLocation object

3.4.1 General

Certain properties in this document specify the location of an artifact. SARIF represents an artifact’s location with an artifactLocation object. The most important member of an artifactLocation object is its uri property (§3.4.3). If the uri property contains a relative reference (the term used in the URI standard [[RFC 3986](https://docs.oasis-open.org/sarif/sarif/v2.1.0/errata01/os/sarif-v2.1.0-errata01-os-complete.html#RFC3986)] for what is commonly called a “relative URI”), the uriBaseId property (§3.4.4) can sometimes be used to resolve the relative reference to an absolute URI.

For the version


The sarifLog object has a required version property that must be "2.1.0". version should come first (even though JSON is insensitive to property order) so SARIF consumers such as viewers can "sniff" the version.

Thanks for the explanation! That looks good to me @jackswiney @jd4235 any concerns?

armadi1809 commented 9 months ago

Looks like there is no opposition. I will start implementing the format suggested above then!

kehoecj commented 7 months ago

@armadi1809 Are you still planning to work this issue?

armadi1809 commented 7 months ago

@kehoecj sorry, the holidays and then some personal stuff got me slacking on this one. I will hopefully have something ready by Monday. Sorry again!

kehoecj commented 7 months ago

@kehoecj sorry, the holidays and then some personal stuff got me slacking on this one. I will hopefully have something ready by Monday. Sorry again!

No rush at all! I was cleaning up the issues and just wanted to make sure some of the assignees were still interested in working the issues.

shiina4119 commented 3 weeks ago

Hi, is this issue being worked on? If not, can I make a pull request?

kehoecj commented 3 weeks ago

@shiina4119 I think it's abandoned at this point. Someone made a pull request with some changes but didn't add any tests and hasn't responded for a long time. You can definitely take it on if you're willing!