-
-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Adds github client and PAT inspection #138
Conversation
depscan/lib/github.py
Outdated
class GitHub: | ||
# The GitHub personal access token required scopes for depscan | ||
DEPSCAN_REQUIRED_TOKEN_SCOPES = [ | ||
RequiredTokenScope("read:packages", "write:packages") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need either of these scopes? We need the token only to access the public vulnerabilities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the depscan documentation, read:packages
is the one required scope on tokens. The scope of write:packages
is a parent of read, such that if a token has write scope, it will also inherit read scope on packages.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The GitHub API will only return one or the other scope which the token has: read:packages
or write:packages
. So although we only need read, the write will technically work for depscan to operate as well. It will just be an over-permissioning problem at that point if the token has write.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timmyteo, could you kindly do some testing? The documentation might be outdated. Could you try using a token with no scope and see if the database is getting filled with advisories? We can definitely not request write:packages
so that we operate with the least privilege.
depscan/cli.py
Outdated
|
||
if not github_client.authenticate(): | ||
LOG.error("The GitHub personal access token supplied appears to be invalid or expired. Please see: https://github.com/owasp-dep-scan/dep-scan#github-security-advisory") | ||
elif github_client.get_token_scopes() is None: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is depscan not working with fine grained tokens?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I saw this note in GitHub documentation for the packages API endpoint: you must authenticate using a personal access token (classic)
. If classic tokens are the only ones allowed, then the new fine-grained tokens will not work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be tested as well to prevent users from getting stuck with a legacy token.
@timmyteo I know you're using Windows, so let me look into why the tests are failing for linux and mac. |
Ok, so there are two discrete issues causing the checks to fail.
We ultimately can't actually test the condition exists to output a warning from within our own repo without implementing the same poor security practice we intend to warn against, as @prabhu describes below - unless we want to set up a separate repo with such overly permissive permissions and run a test there.
I have therefore made minor changes to the pr to address these two issues, as well as to stop all our workflows from running when the only thing that's changed is another workflow. @timmyteo Do you think you could set up a dummy repo with poor security to test this out? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will approve pending confirmation that this works in a repo with an overly permissive GITHUB_TOKEN.
Thanks @prabhu and @cerrussell for your feedback and help! @prabhu I looked at AppThreat VDB and it looks like it calls the
@cerrussell Thanks for helping with the failing tests. I am not understanding your ask for creating a repo with the overly permissive token. Can you please elaborate more? For example, how could I do this in my existing fork? Also, is this a temporary setup, or should this be everlasting to continuously demonstrate this works? |
@cerrussell @timmyteo What is left in this PR? |
@prabhu I think I had wanted a demo to show this works, which we can't do by scanning from our own repo. |
@cerrussell, you can run it using a workflow on AppThreat org, which uses such overly generous GITHUB_TOKEN by default. |
Consolidate exceptions Signed-off-by: Caroline Russell <caroline@appthreat.dev> Output exception Signed-off-by: Caroline Russell <caroline@appthreat.dev> Handle GitHubException Signed-off-by: Caroline Russell <caroline@appthreat.dev> Don't fail-fast version_tests2 Signed-off-by: Caroline Russell <caroline@appthreat.dev> Fix type hints, unnecessary test runs Signed-off-by: Caroline Russell <caroline@appthreat.dev>
* Adds 3.12 tests Signed-off-by: Prabhu Subramanian <prabhu@appthreat.com> * Adds 3.12 tests Signed-off-by: Prabhu Subramanian <prabhu@appthreat.com> --------- Signed-off-by: Prabhu Subramanian <prabhu@appthreat.com>
9c97f7f
to
95d8e57
Compare
@prabhu @timmyteo I am quite possibly missing something here, but I'm getting that the token is expired or invalid rather than the expected message on the test workflow. Maybe the built-in GITHUB_TOKEN is not a classic token? |
@cerrussell Interesting! Both classic and newer fine grained tokens should work, so I don't think that is the problem here. One of these two exceptions are being thrown. Your Github token may be expired, although if it is being used in this workflow, it seems unlikely. Maybe this catch for the two exceptions needs to be separated out for describing different error scenarios, especially if a different issue is occurring here besides expired token. |
@timmyteo The GITHUB_TOKEN is automatically generated by GitHub when the workfow is run, so it must be something else. |
Thanks for these details @cerrussell. It seems the tokens for Actions have a reduced scope by default, which was not suitable for calling the users API. I reworked the code to not call the API for the user details, and instead just call the base API. Testing with classic tokens and fine-grained access tokens show no regression from expected functionality, and I believe this will work now for Action tokens as well. |
@timmyteo Thanks! I just tried it out, but still couldn't get anything in CI. However, I was able to get it locally with a token I generated, so that's good. I guess we just won't be able to do this in CI. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timmyteo Thanks so much for your contribution!
Thanks @cerrussell! The excess permission token warning will only work with classic tokens, as those are the only type that return the associated permission scopes when talking to the GitHub API. |
@timmyteo Confused - I thought that might be it, but I mentioned this upthread and and your reply to that was they should both work. Am I missing something? |
@cerrussell Sorry for the confusion! Let me know if this explanation helps. GitHub has these 3 main token types:
The first two can be long lived and are generated by the developer and associated to their account. The third is short lived, lesser privileged, and generally only lives as long the action does. This pull request adds two pieces of functionality with respect to these three token types:
|
@timmyteo I understand that, I meant your comment in response to where I said "Maybe the built-in GITHUB_TOKEN is not a classic token"
|
Ah yes, I was misunderstanding how the workflow was configured. My first guess was that a personal access token (classic or fine-grained) was generated and manually set as a workflow environment variable GITHUB_TOKEN. But I learned as part of our conversation thanks to your help that there is the option for the additional token type of auto-generated token, which you are utilizing here. So sorry for the confusion and this is just one of many examples that you learn something new everyday :) |
@timmyteo Gotcha, no problem, just wanted to make sure I was on the same page. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please merge at your convenience. Great PR!
Implements feature for #100