microsoft / sarif-web-component Goto Github PK
View Code? Open in Web Editor NEWA React-based component for viewing SARIF files.
License: MIT License
A React-based component for viewing SARIF files.
License: MIT License
The attached SARIF file highlight.sarif.txt describes an issue in the attached source file highlight.cs.txt.
In the Web viewer, the correct range of 5 characters is highlighted:
But when I file a bug in ADO and attach the same SARIF file, the Scans Tab highlights only three columns:
This allows for frequent updates to the site, while not having those updates clutter the commit history for this repo.
@jeffersonking thinks this is a regression.
My recommendation would be to open the URLs open in a new tab so that we don’t lose context of our results.
On Azure DevOps the links from scan tab after running pipeline to the files from repo do not contain branch data and provide to the last chosen repository.
The versionControlProvenance is filled in the following way:
"versionControlProvenance": [{ "repositoryUri": "https://dev.azure.com/xtest-devel/example/_git/example", "branch": "refs/heads/main", "mappedTo": { "uriBaseId": "ROOT_1_main" } } ],
The locatins part from results is filled in the following way:
"results": [{ "locations": [{ "physicalLocation": { "artifactLocation": { "uri": "demo/src/main/java/examples/nbank/Customer.java", "uriBaseId": "ROOT_1_main" }, "region": { "startLine": 89, "startColumn": 41, "endColumn": 42 } } } ] }]
Scan tabs looks like on the screenshot
The produced link for demo/src/main/java/examples/nbank/Customer.java is like this:
https://dev.azure.com/devel/example/_git/example?path=demo%2Fsrc%2Fmain%2Fjava%2Fexamples%2Fnbank%2FCustomer.java
Deep linking to the line numbers is not working in the published version of this extension (as of 5/24/2022).
I see the code to support ADO line numbers here:
However, that code is missing in the github-pages deployment on December 14th: https://github.com/microsoft/sarif-web-component/deployments/activity_log?environment=github-pages
(Checked using Edge DevTools).
This must be a bug with github-pages or in the deployment process since github says the version deployed should support line numbers.
Can confirm the support for line numbers is deployed to github-pages and in the latest version of the extensions (Especially the ADO extension)? I would appreciate it as the feature will make following-up on reports faster!
Test with the attached Results.sarif.txt file (remove .txt
extension): check that the link generated by the UI is missing the line number.
When we navigate to "Clear Filters" button and "1" control using Tab key tooltip appears but we are not able to dismiss the tooltip of "Clear Filters" button and "1" control using the "Esc" key
The user should be able to dismiss the tooltip of "Clear Filters" button and "1" control using the "Esc" key
Azure DevOps provided multiconfiguration pipelines. These pipelines will execute multiple configuration (such as debug & release) for a build. These distinct configurations potentially produce multiple log files that should be aggregated together in the viewer. Generally, however, it does not make sense to merge the logs from two build configurations.
For example, a pipeline might support a debug and a retail build. Each build might produce a log file for Binskim and for Roslyn. The viewer should either show the merged results for the debug Binskim/Roslyn files or the merged release Binskim/Roslyn log files.
SARIF provides a logical id that can be used to understand the broader set of log files to which a specific tool log belongs. This could be one mechanism to solve the problem (but will require results producers to properly emit SARIF that organizes results).
Alternately, configurations could be inferred from output location, file name convention, or some other mechanism.
There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.
Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.
When a result has kind
equal to "review"
, the extension displays it as "informational". But in fact, a "review"
result should be displayed as "warning", because it means that it's an issue that requires human review to determine if there's actually a problem.
The guidance for viewers is:
Here is how the viewer should treat results with a kind
value other than "fail"
:
kind value |
Viewer treatment |
---|---|
"notApplicable" |
Informational |
"open" |
Warning [1] |
"pass" |
Informational [2] |
"review" |
Warning |
[1] Because this value means that the tool didn't have enough information to know if there was a problem. This is used by program correctness provers. If a prover doesn't know (for example), if a particular function can throw an exception, it might not be able to decide whether a code path is safe.
[2] But I think the web viewer already shows a green check-mark for a "pass" results, right? This is good.
@michaelcfanning FYI
Repro steps:
Sarif sample to repro this issue:
{
"$schema": "https://schemastore.azurewebsites.net/schemas/json/sarif-2.1.0-rtm.5.json",
"version": "2.1.0",
"runs": [
{
"results": [
{
"ruleId": "rule01",
"level": "error",
"message": {
"text": "test text."
},
"locations": [
{
"physicalLocation": {
"artifactLocation": {
"uri": ".config/CredScanSuppressions.json",
"uriBaseId": "TARGETROOT",
"index": 0
},
"region": {
"startColumn": 10,
"endColumn": 147,
"snippet": {
"text": "Test text."
}
}
}
}
]
}
],
"tool": {
"driver": {
"name": "Code Analysis"
}
},
"originalUriBaseIds": {
"TARGETROOT": {
"uri": "https://dev.azure.com/mseng/_git/AzureDevOps?path="
}
},
"artifacts": [
{
"location": {
"uri": ".config/CredScanSuppressions.json",
"uriBaseId": "TARGETROOT"
}
}
],
"columnKind": "utf16CodeUnits"
}
]
}
Expected behavior:
On clicking the file path, we should navigate to the proper URL relative to the value of uriBaseID.
e.g. in above exampl, it shoulde be:
https://dev.azure.com/mseng/_git/AzureDevOps?path=.config/CredScanSuppressions.json
Actual behavior:
Incorrect navigation URL is created relative to the sarif view website instead.
If an issue does not have an associated snippet there is no information given about the line/column for the issue. It is embedded instead in the link shown.
It would be great for embedded snippets to have syntax highlighting applied to them to make it easier to read the code.
The SARIF spec allows for a Result to omit the locations
property (it says that results SHOULD include it, rather than SHALL or MUST include it). However, parsing.ts
line 53 unconditionally runs const loc0 = r.locations[0]
on all results it parses, and emits an error like this if there is a result with no locations property:
parsing.ts:50 Uncaught (in promise) TypeError: Cannot read property '0' of undefined
at eval (parsing.ts:50)
at Array.map (<anonymous>)
at eval (parsing.ts:48)
at Array.map (<anonymous>)
at Object.parse (parsing.ts:31)
at async eval (ResultsViewer.tsx:28)
The viewer should treat such results the same as it does results with an empty locations array.
Consider the following screenshot which renders a snippet from a json file. The word "any" is highlighted as if it was a special keyword, but there is no relevance of this word in json file type.
The same is true for other words, like "with", "case", "in".
Expected:
These keywords should be rendered in color only when relevant (e.g. if c# file).
When the result location is at the root of the scan (for example, you scan everything under https://mySite
, and you find a problem in the root URL https://mySite
itself), then the viewer leaves the File column blank (because it always displays the result location relative to the root). Instead, it should display the root URL in that situation.
@jeffersonking says this is NYI.
For triaging, especially a large sarif, it is helpful to be able to filter based on attributes of the results.
xxx@xxx:~/projects/sarif$ npm install @microsoft/sarif-web-component
npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@microsoft%2fsarif-web-component - Not found
Are there any plans or would you consider adding support for SARIF v1.0.0 files?
In the Scans tab we are currently reaching the intended pre-SARIF-2.1 warning message:
sarif-web-component/components/Viewer.tsx
Line 130 in 8ac57c8
The given control type for "Filter" control is "Group" but this control is working as a "Button"
The correct control type should be provided for the "Filter" control that is "Button".
Hi. I'm using this component on my website to show some scanning results, and now I'm facing a problem. Comparing to the Sarif VSCode extension, I found this component does not show code flows, is there any solution to support this property ?
sarif file:
{ "schema": "https://json.schemastore.org/sarif-2.1.0.json", "version": "2.1.0", "runs": [{ "tool": { "driver": { "name": "CODEQL", "organization": "sast", "semanticVersion": "2.4.1", "rules": [{ "id": "11", "name": "go命令执行", "shortDescription": { "text": "go命令执行", "markdown": "" }, "fullDescription": { "text": "", "markdown": "漏洞详情:\n + 要点1:[参考链接](https://domain.com/)\n ```go\nfmt.Println(\"aaa\")\n```\n + 要点2:测试" }, "defaultConfiguration": { "enabled": true, "level": "error" }, "properties": { "ruleKey": "go-exec-cmd", "riskLevel": 3, "tags": [ "security", "cwe-078" ] } }, { "id": "12", "name": "go测试规则", "shortDescription": { "text": "go测试规则", "markdown": "" }, "fullDescription": { "text": "测试规则描述", "markdown": "" }, "defaultConfiguration": { "enabled": true, "level": "warning" }, "properties": { "ruleKey": "go-test-rule", "riskLevel": 2, "tags": [ "security", "test" ] } } ] } }, "artifacts": [{ "location": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" } }, { "location": { "uri": "handler/handler.go", "uriBaseId": "%SRCROOT%" } }, { "location": { "uri": "api/infra/zebra/zebra.pb.go", "uriBaseId": "%SRCROOT%" } } ], "results": [{ "ruleId": "11", "fingerprints": { "vulId": "2354" }, "hostedViewerUri": "http://domain.com/result?id=2354", "message": { "text": "命令执行时接受外部[输入参数](1),最终执行到[系统调用](2)" }, "locations": [{ "physicalLocation": { "artifactLocation": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 22, "startColumn": 43, "endColumn": 50, "endLine": 22, "snippet": "master.Bind(\\\"zebra_post\\\").Insert" } } }], "partialFingerprints": { "primaryLocationLineHash": "d11dee0b20ca483:1", "primaryLocationStartColumnFingerprint": "13" }, "codeFlows": [{ "threadFlows": [{ "locations": [{ "location": { "physicalLocation": { "artifactLocation": { "uri": "handler/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 20, "startColumn": 48, "endColumn": 51, "endLine": 20, "snippet": "" } }, "message": { "text": "污点源变量req" } } }, { "location": { "physicalLocation": { "artifactLocation": { "uri": "api/infra/zebra/zebra.pb.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 131, "startColumn": 7, "endColumn": 8, "endLine": 131, "snippet": "" } }, "message": { "text": "污点传播定义x" } } }, { "location": { "physicalLocation": { "artifactLocation": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 22, "startColumn": 43, "endColumn": 50, "endLine": 22, "snippet": "" } }, "message": { "text": "污点汇聚点content" } } } ] }] }], "relatedLocations": [{ "id": 1, "physicalLocation": { "artifactLocation": { "uri": "handler/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 20, "startColumn": 48, "endColumn": 51, "endLine": 20, "snippet": "" } }, "message": { "text": "外部污点参数" } }, { "id": 2, "physicalLocation": { "artifactLocation": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 22, "startColumn": 43, "endColumn": 50, "endLine": 22, "snippet": "" } }, "message": { "text": "系统调用点" } } ] }, { "ruleId": "12", "fingerprints": { "vulId": "2355" }, "hostedViewerUri": "http://domain.com/result?id=2355", "message": { "text": "命令执行[用户外部输入参数](1)" }, "locations": [{ "physicalLocation": { "artifactLocation": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 36, "startColumn": 15, "endColumn": 18, "endLine": 36, "snippet": "e.Bind()" } } }], "partialFingerprints": { "primaryLocationLineHash": "d8df578734f98695:1", "primaryLocationStartColumnFingerprint": "13" }, "codeFlows": [{ "threadFlows": [{ "locations": [{ "location": { "physicalLocation": { "artifactLocation": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 32, "startColumn": 9, "endColumn": 39, "endLine": 32, "snippet": "" } }, "message": { "text": "调用GetRPCMeta" } } }, { "location": { "physicalLocation": { "artifactLocation": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 36, "startColumn": 15, "endColumn": 18, "endLine": 36, "snippet": "" } }, "message": { "text": "污点传播定义x" } } } ] }] }], "relatedLocations": [{ "id": 1, "physicalLocation": { "artifactLocation": { "uri": "model/handler.go", "uriBaseId": "%SRCROOT%" }, "region": { "startLine": 32, "startColumn": 9, "endColumn": 39, "endLine": 32, "snippet": "" } }, "message": { "text": "grpc入参" } }] } ] }] }
NVDA is announcing the incorrect heading levels for the headings "WebScout" and "Recommendation". NVDA is announcing "heading level 1" for "WebScout" and "heading level 2" for "Recommendation".
Similar issue is also observed with Chromium Edge + Narrator.
NVDA should not announce the correct heading levels for the headings "WebScout" and "Recommendation". NVDA should announce "heading level 2" for "WebScout" and "heading level 3" for "Recommendation".
Repro:
.sarif
.Expected:
Actual:
A result should be shown unless it has at least one suppression whose status
is either missing or accepted
.
If you open this SARIF file:
SnippetWithLeadingWhiteSpace.sarif.txt
... in VS and click on the one result, you see this:
... which is right. But the Web viewer strips the leading white space from the offending line, but doesn't adjust the highlight position, so you see this:
When results have ruleIds that include sub-rules (e.g., "TST1001/cpp
"), then when Group by rule is selected, the viewer should group by sub-rule.
It's not clear whether we should the grouping should look like this (hierarchical):
TST1001
cpp
cs
TST1002
cpp
or like this (flat):
TST1001/cpp
TST1001/cs
TST1002/cpp
@michaelcfanning FYI
Labeled as both bug
and enhancement
. What it's doing now is definitely a bug; what we want is a new feature.
I am trying to embed the sarif component in material UI full-screen dialog. However every time I click on anything in the filter bar it flickers open and closed.
I tried looking at azure-devops-ui package, however, the GitHub repo is private and only the package is published.
@jeffersonking, would love if you might be able to point me in the right direction on how I can debug and then potentially send a fix.
When "Unsuppressed" and "Suppressed" control receives the keyboard focus, the color contrast ratio of border with respect to background is 1.627:1 which is less than 3:1.
When "Unsuppressed" and "Suppressed" control receives the keyboard focus, the color contrast ratio of border with respect to background should be greater than or equal to 3:1.
We're using the Sarif Viewer Build Tab within our Azure DevOps build pipeline.
In our SARIF file, we have some errors that we suppressed as they only exist in unit tests and are not true vulnerabilities. This leads to the following output in the SARIF file:
"suppressions" : [ {
"kind" : "inSource"
} ]
However, the issue still shows up on the Scans tab, which indicates that the suppression isn't being respected.
Please let me know if this issue should instead be filed under the Sarif Viewer Build Tab GitHub project or elsewhere.
DefaultRuleConfiguration.sarif.txt
In the attached sample, there are two rules, one whose defaultConfiguration
specifies that it is an error and the other a warning. The results do not specify level. The viewer renders the results for both rules as warnings.
Keyboard focus is not visible on "Path", "Details" and "WS1138: UseHttpOnlyCookieAttribute" controls in high contrast black/white mode using Tab key
Keyboard focus should be clearly visible on"Path", "Details" and "WS1138: UseHttpOnlyCookieAttribute" controls in high contrast black/white mode using Tab key
We have a sarif file which has file content embedded. When viewed in the web viewer (using scans tab), the file link in points to this location:
Expected:
If possible to view this in some way, the actual file content (that can be extracted from the sarif file) should be viewable.
If it is not possible, we should remove the hyperlink from the scans tab file name.
Here is example of one such case:
https://secretscantest.visualstudio.com/SecDevOps/_build/results?buildId=1317&view=sariftools.sarif-viewer-build-tab.sariftools.sarif-viewer-build-tab
The associated sarif ifle can be downloaded from here:
https://secretscantest.visualstudio.com/SecDevOps/_build/results?buildId=1317&view=artifacts&type=publishedArtifacts
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.