forked from crytic/slither-action
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Improve README and fix linting warnings
- Loading branch information
Showing
1 changed file
with
23 additions
and
19 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -12,9 +12,10 @@ pages](https://github.com/crytic/slither/wiki). | |
| - [Github Code Scanning integration](#github-code-scanning-integration) | ||
| - [Examples](#examples) | ||
|
|
||
| # How to use | ||
| ## How to use | ||
|
|
||
| Create `.github/workflows/slither.yml`: | ||
|
|
||
| ```yaml | ||
| name: Slither Analysis | ||
| on: [push] | ||
|
|
@@ -26,40 +27,40 @@ jobs: | |
| - uses: crytic/[email protected] | ||
| ``` | ||
| ## Options | ||
| ### Options | ||
| | Key | Description | ||
| |------------------|------------ | ||
| | `ignore-compile` | If set to true, the Slither action will not attempt to compile the project. False by default. See [Advanced compilation](#advanced-compilation). | ||
| | `node-version` | The version of `node` to use. If this field is not set, the latest version will be used. | ||
| | `sarif` | If provided, the path of the SARIF file to produce, relative to the repo root (see [Github Code Scanning integration](#github-code-scanning-integration)). | ||
| | `slither-args` | Extra arguments to pass to Slither. | ||
| | `slither-args` | Extra arguments to pass to Slither. | ||
| | `slither-config` | The path to the Slither configuration file. By default, `./slither.config.json` is used if present. See [Configuration file](https://github.com/crytic/slither/wiki/Usage#configuration-file). | ||
| | `slither-version`| The version of slither-analyzer to use. By default, the latest release in PyPI is used. | ||
| | `solc-version` | The version of `solc` to use. If this field is not set, the version will be guessed from project metadata. **This only has an effect if you are not using a compilation framework for your project** -- i.e. if `target` is a standalone `.sol` file. | ||
| | `target` | The path to the root of the project to be analyzed by Slither. Can be a directory or a file. Defaults to the repo root. | ||
|
|
||
| ## Advanced compilation | ||
| ### Advanced compilation | ||
|
|
||
| If the project requires advanced compilation setting, set `ignore-compile` to true and follow the compilation steps before running slither. See the [examples](#examples) section. | ||
| If the project requires advanced compilation settings or steps, set `ignore-compile` to true and follow the compilation steps before running slither. You can find an example workflow using this option in the [examples](#examples) section. | ||
|
|
||
| ## Triaging results | ||
| ### Triaging results | ||
|
|
||
| Add `//slither-disable-next-line DETECTOR_NAME` before the finding, or use the [Github Code Scanning integration](github-code-scanning-integration). | ||
|
|
||
| # Github Code Scanning integration | ||
| ## Github Code Scanning integration | ||
|
|
||
| The action supports the Github Code Scanning integration, which will push slither's alerts to the Security tab of the Github project (see [About code scanning](https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning)). This integration eases the triaging of findings and improves the continious integration. | ||
| The action supports the Github Code Scanning integration, which will push slither's alerts to the Security tab of the Github project (see [About code scanning](https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/about-code-scanning)). This integration eases the triaging of findings and improves the continuous integration. | ||
|
|
||
| ## Code Scanning preview | ||
| ### Code Scanning preview | ||
|
|
||
| ### Findings Summary | ||
| #### Findings Summary | ||
| <img src="https://raw.githubusercontent.com/crytic/slither-action/68ad2434d613601b79da77aeb6b3bb04024d3d10/images/summary.png" alt="Summary" width="500"/> | ||
|
|
||
| ### Findings Details | ||
| #### Findings Details | ||
| <img src="https://raw.githubusercontent.com/crytic/slither-action/68ad2434d613601b79da77aeb6b3bb04024d3d10/images/details.png" alt="Summary" width="500"/> | ||
|
|
||
| ## How to use | ||
| ### How to use | ||
|
|
||
| To enable the integration, use the `sarif` option, and upload the Sarif file to `codeql-action`: | ||
|
|
||
|
|
@@ -70,6 +71,8 @@ jobs: | |
| analyze: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - name: Run Slither | ||
| uses: crytic/[email protected] | ||
| id: slither | ||
|
|
@@ -84,12 +87,13 @@ jobs: | |
| ``` | ||
|
|
||
| Here: | ||
| - `continue-on-error: true` is required to let the SARIF upload step runs if slither finds issues | ||
| - `id: slither` is the name used in for `steps.slither.outputs.sarif` | ||
|
|
||
| # Examples | ||
| - `continue-on-error: true` is required to let the SARIF upload step run if slither finds issues | ||
| - `id: slither` is the name used to reference the step later on (e.g., in `steps.slither.outputs.sarif`) | ||
|
|
||
| ## Examples | ||
|
|
||
| ## Example workflow: simple action | ||
| ### Example workflow: simple action | ||
|
|
||
| The following is a complete GitHub Actions workflow example. It will trigger on | ||
| pushes to the repository, and leverage the Node.js integration in the Slither | ||
|
|
@@ -110,7 +114,7 @@ jobs: | |
| target: 'src/' | ||
| ``` | ||
|
|
||
| ## Example workflow: Hardhat and SARIF | ||
| ### Example workflow: Hardhat and SARIF | ||
|
|
||
| The following is a complete GitHub Actions workflow example. It will trigger | ||
| with commits on `master` as well as any pull request opened against the `master` | ||
|
|
@@ -155,7 +159,7 @@ jobs: | |
| sarif_file: ${{ steps.slither.outputs.sarif }} | ||
| ``` | ||
|
|
||
| ## Example workflow: Brownie and SARIF | ||
| ### Example workflow: Brownie and SARIF | ||
|
|
||
| The following is a complete GitHub Actions workflow example. It will trigger | ||
| with commits on `master` as well as any pull request opened against the `master` | ||
|
|
@@ -199,7 +203,7 @@ jobs: | |
| sarif_file: ${{ steps.slither.outputs.sarif }} | ||
| ``` | ||
|
|
||
| ## Example workflow: Dapp | ||
| ### Example workflow: Dapp | ||
|
|
||
| The following is a complete GitHub Actions workflow example, meant to illustrate | ||
| the usage of the Slither action when the compilation framework is not based on | ||
|
|
||