Comments (20)
@eddynaka already working to add sarif output support to clj-watson
.
from clj-watson.
@yongyan-gh , if you have time, pls suggest the fixes.
@mthbernardes , thanks! We will contact GH to fix the properties problem.
from clj-watson.
Hi @yongyan-gh
Not sure if sarif is a good call to clj-watson
since it's kind of a dependabot focused on clojure.
It was the main reason for me not to implement the sarif output.
from clj-watson.
Hi @mthbernardes ,
The idea is to use clj-watson in PRs with the SARIF integration and send the data to GHAS. This will create security alert notifications during PR, which would facilitate a lot and prevent anyone from check-in vulnerable packages.
from clj-watson.
Hm I thought that since the sarif upload was only available for the code scanning functionality it would only make sense to send code analyses and not vulnerable dependencies.
But if u guy think that it's a good idea I'll start implementing it.
from clj-watson.
This is an example of clj-watson output.
[
{
"dependency": "com.fasterxml.jackson.core/jackson-databind",
"dependents": [
"com.auth0/java-jwt"
],
"paths": [
"/Users/username/.m2/repository/com/fasterxml/jackson/core/jackson-databind/2.9.8/jackson-databind-2.9.8.jar"
],
"secure-version": {
"mvn/version": "2.13.1"
},
"deps/manifest": "mvn",
"mvn/version": "2.9.8",
"parents": [
[
"com.auth0/java-jwt"
]
],
"remediate-suggestion": {
"com.auth0/java-jwt": {
"exclusions": [
"com.fasterxml.jackson.core/jackson-databind"
]
},
"com.fasterxml.jackson.core/jackson-databind": {
"mvn/version": "2.13.1"
}
},
"vulnerabilities": [
{
"vulnerableVersionRange": ">= 2.0.0, < 2.9.9",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 7.5
},
"identifiers": [
{
"value": "GHSA-5ww9-j83m-q7qx"
},
{
"value": "CVE-2019-12086"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.9"
}
},
{
"vulnerableVersionRange": "< 2.9.10",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-85cw-hj65-qqv9"
},
{
"value": "CVE-2019-16335"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10"
}
},
{
"vulnerableVersionRange": "< 2.9.10",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-h822-r4r5-v8jg"
},
{
"value": "CVE-2019-14540"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.1",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-gww7-p5w4-wrfv"
},
{
"value": "CVE-2019-20330"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.2"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.2",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-4w82-r329-3q67"
},
{
"value": "CVE-2020-8840"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.3"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.10.3",
"advisory": {
"severity": "MODERATE",
"cvss": {
"score": 0
},
"identifiers": [
{
"value": "GHSA-fqwf-pjwf-7vqv"
},
{
"value": "CVE-2020-10673"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, < 2.9.10",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 0
},
"identifiers": [
{
"value": "GHSA-qmqc-x3r4-6v39"
},
{
"value": "CVE-2019-14893"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.10.3",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-q93h-jc49-78gg"
},
{
"value": "CVE-2020-9547"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.8
},
"identifiers": [
{
"value": "GHSA-95cm-88f5-f2c7"
},
{
"value": "CVE-2020-10672"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-h4rc-386g-6m85"
},
{
"value": "CVE-2020-11620"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.10.3",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-p43x-xfjf-5jhr"
},
{
"value": "CVE-2020-9548"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-5p34-5m6p-p58g"
},
{
"value": "CVE-2020-9546"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.8
},
"identifiers": [
{
"value": "GHSA-758m-v56v-grj4"
},
{
"value": "CVE-2020-10969"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, < 2.9.10",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 7.5
},
"identifiers": [
{
"value": "GHSA-cf6r-3wgc-h863"
},
{
"value": "CVE-2019-14892"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.8
},
"identifiers": [
{
"value": "GHSA-rf6r-2c4q-2vwg"
},
{
"value": "CVE-2020-10968"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.8
},
"identifiers": [
{
"value": "GHSA-v3xw-c963-f5hc"
},
{
"value": "CVE-2020-11111"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.8
},
"identifiers": [
{
"value": "GHSA-9vvp-fxw6-jcxr"
},
{
"value": "CVE-2020-11113"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-27xj-rqx5-2255"
},
{
"value": "CVE-2020-11619"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.3",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.8
},
"identifiers": [
{
"value": "GHSA-58pp-9c76-5625"
},
{
"value": "CVE-2020-11112"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.4"
}
},
{
"vulnerableVersionRange": "< 2.9.10",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-f3j5-rmmp-3fc5"
},
{
"value": "CVE-2019-17267"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.4",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-mc6h-4qgp-37qh"
},
{
"value": "CVE-2020-14195"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.5"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.4",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-j823-4qch-3rgm"
},
{
"value": "CVE-2020-14060"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.5"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.4",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-c265-37vj-cwcc"
},
{
"value": "CVE-2020-14062"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.5"
}
},
{
"vulnerableVersionRange": ">= 2.9.0, <= 2.9.10.4",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-c2q3-4qrh-fm48"
},
{
"value": "CVE-2020-14061"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.5"
}
},
{
"vulnerableVersionRange": "<= 2.9.10.6",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 0
},
"identifiers": [
{
"value": "GHSA-5949-rw7g-wx7w"
},
{
"value": "CVE-2021-20190"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.7"
}
},
{
"vulnerableVersionRange": ">= 2.7.0.0, <= 2.9.10.6",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 7.5
},
"identifiers": [
{
"value": "GHSA-288c-cq4h-88gq"
},
{
"value": "CVE-2020-25649"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.7"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-vfqx-33qm-g869"
},
{
"value": "CVE-2020-36189"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-r695-7vr9-jgc2"
},
{
"value": "CVE-2020-36187"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-f9xh-2qgp-cq57"
},
{
"value": "CVE-2020-36188"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-9m6f-7xcq-8vf8"
},
{
"value": "CVE-2020-36183"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-m6x4-97wx-4q27"
},
{
"value": "CVE-2020-36184"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-8c4j-34r4-xr8g"
},
{
"value": "CVE-2020-36180"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-cvm9-fjm9-3572"
},
{
"value": "CVE-2020-36181"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-8w26-6f25-cm9x"
},
{
"value": "CVE-2020-36185"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-9gph-22xh-8x98"
},
{
"value": "CVE-2020-36179"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-89qr-369f-5m5x"
},
{
"value": "CVE-2020-36182"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0, <= 2.9.10.5",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-qjw2-hr98-qgfh"
},
{
"value": "CVE-2020-24750"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.6"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-r3gr-cxrf-hg25"
},
{
"value": "CVE-2020-35491"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.10.7",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-wh8g-3j2c-rqj5"
},
{
"value": "CVE-2020-35490"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.8"
}
},
{
"vulnerableVersionRange": "<= 2.9.9.1",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 7.5
},
"identifiers": [
{
"value": "GHSA-gwp4-hfv6-p7hw"
},
{
"value": "CVE-2019-14439"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.9.2"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.9",
"advisory": {
"severity": "MODERATE",
"cvss": {
"score": 5.9
},
"identifiers": [
{
"value": "GHSA-cmfg-87vq-g5g4"
},
{
"value": "CVE-2019-12814"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.9.1"
}
},
{
"vulnerableVersionRange": "<= 2.9.9",
"advisory": {
"severity": "MODERATE",
"cvss": {
"score": 5.9
},
"identifiers": [
{
"value": "GHSA-mph4-vhrx-mv67"
},
{
"value": "CVE-2019-12384"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.9.1"
}
},
{
"vulnerableVersionRange": "<= 2.9.10.0",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-gjmw-vf9h-g25v"
},
{
"value": "CVE-2019-17531"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.1"
}
},
{
"vulnerableVersionRange": "<= 2.9.10.0",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-fmmc-742q-jg75"
},
{
"value": "CVE-2019-16943"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.1"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.10",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-mx7p-6679-8g3q"
},
{
"value": "CVE-2019-16942"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.1"
}
},
{
"vulnerableVersionRange": "<= 2.9.9.1",
"advisory": {
"severity": "CRITICAL",
"cvss": {
"score": 9.8
},
"identifiers": [
{
"value": "GHSA-6fpp-rgj9-8rwc"
},
{
"value": "CVE-2019-14379"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.9.2"
}
},
{
"vulnerableVersionRange": ">= 2.0.0, <= 2.9.10.5",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 8.1
},
"identifiers": [
{
"value": "GHSA-h3cw-g4mq-c5x2"
},
{
"value": "CVE-2020-24616"
}
]
},
"firstPatchedVersion": {
"identifier": "2.9.10.6"
}
}
]
},
{
"mvn/version": "42.2.10",
"deps/manifest": "mvn",
"parents": [
[]
],
"paths": [
"/Users/username/.m2/repository/org/postgresql/postgresql/42.2.10/postgresql-42.2.10.jar"
],
"dependency": "org.postgresql/postgresql",
"vulnerabilities": [
{
"vulnerableVersionRange": ">= 9.4.1208, < 42.2.25",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 7
},
"identifiers": [
{
"value": "GHSA-v7wg-cpwc-24m4"
},
{
"value": "CVE-2022-21724"
}
]
},
"firstPatchedVersion": {
"identifier": "42.2.25"
}
},
{
"vulnerableVersionRange": "< 42.2.13",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 7.7
},
"identifiers": [
{
"value": "GHSA-88cc-g835-76rp"
},
{
"value": "CVE-2020-13692"
}
]
},
"firstPatchedVersion": {
"identifier": "42.2.13"
}
},
{
"vulnerableVersionRange": ">= 42.1.0, < 42.3.3",
"advisory": {
"severity": "MODERATE",
"cvss": {
"score": 0
},
"identifiers": [
{
"value": "GHSA-673j-qm5f-xpv8"
}
]
},
"firstPatchedVersion": {
"identifier": "42.3.3"
}
}
],
"secure-version": {
"mvn/version": "42.3.3"
},
"remediate-suggestion": {
"org.postgresql/postgresql": {
"mvn/version": "42.3.3"
}
}
},
{
"dependency": "com.taoensso/nippy",
"dependents": [
"com.taoensso/carmine"
],
"paths": [
"/Users/username/.m2/repository/com/taoensso/nippy/2.14.0/nippy-2.14.0.jar"
],
"secure-version": {
"mvn/version": "3.1.1"
},
"deps/manifest": "mvn",
"mvn/version": "2.14.0",
"parents": [
[
"io.replikativ/datahike",
"io.replikativ/hitchhiker-tree",
"com.taoensso/carmine"
]
],
"remediate-suggestion": {
"io.replikativ/datahike": {
"exclusions": [
"com.taoensso/carmine"
]
},
"com.taoensso/carmine": {
"mvn/version": "3.2.0-SNAPSHOT"
}
},
"vulnerabilities": [
{
"vulnerableVersionRange": "< 2.14.2",
"advisory": {
"severity": "HIGH",
"cvss": {
"score": 7.8
},
"identifiers": [
{
"value": "GHSA-p5gm-fgfx-hr7h"
},
{
"value": "CVE-2020-24164"
}
]
},
"firstPatchedVersion": {
"identifier": "2.14.2"
}
}
]
}
]
It does not contains a few data necessary to sarif output, like line information and the rule is basically a public cve/github advisory.
from clj-watson.
Hm I thought that since the sarif upload was only available for the code scanning functionality it would only make sense to send code analyses and not vulnerable dependencies. But if u guy think that it's a good idea I'll start implementing it.
This is like https://github.com/aquasecurity/trivy, which analyzes container package dependencies checking for vulnerabilities.
My thoughts were:
- you as a developer change some packages in a PR, where one of those is vulnerable
- GH Action runs and outputs a SARIF
- GH fails the checks since u have a vulnerable package
let us know if you want us to do that work or if u are going to do it. :)
from clj-watson.
I've just implemented it on PR #19 and made a alpha release https://github.com/clj-holmes/clj-watson/releases/tag/v3.0.2-ALPHA
Now you're able to test it and check if I did everything right :)
from clj-watson.
I generated a report and tested it in this site and the results were detected.
But I created a public repository with a action to run clj-watson to test the sarif upload and everything seems to work but no alert appeared on code scanning interface.
from clj-watson.
output example:
{
"$schema": "https://www.schemastore.org/schemas/json/sarif-2.1.0-rtm.5.json",
"version": "2.1.0",
"runs": [
{
"tool": {
"driver": {
"name": "clj-watson",
"informationUri": "https://github.com/clj-holmes/clj-watson",
"version": "3.0.1",
"rules": [
{
"id": "GHSA-p5gm-fgfx-hr7h",
"name": "VulnerableDependencyNippy",
"shortDescription": {
"text": "Gadget chain attack in Nippy"
},
"fullDescription": {
"text": "A deserialization flaw is present in Taoensso Nippy before 2.14.2. In some circumstances, it is possible for an attacker to create a malicious payload that, when deserialized, will allow arbitrary code to be executed. This occurs because there is automatic use of the Java Serializable interface."
},
"help": {
"text": "Vulnerability found in package com.taoensso/nippy"
},
"helpUri": "https://github.com/advisories/GHSA-p5gm-fgfx-hr7h",
"properties": {
"security-severity": 7.8
},
"defaultConfiguration": {
"level": "error"
}
}
]
}
},
"results": [
{
"ruleId": "GHSA-p5gm-fgfx-hr7h",
"message": {
"text": "Vulnerability found in package com.taoensso/nippy"
},
"locations": [
{
"physicalLocation": {
"artifactLocation": {
"uri": "deps.edn"
},
"region": {
"startLine": 5,
"endLine": 5,
"startColumn": 12,
"endColumn": 34
}
}
}
]
}
]
}
]
}
from clj-watson.
@yongyan-gh , can you test as well?
from clj-watson.
@mthbernardes , can you add one configuration in ur sarif-upload:
wait-for-processing: true
let's see if we get a result.
Otherwise, I can ask someone from GH to help us.
from clj-watson.
@mthbernardes the output looks pretty good, verified using validator, and looks fine in SARIF web viewer and VS viewer.
Only issue is when open the generated SARIF file in VS Code. it complains about the schema.
I replaced the schema in the file (https://www.schemastore.org/schemas/json/sarif-2.1.0-rtm.5.json) with another Uri (https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.5.json) it works for VS code.
I think its an problem with VS code, the SARIF file is valid. When you open new Uri actually redirects to the old Uri.
I tried the create similar workflow @mthbernardes created in another test repo, I see the same issue:
No alert created in Security -> Code scanning alert, even the workflow generated SARIF contains error results and uploaded to GitHub successfully.
Also tried the SARIF file with updated schema Uri, got same issue.
According to GitHub's document https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning , all the required fields are provided in SARIF file.
@eddynaka I haven't seen this kind of issue before, may need GH team to take a look.
Attached the sample SAIRF generated using clj-watson. Artifact
from clj-watson.
btw I investigate further and found an error while uploading clj-watson's SARIF results (github/codeql-action/upload-sarif@v1):
Waiting for processing to finish
Analysis upload status is failed.
Error: Code Scanning could not process the submitted SARIF file:
parsing restricted subset of SARIF data has failed: parse error: expected string near offset 768 of '7.8'
Error: Code Scanning could not process the submitted SARIF file:
parsing restricted subset of SARIF data has failed: parse error: expected string near offset 768 of '7.8'
at Object.waitForProcessing (/home/runner/work/_actions/github/codeql-action/v1/lib/upload-lib.js:3[23](https://github.com/yongyan-gh/clojurescript/runs/5418124043?check_suite_focus=true#step:8:23):23)
at async run (/home/runner/work/_actions/github/codeql-action/v1/lib/upload-sarif-action.js:53:13)
at async runWrapper (/home/runner/work/_actions/github/codeql-action/v1/lib/upload-sarif-action.js:68:9)
The issue seems caused by SARIF file has a property bag "security-severity" value is 7.8
"rules": [
{
"id": "GHSA-p5gm-fgfx-hr7h",
"name": "VulnerableDependencyNippy",
"shortDescription": {
"text": "Gadget chain attack in Nippy"
},
"fullDescription": {
"text": "A deserialization flaw is present in Taoensso Nippy before 2.14.2. In some circumstances, it is possible for an attacker to create a malicious payload that, when deserialized, will allow arbitrary code to be executed. This occurs because there is automatic use of the Java Serializable interface."
},
"help": {
"text": "Vulnerability found in package com.taoensso/nippy"
},
"helpUri": "https://github.com/advisories/GHSA-p5gm-fgfx-hr7h",
"properties": {
"security-severity": 7.8
},
"defaultConfiguration": {
"level": "error"
}
}
]
The value of property bags can be a float/double number according to SARIF spec. Seems GitHub cannot parse it somehow.
In GitHub's document the sample property bags has "security-severity" value as string:
{
"id": "R01"
...
"properties" : {
"id" : "java/unsafe-deserialization",
"kind" : "path-problem",
"name" : "...",
"problem.severity" : "error",
"security-severity" : "9.8",
}
@mthbernardes if you can remove this property or convert it to string in your branch, we can try again to see if it works.
from clj-watson.
@mthbernardes I found other issues in clj-watson's SARIF report when I use parameter --database-strategy dependency-check
. The rule's short description text is set to null and region of some results is set to null.
Please see the sample SARIF file: clj-watson2.zip
To summary all above issues below, please take a look.
- Update schema Uri to "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.5.json"
- Convert properties values to string if they are not.
- The rule's short description is set to null when database-strategy parameter set to
dependency-check
- The region of some results is set to null when database-strategy parameter set to
dependency-check
from clj-watson.
Thx for all the help @yongyan-gh @eddynaka it's now working.
from clj-watson.
The rule help text markdown looks very nice in code scanning alert page!
I still see issues with parameter --database-strategy dependency-check
.
The rule id is set to null
and one of result's region is null
.
Here is the link to workflow run.
Can you pls take a look?
[build](https://github.com/yongyan-gh/clojurescript/runs/5429770377?check_suite_focus=true)
Unable to upload "results.sarif" as it is not valid SARIF:
- instance.runs[0].tool.driver.rules[0].id is not of a type(s) string
- instance.runs[0].tool.driver.rules[1].id is not of a type(s) string
- instance.runs[0].tool.driver.rules[2].id is not of a type(s) string
- instance.runs[0].tool.driver.rules[3].id is not of a type(s) string
- instance.runs[0].results[0].ruleId is not of a type(s) string
- instance.runs[0].results[1].ruleId is not of a type(s) string
- instance.runs[0].results[2].ruleId is not of a type(s) string
- instance.runs[0].results[3].ruleId is not of a type(s) string
- instance.runs[0].results[3].locations[0].physicalLocation.region is not of a type(s) object
from clj-watson.
@mthbernardes do you plan to merge the changes from your branch to the main branch and create an official release?
Or you'd like to the action/starter workflow to reference to the alpha version?
actions/starter-workflows#1460
- name: Dependency scan
uses: clj-holmes/clj-watson-action@992d0e6270ab50ac6f7d8709f323a77cfa816b66
with:
clj-watson-sha: "992d0e6"
clj-watson-tag: "v3.0.2-ALPHA"
database-strategy: github-advisory
aliases: clojure-lsp,test
deps-edn-path: deps.edn
suggest-fix: true
output-type: sarif
output-file: clj-watson-results.sarif
fail-on-result: 'true'
from clj-watson.
I'll merge the PR without the sarif support to dependency-check scan and create a new issue for it.
from clj-watson.
Thank you @mthbernardes, can you pls also publish a new release of clj-watson-action with the new output-file
argument change?
from clj-watson.
Related Issues (14)
- comparing version in a really wrong way. HOT 1
- Sorted report
- Project- and version-based false positives when shadow-cljs is a dependency HOT 5
- support sarif output for dependency-check scan strategy HOT 1
- CVE identifiers are missing in 3.0.2 output HOT 9
- core.async false positive HOT 3
- Can't run clj-watson as a -M alias HOT 2
- Bug in 4.1.1? HOT 4
- Unable to update watson database, version exceeds column limit HOT 1
- depstar is archived/deprecated and will get no updates HOT 1
- Compare/contrast with nvd-clojure in README? HOT 4
- missing LICENSE file
- Breaks on datahike dep HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from clj-watson.