actions-rs / audit-check Goto Github PK

Hi,
I'm having an issue with the audit failing with the error:

Cannot use 'in' operator to search for 'unmaintained' in yanked

the related run is here:

https://github.com/wayfair-tremor/tremor-runtime/actions/runs/43254102

Not sure how long this link lasts: https://github.com/portier/portier-broker/commit/4dbe08dfe176b2f10755f22e6a2ba25e11bd9258/checks?check_suite_id=417536094

Previous runs all succeeded, so maybe the cargo-audit output changed? I'm looking at the JSON, and think this no longer holds true:

(Or maybe even Vulnerability itself has changed, I don't know.)

The warning object in the output looks like:

{
  "kind": {
    "unmaintained": {
      "advisory": {
        "id": "RUSTSEC-2019-0031",
        "package": "spin",
        "date": "2019-11-21",
        "aliases": [],
        "references": [],
        "collection": "crates",
        "categories": [],
        "keywords": [],
        "cvss": null,
        "informational": "unmaintained",
        "obsolete": false,
        "url": "https://github.com/mvdnes/spin-rs/commit/7516c80",
        "title": "spin is no longer actively maintained",
        "description": "The author of the `spin` crate does not have time or interest to maintain it.\n\nConsider the following alternatives (both of which support `no_std`):\n\n- [`conquer-once`](https://github.com/oliver-giersch/conquer-once)\n- [`lock_api`](https://crates.io/crates/lock_api) (a subproject of `parking_lot`)\n",
        "patched_versions": [],
        "unaffected_versions": []
      },
      "versions": {
        "patched": [],
        "unaffected": [
          "> 0.5.2"
        ]
      }
    }
  },
  "package": {
    "name": "spin",
    "version": "0.5.2",
    "source": "registry+https://github.com/rust-lang/crates.io-index",
    "checksum": "6e63cff320ae2c57904679ba7cb63280a3dc4613885beafb148ee7bf9aa9042d",
    "replace": null
  }
}

 Run actions-rs/audit-check@v1
0s
(node:2570) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
Run actions-rs/audit-check@v1
(node:2570) UnhandledPromiseRejectionWarning: Error: Input required and not supplied: token
    at Object.getInput (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:346432)
    at Object.getInput (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:184101)
    at Object.get (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:154401)
    at main (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:29365)
    at Object.131 (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:29427)
    at __webpack_require__ (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:154)
    at startup (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:291)
    at module.exports.0 (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:323)
    at Object.<anonymous> (/home/runner/work/_actions/actions-rs/audit-check/v1/dist/index.js:1:333)
    at Module._compile (internal/modules/cjs/loader.js:774:30)
(node:2570) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:2570) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I would have expected this to cause a warning/failure but it still ended up in success/green checkmark.

Caused by just missing these two lines:

        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

The action crashes with Error: Resource not accessible by integration when setting "Workflow permissions" to read only

Workflow code

name: Security audit
on:
  push:
    paths:
      - "**/Cargo.toml"
      - "**/Cargo.lock"
  pull_request:
  workflow_dispatch:
  schedule:
    - cron: "0 0 * * *"
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: Swatinem/rust-cache@v1
      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Action output

logs_122.zip

Expected behavior

It should fail. But the Readme should mention which permissions are required and why these are required

Additional context

This is probably just missing documentation :)

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

The workflow errors with Error: t is not iterable

Workflow code

https://github.com/MyK00L/cmsrs/actions/runs/1156620794/workflow

Paste that part of your workflow yaml file that causes the bug in here.

Alternatively you can remove that code block and insert direct link to your workflow file.
Ensure that link points to the specific commit, and not just to the master branch.

Action output

  {"database":{"advisory-count":340,"last-commit":"101d914e049f02bf7527aabbc32556461b2d5a46","last-updated":"2021-08-22T09:43:52Z"},"lockfile":{"dependency-count":201},"settings":{"target_arch":null,"target_os":null,"severity":null,"ignore":[],"informational_warnings":["unmaintained"],"package_scope":null},"vulnerabilities":{"found":false,"count":0,"list":[]},"warnings":{}}
