Using Docker action type only works on Linux runners and makes the action take 25-30 extra seconds setup time in every workflow execution

[joshuagrisham]

As I mentioned in #128 , per the GitHub documentation Docker actions are slower because the Dockerfile needs to be built (including any source layers that need to be fetched).

After a bit of testing it seems like the build time for the Dockerfile when I use the GitHub hosted ubuntu-latest runner is typically between 25-30 seconds for every execution of every workflow where this action is used within one of the steps of a job.

This time can actually be entirely removed if you use a JavaScript (or potentially a composite) action instead.

Actually I realized that ubuntu-latest already has aws-cli and python3 available so in theory you can just run the Python scripts exactly as they are in the repo if you are using this or a similar runner image.

I did a small prototype branch with this idea which you can see here: joshuagrisham/vulnerability-scan-github-action-for-amazon-inspector:use-composite-action (if you want, I can actually open a PR with this.. ?).

Basically I just converted the action.yml from Docker-based to a composite action (including fixing some variables and adding input sanitizing to avoid injection attack vulnerabilities) plus one small tweak I noticed that would help with making the Python script more cross-platform (though I think there are a few more issues. e.g. the hard-coded path for the inspector-sbomgen destination path) -- in theory all of these small cross-platform things can be tweaked and then this branch would also allow the action to be run on multiple platforms (not just Linux runners).

This branch is now basically a drop-in replacement for the official action, e.g. like this:

    - name: Scan image with Amazon Inspector
      id: inspector
      # Temporary test to see if we can speed up the workflow time even more (using composite action instead of Docker)
      uses: joshuagrisham/vulnerability-scan-github-action-for-amazon-inspector@use-composite-action
      #uses: aws-actions/vulnerability-scan-github-action-for-amazon-inspector@v1
      with:
        artifact_type: 'container'
        artifact_path: ${{ steps.build.outputs.image }}
        display_vulnerability_findings: 'enabled'
        critical_threshold: 1
        high_threshold: 1
        medium_threshold: 0
        low_threshold: 0
        other_threshold: 0

With this prototype branch now there is 0 container build time (the 25-30 extra seconds per workflow execution is just totally removed) but I can understand that maybe there would be some things to consider regarding dependency management as you no longer have full control of the environment that the scripts are being executed in.

As your existing Dockerfile always pulls in amazonlinux:latest and installs the latest aws-cli available in dnf for it, my guess is what is available in ubuntu-latest as aws-cli and python3 are effectively "just as good" as this, but maybe there could be concerns with other runners or with custom built images? I guess if you wanted to go in a direction like this then you could always check for existence of these tools (and their versions?) and just fail in case they do not already exist (or meet a minimum version)? But it is up to you if you wanted to do something like this.

Also my testing with other actions has always shown that JavaScript-based actions (when optimized, i.e. create a distribution with all bundled dependencies and use tree shaking as much as possible to REALLY minimize the download and execution size) are almost always faster so if you are looking to even speed up more then that is of course a possibility (and a bit more out-of-the-box dependency management with GH Actions to boot) but you will always be at the mercy of the inspector-sbomgen program no matter what, so it might not be worth the effort to consider converting to JavaScript anyway!

So in summary, using this Docker-based action means that it currently only works on Linux runners, plus that there is seemingly on average around 25-30 seconds extra build time required every time your workflow executes, that could be significantly reduced if not completely avoided. For those of us who will build hundreds or thousands of images that we want to scan with this action, plus if we are billed for per-minute usage of GitHub Actions, it would be nice to optimize this as much as possible!

[joshuagrisham]

One thing I thought to add regarding my composite action -- there might be issues with using the YAML folded block scalar (>) in cases where some of the optional inputs are given vs not.. (e.g. it might break the string into multiple lines if there are blank lines in between). I have not really tested all of those different scenarios so it might be worth to take a closer look at that to ensure there would not be any issues 🙂

Edit: I think this should actually be solved now; I updated this over the weekend to use a block scalar instead (|) with explicit line continuations and it seems to work fine for me now no matter what parameter I send (or don't send)

[bluesentinelsec]

Hello, thank you for the detailed feedback.
I agree we can likely see a performance improvement leveraging JavaScript.
Unfortunately, the JavaScript option necessitates a re-write of the action's code, so we will not pursue this option at this time.

In the near term, we are investigating alternate solutions, such as leveraging the AWS CLI image you referenced in this PR: #128
We are also exploring other options such as multi-stage builds and caching.

Marking this issue as resolved; please re-open if there are pertinent developments or follow-up issues.