GitHub Action

[pandatix]

Hello, I saw in @laluka videos on pwning GitHub Actions that a suggested evolution could be a GitHub Action.
I align with the idea that octoscan should be an action for ease of use (and continuous audit).

As octoscan is written in Golang, we do not have other choice that making a Docker image for it.
A simplistic Dockerfile could be the following, based upon the fact that the CI already compiles the binary.

FROM scratch
COPY octoscan .
ENTRYPOINT [ "/octoscan" ]

The problem here is that I cannot fully contribute on the codebase to create the action: it requires synacktiv to either publish a Docker image on Docker Hub or ghcr.io (or any alternative, those are suggestions). This requires setup of third party tools, that I cannot do (at least for Docker Hub).

On the hypothesis that the previous is done, we have 2 choices:

1. publish the action along octoscan codebase (a monorepo, more messy)
2. publish the action in another repository (cleaner according to the Separation of Concerns Principle, but two places to maintain)

I would recommend 2., but still cannot do anything to it: I cannot create a repository for synacktiv...

[hugo-syn]

Hi, thank you for watching the video, after the talk I started implementing an action for octoscan but I'm facing some difficulties. I wanted to try reviewdog, it works well on pull requests but it doesn't work (or I don't know how to configure it) on push events, I opened an issue but nobody answered.

If you want to take a look and help me, here is my temporary repository that I use for testing: https://github.com/hugo-syn/octoscan-action

Reviewdog seems quite powerfull but if you have a better idea I'm open to suggestions :)

[echoix]

What do you try to achieve by using reviewdog? It is useful to add review comments on files, from the output of tools or a unified diff with 0 lines of context.

How would you see it work on pushes outside of a PR? (Who can push to an arbitrary repo anyways?)

If it's only for showing some error annotations, it's easier to just use a special syntax for GitHub actions that show at what line/char an error occurs and the message.

Since it's a tool on the security topic, it might be useful to output the results with the SARIF format, and that could be fed to the upload-sarif subaction of CodeQL action, that allows to feed the details into GitHub security checks and reviews, a bit like CodeQL. For example, a project I collaborate use it for the Python tool bandit.

Otherwise, in that same GPL-licenced project, I setup an reusable workflow+workflow to use reviewdog, but working with pull_request_target in a somewhat safe way, without bypassing the pull_request_target intentions. I had to feed some env vars/flags to reviewdog so it could send the review comments to the PR, even if the context wasn't a PR. The project is called GRASS in the OSGeo org.

[hugo-syn]

Hi, I don't know exactly what's the best option here. But I think that it would be nice on push events because if someone in a team of dev introduce a vulnerability in a workflow this could allow someone to compromise it so monitoring push is essential I think.

When you say 'If it's only for showing some error annotations, it's easier to just use a special syntax for GitHub actions' what are you talking about? 

I didn't know the upload sarif action, I'll take a look thanks and I'll take a look at your reviewdog configuration.

[hugo-syn]

How can you make it work on pull requests with codeql since the external user won't be able to push sarif results to GitHub ?

[echoix]

Hi, I don't know exactly what's the best option here. But I think that it would be nice on push events because if someone in a team of dev introduce a vulnerability in a workflow this could allow someone to compromise it so monitoring push is essential I think.

When you say 'If it's only for showing some error annotations, it's easier to just use a special syntax for GitHub actions' what are you talking about? 

Format the text of the message to follow this: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions

I didn't know the upload sarif action, I'll take a look thanks and I'll take a look at your reviewdog configuration.

How can you make it work on pull requests with codeql since the external user won't be able to push sarif results to GitHub ?

For sarif, look here https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning

We run this on pushes (merged pull requests) and pull requests without problems (bandit and CodeQL). The pull requests are all coming from forks, where there are some extra limitations, and work even with contributors outside the organization.

Personally, I think outputting a sarif file (a json) is the best option overall for this project, that would be the most useful overall in the future. It is the standard for tools like this.

[hugo-syn]

Hi @echoix, @pandatix, here you can find an action for octoscan: https://github.com/synacktiv/action-octoscan.

I've added support for the sarif file format, it's based on https://github.com/rhysd/actionlint/blob/main/testdata/format/README.md

Everything works well on push/pull_request:

I've also added a Docker image: https://github.com/synacktiv/octoscan/pkgs/container/octoscan/296212503?tag=latest. This image is used in the action.

If you test it, I would appreciate your feedback to help me improve it.

Thank you for your help 💯

[pandatix]

Nice, exactly what I imagined ! 🎉

[echoix]

I won't be able to this week though. I saw I think three releases of the same version by email this weekend, is it expected?

[hugo-syn]

@echoix , I apologize for not realizing that it would send emails. I'm still getting familiar with the release processes. It should be sorted out now. Sorry for any inconvenience!

[echoix]

One of the (less perfect) ways to make sure the same action is pulled even if it changes is to use the full version tag, but it is not prone to situations where the tag is changed to point to a new content. This is probably what happened this weekend. The "correct", "honest" way of adding changes after a release would be to make new patch releases with a new tag, and update the less precise (minor and major) version tags to point to the latest patch.

Later on, tools like renovate will probably have some difficulty presenting the changes correctly when it's the same "release" same release notes, but different contents. It's hard to see what could be hidden (especially security-wise, supply-chain security-wise)

[hugo-syn]

Ok thanks for this, I'll use a different tag next time ! :)