Code Monkey home page Code Monkey logo

cve-bin-tool-action's Introduction

CVE Binary Tool GitHub Action

CVE Binary Tool GitHub Action helps you to scan your GitHub repositories more conveniently. Just add this Action by following the instructions below and It will start doing it's work and will give you updates through the security tab.

Inputs

scan_mode

Optional CVE Binary Tool GitHub Action has three scan modes. The scan modes are listed below:

  1. repo-only (default): In this mode cve-bin-tool will automatically detect binary and requirement files and scan them.
  2. sbom-only: In this mode cve-bin-tool will only automatically detect supported SBOM files and scan them.
  3. both: In this mode cve-bin-tool will automatically detect SBOM, binary and requirement files and scan them.

NOTE: Scans may have duplicate results when using the both option as scan_mode.

nvd_api_key

Optional NVD API Key is required for downloading National Vulnerbility Database.

NOTE: CVE Binary Tool GitHub Action uses https://cveb.in as mirror to fetch the latest CVEs, and this mirror gets updated every day. So when you provide the nvd_api_key it uses the latest NVD data instead of one day old mirror data.

exclude_dir

Optional While scanning, CVE Binary Tool will ignore these directories.

NOTE: To mention multiple directories, use comma as a separator and don't include spaces.

alerts_based_on_file

Optional Split security alerts based on source file. By default it creates separate security alerts for every component.

build_command

Optional It will run the build_command before running CVE Binary Tool on the build output and the repository content.

sbom_type

Optional CVE Binary Tool GitHub Action provides SBOM report in security tab along with HTML/PDF scan reports. Valid SBOM types are spdx, cyclonedx. (default: spdx)

sbom_format

Optional Valid SBOM formats are tag, json, yaml. (default: json)

triage_input_file

Optional Provide input filename for triage data. The supported format is CycloneDX VEX. Find more information here.

Example usage

name: CVE Binary Tool Scanner

on:
  push:
  pull_request:
  workflow_dispatch:
  schedule:
    - cron: '20 2 * * *'

permissions:
  security-events: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: intel/cve-bin-tool-action@main
        with:
          nvd_api_key: '${{ secrets.NVD_API_KEY }}'
          exclude_dir: test

Build before scanning

Make example

name: CVE Binary Tool Scanner

on:
  push:
  workflow_dispatch:

permissions:
  security-events: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: intel/cve-bin-tool-action@main
        with:
          nvd_api_key: '${{ secrets.NVD_API_KEY }}'
          alerts_based_on_file: true
          build_command: make

Node.js/Electron.js example

name: CVE Binary Tool Scanner

on:
  push:
  workflow_dispatch:

permissions:
  security-events: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Setup node v16 (for build process)
        run: |
          curl -sL https://deb.nodesource.com/setup_16.x | sudo bash -
          sudo apt -y install nodejs
      - uses: intel/cve-bin-tool-action@main
        with:
          nvd_api_key: '${{ secrets.NVD_API_KEY }}'
          build_command: npm run build

Update SBOM automatically with a PR in regular interval

name: Update SBOM Action
on:
  schedule:
    - cron: '20 2 * * *'

permissions:
  security-events: write
  contents: write
  pull-requests: write

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: intel/cve-bin-tool-action@main
        with:
          nvd_api_key: '${{ secrets.NVD_API_KEY }}'
          exclude_dir: binary
          sbom_type: spdx
          sbom_format: json
          alerts_based_on_file: false

      - run: |
          mkdir -p reports
          mv SBOM.spdx.json reports/SBOM.spdx.json # by default the SBOM file will be stored in the root directory of the repository, in this example the SBOM file is moved to reports directory in the repository

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v5
        with:
          commit-message: 'chore: update sbom'
          title: 'chore: update sbom'
          branch: chore-update-sbom
          delete-branch: true
          author: GitHub <[email protected]>

Screenshots

image

image

image

cve-bin-tool-action's People

Contributors

b31ngd3v avatar dependabot[bot] avatar rdower avatar terriko avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar

Forkers

b31ngd3v terriko

cve-bin-tool-action's Issues

ci: move linters to correct directory so they run

I think when I was copying files over from the main cve-bin-tool repo I forgot to put some of them into .github/workflows and the linters, at least, need to be in a workflows directory to, well, work.

refactor: do we need shell=true in scanner.py?

I just approved some code that uses subprocess shell=true:

args.build_command, capture_output=True, text=True, shell=True

But I wanted to open this up to see if maybe we could refactor to avoid this, since bandit (quite rightly) warns that it could be a security issue:

https://bandit.readthedocs.io/en/latest/plugins/b602_subprocess_popen_with_shell_equals_true.html

