search

veracode / veracode-uploadandscan-action

This action uploads and scans code to Veracode for a static policy (or sandbox) scan.
MIT License
30 stars 29 forks source link

Versioning scheme #10

Open tjarrettveracode opened 3 years ago

tjarrettveracode commented 3 years ago

We use GitHub veracode-uploadandscan-action to scan our application.

But the versioning they have is confusing.

In the README they recommend to use @master tag. But this disagrees with GitHub recommendations:

We strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag number. If you don't specify a version, it could break your workflows or cause unexpected behavior when the action owner publishes an update.

  • Using the commit SHA of a released action version is the safest for stability and security.
  • Using the specific major action version allows you to receive critical fixes and security patches while still maintaining compatibility. It also assures that your workflow should still work.
  • Using the default branch of an action may be convenient, but if someone releases a new major version with a breaking change, your workflow could break.

So using @master how it is recommended in the README seems to be one of the worst propositions.

Also considering Security hardening for GitHub Actions they recommend to use

either commit SHA ("paranoid mode") or tag version if we trust the creator (Yes, we trust https://github.com/veracode repository, but obtaining "Verified creator" tag could be beneficial for companies like they are 🙂, https://docs.github.com/en/developers/github-marketplace/github-marketplace-overview/about-marketplace-badges )

Other references regarding GitHub action tagging

At he same time, the versioning in theirs action seems confusing and unclear and doesn't follow semver pattern.

For example, 0.2.1 seems to be more up-to-date comparing to v1.0

https://github.com/veracode/veracode-uploadandscan-action/compare/v1.0...0.2.1

at the same time by usual conventions (semver) and GiHub recommendations v1.0 should be used.

For example, look at the version tagging in setup-java action, which had v1 and then upgraded to v2 . There it's pretty clear and convenient to use.

So the question is:

who is responsible for that action development and how to negotiate them to follow clear action tagging and versioning?

(Source: Veracode Community )

andrii-kovalenko-celonis commented 3 years ago

I missed to put the reference to the first cite from GitHub:

We strongly recommend that you include the version of the action you are using by specifying a Git ref, SHA, or Docker tag number

https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions