Feature: use in Pull Request

[hazcod]

Instead of having an hourly scan or so, developers should receive direct feedback about their fixes in the CI/CD workflow.
Allowing us to use zaproxy/action-baseline in a pull_request flow should allow this behavior easily.

IMO, the only thing that needs to be changed is detecting whether we're in a pull request and commenting instead of creating an issue.

[sshniro]

Good suggestion, but I assume this should run in conjunction with locally building the webapp, and then running the baseline scan against the local app.

[hazcod]

Indeed, the url can be extracted from a previous job output variable and used as input to zap.

[sshniro]

I would like to start working on this issue: would like to get some clarifications, @psiinon @thc202

1. If a user commits to a pull request should we report the new results of ZAP as a comment or comment on the difference between the previous commit and current commit?

Example: Alert x has been newly identified?

[thc202]

Following the behaviour of other tools (e.g. LGTM), comment always with the difference between the latest changes of the PR and the base branch.

This will have to be done in two steps, e.g. first creates the data and the second adds the comment (using pull_request_target event).

[nissessenap]

Any update on this?
Personally It would be enough for me to see the ZAP output on PR and you don't have to mix in any previous scan results.
First step keep it simple and second step you can mix in some extra things like comparing between old commits.

[nissessenap]

Did a rather simple version of this that you can definitly improve but at least it runs zap on each PR.
Shoulden't be to hard to add rules for zap, one way could be to store them in the repo which you probably should do any way.

https://github.com/XenitAB/opa-bundle-api/pull/3/files

name: ZAP PR Validation

on: pull_request

jobs:
  zap:
    timeout-minutes: 5
    runs-on: ubuntu-latest
    env:
      GO111MODULE: on
    steps:
      - name: Clone repo
        uses: actions/checkout@v2.3.4
      - name: Setup go
        uses: actions/setup-go@v2
        with:
          go-version: "^1.16.2"
      - name: Run application
        run: |
          go mod download
          timeout 120s go run ./cmd/opa-bundle-api/main.go &
          docker run -t owasp/zap2docker-stable zap-baseline.py -t http://$(ip -f inet -o addr show docker0 | awk '{print $4}' | cut -d '/' -f 1):8080

[BrandonOldenhof]

Sneaky bump on this issue: I'm looking for this exact functionality; from what I've seen in the docs, so far, it looks like we'd need a single input to be added that lets us add an existing issue id to overwrite :

Every pull request is an issue, but not every issue is a pull request. For this reason, "shared" actions for both features, like manipulating assignees, labels and milestones, are provided within the Issues API.

https://docs.github.com/en/rest/reference/pulls

I'm pretty sure we can get that PR id in the workflow by using the GITHUB_REF variable.

[psiinon]

@sshniro are you still able to look at this?
If not then no problem but we'll unassign you and try to encourage someone else to look at it :)

[sshniro]

Hi @psiinon unfortunately I will be not able to look into this during this month, would highly welcome any contribution from someone else.