I don't think the risk in this context is super high (most people running stuff in github actions already have shell access) but there's a minor risk that a pull request could do something hinky here so we might as well do a bit of hardening and switch to shell=false if we can.

feat: sbom generation (by default?)

With the current interest in SBOMs I think it would be pretty handy for a lot of people if we generated an SBOM to go alongside the reports published in the Security tab.

The idea would be that users could then review the SBOM and potentially publish it themselves if they wanted. Or at least know that SBOM generation was an option (and, hopefully, pretty easy for them to use!). I'd suggest we provide this as a default option just to encourage usage (we could maybe provide an option to turn it off if users aren't interested)

We could even offer an option to generate a pull request in future so users of the action to use it to do something similar to what we do on the main cve-bin-tool repo: https://github.com/intel/cve-bin-tool/blob/main/.github/workflows/sbom.yml -- I'm sure we're not the only open source project looking to publish SBOMs regularly. I'd suggest we default to some kind of standard-ish name, similar to how people expect to find LICENSE.txt and README.md or whatever. So probably SBOM.json for what we make now (change that file extension as needed if we generate a different format.) Probably add the ability to configure the file type and possibly the file name later.

We might need to be a bit careful about how to handle it if we then enable SBOM discovery and scanning as described in cve-bin-tool#3116. I'm guessing we'd want to have the option to do diffs and pull requests to update or something, and we'd have to be careful of not overwriting other non-generated SBOMs (probably why we'd want to give people an option to config the name). That seems like a bridge to cross when we come to it.

refactor: improve tests to withstand future cve data changes

I left a bunch of review comments in #10 that I think should be addressed, but didn't need to be addressed right away. So this issue is to address the comments here:

#10 (review)

We've got the same problem on the main cve-bin-tool repo: assert == style tests tend to be brittle if a new CVE is discovered because they rely on exact matching. CVEs don't change often, so we have defaulted to just updating the test as needed, but I think we could save ourselves some maintenance by using python's built-in set function issubset() to allow for the case where our output might have a few more lines than it did when the test was written.

Also we maybe should enable that least bandit rule if there's no actual reason to disable it.

action failing

Not sure what's up, but here's the error we're getting on intel/cve-bin-tool:

Downloading CVEs... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:07
  File "/home/runner/work/_actions/intel/cve-bin-tool-action/main/src/scanner.py", line 123, in <module>

    main()
  File "/home/runner/work/_actions/intel/cve-bin-tool-action/main/src/scanner.py", line 98, in main
    available_fixes = cve_bin_tool.scan(
  File "/home/runner/work/_actions/intel/cve-bin-tool-action/main/src/cve_bin_tool.py", line 77, in scan
    with open(f"{output}.json") as fd:
FileNotFoundError: [Errno 2] No such file or directory: './scan-result.json'

I'm re-reunning in case it's related to a network error but it looks like the CVEs downloaded so I don't think that's it?

docs: What happens if you don't supply nvd_api_key ?

The README notes that nvd_api_key is optional but it doesn't really explain what happens if you don't supply one. I'm assuming we just default to using the mirror/cache (from https://github.com/sec-data/mirror-sandbox) but we should probably tell people that and how often that cache is updated so they can make informed decisions. (Some similar tools will default to up to month old databases, so we want to make sure users know that's not what happens here!)

feat: scanning build output

Since cve-bin-tool can be used to scan built binaries, it's possible some users will want to specify a build command and execute it before scanning, somewhat similar to what we see in the unofficial coverity action here: https://github.com/marketplace/actions/unofficial-coverity-scan#usage

I'm not sure how many people would want this, since it's possible that anyone actually building stuff would prefer to integrate cve-bin-tool into that workflow rather than execute a separate action, but since it's a lot easier to run a prebuilt action I'm guessing it'll be nice for at least some users.

fix: support other versions of cyclonedx?

I noticed our main repo's SBOMs are now being generated in CycloneDX 1.5:

  "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",

But I remembered from code review that we're explicitly looking for CycloneDX 1.3 in a few spots:

if data.find("cyclonedx.org/schema/bom/1.3") != -1:

Do we need to change anything to make sure other versions of CycloneDX get picked up?

feat: separate alerts for separate components

Right now, I get a single entry in my Security / code-scanning tab that shows all the issues found per file such as a requirements.txt. It would be handy if we could break this up so it displayed per-product/version, so we could discard some alerts as false positives (e.g. the ones with docutils that are for the wrong library) without discarding real alerts in other components.

This is probably more urgent for component lists / language parser stuff since they have longer lists of unrelated components than binary files usually do, but probably the binary files should also be separated into alerts per product found as well.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.