diff --git a/jfrog-applications/.gitbook/assets/build-info-summary.png b/jfrog-applications/.gitbook/assets/build-info-summary.png
index 27f5de3..4822d43 100644
Binary files a/jfrog-applications/.gitbook/assets/build-info-summary.png and b/jfrog-applications/.gitbook/assets/build-info-summary.png differ
diff --git a/jfrog-applications/frogbot/setup-frogbot-using-github-actions.md b/jfrog-applications/frogbot/setup-frogbot-using-github-actions.md
index 7de8022..77d397f 100644
--- a/jfrog-applications/frogbot/setup-frogbot-using-github-actions.md
+++ b/jfrog-applications/frogbot/setup-frogbot-using-github-actions.md
@@ -2,22 +2,23 @@
### Github Prerequisites
-* Go to your repository's **settings** tab and save the JFrog connection details as repository secrets with the following names:
- * **JF\_URL** (JFrog Platform URL - Example: `https://acme.jfrog.io`)
- > You can also use **JF\_XRAY\_URL** and **JF\_ARTIFACTORY\_URL** instead of **JF\_URL**
- * **JF\_ACCESS\_TOKEN** (JFrog access token)
- > You can also use **JF\_USER** + **JF\_PASSWORD** instead of **JF\_ACCESS\_TOKEN**.
- >
- >
- > Instead of using **JF\_ACCESS\_TOKEN** and providing an access token as a GitHub secret, you can utilize the GitHub [OpenID Connect (OIDC)](#authenticating-using-openid-connect-oidc) authentication protocol.
- * **JF\_GIT\_TOKEN** (GitHub token)
- > You can utilize [${{secrets.GITHUB_TOKEN}}](https://docs.github.com/en/actions/security-guides/automatic-token-authentication) for **JF_GIT_TOKEN**, which is an automatically generated token by GitHub.
- > However, this option comes with a limitation: a workflow, such as Frogbot itself, cannot trigger another workflow. Consequently, if you have additional workflows intended to activate upon the creation of a new pull request, they might not be initiated.
- > To resolve this issue, you can generate a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) and use it as JF_GIT_TOKEN.
-
+* Go to your repository's **settings** tab and save the JFrog connection details as repository secrets with the following names:
-![](../.gitbook/assets/github-repository-secrets.png)
+ * **JF\_URL** (JFrog Platform URL - Example: `https://acme.jfrog.io`)
+
+ > You can also use **JF\_XRAY\_URL** and **JF\_ARTIFACTORY\_URL** instead of **JF\_URL**
+
+ * **JF\_ACCESS\_TOKEN** (JFrog access token)
+
+ > You can also use **JF\_USER** + **JF\_PASSWORD** instead of **JF\_ACCESS\_TOKEN**.
+ >
+ > Instead of using **JF\_ACCESS\_TOKEN** and providing an access token as a GitHub secret, you can utilize the GitHub [OpenID Connect (OIDC)](setup-frogbot-using-github-actions.md#authenticating-using-openid-connect-oidc) authentication protocol.
+ * **JF\_GIT\_TOKEN** (GitHub token)
+
+ > You can utilize [$\{{secrets.GITHUB\_TOKEN\}}](https://docs.github.com/en/actions/security-guides/automatic-token-authentication) for **JF\_GIT\_TOKEN**, which is an automatically generated token by GitHub. However, this option comes with a limitation: a workflow, such as Frogbot itself, cannot trigger another workflow. Consequently, if you have additional workflows intended to activate upon the creation of a new pull request, they might not be initiated. To resolve this issue, you can generate a [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) and use it as JF\_GIT\_TOKEN.
+
+![](../.gitbook/assets/github-repository-secrets.png)
* Under **Actions** > **General**, check the **Allow GitHub Actions to create and approve pull requests** check box.
@@ -30,50 +31,40 @@
### Frogbot GitHub Action Templates
1. Begin by cloning the GitHub repository to your local environment.
-
2. Switch to the target branch where you'd like the pull requests to be scanned.
-
3. Create a file named **frogbot-scan-pull-request.yml**. Fill it with the provided [template](templates/github-actions/frogbot-scan-pull-request.yml), and then push it into the **.github/workflows** directory at the root of your GitHub repository.
-
4. Return to the default branch.
-
5. Now, create a file named **frogbot-scan-repository.yml**. Again, populate it with the provided [template](templates/github-actions/frogbot-scan-repository.yml) and push it into the **.github/workflows** directory at the root of your GitHub repository.
-
+\
+
+
Authenticating using OpenID Connect (OIDC)
-#### General
+Authenticating using OpenID Connect (OIDC)
-The sensitive connection details, such as the access token used by JFrog Frogbot, can be automatically generated by the action instead of storing it as a secret in GitHub.
-This is made possible by leveraging the OpenID-Connect (OIDC) protocol. This protocol can authenticate the workflow issuer and supply a valid access token. Learn more about this integration in [this](https://jfrog.com/blog/secure-access-development-jfrog-github-oidc) blog post.
-To utilize the OIDC protocol, follow these steps:
+**General**
-#### JFrog Platform configuration
+The sensitive connection details, such as the access token used by JFrog Frogbot, can be automatically generated by the action instead of storing it as a secret in GitHub. This is made possible by leveraging the OpenID-Connect (OIDC) protocol. This protocol can authenticate the workflow issuer and supply a valid access token. Learn more about this integration in [this](https://jfrog.com/blog/secure-access-development-jfrog-github-oidc) blog post. To utilize the OIDC protocol, follow these steps:
-1. **Configure an OIDC Integration**: This phase sets an integration between GitHub Actions to the JFrog platform.
- A) Navigate to the Administration tab In the JFrog Platform UI
- B) Click `General` | `Manage Integrations`
- C) Click `New Integration` | `OpenID Connect`:
- ![](../.gitbook/assets/oidc-new-integration.png)
- D) Configure the OIDC integration:
- ![](../.gitbook/assets/oidc-configure-integration.png)
+**JFrog Platform configuration**
-| NOTE: |
-|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| The value specified as the 'Provider Name' should be used as the 'oidc-provider-name' input in [Workflow configuration step 2](#workflowstep2) below. |
-| The 'Audience' field does NOT represent the 'aud' claim that can be added into identity-mapping configured in the 'Claims JSON' (shown below). Only claims that are included in the 'Claims Json' created during step 2 will be validated. |
+1. **Configure an OIDC Integration**: This phase sets an integration between GitHub Actions to the JFrog platform.\
+ A) Navigate to the Administration tab In the JFrog Platform UI\
+ B) Click `General` | `Manage Integrations`\
+ C) Click `New Integration` | `OpenID Connect`:\
+ ![](../.gitbook/assets/oidc-new-integration.png)\
+ D) Configure the OIDC integration:\
+ ![](../.gitbook/assets/oidc-configure-integration.png)
-
+
2. **Configure an identity mapping**: This phase sets an integration between a particular GitHub repository to the JFrog platform.
- An identity mapping is a configuration object utilized by the JFrog Platform to associate incoming OIDC claims with particular selected fields. These fields might include `repository`, `actor`, `workflow`, and others.
- To configure the identity mapping, click on the identity mapping created in section 1 and then click on `Add Identity Mapping`. In the 'priority' field insert the value '1' and fill in the rest of the required fields:
+ An identity mapping is a configuration object utilized by the JFrog Platform to associate incoming OIDC claims with particular selected fields. These fields might include `repository`, `actor`, `workflow`, and others. To configure the identity mapping, click on the identity mapping created in section 1 and then click on `Add Identity Mapping`. In the 'priority' field insert the value '1' and fill in the rest of the required fields:\
![](../.gitbook/assets/oidc-identity-mapping.png)
- You have the flexibility to define any valid list of claims required for request authentication. You can check a list of the possible claims [here](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token).
- Example Claims JSON:
+ You have the flexibility to define any valid list of claims required for request authentication. You can check a list of the possible claims [here](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#understanding-the-oidc-token). Example Claims JSON:
```json
{
@@ -81,7 +72,7 @@ To utilize the OIDC protocol, follow these steps:
}
```
-### Workflow configuration
+#### Workflow configuration
1. **Set required permissions**: In the course of the protocol's execution, it's imperative to acquire a JSON Web Token (JWT) from GitHub's OIDC provider. To request this token, it's essential to configure the specified permission in the workflow file:
@@ -89,20 +80,18 @@ To utilize the OIDC protocol, follow these steps:
permissions:
id-token: write
```
-
-
-
-2. **Pass the 'oidc-provider-name' input to the Action (Required)**: The 'oidc-provider-name' parameter designates the OIDC configuration whose one of its identity mapping should align with the generated JWT claims. This input needs to align with the 'Provider Name' value established within the OIDC configuration in the JFrog Platform.
-3. **Pass the 'oidc-audience' input to the Action (Optional)**: The 'oidc-audience' input defines the intended recipients of an ID token (JWT), ensuring access is restricted to authorized recipients for the JFrog Platform. By default, it contains the URL of the GitHub repository owner. It enforces a condition, allowing only workflows within the designated repository/organization to request an access token. Read more about it [here](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-audience-value).
+2. **Pass the 'oidc-provider-name' input to the Action (Required)**: The 'oidc-provider-name' parameter designates the OIDC configuration whose one of its identity mapping should align with the generated JWT claims. This input needs to align with the 'Provider Name' value established within the OIDC configuration in the JFrog Platform.
+3. **Pass the 'oidc-audience' input to the Action (Optional)**: The 'oidc-audience' input defines the intended recipients of an ID token (JWT), ensuring access is restricted to authorized recipients for the JFrog Platform. By default, it contains the URL of the GitHub repository owner. It enforces a condition, allowing only workflows within the designated repository/organization to request an access token. Read more about it [here](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#customizing-the-audience-value).
Example step utilizing OpenID Connect:
```yml
- uses: jfrog/frogbot@v2
env:
- JF_URL: ${{ secrets.JF_URL }}
+ JF_URL: ${{ vars.JF_URL }}
JF_GIT_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
oidc-provider-name: frogbot-integration
```
-
[Default: 0s]
Number of seconds or milliseconds to wait between retries. The numeric value should either end with s for seconds or ms for milliseconds (for example: 10s or 100ms).
[Default: false]
Set to true to include a list of the affected files as part of the command output summary.
[Default: false]
Set to true to skip TLS certificates verification.
[Default: 200]
The minimum file size in MiB required to attempt a multi-part upload. This option, as well as the functionality of multi-part upload, requires Artifactory with S3 storage.
[Default: 5]
The maximum number of parts that can be concurrently uploaded per file during a multi-part upload. Set to 0 to disable multi-part upload. This option, as well as the functionality of multi-part upload, requires Artifactory with S3 storage.
[Default: 20]
The upload chunk size in MiB that can be concurrently uploaded during a multi-part upload. This option, as well as the functionality of multi-part upload, requires Artifactory with S3 or GCP storage.
[Default: 200]
The minimum file size in MiB required to attempt a multi-part upload. This option, as well as the functionality of multi-part upload, requires Artifactory with S3 or GCP storage.
[Default: 5]
The maximum number of parts that can be concurrently uploaded per file during a multi-part upload. Set to 0 to disable multi-part upload. This option, as well as the functionality of multi-part upload, requires Artifactory with S3 or GCP storage.
[Default: 3]
The number of parallel threads used to determine the curation status for each package in the project tree.
[Optional] [Pip]
Defines pip requirements file name. For example: 'requirements.txt'
[Optional]
Server ID configured using the jf c add command. If not specified, the default configured server is used.
[Optional]
A comma-separated(,) list of Xray watches, to enable Xray to determine violations accordingly. The command accepts this option only if the --project and --repo-path options are not provided. If none of the three options are provided, the command will show all known vulnerabilities.
[Default: false]
Set if you also require the list of licenses to be displayed.
[Optional]
Produces a JSON file containing the scan results.
[Optional]
Set if you'd like to receive all vulnerabilities, regardless of the policy configured in Xray.
[Default: false]
Set if you also require the list of licenses to be displayed.
[Default: false] Triggers token validation on found secrets
| | --format=json |[Optional]
Produces a JSON file containing the scan results.
[Optional]
Set if you'd like to receive all vulnerabilities, regardless of the policy configured in Xray.
[Optional]
Server ID configured using the jf c add command. If not specified, the default configured server is used.
[Optional]
JFrog project key, to enable Xray to determine security violations accordingly. The command accepts this option only if the --repo-path and --watches options are not provided. If none of the three options are provided, the command will show all known vulnerabilities
[Optional]
Artifactory repository path, to enable Xray to determine violations accordingly. The command accepts this option only if the --project and --watches options are not provided. If none of the three options are provided, the command will show all known vulnerabilities
[Optional]
A comma-separated(,) list of Xray watches, to enable Xray to determine violations accordingly. The command accepts this option only if the --repo-path and --repo-path options are not provided. If none of the three options are provided, the command will show all known vulnerabilities
[Default: false]
Set if you'd also like the list of licenses to be displayed.
[Default: table]
Defines the output format of the command. Acceptable values are: table and json.
[Default: true]
When using one of the flags --watches, --project or --repo-path and a Fail build rule is matched the command will return exit code 3. Set to false if you'd like to see violations with exit code 0.
[Default: false] [Gradle]
Set to true if you'd like to use the Gradle wrapper.
[Default: all] [npm]
Defines npm dependencies type. Possible values are: all, devOnly and prodOnly
[Default: false] [Gradle]
Set to true if you'd like to exclude Gradle test dependencies from Xray scanning.
[Optional] [Pip]
Defines pip requirements file name. For example: 'requirements.txt'
[Optional]
A comma-separated(,) list of relative working directories, to determine the audit targets locations.
If flag isn't provided, a recursive scan is triggered from the root directory of the project.
| -| `--exclusions` |[Default: .git;node_modules;target;venv;test]
List of semicolon-separated(;) exclusions, utilized to skip sub-projects from undergoing an audit. These exclusions may incorporate the * and ? wildcards.
[Optional]
Set to true if you wish to display issues that have a fix version only.
[Optional]
Set the minimum severity of issues to display. The following values are accepted: Low, Medium, High or Critical
[Default: 3]
The number of parallel threads used to scan the source code project.
[Default: false]
Set to true to request audit for a Go project.
[Default: false]
Set to true to request audit for a Gradle project.
[Default: false]
Set to true to request audit for a Maven project.
[Default: false]
Set to true to request audit for a npm project.
[Default: false]
Set to true to request audit for a pnpm project.
[Default: false]
Set to true to request audit for a .Net project.
[Default: false]
Set to true to request audit for a Pip project.
[Default: false]
Set to true to request audit for a Pipenv project.
[Default: false]
Set to true to request audit for a Yarn project.
[Default: false] Selective scanners mode: Execute SCA (Software Composition Analysis) sub-scan. By default, runs both SCA and Contextual Analysis. Can be combined with --secrets, --sast, --iac, and --without-contextual-analysis.
| -| `--iac` |[Default: false] Selective scanners mode: Execute IaC sub-scan. Can be combined with --sca, --secrets and --sast.
| -| `--secrets` |[Default: false] Selective scanners mode: Execute Secrets sub-scan. Can be combined with --sca, --sast and --iac.
| -| `--sast` |[Default: false] Selective scanners mode: Execute SAST sub-scan. Can be combined with --sca, --secrets and --iac.
| -| `--without-contextual-analysis` |[Default: false] Selective scanners mode: Disable Contextual Analysis scanner after SCA. Relevant only with --sca flag.
| -| `--validate-secrets` |[Default: false] Triggers token validation on found secrets
| -| **Command arguments** | The command accepts no arguments | + +| | | +|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Command name** | audit | +| **Abbreviation** | aud | +| **Command options** | | +| `--server-id` |[Optional]
Server ID configured using the jf c add command. If not specified, the default configured server is used.
[Optional]
JFrog project key, to enable Xray to determine security violations accordingly. The command accepts this option only if the --repo-path and --watches options are not provided. If none of the three options are provided, the command will show all known vulnerabilities
[Optional]
Artifactory repository path, to enable Xray to determine violations accordingly. The command accepts this option only if the --project and --watches options are not provided. If none of the three options are provided, the command will show all known vulnerabilities
[Optional]
A comma-separated(,) list of Xray watches, to enable Xray to determine violations accordingly. The command accepts this option only if the --repo-path and --repo-path options are not provided. If none of the three options are provided, the command will show all known vulnerabilities
[Default: false]
Set if you'd also like the list of licenses to be displayed.
[Default: table]
Defines the output format of the command. Acceptable values are: table and json.
[Default: true]
When using one of the flags --watches, --project or --repo-path and a Fail build rule is matched the command will return exit code 3. Set to false if you'd like to see violations with exit code 0.
[Default: false] [Gradle]
Set to true if you'd like to use the Gradle wrapper.
[Default: all] [npm]
Defines npm dependencies type. Possible values are: all, devOnly and prodOnly
[Default: false] [Gradle]
Set to true if you'd like to exclude Gradle test dependencies from Xray scanning.
[Optional] [Pip]
Defines pip requirements file name. For example: 'requirements.txt'
[Optional]
A comma-separated(,) list of relative working directories, to determine the audit targets locations.
If flag isn't provided, a recursive scan is triggered from the root directory of the project.
| +| `--exclusions` |[Default: .git;node_modules;target;venv;test]
List of semicolon-separated(;) exclusions, utilized to skip sub-projects from undergoing an audit. These exclusions may incorporate the * and ? wildcards.
[Optional]
Set to true if you wish to display issues that have a fix version only.
[Optional]
Set the minimum severity of issues to display. The following values are accepted: Low, Medium, High or Critical
[Default: 3]
The number of parallel threads used to scan the source code project.
[Default: false]
Set to true to request audit for a Go project.
[Default: false]
Set to true to request audit for a Gradle project.
[Default: false]
Set to true to request audit for a Maven project.
[Default: false]
Set to true to request audit for a npm project.
[Default: false]
Set to true to request audit for a pnpm project.
[Default: false]
Set to true to request audit for a .Net project.
[Default: false]
Set to true to request audit for a Pip project.
[Default: false]
Set to true to request audit for a Pipenv project.
[Default: false]
Set to true to request audit for a Yarn project.
[Default: false] Selective scanners mode: Execute SCA (Software Composition Analysis) sub-scan. By default, runs both SCA and Contextual Analysis. Can be combined with --secrets, --sast, --iac, and --without-contextual-analysis.
| +| `--iac` |[Default: false] Selective scanners mode: Execute IaC sub-scan. Can be combined with --sca, --secrets and --sast.
| +| `--secrets` |[Default: false] Selective scanners mode: Execute Secrets sub-scan. Can be combined with --sca, --sast and --iac.
| +| `--sast` |[Default: false] Selective scanners mode: Execute SAST sub-scan. Can be combined with --sca, --secrets and --iac.
| +| `--without-contextual-analysis` |[Default: false] Selective scanners mode: Disable Contextual Analysis scanner after SCA. Relevant only with --sca flag.
| +| `--vuln` |[Optional]
Set if you'd like to receive all vulnerabilities, regardless of the policy configured in Xray.
[Default: false] Triggers token validation on found secrets
| +| **Command arguments** | The command accepts no arguments | #### **Output Example** diff --git a/jfrog-applications/jfrog-cli/cli-plugins/developer-guide.md b/jfrog-applications/jfrog-cli/cli-plugins/developer-guide.md index cf0cb80..0d754c7 100644 --- a/jfrog-applications/jfrog-cli/cli-plugins/developer-guide.md +++ b/jfrog-applications/jfrog-cli/cli-plugins/developer-guide.md @@ -58,7 +58,7 @@ Well, plugins can do almost anything. The sky is the limit. 2. You can also add other Go packages to your *go.mod* and use them in your code. 3. You can package any external resources, such as executables or configuration files, and have them published alongside your plugin. Read more about - this [here](jfrog-cli-plugins-developer-guide.md#having-your-plugin-use-external-resources) + this [here](developer-guide.md#having-your-plugin-use-external-resources) ## Including plugins in the official registry