9
No vulnerabilities were found
10
Warning: undefined warnings found!
11
Error: t is not iterable

Expected behavior

The test passes

Additional context

i think it may be related to the workaround for audit <0.12

Hi all,

I'd like a way to link between the security issue which was found and the code which is "flawed". That will make it much easier to track down and fix.

Also wondering if it is possible to annotate "vulnerable" code to be ignored if it is not going to be fixed and the audit is creating noise in those cases.

Thanks!

I'm integrating cargo-audit, and it seems not to generate reports when I run it on pull requests. My workflow code is below, and you can see the jobs from a run here:

https://github.com/agora-org/agora/runs/3911274358

The audit step failed, but it did not generate an HTML report page.

Is this because I have it configured to run on pull_request?

Here's an example of a previous configuration, where I was running it on push and pull_request, and both instances failed, but it seems to have only generated a report for the push instance:

https://github.com/agora-org/agora/runs/3911258812

Is this expected behavior? I'm happy to enable logging and post the debug logs, but I wanted to make sure that this wasn't just expected behavior first.

Workflow Code

name: Audit
on:
  pull_request:
    branches:
    - master
    paths:
      - '**/Cargo.lock'
      - '**/Cargo.toml'
jobs:
  all:
    name: All
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

I created a new branch in a Rust repository, added the audit workflow and pushed a commit, that changed both Cargo.toml and Cargo.lock to the same branch.

Somehow the action is still not executed: https://github.com/editorconfig-checker/editorconfig-checker.rust/actions

Is there anything else to do, for this action to work?

Update:

I added on: pull_request: to the action, and the action was executed when I created a PR for my branch. Is the push trigger only triggered on specific branches?

Update2:

The scheduled trigger is not executed, too. Same here: does the trigger only apply if the yml is on a specific branch?

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Starting very recently, audit-check began failing! You can see an example output here:

https://github.com/alex/csv-sql/pull/342/checks?check_run_id=650426469

Calling cargo-audit (JSON output)
  /usr/share/rust/.cargo/bin/cargo audit --json
  {"database":{"advisory-count":83,"last-commit":"4565a921dd2212cf4e68ad763b114648907e790d","last-updated":"2020-05-04T23:46:31Z"},"lockfile":{"dependency-count":66},"settings":{"target_arch":null,"target_os":null,"severity":null,"ignore":[],"informational_warnings":["unmaintained"],"package_scope":null},"vulnerabilities":{"found":false,"count":0,"list":[]},"warnings":{"unmaintained":[{"kind":"unmaintained","package":{"name":"term","version":"0.5.2","source":"registry+https://github.com/rust-lang/crates.io-index","checksum":"edd106a334b7657c10b7c540a0106114feadeb4dc314513e97df481d5d966f42","dependencies":[{"name":"byteorder","version":"1.3.4","source":"registry+https://github.com/rust-lang/crates.io-index"},{"name":"dirs","version":"1.0.5","source":null},{"name":"winapi","version":"0.3.8","source":"registry+https://github.com/rust-lang/crates.io-index"}],"replace":null},"advisory":{"id":"RUSTSEC-2018-0015","package":"term","title":"term is looking for a new maintainer","description":"The author of the `term` crate does not have time to maintain it and is looking\nfor a new maintainer.\n\nSome maintained alternatives you can potentially switch to instead, depending\non your needs:\n\n- [`crossterm`](https://github.com/crossterm-rs/crossterm)\n- [`termcolor`](https://crates.io/crates/termcolor)\n- [`yansi`](https://crates.io/crates/yansi)\n","date":"2018-11-19","aliases":[],"references":[],"collection":"crates","categories":[],"keywords":[],"cvss":null,"informational":"unmaintained","obsolete":false,"url":"https://github.com/Stebalien/term/issues/93","patched_versions":[],"unaffected_versions":[]},"versions":{"patched":[],"unaffected":["> 0.6.1"]}}]}}
No vulnerabilities were found
##[warning]undefined warnings found!
##[error]t is not iterable

Workflow code

      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Expected behavior

It doesn't error out :-)

Hello.

I'd like to use your audit-check action on our GHES (GitHub Enterprise Server) instance.
But failed due to below error;

::group::Calling cargo-audit (JSON output)
Calling cargo-audit (JSON output)
Warning: 1 vulnerabilities found!
No warnings were found
##[debug]Action was triggered on a push event, creating a Check report
Found 1 advisory(ies)
Error: Bad credentials

FYI, api endpoint for our GHES is; https://<internal_github_domain>/api/v3.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

audit-check or cargo-audit does not parse the semver of x.x.x-beta.x versions correctly?

Workflow code

name: Security Audit

on:
  schedule:
    - cron: '0 0 * * *'
  push:
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'
  pull_request:

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Action output

I got this issue opened by github-actions user:

Multiple memory safety issues

Affected versions contain multiple memory safety issues, such as:

• Unsoundly coercing immutable references to mutable references
• Unsoundly extending lifetimes of strings
• Adding the Send marker trait to objects that cannot be safely sent between threads

This may result in a variety of memory corruption scenarios, most likely use-after-free.

A signficant refactoring effort has been conducted to resolve these issues.

See advisory page for additional details.

Expected behavior

Notice the version of actix-web I use? it is 4.0.0-beta.1 and this bug is patched and fixed like 3 years ago! version 0.7.15.

it should not report a bug

Additional context

I'm not sure, but the problem is the code is private .. So I could only share a subset of it.
Also, feel free to guide me to open the same issue at another repo if it is not related to audit-check action.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

When updating to rust 2021 edition we get this error due to the fact that the cargo audit action is using the previous version of cargo.

Workflow code

https://github.com/TrueLayer/ginepro/blob/c6df27b7db64e64227dcaca6ec4d2c45d9db8f3e/.github/workflows/audit.yml

Action output

Run actions-rs/audit-check@v1
  with:
    token: ***
/usr/share/rust/.cargo/bin/cargo generate-lockfile
error: failed to load manifest for workspace member `/home/runner/work/ginepro/ginepro/ginepro`

Caused by:
  failed to parse manifest at `/home/runner/work/ginepro/ginepro/ginepro/Cargo.toml`

Caused by:
  feature `edition2021` is required

  The package requires the Cargo feature called `edition2021`, but that feature is not stabilized in this version of Cargo (1.55.0 (32da73ab1 2021-08-23)).
  Consider trying a newer version of Cargo (this may require the nightly release).
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#edition-2021 for more information about the status of this feature.
Error: The process '/usr/share/rust/.cargo/bin/cargo' failed with exit code 101

Expected behavior

Cargo audit action uses the latest version of cargo if available.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Codeblocks in the security report show " instead of "

Workflow code

name: Security audit

on:
  workflow_dispatch:
  schedule:
    - cron: '0 0 * * *'
  push:
    branches: [main]
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'
  pull_request:
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions:
      checks: write
      contents: read
      issues: write
      pull-requests: read
    steps:
      - uses: actions/checkout@v3
      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

chrono = { version = "0.4.24", features = ["serde"] } # triggers a security warning (at the time of writing)

Action output

The code blocks look like this:

Expected behavior

The code blocks should look like:

chrono = { version = "0.4", default-features = false, features = ["serde"] }

Additional context

Hiya, I can't find instructions on setting up the GITHUB_TOKEN -- ctrl F / searched issues / PRs. I'm assuming I would have to create a personal access token

Based on reporter.ts, it's used for:

• client.search.issuesAndPullRequests
• client.issues.create
• checks.CheckReporter(client, 'Security audit');

Do those correspond to the write/read:discussion, and workflow permissions?
Is anything else missing?

Motivation

cargo-audit has some useful options, and it would be nice to be able to use them via audit-check. For example:

• --deny-warnings: Fail if a warning exists -- warnings may be missed by reviewers until the PR has been merged and the issue submitted.
• --ignore: Ignore specified advisory -- if fix requires breaking change, the fix may be postponed as it cannot be fixed immediately (especially if that advisory is warning).

Workflow example

      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          options: --deny-warnings --ignore RUSTSEC-2020-0016

or

      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          deny-warnings: true
          ignore: [RUSTSEC-2020-0016]

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Running this action in GitHub gives the following message:

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/. Please update the following actions to use Node.js 16: actions-rs/audit-check@35b7b53b1e25b55642157ac01b4adceb5b9ebef3

The URL given states that

Node 12 has been out of support since April 2022, as a result we have started the deprecation process of Node 12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023. We will monitor the progress of the migration and listen to the community for how things are going before we define a final date.

To raise awareness of the upcoming change, we are adding a warning into workflows which contain Actions running on Node 12. This will come into effect starting on September 27th.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

For a variety of reasons, many projects don't contain their Cargo.toml file in their root directory, or they have multiple sub-projects each with their own Cargo.tomls. Would it be possible to make the project path configurable? That way the community would benefit from being able to run from a specified path.
We've added this action to a few of our projects and I'm in the process of expanding that to others as it works well, but I've hit this issue which seems to block me from using it in projects such as here and only the root directory `Cargo.toml in this repo here EDIT: was mistaken about this particular linked repo being an example.

Workflow example

name: Security audit
on:
  schedule:
    - cron: '0 0 * * *'
      
  paths: 
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
        env:
          PROJECT_PATH: ./my_sub_folder

Additional context

As far as I'm aware there's no way around this at the moment. Been looking for workarounds to this issue I'm facing and found the working-directory option here but turns out it can only be used with run and not with uses.
Found a PR here which seems to have resolved this in another action, hoping something similar would work with audit-check.

Please implement the same workaround for audit-check as you did for clippy.

Motivation

First step of triaging an audit issue is to see why the affected crate is being included in the build, to see if it's a direct dependency that can be controlled, or a deep dependency that may need more effort. Including the output from cargo tree -i <crate> in the opened issue would allow trivially seeing this from the issue directly (example).

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

My rust/cargo project isn't at the top level of my repo, so my audit check always fails because it can't find my Cargo.toml/Cargo.lock file and it doesn't take a manifest-path like other cargo commands do.

Describe your idea, motivation, and how Rust community could benefit from this feature.

Workflow example

It would be awesome if the action would read working-directory or take a manifest-path arg

jobs:
  security_audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions-rs/audit-check@v1
        with:
          # consume working-directory
          working-directory: api
          # or read args
          args: --manifest-path api/Cargo.lock
          token: ${{ secrets.GITHUB_TOKEN }}

Additional context

I've tried a couple work arounds but couldn't get any of them working, I hope this isn't an invasive/difficult addition.

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

onefetch currently has many PRs that are failing due to the audit check (discussed in o2sh/onefetch#534). However, these PRs are not introducing dependencies with audit findings. The PRs should probably pass, as the audit findings aren't caused by the PRs themselves, but by the existing dependencies in the main branch that the PRs branched off of.

Workflow example

I would assume that, depending on how this would be implemented, it would require a fetch depth of at least 2 to be able to compare with the previous commit. Although more commits would have to be fetched for multi-commit PRs.

name: Security audit
on:
  pull_request:
    paths: 
      - '**/Cargo.toml'
      - '**/Cargo.lock'
jobs:
  security_audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0 # fetch all commits (if needed, depends on implementation)
      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          diff-only: true

Additional context

One way to do this might be to fail only if the PR introduces new audit findings that weren't found in the main branch, perhaps by caching the main branch's audit findings somehow.
The other way I can think of would be to compare the diff between the main branch and the PR, and audit only the dependencies that show up in the diff.

It shouldn't be rebuild every time. Only when there is a new version of cargo-audit or rustc.

Motivation

Setting up a GitHub token usually isn't easy and often requires access that I, as a member of an organization, don't have. Presently, if token is not passed, the job fails. All I'd like it to do is to run cargo audit without needing to access/update anything in GitHub. I simply want my build to fail with reports on what vulnerabilities were found in the logs within GitHub Actions.

Workflow example

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions-rs/audit-check@v1

cargo-audit v0.11.0 added (experimental) support for automatically updating the Cargo.toml https://blog.rust-lang.org/inside-rust/2020/01/23/Introducing-cargo-audit-fix-and-more.html#cargo-audit-fix-automatically-update-vulnerable-dependencies
Consider adding a feature to create a PR with this fix.

Description

I have a repo where I've checked in Cargo.lock, since it's producing a binary which I'm shipping. I've just started getting audit violations in CI for this that I cannot reproduce locally. I've tracked this down to the generate-lockfile call at the beginning; this updates the checked-in Cargo-lock. In my case, it brings in a new vulnerability due to a transitive dependency update.

Workflow code

name: Security audit
on:
  push:
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'
jobs:
  security_audit:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Expected behavior

If a Cargo.lock is in source control, it should be used as-is.

At https://github.com/step-security/secure-workflows we are building a knowledge-base (KB) of GITHUB_TOKEN permissions needed by different GitHub Actions. When developers try to set minimum token permissions for their workflows, they can use this knowledge-base instead of trying to research permissions needed by each GitHub Action they use.

Below you can see the KB of your GITHUB Action.

name: 'rust-audit-check'
github-token:
  action-input:
    input: token
    is-default: false
  permissions:
    issues: write
    issues-reason: to create issues #Checkout: https://github.com/actions-rs/audit-check/blob/35b7b53b1e25b55642157ac01b4adceb5b9ebef3/src/reporter.ts#L243
    checks: write
    checks-reason: to create check #Checkout: https://github.com/actions-rs/audit-check/blob/35b7b53b1e25b55642157ac01b4adceb5b9ebef3/src/reporter.ts#L185
#Fixes #643

If you think this information is not accurate, or if in the future your GitHub Action starts using a different set of permissions, please create an issue at https://github.com/step-security/secure-workflows/issues to let us know.

This issue is automatically created by our analysis bot, feel free to close after reading :)

References:

GitHub asks users to define workflow permissions, see https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ and https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token for securing GitHub workflows against supply-chain attacks.

Setting minimum token permissions is also checked for by Open Source Security Foundation (OpenSSF) Scorecards. Scorecards recommend using https://github.com/step-security/secure-workflows so developers can fix this issue in an easier manner.

Motivation

When using audit-check on schedule, the action automatically creates an issue. However, given this is a security vulnerability it seems creating an issue is not a desired behavior. At least this should be optional through an input to the action.

