Make it easier to use csaf_distribution as go library to access CSAF file contents #367
Comments
Ideas and considerations
|
publish the module on https://pkg.go.dev upstream stepsSee following reports that affect us: |
|
With the new https://github.com/csaf-poc/csaf_distribution/releases/tag/v2.2.0 release and #371 done, we are now listed on https://pkg.go.dev/github.com/csaf-poc/csaf_distribution/v2 @knqyf263 @mpermar @beltran-rubo with the above improvements, you shall be able to technically experiment using the csaf_distribution v2 code as go modules. Note that this is not an official API. Still experimenting with it, may help you to see how close we are already to a usable library. |
|
@tschmidtb51 this issue itself is a rough concept of how to access go as a library. My suggestion is: We remove the service+dev label, as the part of doing a rough concept is done. And then we rename the issue to something like "Make it easier to use csaf_distribution as go library to access CSAF file contents". Because the links are useful to keep in an open issue. |
tschmidtb51
changed the title
|
@bernhardreiter I've been looking at the code, and to be honest I never have done much golang so it is pretty likely that I'm missing the obvious here, but any hints on how could I use the library? The typical use case for supporting Trivy VEX filtering flow is to read a CSAF VEX file, then loop over the product tree finding purl packages and use that information to match vulnerabilities and detect which vulnerabilities can be filtered out through the VEX statuses. And finally the VEX code returns the filtered list of vulnerabilities. This can be seen here for CycloneDX and OpenVex. When looking at the csaf package, I'm not totally sure how I can import a struct that I could use for unmarshalling the CSAF file and run the logic above. {
"document": {
"category": "csaf_vex",
"csaf_version": "2.0",
"notes": [
{
"category": "summary",
"text": "Example Company VEX document. Unofficial content for demonstration purposes only.",
"title": "Author comment"
}
],
"publisher": {
"category": "vendor",
"name": "Example Company ProductCERT",
"namespace": "https://psirt.example.com"
},
"title": "AquaSecurity example VEX document",
"tracking": {
"current_release_date": "2022-03-03T11:00:00.000Z",
"generator": {
"date": "2022-03-03T11:00:00.000Z",
"engine": {
"name": "Secvisogram",
"version": "1.11.0"
}
},
"id": "2022-EVD-UC-01-A-001",
"initial_release_date": "2022-03-03T11:00:00.000Z",
"revision_history": [
{
"date": "2022-03-03T11:00:00.000Z",
"number": "1",
"summary": "Initial version."
}
],
"status": "final",
"version": "1"
}
},
"product_tree": {
"branches": [
{
"branches": [
{
"branches": [
{
"category": "product_version",
"name": "2.6.0",
"product": {
"name": "Spring Boot 2.6.0",
"product_id": "SPB-00260",
"product_identification_helper": {
"purl": "pkg:maven/org.springframework.boot/[email protected]"
}
}
}
],
"category": "product_name",
"name": "Spring Boot"
}
],
"category": "vendor",
"name": "Spring"
}
]
},
"vulnerabilities": [
{
"cve": "CVE-2021-44228",
"notes": [
{
"category": "description",
"text": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.",
"title": "CVE description"
}
],
"product_status": {
"known_not_affected": [
"SPB-00260"
]
},
"threats": [
{
"category": "impact",
"details": "Class with vulnerable code was removed before shipping.",
"product_ids": [
"SPB-00260"
]
}
]
}
]
} |
|
To add on the above. Here is a possible implementation on CSAF filtering based on very simple and incomplete structs. I've just gone and make the basic filtering unit test pass just to make the point and better express the use case. As you will notice, the code essentially loops over CVEs from a Trivy report and then for each of the CVEs it tries to find if exists a VEX statement for that CVE id marked as That test is passing but using hardcoded structs on Trivy itself. The model plus the utility methods to work through the model is what I would expect from a CSAF golang library. One of those utilities could be perhaps for example find the identifications (purls, cpes, sbom_urls) for a given vulnerability id. Just like the code tries naively to do here. |
|
@mpermar though we believe to have a pretty complete model to be useful, there maybe model parts missing depending on the use case. So thanks a lot for your question and the details in the request! (The last weeks were summer holiday time here in Germany. So we can only start to look at this in the next days.) One goal of this issue is to find out what is missing (in terms of model parts, helping functions, documentation or whatever) to make this a useful library. Please keep in mind that csaf_distribution does not promise an API currently, only experimental access to the internal possibilities. ;) |
|
Hey @bernhardreiter , likewise on PTO here for the next few days, but just wanted to chime in to mention that if I recall it right pretty much most of the VEX profile objects were missing so the example above could not be implemented. Have a look at the code. General CSAF concepts like |
thanks for adding more detail. I think our devs are also thinking along those lines and we see if someone can come up with a simple example. Enjoy your PTO! |
|
@mpermar I'm working on a fork for a PR to add the code that is necessary to work with csaf_distribution as a library. The most interesting part is the new file advisory.go. Then I have an example which shows how to find PURLs in an advisory by providing product IDs. That is one functionality of those in your linked comparison. With the additional structs and functions you could also edit an existing advisory and save it as a new file. |
|
Hey @cintek , @bernhardreiter , I got some time to redo the experimental filter on my fork with the work you did there and it worked perfectly! Here is an example of how this works. With the following SBOM running a Trivy scan will show: bash-3.2$ trivy sbom trivy.sbom.cdx
2023-09-15T18:25:55.095+0200 INFO Vulnerability scanning is enabled
2023-09-15T18:25:55.100+0200 INFO Detected SBOM format: cyclonedx-json
2023-09-15T18:25:55.110+0200 WARN Ignore the OS package as no OS information is found.
2023-09-15T18:25:55.156+0200 INFO Number of language-specific files: 1
2023-09-15T18:25:55.156+0200 INFO Detecting gomod vulnerabilities...
go.mod (gomod)
Total: 3 (UNKNOWN: 0, LOW: 0, MEDIUM: 3, HIGH: 0, CRITICAL: 0)
┌───────────────────────────────────────┬─────────────────────┬──────────┬───────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Installed Version │ Fixed Version │ Title │
├───────────────────────────────────────┼─────────────────────┼──────────┼───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ github.com/cloudflare/circl │ CVE-2023-1732 │ MEDIUM │ 1.1.0 │ 1.3.3 │ Improper random reading in CIRCL │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2023-1732 │
├───────────────────────────────────────┼─────────────────────┤ ├───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ github.com/cyphar/filepath-securejoin │ GHSA-6xv5-86q9-7xr8 │ │ 0.2.3 │ 0.2.4 │ SecureJoin: on windows, paths outside of the rootfs could be │
│ │ │ │ │ │ inadvertently produced... │
│ │ │ │ │ │ https://github.com/advisories/GHSA-6xv5-86q9-7xr8 │
├───────────────────────────────────────┼─────────────────────┤ ├───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ github.com/sigstore/rekor │ CVE-2023-33199 │ │ 1.1.1 │ 1.2.0 │ malformed proposed intoto entries can cause a panic │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2023-33199 │
└───────────────────────────────────────┴─────────────────────┴──────────┴───────────────────┴───────────────┴──────────────────────────────────────────────────────────────┘Now, if we create a CSAF VEX assessment for bash-3.2$ ./trivy sbom trivy.sbom.cdx --vex trivy.vex.csaf
2023-09-15T18:28:36.082+0200 INFO Vulnerability scanning is enabled
2023-09-15T18:28:36.084+0200 INFO Detected SBOM format: cyclonedx-json
2023-09-15T18:28:36.093+0200 WARN Ignore the OS package as no OS information is found.
2023-09-15T18:28:36.135+0200 INFO Number of language-specific files: 1
2023-09-15T18:28:36.135+0200 INFO Detecting gomod vulnerabilities...
2023-09-15T18:28:36.178+0200 INFO Detected VEX format: CSAF
Found URLs for SPB-00260:
1. pkg:golang/github.com/cloudflare/[email protected]
2023-09-15T18:28:36.178+0200 INFO Found the following VEX statements: %!w([]vex.Statement=[{CVE-2023-1732 [pkg:golang/github.com/cloudflare/[email protected]] not_affected TODO}])
2023-09-15T18:28:36.178+0200 INFO Filtering with filter CSAF
2023-09-15T18:28:36.178+0200 INFO Filtering with filter CSAF
2023-09-15T18:28:36.178+0200 INFO Filtered out the detected vulnerability {"VEX format": "CSAF", "vulnerability-id": "CVE-2023-1732", "status": "not_affected", "justification": "TODO"}
2023-09-15T18:28:36.178+0200 INFO Filtering with filter CSAF
go.mod (gomod)
Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 2, HIGH: 0, CRITICAL: 0)
┌───────────────────────────────────────┬─────────────────────┬──────────┬───────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Installed Version │ Fixed Version │ Title │
├───────────────────────────────────────┼─────────────────────┼──────────┼───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ github.com/cyphar/filepath-securejoin │ GHSA-6xv5-86q9-7xr8 │ MEDIUM │ 0.2.3 │ 0.2.4 │ SecureJoin: on windows, paths outside of the rootfs could be │
│ │ │ │ │ │ inadvertently produced... │
│ │ │ │ │ │ https://github.com/advisories/GHSA-6xv5-86q9-7xr8 │
├───────────────────────────────────────┼─────────────────────┤ ├───────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ github.com/sigstore/rekor │ CVE-2023-33199 │ │ 1.1.1 │ 1.2.0 │ malformed proposed intoto entries can cause a panic │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2023-33199 │
└───────────────────────────────────────┴─────────────────────┴──────────┴───────────────────┴───────────────┴──────────────────────────────────────────────────────────────┘And the CVE is gone from the scanner results 👏 |
|
@bernhardreiter , @cintek , I think this is great and should work for sending some PRs for the scanners to support this type of native filtering for CSAF (like Trivy does today with OpenVEX/CycloneDX-VEX). Do you think it is realistic to have a golang package available in the short term? We can take care of sending the PRs to the scanners. Also a couple of observations @cintek, Trivy requires golang 1.20 but this CSAF distribution library requires golang 1.21. My golang knowledge is very basic so not sure if that would work. Other one, I wonder if it could be possible to add product finding as a library util in this module. I've implemented it on the client side for the sake of this test, but due to the number of different product identification helpers it kind of feels that maybe it should be on the library side. And last one by the way, I initially was trying with SBOM links from CycloneDX, but those don't seem to be supported by CSAF. Or I presume that for SBOM Links one should use Great weekend! |
|
Any news here. Is there any other way we can help to accelerate adoption? We are happy to help you guys to put this in prod if there is anything else we can help with here. |
|
Unfortunately not. We are working in the background on some bureaucracy to push the topic forward. Keeping you posted.
|
|
Hey, I saw the advisory model is now merged and looks very promising. From your perspective, anything left to do in that regard? Also, I'm kind of curious about the Any thoughts? |
I'll leave that to @csaf-poc/dev to answer. |
The Nevertheless, it is supported, production-ready and used in production... |
At least I do not know about specific todos on our list. Maybe @s-l-teichmann or @cintek know more. Please note that some of the disclaimers from above still hold, this is not yet a fully supported API, however it can be used to build software that may even be ready for some real use cases, though you have to take responsibility for it yourself. (The go modules versioning should prevent at least some accidents.) A while ago you've also asked:
Go 1 comes with a promisse of compatibility, which for 1.21 means: expect almost all Go programs to continue to compile and run as before. In practice you should be able to build Trivy with Go 1.21 without problems and then you can use csaf_distribution as a dependency.
Please open an issue for this wish. (It sound like a good idea in principle.)
That is a question for @tschmidtb51 ;) |
Sorry - I missed that. Does that answer your question? |
|
Sure it does. Thanks @tschmidtb51 ! Also thanks @bernhardreiter ! Opened a request. We're going to start working on contributions to some of the other OSS scanners. We will check the Golang 1.21. It should work, a few weeks ago they were struggling with some Golang 1.21 dependency but it seems they got around those issues. Will ping back soon. |
Hi! We are currently trying to evaluate integrating CSAF support into our cloud compliance framework Clouditor (https://github.com/clouditor/clouditor). However, the warning page on https://pkg.go.dev/github.com/csaf-poc/csaf_distribution/v3/csaf was a little bit concerning. The contents in As long as its clear the the |
I did some digging: We added the license file with 9cba4ee to resolve #223. As Go 1.19 was not released at that point, we imported the file from the Go Code. It was removed with 6b9ecea which IMHO forgot to remove the License file. @s-l-teichmann / @bernhardreiter : Is that correct? Can we remove the file safely or did I miss something? |
|
@tschmidtb51 yes, we can remove that license file safely. #544 does so. @oxisto the warning at https://pkg.go.dev/github.com/csaf-poc/csaf_distribution/v3/csaf is highly missleading, as explained on the linked issues we've opened with the Go infrastructure. Anyhow, the |
koplas
modified the milestones:
Go-Library,
Prerelease for version 4 (towards better use as library)
To facilitate more usage of CSAF, how would a go library have to be constructed to be able to help implementors to access the contents of the advisories?
potential use cases
The text was updated successfully, but these errors were encountered: