Analyzes Git repositories and commit history to detect secrets and security issues across the entire project history.
Enables analysis of GitHub repositories for secrets, vulnerabilities, misconfigurations, and security issues through Cycode's scanning capabilities.
Supports integration with GitHub Actions workflows for automated security scanning in CI/CD pipelines.
Provides AI-assisted security scanning tools that can be integrated with GitHub Copilot to analyze code for secrets, vulnerabilities, and security issues.
Supports scanning Gradle projects for software composition analysis vulnerabilities, including scanning sub-projects.
Enables integration with Jenkins CI/CD pipelines for automated security scanning of code during build processes.
Scans npm packages and dependencies for vulnerabilities and license compliance issues.
Analyzes Python projects for security vulnerabilities, hardcoded secrets, and code quality issues.
Generates Software Bill of Materials (SBOM) reports in SPDX format for documenting software components and dependencies.
Scans Terraform configurations and plan files for infrastructure as code misconfigurations and security vulnerabilities.
Analyzes YAML files for infrastructure as code misconfigurations and security vulnerabilities.
Cycode CLI User Guide
The Cycode Command Line Interface (CLI) is an application you can install locally to scan your repositories for secrets, infrastructure as code misconfigurations, software composition analysis vulnerabilities, and static application security testing issues.
This guide walks you through both installation and usage.
Table of Contents
Prerequisites
The Cycode CLI application requires Python version 3.9 or later.
Use the
cycode auth
to authenticate to Cycode with the CLIAlternatively, you can get a Cycode Client ID and Client Secret Key by following the steps detailed in the Service Account Token and Personal Access Token pages, which contain details on getting these values.
Installation
The following installation steps are applicable to both Windows and UNIX / Linux operating systems.
[!NOTE] The following steps assume the use of
python3
andpip3
for Python-related commands; however, some systems may instead use thepython
andpip
commands, depending on your Python environment’s configuration.
Install Cycode CLI
To install the Cycode CLI application on your local machine, perform the following steps:
Open your command line or terminal application.
Execute one of the following commands:
To install from PyPI:
To install from Homebrew:
To install from GitHub Releases navigate and download executable for your operating system and architecture, then run the following command:
Finally authenticate the CLI. There are three methods to set the Cycode client ID and client secret:
cycode auth (Recommended)
Add them to your environment variables
Using the Auth Command
[!NOTE] This is the recommended method for setting up your local machine to authenticate with Cycode CLI.
Type the following command into your terminal/command line window:
cycode auth
A browser window will appear, asking you to log into Cycode (as seen below):
Enter your login credentials on this page and log in.
You will eventually be taken to the page below, where you'll be asked to choose the business group you want to authorize Cycode with (if applicable):
[!NOTE] This will be the default method for authenticating with the Cycode CLI.
Click the Allow button to authorize the Cycode CLI on the selected business group.
Once completed, you'll see the following screen if it was selected successfully:
In the terminal/command line screen, you will see the following when exiting the browser window:
Successfully logged into cycode
Using the Configure Command
[!NOTE] If you already set up your Cycode Client ID and Client Secret through the Linux or Windows environment variables, those credentials will take precedent over this method.
Type the following command into your terminal/command line window:
Enter your Cycode API URL value (you can leave blank to use default value).
Cycode API URL [https://api.cycode.com]: https://api.onpremise.com
Enter your Cycode APP URL value (you can leave blank to use default value).
Cycode APP URL [https://app.cycode.com]: https://app.onpremise.com
Enter your Cycode Client ID value.
Cycode Client ID []: 7fe5346b-xxxx-xxxx-xxxx-55157625c72d
Enter your Cycode Client Secret value.
Cycode Client Secret []: c1e24929-xxxx-xxxx-xxxx-8b08c1839a2e
If the values were entered successfully, you'll see the following message:
Successfully configured CLI credentials!
or/and
Successfully configured Cycode URLs!
If you go into the .cycode
folder under your user folder, you'll find these credentials were created and placed in the credentials.yaml
file in that folder.
The URLs were placed in the config.yaml
file in that folder.
Add to Environment Variables
On Unix/Linux:
and
On Windows
From the Control Panel, navigate to the System menu:
Next, click Advanced system settings:
In the System Properties window that opens, click the Environment Variables button:
Create
CYCODE_CLIENT_ID
andCYCODE_CLIENT_SECRET
variables with values matching your ID and Secret Key, respectively:Insert the
cycode.exe
into the path to complete the installation.
Install Pre-Commit Hook
Cycode's pre-commit and pre-push hooks can be set up within your local repository so that the Cycode CLI application will identify any issues with your code automatically before you commit or push it to your codebase.
[!NOTE] pre-commit and pre-push hooks are not available for IaC scans.
Perform the following steps to install the pre-commit hook:
Installing Pre-Commit Hook
Install the pre-commit framework (Python 3.9 or higher must be installed):
Navigate to the top directory of the local Git repository you wish to configure.
Create a new YAML file named
.pre-commit-config.yaml
(include the beginning.
) in the repository’s top directory that contains the following:Modify the created file for your specific needs. Use hook ID
cycode
to enable scan for Secrets. Use hook IDcycode-sca
to enable SCA scan. Use hook IDcycode-sast
to enable SAST scan. If you want to enable all scanning types, use this configuration:Install Cycode’s hook:
A successful hook installation will result in the message:
Pre-commit installed at .git/hooks/pre-commit
.Keep the pre-commit hook up to date:
It will automatically bump
rev
in.pre-commit-config.yaml
to the latest available version of Cycode CLI.
[!NOTE] Trigger happens on
git commit
command. Hook triggers only on the files that are staged for commit.
Installing Pre-Push Hook
To install the pre-push hook in addition to or instead of the pre-commit hook:
Add the pre-push hooks to your
.pre-commit-config.yaml
file:Install the pre-push hook:
For both pre-commit and pre-push hooks, use:
[!NOTE] Pre-push hooks trigger on
git push
command and scan only the commits about to be pushed.
Cycode CLI Commands
The following are the options and commands available with the Cycode CLI application:
Option | Description |
,
| Show detailed logs. |
| Do not show the progress meter. |
| Do not check CLI for updates. |
,
| Specify the output type. The default is
. |
| Specify a Cycode client ID for this specific scan execution. |
| Specify a Cycode client secret for this specific scan execution. |
| Install completion for the current shell.. |
| Show completion for the specified shell, to copy it or customize the installation. |
,
| Show options for given command. |
Command | Description |
Authenticate your machine to associate the CLI with your Cycode account. | |
Initial command to configure your CLI client authentication. | |
Ignore a specific value, path or rule ID. | |
Start the Model Context Protocol (MCP) server to enable AI integration with Cycode scanning capabilities. | |
Scan the content for Secrets/IaC/SCA/SAST violations. You`ll need to specify which scan type to perform: commit-history/path/repository/etc. | |
Generate report. You will need to specify which report type to perform as SBOM. | |
status | Show the CLI status and exit. |
MCP Command [EXPERIMENT]
[!WARNING] The MCP command is available only for Python 3.10 and above. If you're using an earlier Python version, this command will not be available.
The Model Context Protocol (MCP) command allows you to start an MCP server that exposes Cycode's scanning capabilities to AI systems and applications. This enables AI models to interact with Cycode CLI tools via a standardized protocol.
[!TIP] For the best experience, install Cycode CLI globally on your system using
pip install cycode
orbrew install cycode
, then authenticate once withcycode auth
. After global installation and authentication, you won't need to configureCYCODE_CLIENT_ID
andCYCODE_CLIENT_SECRET
environment variables in your MCP configuration files.
Starting the MCP Server
To start the MCP server, use the following command:
By default, this starts the server using the stdio
transport, which is suitable for local integrations and AI applications that can spawn subprocesses.
Available Options
Option | Description |
| Transport type for the MCP server:
,
, or
(default:
) |
| Host address to bind the server (used only for non stdio transport) (default:
) |
| Port number to bind the server (used only for non stdio transport) (default:
) |
| Show help message and available options |
MCP Tools
The MCP server provides the following tools that AI systems can use:
Tool Name | Description |
| Scan files for hardcoded secrets |
| Scan files for Software Composition Analysis (SCA) - vulnerabilities and license issues |
| Scan files for Infrastructure as Code (IaC) misconfigurations |
| Scan files for Static Application Security Testing (SAST) - code quality and security flaws |
| Get Cycode CLI version, authentication status, and configuration information |
Usage Examples
Basic Command Examples
Start the MCP server with default settings (stdio transport):
Start the MCP server with explicit stdio transport:
Start the MCP server with Server-Sent Events (SSE) transport:
Start the MCP server with streamable HTTP transport on custom host and port:
Learn more about MCP Transport types in the MCP Protocol Specification – Transports.
Configuration Examples
Using MCP with Cursor/VS Code/Claude Desktop/etc (mcp.json)
[!NOTE] For EU Cycode environments, make sure to set the appropriate
CYCODE_API_URL
andCYCODE_APP_URL
values in the environment variables (e.g.,https://api.eu.cycode.com
andhttps://app.eu.cycode.com
).
Follow this guide to configure the MCP server in your VS Code/GitHub Copilot. Keep in mind that in settings.json
, there is an mcp
object containing a nested servers
sub-object, rather than a standalone mcpServers
object.
For stdio transport (direct execution):
For stdio transport with pipx
installation:
For stdio transport with uvx
installation:
For SSE transport (Server-Sent Events):
For SSE transport on custom port:
For streamable HTTP transport:
Running MCP Server in Background
For SSE transport (start server first, then configure client):
For streamable HTTP transport:
[!NOTE] The MCP server requires proper Cycode CLI authentication to function. Make sure you have authenticated using
cycode auth
or configured your credentials before starting the MCP server.
Troubleshooting MCP
If you encounter issues with the MCP server, you can enable debug logging to get more detailed information about what's happening. There are two ways to enable debug logging:
Using the
-v
or--verbose
flag:
Using the
CYCODE_CLI_VERBOSE
environment variable:
The debug logs will show detailed information about:
Server startup and configuration
Connection attempts and status
Tool execution and results
Any errors or warnings that occur
This information can be helpful when:
Diagnosing connection issues
Understanding why certain tools aren't working
Identifying authentication problems
Debugging transport-specific issues
Scan Command
Running a Scan
The Cycode CLI application offers several types of scans so that you can choose the option that best fits your case. The following are the current options and commands available:
Option | Description |
| Specify the scan you wish to execute (
/
/
/
), the default is
. |
| Show secrets in plain text. See section for more details. |
| Run scan without failing, always return a non-error status code. See section for more details. |
| Show only violations at the specified level or higher. |
| Specify the SCA scan you wish to execute (
/
). The default is both. |
| When specified, the scan results will be recorded in Cycode. |
| Display a link to the scan report in the Cycode platform in the console output. |
| When specified, Cycode will not run the restore command. This will scan direct dependencies ONLY! |
| Run gradle restore command for all sub projects. This should be run from |
| For Maven only, allows using a custom file when scanning for dependencies |
| Show options for given command. |
Command | Description |
Scan commit history or perform diff scanning between specific commits | |
Scan the files in the path supplied in the command | |
Use this command to scan the content that was not committed yet | |
Scan git repository including its history |
Options
Severity Option
To limit the results of the scan to a specific severity threshold, the argument --severity-threshold
can be added to the scan command.
For example, the following command will scan the repository for policy violations that have severity of Medium or higher:
cycode scan --severity-threshold MEDIUM repository ~/home/git/codebase
Monitor Option
[!NOTE] This option is only available to SCA scans.
To push scan results tied to the SCA policies found in an SCA type scan to Cycode, add the argument --monitor
to the scan command.
For example, the following command will scan the repository for SCA policy violations and push them to Cycode platform:
cycode scan -t sca --monitor repository ~/home/git/codebase
Cycode Report Option
For every scan performed using the Cycode CLI, a report is automatically generated and its results are sent to Cycode. These results are tied to the relevant policies (e.g., SCA policies for Repository scans) within the Cycode platform.
To have the direct URL to this Cycode report printed in your CLI output after the scan completes, add the argument --cycode-report
to your scan command.
cycode scan --cycode-report repository ~/home/git/codebase
All scan results from the CLI will appear in the CLI Logs section of Cycode. If you included the --cycode-report
flag in your command, a direct link to the specific report will be displayed in your terminal following the scan results.
[!WARNING] You must have the
owner
oradmin
role in Cycode to view this page.
The report page will look something like below:
Package Vulnerabilities Option
[!NOTE] This option is only available to SCA scans.
To scan a specific package vulnerability of your local repository, add the argument --sca-scan package-vulnerabilities
following the -t sca
or --scan-type sca
option.
In the previous example, if you wanted to only run an SCA scan on package vulnerabilities, you could execute the following:
cycode scan -t sca --sca-scan package-vulnerabilities repository ~/home/git/codebase
License Compliance Option
[!NOTE] This option is only available to SCA scans.
To scan a specific branch of your local repository, add the argument --sca-scan license-compliance
followed by the name of the branch you wish to scan.
In the previous example, if you wanted to only scan a branch named dev
, you could execute the following:
cycode scan -t sca --sca-scan license-compliance repository ~/home/git/codebase -b dev
Lock Restore Option
[!NOTE] This option is only available to SCA scans.
We use the sbt-dependency-lock plugin to restore the lock file for SBT projects.
To disable lock restore in use --no-restore
option.
Prerequisites:
sbt-dependency-lock
plugin: Install the plugin by adding the following line toproject/plugins.sbt
:
Repository Scan
A repository scan examines an entire local repository for any exposed secrets or insecure misconfigurations. This more holistic scan type looks at everything: the current state of your repository and its commit history. It will look not only for secrets that are currently exposed within the repository but previously deleted secrets as well.
To execute a full repository scan, execute the following:
cycode scan repository {{path}}
For example, if you wanted to scan a repository stored in ~/home/git/codebase
, you could execute the following:
cycode scan repository ~/home/git/codebase
The following option is available for use with this command:
Option | Description |
| Branch to scan, if not set scanning the default branch |
Branch Option
To scan a specific branch of your local repository, add the argument -b
(alternatively, --branch
) followed by the name of the branch you wish to scan.
Given the previous example, if you wanted to only scan a branch named dev
, you could execute the following:
cycode scan repository ~/home/git/codebase -b dev
Path Scan
A path scan examines a specific local directory and all the contents within it, instead of focusing solely on a GIT repository.
To execute a directory scan, execute the following:
cycode scan path {{path}}
For example, consider a scenario in which you want to scan the directory located at ~/home/git/codebase
. You could then execute the following:
cycode scan path ~/home/git/codebase
Terraform Plan Scan
Cycode CLI supports Terraform plan scanning (supporting Terraform 0.12 and later)
Terraform plan file must be in JSON format (having .json
extension)
If you just have a configuration file, you can generate a plan by doing the following:
Initialize a working directory that contains Terraform configuration file:
terraform init
Create Terraform execution plan and save the binary output:
terraform plan -out={tfplan_output}
Convert the binary output file into readable JSON:
terraform show -json {tfplan_output} > {tfplan}.json
Scan your
{tfplan}.json
with Cycode CLI:cycode scan -t iac path ~/PATH/TO/YOUR/{tfplan}.json
Commit History Scan
[!NOTE] Commit History Scan is not available for IaC scans.
The commit history scan command provides two main capabilities:
Full History Scanning: Analyze all commits in the repository history
Diff Scanning: Scan only the changes between specific commits
Secrets scanning can analyze all commits in the repository history because secrets introduced and later removed can still be leaked or exposed. For SCA and SAST scans, the commit history command focuses on scanning the differences/changes between commits, making it perfect for pull request reviews and incremental scanning.
A commit history scan examines your Git repository's commit history and can be used both for comprehensive historical analysis and targeted diff scanning of specific changes.
To execute a commit history scan, execute the following:
cycode scan commit-history {{path}}
For example, consider a scenario in which you want to scan the commit history for a repository stored in ~/home/git/codebase
. You could then execute the following:
cycode scan commit-history ~/home/git/codebase
The following options are available for use with this command:
Option | Description |
| Scan a commit range in this git repository, by default cycode scans all commit history (example: HEAD~1) |
Commit Range Option (Diff Scanning)
The commit range option enables diff scanning – scanning only the changes between specific commits instead of the entire repository history. This is particularly useful for:
Pull request validation: Scan only the changes introduced in a PR
Incremental CI/CD scanning: Focus on recent changes rather than the entire codebase
Feature branch review: Compare changes against main/master branch
Performance optimization: Faster scans by limiting scope to relevant changes
Commit Range Syntax
The --commit-range
(-r
) option supports standard Git revision syntax:
Syntax | Description | Example |
| Changes from commit1 to commit2 |
|
| Changes in commit2 not in commit1 |
|
| Changes from commit to HEAD |
|
| Changes from branch1 to branch2 |
|
Diff Scanning Examples
Scan changes in the last commit:
Scan changes between two specific commits:
Scan changes in your feature branch compared to main:
Scan changes between main and a feature branch:
Scan all changes in the last 3 commits:
[!TIP] For CI/CD pipelines, you can use environment variables like
${{ github.event.pull_request.base.sha }}..${{ github.sha }}
(GitHub Actions) or$CI_MERGE_REQUEST_TARGET_BRANCH_SHA..$CI_COMMIT_SHA
(GitLab CI) to scan only PR/MR changes.
Pre-Commit Scan
A pre-commit scan automatically identifies any issues before you commit changes to your repository. There is no need to manually execute this scan; configure the pre-commit hook as detailed under the Installation section of this guide.
After installing the pre-commit hook, you may occasionally wish to skip scanning during a specific commit. To do this, add the following to your git
command to skip scanning for a single commit:
Pre-Push Scan
A pre-push scan automatically identifies any issues before you push changes to the remote repository. This hook runs on the client side and scans only the commits that are about to be pushed, making it efficient for catching issues before they reach the remote repository.
[!NOTE] Pre-push hook is not available for IaC scans.
The pre-push hook integrates with the pre-commit framework and can be configured to run before any git push
operation.
Installing Pre-Push Hook
To set up the pre-push hook using the pre-commit framework:
Install the pre-commit framework (if not already installed):
Create or update your
.pre-commit-config.yaml
file to include the pre-push hooks:For multiple scan types, use this configuration:
Install the pre-push hook:
A successful installation will result in the message:
Pre-push installed at .git/hooks/pre-push
.Keep the pre-push hook up to date:
How Pre-Push Scanning Works
The pre-push hook:
Receives information about what commits are being pushed
Calculates the appropriate commit range to scan
For new branches: scans all commits from the merge base with the default branch
For existing branches: scans only the new commits since the last push
Runs the same comprehensive scanning as other Cycode scan modes
Smart Default Branch Detection
The pre-push hook intelligently detects the default branch for merge base calculation using this priority order:
Environment Variable:
CYCODE_DEFAULT_BRANCH
- allows manual overrideGit Remote HEAD: Uses
git symbolic-ref refs/remotes/origin/HEAD
to detect the actual remote default branchGit Remote Info: Falls back to
git remote show origin
if symbolic-ref failsHardcoded Fallbacks: Uses common default branch names (origin/main, origin/master, main, master)
Setting a Custom Default Branch:
This smart detection ensures the pre-push hook works correctly regardless of whether your repository uses main
, master
, develop
, or any other default branch name.
Skipping Pre-Push Scans
To skip the pre-push scan for a specific push operation, use:
Or to skip all pre-push hooks:
[!TIP] The pre-push hook is triggered on
git push
command and scans only the commits that are about to be pushed, making it more efficient than scanning the entire repository.
Scan Results
Each scan will complete with a message stating if any issues were found or not.
If no issues are found, the scan ends with the following success message:
Good job! No issues were found!!! 👏👏👏
If an issue is found, a violation card appears upon completion instead. In this case you should review the file in question for the specific line highlighted by the result message. Implement any changes required to resolve the issue, then execute the scan again.
Show/Hide Secrets
In the examples below, a secret was found in the file secret_test
, located in the subfolder cli
. The second part of the message shows the specific line the secret appears in, which in this case is a value assigned to googleApiKey
.
Note how the example obscures the actual secret value, replacing most of the secret with asterisks. Scans obscure secrets by default, but you may optionally disable this feature to view the full secret (assuming the machine you are viewing the scan result on is sufficiently secure from prying eyes).
To disable secret obfuscation, add the --show-secret
argument to any type of scan.
In the following example, a Path Scan is executed against the cli
subdirectory with the option enabled to display any secrets found in full:
cycode scan --show-secret path ./cli
The result would then not be obfuscated.
Soft Fail
In normal operation the CLI will return an exit code of 1
when issues are found in the scan results. Depending on your CI/CD setup this will usually result in an overall failure. If you don't want this to happen, you can use the soft fail feature.
By adding the --soft-fail
option to any type of scan, the exit code will be forced to 0
regardless of whether any results are found.
Example Scan Results
Secrets Result Example
IaC Result Example
SCA Result Example
SAST Result Example
Company Custom Remediation Guidelines
If your company has set custom remediation guidelines in the relevant policy via the Cycode portal, you'll see a field for “Company Guidelines” that contains the remediation guidelines you added. Note that if you haven't added any company guidelines, this field will not appear in the CLI tool.
Ignoring Scan Results
Ignore rules can be added to ignore specific secret values, specific SHA512 values, specific paths, and specific Cycode secret and IaC rule IDs. This will cause the scan to not alert these values. The ignoring rules are written and saved locally in the ./.cycode/config.yaml
file.
[!WARNING] Adding values to be ignored should be done with careful consideration of the values, paths, and policies to ensure that the scans will pick up true positives.
The following are the options available for the cycode ignore
command:
Option | Description |
| Ignore a specific value while scanning for secrets. See for more details. |
| Ignore a specific SHA512 representation of a string while scanning for secrets. See for more details. |
| Avoid scanning a specific path. Need to specify scan type. See for more details. |
| Ignore scanning a specific secret rule ID/IaC rule ID/SCA rule ID. See for more details. |
| Ignore scanning a specific package version while running an SCA scan. Expected pattern -
. See for more details. |
| Ignore scanning a specific CVE while running an SCA scan. Expected pattern: CVE-YYYY-NNN. |
| Specify the scan you wish to execute (
/
/
/
). The default value is
. |
| Add an ignore rule and update it in the global
config file. |
Ignoring a Secret Value
To ignore a specific secret value, you will need to use the --by-value
flag. This will ignore the given secret value from all future scans. Use the following command to add a secret value to be ignored:
cycode ignore --by-value {{secret-value}}
In the example at the top of this section, the command to ignore a specific secret value is as follows:
cycode ignore --by-value h3110w0r1d!@#$350
In the example above, replace the h3110w0r1d!@#$350
value with your non-masked secret value. See the Cycode scan options for details on how to see secret values in the scan results.
Ignoring a Secret SHA Value
To ignore a specific secret SHA value, you will need to use the --by-sha
flag. This will ignore the given secret SHA value from all future scans. Use the following command to add a secret SHA value to be ignored:
cycode ignore --by-sha {{secret-sha-value}}
In the example at the top of this section, the command to ignore a specific secret SHA value is as follows:
cycode ignore --by-sha a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0
In the example above, replace the a44081db3296c84b82d12a35c446a3cba19411dddfa0380134c75f7b3973bff0
value with your secret SHA value.
Ignoring a Path
To ignore a specific path for either secret, IaC, or SCA scans, you will need to use the --by-path
flag in conjunction with the -t, --scan-type
flag (you must specify the scan type). This will ignore the given path from all future scans for the given scan type. Use the following command to add a path to be ignored:
cycode ignore -t {{scan-type}} --by-path {{path}}
In the example at the top of this section, the command to ignore a specific path for a secret is as follows:
cycode ignore -t secret --by-path ~/home/my-repo/config
In the example above, replace the ~/home/my-repo/config
value with your path value.
In the example at the top of this section, the command to ignore a specific path from IaC scans is as follows:
cycode ignore -t iac --by-path ~/home/my-repo/config
In the example above, replace the ~/home/my-repo/config
value with your path value.
In the example at the top of this section, the command to ignore a specific path from SCA scans is as follows:
cycode ignore -t sca --by-path ~/home/my-repo/config
In the example above, replace the ~/home/my-repo/config
value with your path value.
Ignoring a Secret, IaC, SCA, or SAST Rule
To ignore a specific secret, IaC, SCA, or SAST rule, you will need to use the --by-rule
flag in conjunction with the -t, --scan-type
flag (you must specify the scan type). This will ignore the given rule ID value from all future scans. Use the following command to add a rule ID value to be ignored:
cycode ignore -t {{scan-type}} --by-rule {{rule-ID}}
In the example at the top of this section, the command to ignore the specific secret rule ID is as follows:
cycode ignore -t secret --by-rule ce3a4de0-9dfc-448b-a004-c538cf8b4710
In the example above, replace the ce3a4de0-9dfc-448b-a004-c538cf8b4710
value with the rule ID you want to ignore.
In the example at the top of this section, the command to ignore the specific IaC rule ID is as follows:
cycode ignore -t iac --by-rule bdaa88e2-5e7c-46ff-ac2a-29721418c59c
In the example above, replace the bdaa88e2-5e7c-46ff-ac2a-29721418c59c
value with the rule ID you want to ignore.
In the example at the top of this section, the command to ignore the specific SCA rule ID is as follows:
cycode ignore -t sca --by-rule dc21bc6b-9f4f-46fb-9f92-e4327ea03f6b
In the example above, replace the dc21bc6b-9f4f-46fb-9f92-e4327ea03f6b
value with the rule ID you want to ignore.
Ignoring a Package
[!NOTE] This option is only available to the SCA scans.
To ignore a specific package in the SCA scans, you will need to use the --by-package
flag in conjunction with the -t, --scan-type
flag (you must specify the sca
scan type). This will ignore the given package, using the {{package_name}}@{{package_version}}
formatting, from all future scans. Use the following command to add a package and version to be ignored:
cycode ignore --scan-type sca --by-package {{package_name}}@{{package_version}}
OR
cycode ignore -t sca --by-package {{package_name}}@{{package_version}}
In the example below, the command to ignore a specific SCA package is as follows:
cycode ignore --scan-type sca --by-package pyyaml@5.3.1
In the example above, replace pyyaml
with package name and 5.3.1
with the package version you want to ignore.
Ignoring via a config file
The applied ignoring rules are stored in the configuration file called config.yaml
.
This file could be easily shared between developers or even committed to remote Git.
These files are always located in the .cycode
folder.
The folder starts with a dot (.), and you should enable the displaying of hidden files to see it.
Path of the config files
By default, all cycode ignore
commands save the ignoring rule to the current directory from which CLI has been run.
Example: running ignoring CLI command from /Users/name/projects/backend
will create config.yaml
in /Users/name/projects/backend/.cycode
The second option is to save ignoring rules to the global configuration files.
The path of the global config is ~/.cycode/config.yaml
,
where ~
means user`s home directory, for example, /Users/name
on macOS.
Saving to the global space could be performed with the -g
flag of the cycode ignore
command.
For example: cycode ignore -g --by-value test-value
.
Proper working directory
It is incredibly important to place the .cycode
folder and run CLI from the same place.
You should double-check it when working with different environments like CI/CD (GitHub Actions, Jenkins, etc.).
You can commit the .cycode
folder to the root of your repository. In this scenario, you must run CLI scans from the repository root. If that doesn't fit your requirements, you could temporarily copy the .cycode
folder to wherever you want and perform a CLI scan from this folder.
Structure ignoring rules in the config
It's important to understand how CLI stores ignored rules to be able to read these configuration files or even modify them without CLI.
The abstract YAML structure:
Possible values of scanTypeName
: iac
, sca
, sast
, secret
.
Possible values of ignoringType
: paths
, values
, rules
, packages
, shas
, cves
.
[!WARNING] Values for "ignore by value" are not stored as plain text! CLI stores sha256 hashes of the values instead. You should put hashes of the string when modifying the configuration file by hand.
Example of real config.yaml
:
Report Command
Generating SBOM Report
A software bill of materials (SBOM) is an inventory of all constituent components and software dependencies involved in the development and delivery of an application. Using this command, you can create an SBOM report for your local project or for your repository URI.
The following options are available for use with this command:
Option | Description | Required | Default |
| SBOM format | Yes | |
| Specify the output file format | No | json |
| Output file | No | autogenerated filename saved to the current directory |
| Include vulnerabilities | No | False |
| Include dev dependencies | No | False |
The following commands are available for use with this command:
Command | Description |
| Generate SBOM report for provided path in the command |
| Generate SBOM report for provided repository URI in the command |
Repository
To create an SBOM report for a repository URI:cycode report sbom --format <sbom format> --include-vulnerabilities --include-dev-dependencies --output-file </path/to/file> repository_url <repository url>
For example:cycode report sbom --format spdx-2.3 --include-vulnerabilities --include-dev-dependencies repository_url https://github.com/cycodehq/cycode-cli.git
Local Project
To create an SBOM report for a path:cycode report sbom --format <sbom format> --include-vulnerabilities --include-dev-dependencies --output-file </path/to/file> path </path/to/project>
For example:cycode report sbom --format spdx-2.3 --include-vulnerabilities --include-dev-dependencies path /path/to/local/project
Scan Logs
All CLI scans are logged in Cycode. The logs can be found under Settings > CLI Logs.
Syntax Help
You may add the --help
argument to any command at any time to see a help message that will display available options and their syntax.
To see general help, simply enter the command:
cycode --help
To see scan options, enter:
cycode scan --help
To see the options available for a specific type of scan, enter:
cycode scan {{option}} --help
For example, to see options available for a Path Scan, you would enter:
cycode scan path --help
To see the options available for the ignore scan function, use this command:
cycode ignore --help
To see the options available for a report, use this command:
cycode report --help
To see the options available for a specific type of report, enter:
cycode scan {{option}} --help
This server cannot be installed
remote-capable server
The server can be hosted and run remotely because it primarily relies on remote services or has no dependency on the local environment.
Boost security in your dev lifecycle via SAST, SCA, Secrets & IaC scanning
Related MCP Servers
- -securityAlicense-qualityProvides Trivy security scanning capabilities through a standardized interface, allowing users to scan projects for vulnerabilities and automatically fix them by updating dependencies.Last updated -10MIT License
ZeroPath MCP Serverofficial
-securityFlicense-qualityAllows developers to query security findings (SAST issues, secrets, patches) using natural language within AI-assisted tools like Claude Desktop, Cursor, and other MCP-compatible environments.Last updated -3- AsecurityAlicenseAqualityProvides structured spec-driven development workflow tools for AI-assisted software development with sequential spec creation (Requirements → Design → Tasks). Features a real-time web dashboard for monitoring project progress and managing development workflows.Last updated -145,2001,941GPL 3.0
- -securityAlicense-qualityEnables comprehensive security scanning of code repositories to detect secrets, vulnerabilities, dependency issues, and configuration problems. Provides real-time security checks and best practice recommendations to help developers identify and prevent security issues.Last updated -42MIT License