Skip to content

Add go binary scanning #1011

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
Jun 11, 2024
Merged

Conversation

another-rex
Copy link
Collaborator

Add go binary scanning extractor, and use it in image scanning.

This shows quite a few false positives that can be resolved with call analysis, which will be implemented in a followup PR.

@another-rex another-rex requested a review from oliverchang May 31, 2024 00:52
@codecov-commenter
Copy link

codecov-commenter commented May 31, 2024

Codecov Report

Attention: Patch coverage is 84.52381% with 13 lines in your changes missing coverage. Please review.

Project coverage is 65.25%. Comparing base (8fd553a) to head (6d68a3c).

Files Patch % Lines
pkg/lockfile/go-binary.go 82.00% 6 Missing and 3 partials ⚠️
internal/image/extractor.go 87.87% 3 Missing and 1 partial ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1011      +/-   ##
==========================================
+ Coverage   65.14%   65.25%   +0.11%     
==========================================
  Files         149      150       +1     
  Lines       12338    12401      +63     
==========================================
+ Hits         8037     8092      +55     
- Misses       3849     3855       +6     
- Partials      452      454       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

}

// Any other path can be a go binary
return true
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this incur much performance penalty when scanning a container filesystem?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sort of depends on whether the DepFile passed into this extractor has the ReaderAt interface. If it does, then the performance cost is relatively minimal, as it checks the headers to see if it's a relevant file (e.g. has ELF header, various magic bytes, has go debug info...etc) and returns early if it isn't.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ack, I think it's reasonable to expect ReaderAt in most cases.

@another-rex another-rex merged commit 0c01488 into google:main Jun 11, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants