The frogbot-config.yml File Structure
If your Git repository uses
maininstead ofmasteras the default branch, be sure to update thebranchesfield in your YAML file accordingly.
Create The frogbot-config.yml File
frogbot-config.yml FileWhat is the frogbot-config.yml File?
frogbot-config.yml File?The frogbot-config.yml file encompasses project-related configurations used by Frogbot's scanning. This includes details about the repository's directory structure and may additionally encompass package manager commands necessary for Frogbot to list the project's dependencies.
Is the frogbot-config.yml File Mandatory?
frogbot-config.yml File Mandatory?No, the file isn't mandatory. In most cases, Frogbot can understand the structure of the projects in the repository and list the project's dependencies without the file.
If your project doesn't use a frogbot-config.yml file, all the configuration Frogbot requires
should be provided as variables as part of the Frogbot workflows.
How Does the frogbot-config.yml File Helps Frogbot Scan Repositories?
Frogbot relies on the project's descriptor files, such as package.json and pom.xml, to identify the project's dependencies. It scans the repository for these descriptor files and utilizes the appropriate package manager, such as npm or Maven, to compile a list of dependencies for the project. If you desire manual control over the project structure or the package manager commands, you can achieve this by creating a frogbot-config.yml file. In the provided example, we outline two subprojects located at path/to/project-1 and path/to/project-2 for Frogbot to include in its scanning process.
- params:
git:
repoName: my-git-repo-name
branches:
- master
scan:
projects:
- workingDirs:
- path/to/npm/project-1
- path/to/npm/project-2
Here's another example. Notice that we specify a custom install command here.
- params:
git:
repoName: my-git-repo-name
branches:
- master
scan:
projects:
- workingDirs:
- path/to/node/project
- installCommand: nuget restore
workingDirs:
- path/to/.net/project
Can One frogbot-config.yml File Be Used for Multiple Git Repositories?
frogbot-config.yml File Be Used for Multiple Git Repositories?You have the option of using a single frogbot-config.yml file for scanning multiple Git repositories in the same organization if one of the following platforms is used.
- GitHub with Jenkins
- Bitbucket Server
- Azure Repos
The file can be placed in any repository if it's in the same organization as all the repositories referenced in the file. Here's an example of a frogbot-config.yml referencing multiple repositories.
- params:
git:
repoName: repo-1
branches:
- master
- params:
git:
repoName: repo-2
branches:
- master
- dev
- params:
git:
repoName: repo-3
branches:
- master
scan:
projects:
- pipRequirementsFile: requirements.txt
If however you're using one of the following platforms, each repository that needs to be scanned by Frogbot should include its own frogbot-config.yml file.
- GitHub with GitHub actions
- GitLab
YAML File
If your Git repository uses
maininstead ofmasteras the default branch, be sure to update thebranchesfield in your YAML file accordingly.
# The "params" section includes the configuration of a single Git repository that needs to be scanned.
# For Azure Repos, Bitbucket Server and GitHub with JFrog Pipelines or Jenkins, you can define multiple "params" sections one after the other, for scanning multiple
# Git repositories in the same organization.
- params:
# Git parameters
git:
# [Mandatory]
# Name of the git repository to scan
repoName: repo-name
# [Mandatory]
# List of branches to scan
branches:
- master
# [Optional]
# Template for the branch name generated by Frogbot when creating pull requests with fixes.
# The template must include ${BRANCH_NAME_HASH}, to ensure that the generated branch name is unique.
# The template can optionally include the ${IMPACTED_PACKAGE} and ${FIX_VERSION} variables.
# branchNameTemplate: "frogbot-${IMPACTED_PACKAGE}-${BRANCH_NAME_HASH}"
# [Optional]
# Template for the commit message generated by Frogbot when creating pull requests with fixes
# The template can optionally include the ${IMPACTED_PACKAGE} and ${FIX_VERSION} variables.
# commitMessageTemplate: "Upgrade ${IMPACTED_PACKAGE} to ${FIX_VERSION}"
# [Optional]
# Template for the pull request title generated by Frogbot when creating pull requests with fixes.
# The template can optionally include the ${IMPACTED_PACKAGE} and ${FIX_VERSION} variables.
# pullRequestTitleTemplate: "[πΈ Frogbot] Upgrade ${IMPACTED_PACKAGE} to ${FIX_VERSION}"
# [Optional, Default: false]
# If true, Frogbot creates a single pull request with all the fixes.
# If false, Frogbot creates a separate pull request for each fix.
# aggregateFixes: false
# [Optional, Default: [email protected]]
# Set the email of the commit author
# emailAuthor: ""
# Frogbot scanning parameters
scan:
# [Default: false]
# Frogbot displays all existing vulnerabilities, including the ones that were not added by the pull request
# includeAllVulnerabilities: true
# [Default: false]
# When adding new comments on pull requests, keep old comments that were added by previous scans.
# avoidPreviousPrCommentsDeletion: true
# [Default: true]
# Frogbot does not fail the task if security issues are found and this parameter is set to false
# failOnSecurityIssues: false
# [Default: false]
# Handle vulnerabilities with fix versions only
# fixableOnly: true
# [Optional]
# Set the minimum severity for vulnerabilities that should be fixed and commented on in pull requests
# The following values are accepted: Low, Medium, High or Critical
# minSeverity: ""
# [Optional]
# List of email addresses to receive emails about secrets that has been detected in a pull request scan.
# Applies only to servers that are entitled to JFrog Advanced Security.
# emailReceivers:
# - [email protected]
# List of subprojects / project dirs inside the Git repository
projects:
# [Mandatory if the two conditions below are met]
# 1. The project uses yarn 2, NuGet or .NET Core to download its dependencies
# 2. The - `installCommand` variable isn't set in your frogbot-config.yml file.
#
# The command that installs the project dependencies (e.g "nuget restore")
# - installCommand: ""
# [Default: root directory]
# List of relative path's to the projects directories in the git repository. If left empty (without providing "." yourself as the root directory's path), a recursive scan is triggered from the root directory of the project.
# workingDirs:
# - "."
# [Default: ["*.git*", "*node_modules*", "*target*", "*venv*", "*test*"]]
# List of exclusion patterns (utilizing wildcards) for excluding paths in the source code of the Git repository during SCA scans.
# pathExclusions:
# - "*node_modules*"
# - "*target*"
# - "*venv*"
# - "*test*"
# [Mandatory for pip only if using requirements file, Default: pip install .]
# The requirements file name that is used to install dependencies in case of pip package manager
# pipRequirementsFile: ""
# [Default: true]
# Use Gradle Wrapper (gradlew/gradlew.bat) to run Gradle
# useWrapper: true
# [Optional]
# Name of a Virtual Repository in Artifactory to resolve (download) the project dependencies from
# repository: ""
# JFrog Platform parameters
jfrogPlatform:
# [Optional]
# JFrog project key. Learn more about it [here](https://www.jfrog.com/confluence/display/JFROG/Projects)
# jfrogProjectKey: ""
# [Optional]
# Xray Watches. Learn more about it [here](https://www.jfrog.com/confluence/display/JFROG/Configuring+Xray+Watches)
# watches:
# - ""Updated about 12 hours ago
