478 identify go binaries and extract mod information #534
Conversation
Signed-off-by: Alex Goodman <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
- add bin cataloger - add bin parser - add mime type go utils - import new resolver Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
- keep them in their own (original) files - add note for "this code was copied from" - comment the lines the required changing Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
bf6e326 to
8b199ee
Compare
Benchmark Test ResultsBenchmark results from the latest changes vs base branch |
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
|
This implementation is different than our internal one (we generate an anchore_hints.json file at binary build time so we use the compiler to output the result and massage it), but one issue we recently hit is that our initial implementation (now fixed) included the v in the go version strings (e.g. v1.1.1) but the CPE strings in the NVD seem to never contain the v. I see that this is including the v in the output. For the generated CPE string is the v being stripped? |
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
|
@wagoodman updated code inline with PR comments |
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
|
I'll update the failing integration tests. Looks like there was a regression covering if a cataloger was removed. |
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
|
The other thing our internal implementation does is extract the version of go used to build the binary and add that to the hints file. I believe that’s in a different location in the binary but I’m thinking it would be nice to provide that as well, possibly controlled by a flag. There have been cases in the past of a bug/vulnerability in the compiler being inherited by the binaries it produces. |
| pkgsSlice := make([]pkg.Package, 0) | ||
| fields := strings.Fields(mod) | ||
|
|
||
| // slice off root package info |
There was a problem hiding this comment.
it seems like this block could be removed if the loop below was simplified to a line scanner:
scanner := bufio.NewScanner(strings.NewReader(mod))
for scanner.Scan() {
fields := strings.Fields(scanner.Text())
switch fields[0] {
case packageIdentifier:
...
}
}| } | ||
| } | ||
|
|
||
| sort.SliceStable(pkgsSlice, func(i, j int) bool { |
There was a problem hiding this comment.
question: is this sort necessary?
| {}, | ||
| }, | ||
| }, | ||
| { |
There was a problem hiding this comment.
I think the correct answer in this case is to use the replacement value and not the original entry
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Interesting - @wagoodman should we get the version of go used and add that as a package in the list? |
Signed-off-by: Christopher Angelo Phillips <[email protected]>
|
@cburgess we're going to implement a custom package metadata type in a follow-on PR that captures the We're trying to stay open here since we have more exploration to do on the go build list side of scanning go projects. We want to make sure we get the correct metadata information lined up across Really appreciate your insight since it helps us make sure we are keeping the most required bits for vuln scanning front and center. |
Signed-off-by: Christopher Angelo Phillips <[email protected]>
Signed-off-by: Christopher Angelo Phillips <[email protected]>
|
@spiffcs makes sense. As I said, just excited to see some of this making its way into the product. |
* add query by MIME type to source.FileResolver Signed-off-by: Alex Goodman <[email protected]> * import stereoscope lib changes to find mime type - add bin cataloger - add bin parser - add mime type go utils - import new resolver Signed-off-by: Christopher Angelo Phillips <[email protected]> * add go std library code to unpack bin - keep them in their own (original) files - add note for "this code was copied from" - comment the lines the required changing Signed-off-by: Christopher Angelo Phillips <[email protected]> Co-authored-by: Alex Goodman <[email protected]>
New output after running Syft against its own image when using this branch:
New:
Old: