Have you thought about how you will handle problems discovered during your scan process? Let me give you an example (hypothetical) ... suppose someone requests you add an action. In scanning the action you discover that V1 contained a vulnerability. They have fixed it and V2 and V3 are fine. What do you do?
If you bring in the action, then you will always be vulnerable to someone referencing V1 or a sha1 that has the vulnerability.
I guess in this case the answer is "easy" ... you reject adding this action.
I suppose this also means if you have added and synced an action and then a future version adds a vulnerability that you detect then this also pretty much freezes the action on your instance to the last good version that you synced?
Yep. No way around that yet, except for checking all workflows in your org and alerting on the use of a vulnerable version, or removal of the entire action for internal use. Alternatively you could remove the tag (=version) from the forked repo, but that would defy the purpose (and users can still use a commit SHA with the vulnerable version).
For these reasons, I suggested GitHub to add a “disallow” list, next to the allow list of actions that cannot be used in your org/repo.
One way that may work is to explicitly add tags to the fork with the versions that are approved. Eg @v2-approved, and then limit the allow list to each forked action repo with those specific tags (@v2-approved or @approved*)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Have you thought about how you will handle problems discovered during your scan process? Let me give you an example (hypothetical) ... suppose someone requests you add an action. In scanning the action you discover that V1 contained a vulnerability. They have fixed it and V2 and V3 are fine. What do you do?
If you bring in the action, then you will always be vulnerable to someone referencing V1 or a sha1 that has the vulnerability.
I guess in this case the answer is "easy" ... you reject adding this action.
I suppose this also means if you have added and synced an action and then a future version adds a vulnerability that you detect then this also pretty much freezes the action on your instance to the last good version that you synced?
Yep. No way around that yet, except for checking all workflows in your org and alerting on the use of a vulnerable version, or removal of the entire action for internal use. Alternatively you could remove the tag (=version) from the forked repo, but that would defy the purpose (and users can still use a commit SHA with the vulnerable version).
For these reasons, I suggested GitHub to add a “disallow” list, next to the allow list of actions that cannot be used in your org/repo.
One way that may work is to explicitly add tags to the fork with the versions that are approved. Eg @v2-approved, and then limit the allow list to each forked action repo with those specific tags (@v2-approved or @approved*)