zaproxy/actions-common

Common code for ZAP's GitHub Actions

ZAP

The Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by a dedicated international team of volunteers. It can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications. It's also a great tool for experienced pentesters to use for manual security testing.

For more details about ZAP see the new ZAP website at zaproxy.org

actions-common's Issues

Support SARIF export

Hey,
wouldn't it be better for GitHub actions to upload results as SARIF (https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/uploading-a-sarif-file-to-github) instead of creating an issue?
At the moment it can get very confusing regarding the status of individual findings within the issue.
In addition this would also cover the flow of handling individual false-positives.

I found https://www.zaproxy.org/docs/desktop/addons/report-generation/report-sarif-json/ , but no way to use it within the GitHub Actions. Would be great to have it like

name: "Upload SARIF"
on: ...
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      actions: read
      contents: read
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: ZAP Scan
        uses: zaproxy/[email protected]
        with:
          target: 'http://example.com/'
          sarif_file: results.sarif
      - name: Upload SARIF file
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: results.sarif
          category: zap

Combine actions into one

To simplify maintenance it is possible to combine the 4 repositories, and allow specifying script_name as an input. Raise an error if script_name isn't found (in case someone forks with a custom script)

steps:
  - name: ZAP Scan
    uses: zaproxy/action
    with:
      script_name: 'zap-api-scan.py'
      target: 'https://www.zaproxy.org/'

The index.js can then have a switch / if to handle differences between the scripts.

The scripting logic can then validate any specialized (script specific) inputs correctness and throw/exit as needed.

This eliminates needing to main 4 repos and keeps everything sync'd without needing to keep the common library up to date.

On the issue tracker labels can be created referring to the script.

Update `@actions` packages throughout packages

I think it's a plus to use the latest stable versions of the actions/toolkit packages:

• @actions/artifact - release notes
• @actions/core - release notes
• @actions/exec - release notes
• @actions/github - release notes

GITHUB_API_URL no effect for creating Issues Github Enterprise

Trying to set the GITHUB_API_URL for it to override github.com for the issues to be created after I run a baseline scan.
However, it seems that it's not working?

I checked the code and I can see that it's using the env variable when instantiating Octokit.

 const octokit = getOctokit(token, {
      baseUrl: process.env.GITHUB_API_URL,
    }).rest;

In my workflow file it looks like this:

jobs:
  zap_scan:
    runs-on: [ our custom runner ]
    env:
      GITHUB_API_URL: 'https://our-github-enterprise-url/api/v3/'

    steps:
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Echo GITHUB_API_URL
      run: echo '${{ env.GITHUB_API_URL }}'

    - name: ZAP Baseline Scan With Auth 
      uses: zaproxy/[email protected]
      env:
        ZAP_AUTH_HEADER_VALUE: 'ApiKey 12345'
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
        target: 'https://my-target'
        cmd_options: '-d'

When I run this action it fails at the end when the issue is to be created:

Scanning process completed, starting to analyze the results!
[@octokit/rest] `const Octokit = require("@octokit/rest")` is deprecated. Use `const { Octokit } = require("@octokit/rest")` instead
Error: request to https://api.github.com/search/issues?q=is%3Aissue+state%3Aopen+repo%3APESS%2Fpess+ZAP+Scan+Baseline+Report&sort=updated failed, reason: getaddrinfo ENOTFOUND api.github.com

What could I be doing wrong?
Thanks

Thoughts on the recent PRs re: eslint, prettier?

In JS projects it's pretty common to find a setup with both of those, the reason why is editors and CI work with the prettier/eslint very well.

Any thoughts on adopting these here and in the other projects for consistency? If there is I can make PRs across the others (and if there's a prettier/eslint config)

I think the value equation is there. eslint catches a lot of basic mistakes and prettier keeps code consistent resulting in easier to read diffs / reviews in the long run.

Endgame: My idea is to have a basic CI setup with eslint / prettier and perhaps checking for the exit code of npx ncc build src/index.js to assure it builds without failing. T

Publish release

Hi, thank you for the project!

#15 was merged in dc737b2, for specifying artifact name. The current actions-common release has it being hard-coded. It causes artifacts to be overwritten if multiple scans are in the same run.

This is needed for issue zaproxy/action-baseline#45 (PR: zaproxy/action-baseline#64)

There doesn't seem to be anything breaking: scans-v0.2.0...master

Since the param differs (but is a noop for current users if artifactName is unspecified), it may make sense to have this as 0.3.0.

Make alert messages in issue more helpful

Hi there!

I've just implemented the GitHub Actions at a company, and there are some things which are cumbersome around the workflow. This issue specifically addresses the "Issue" created and missing information in it.

1. The individual alerts are hard to understand without more context.

   To solve this, I would add information about the severity and add a link to the description for each alert. I already provided a PR (#43) for this.

2. It's hard to see which alerts are more and which are less important

   For this, I would group the alerts by severity.

3. There's no good summary for the overall report

   Here, I would recreate the summary table from the markdown report and add it to the top of the issue.

In addition, I would like to add a testing framework and some tests to be able to more confidently work on the code.

DEPRECATION: This will stop working on June 30, 2024

Hi there,

We use the zap-full-scan-action and have noticed deprecation warnings in our pipeline. It seems to use this actions-common repo, which in turn has a very outdated version of "@actions/artifact": "^1.1.0".

As per the alert on the repo's README:

actions/upload-artifact@v3 is scheduled for deprecation on November 30, 2024. Similarly, v1/v2 are scheduled for deprecation on June 30, 2024. Please update your workflow to use v4 of the artifact actions.

Please could this be updated (and the updated version propagated to any consuming repos, such as zap-full-scan-action) urgently, to ensure these useful tools continue to be usable?

Can I also humbly suggest enabling Dependabot to ensure dependencies are maintained going forwards? My team wrote an action, Dependabot Batcher, that you might find useful.

Thanks!

Add unit tests for actions common code

Units tests are currently missing for the actions common code.

Road ahead

Hi! After the first PR, I would like to talk a bit about the road ahead before taking this on. On the meta level I would like to understand what I can do to get PRs merged faster, and, on a content level, align on a roadmap.

For the roadmap, I currently see these steps:

1. Automatically publish new versions of this package to npm (this requires hands-on support as I don't have the key to publish to npm and therefore can't set this up alone)
2. Update the actions to the new version, or even add something that automatically updates them when this package changes
3. Add the ideas from #44 and related tests.

I'm happy about feedback on the roadmap, but would also love to understand what I can do to speed up the merge process and discussion. I could e.g. offer to have a synchronous 30 minute session when a PR is done with everyone who is needed to approve the PR to discuss what needs to be done. But I'm also open to other suggestions.

What do you think?

Unable to debug error in readPreviousReport

Everytime My Zap actions run, even though there's an Issue open and the action can find such Issue, they create new issues due to an error in processing.

Ongoing open issue has been identified #1234
Error occurred while downloading the artifacts!
Alerts present in the current report: true
Process completed successfully and a new issue #1235 has been created for the ZAP Scan.

Unfortunately, the error handling code does not print the error, so it's very hard to figure out what's going on.

Could we change that error catching to print the error?

Scan report: Duplicate issue creation when `artifactName` passed

Since readPreviousReport isn't checking for the artifact name, it will create a new issue when artifact_name is passed in through a PR like zaproxy/action-baseline#64