Workflow example

     - uses: actions-rs/audit-check@v2`
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          create-issue: false

Additional context

N/A

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

The recommended "Scheduled audit" workflow seems to not work: https://github.com/marketplace/actions/rust-audit-check#scheduled-audit

Workflow code

https://github.com/vn971/rm_rf/blob/master/.github/workflows/cargo-audit.yml

name: cargo audit

on:
  schedule:
    - cron: '0 0 0 * *'
  push:
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'
  pull_request:

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/audit-check@issue-104
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Action output

https://github.com/vn971/rm_rf/actions/runs/2272630581/workflow

Expected behavior

The workflow yml should be valid, the workflow should be able to start (as opposed to syntax failure).

Additional context

The observed behavior occurs in a very small and public repo, this one: https://github.com/vn971/rm_rf

Hi, I've integrated audit-check as a Github Action in a Rust project. However, the results are not identical to running cargo audit locally. For example, the following output is from Github Actions and no vulnerabilities nor warnings were found.

  {"database":{"advisory-count":323,"last-commit":"67da87fc89b37912c25a32e4b647e1d6c576cdb9","last-updated":"2021-08-10T21:54:42Z"},"lockfile":{"dependency-count":161},"settings":{"target_arch":null,"target_os":null,"severity":null,"ignore":[],"informational_warnings":["unmaintained"],"package_scope":null},"vulnerabilities":{"found":false,"count":0,"list":[]},"warnings":{}}
No vulnerabilities were found
No warnings were found

Warnings are ignored based on how cargo audit is configured but the results will always output "No warnings were found". Thus, the output is misleading.

Can we enable information warnings by default, or make it configurable?

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

Sometimes addressing an advisory is not important for a repository. Maybe it's only used in test or deprecated code, or is a difficult fix and analysis of the vulnerability shows the repo isn't actually vulnerable. In those cases, cargo audit provides --ignore, but it seems this option is not available in the GitHub action.

Workflow example

jobs:
  audit:
    runs-on: ubuntu-latest
    permissions: write-all
    name: "Audit Dependencies"
    steps:
      - uses: actions/checkout@v2
      - uses: actions-rs/audit-check@v1                                                                                                                                                                                                                                                                                        
        with:
          ignore:
            - RUSTSEC-2021-0124
          token: ${{ secrets.GITHUB_TOKEN }}

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about bugs reporting: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#reporting-bugs
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Description

Under this configuration on a simple project, cargo audit fails with this output.

Workflow code

name: Security audit

on:
  push:
    paths:
      - '**/Cargo.toml'
      - '**/Cargo.lock'
  pull_request:

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - uses: actions-rs/audit-check@v1
        with:
          token: ${{ secrets.GITHUB_TOKEN }}

Action output

Error: t is not iterable

Expected behavior

Don't fail.

Additional context

cargo audit runs fine on my local machine.

Additionally, it seems like the last time this was a bug, it was due to a change in cargo-audit itself - maybe this is the same thing? #115

Do the checklist before filing an issue:

• Is this related to the actions-rs Actions?
  If you think it's a problem related to Github Actions in general, use GitHub Community forum instead: https://github.community
• You've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

When this action creates an issue it would be great if you could specify which labels it should add to that issue. I would personally use it to apply an "automated" label to it so I can filter it out from project boards.

In addition to manually specifying labels I would like labels for the severity. E.g. severity-unmaintained and severity-critical. This could be toggled on/off with a severityLabels bool option. It would also be nice to be able to edit those severity labels.

Workflow example

      - uses: rustsec/[email protected]
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          labels: ["automated", "audit"]
          severityLabels: true

for vulnerabilities that have been solved, will the action close the issue or will I need to manually close them?
Also will the action create duplicate issues each run or it detects that the issue is already created (asking if I close something which shouldn't have been, will it be recreated)

Thanks

Checklist before filing an issue:

• Is this related to the actions-rs Actions?
• I've read the Contributing section about feature requests: https://github.com/actions-rs/.github/blob/master/CONTRIBUTING.md#feature-requests
• Is this something you can debug and fix? Send a pull request! Bug fixes and documentation fixes are welcome.

Motivation

I would like for the default workflow yml to include permissions for the GITHUB_TOKEN it uses.

Without this, one might fear of giving too many permissions to this github action and as a result they won't use cargo audit (which in turn means that their audits will likely be absent, which I think is not good).

If we implement this, people might be more stusting to install this Action, and its usage will therefore grow.

Workflow example

I would like to set up something like this:

permissions:
  issues: write
  pull-requests: read
  contents: read

So that GITHUB_TOKEN would have exactly the right it needs, which would in turn make me feel safer about using this Action/Workflow. I do not immediately know this list, however. The above one is random-guessed and might be invalid.

Additional context

See the full list of possible permissions: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#permissions

Motivation

Having the security scan action integrated with GitHub's security tab will give security issues found by the scan more visibility, and let maintainers deal with security advisories and fixes all in the same place instead of having a split between regular issues and advisories that could come from other actions integrated with the Security tab.

Workflow example

name: Security audit
on:
  push:
    paths: 
      - '**/Cargo.toml'
      - '**/Cargo.lock'
jobs:
  security_audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions-rs/audit-check@v1
        with:
          sarif-report: results.sarif
          token: ${{ secrets.GITHUB_TOKEN }}
      - name: Upload SARIF file
        uses: github/codeql-action/upload-sarif@v1
        with:
          sarif_file: results.sarif

Additional context

GitHub offers an action to upload SARIF reports that should make implementing this feature easier: https://docs.github.com/en/free-pro-team@latest/github/finding-security-vulnerabilities-and-errors-in-your-code/uploading-a-sarif-file-to-github

SARIF is stands for Static Analysis Results Interchange Format and is a standard, JSON-based format for the output of static analysis tools. For a quick introduction you can read this: https://github.com/microsoft/sarif-tutorials/blob/main/docs/1-Introduction.md