.cybeignore Exclusion File

Overview

The .cybeignore file lets you exclude specific files or directories from SAST vulnerability reports. It uses the same syntax as .gitignore, so it is familiar and easy to use.

To suppress a single finding on one precise line instead of a whole file, use an inline cybedefend-ignore comment.

How It Works

Create a .cybeignore file in your project’s root directory to define exclusion patterns. Vulnerabilities found in matching files are automatically filtered from scan results.

Where CybeDefend Looks

The scanner reads the first file it finds, in this order:

Order	Path	Status
1	`.cybeignore`	Recommended
2	`.cybedefend`	Deprecated — still read
3	`.cybedefend/ignore`	Use when `.cybedefend` is a directory

.cybedefend is deprecated. It still works and nothing breaks today, but it collides with the .cybedefend/ directory that VibeDefend creates for config.json — a single path cannot be both a file and a directory. Rename your file to .cybeignore; the contents do not change.

If your repository is linked with VibeDefend, you already have a .cybedefend/ directory. You have two options, and they behave identically:

Put your patterns in .cybeignore at the project root (recommended), or
Put them in .cybedefend/ignore, alongside config.json.

Usage

Creating a .cybeignore File

Create a file named .cybeignore in your project root:

# Ignore test files
**/test/**
**/tests/**
**/*_test.py
**/*_test.go

# Ignore dependencies
node_modules/
vendor/
.venv/

# Ignore specific directories
**/examples/**
**/demo/**

# Ignore by extension
*.min.js
*.log

Migrating from .cybedefend

Renaming the file is the whole migration — the syntax is unchanged:

git mv .cybedefend .cybeignore

If you use VibeDefend and the root path is taken by the .cybedefend/ directory, move your patterns inside it instead:

mv my-patterns.txt .cybedefend/ignore

Supported Patterns

The syntax is identical to .gitignore:

Pattern	Description	Example
`file.txt`	Ignore specific file	`secrets.txt`
`*.ext`	Ignore by extension	`*.log`
`dir/`	Ignore directory	`node_modules/`
`**/pattern`	Recursive matching	`/bad/`
`!file.txt`	Negation (don’t ignore)	`!important.log`
`#comment`	Comment line	`# This is a comment`

Negation is the tool for excluding a whole class while keeping one member of it under review:

# Exclude every spec file…
**/*.spec.ts

# …except this one, which carries a credential whose origin is still unconfirmed
!services/export/redact-secrets.spec.ts

Scope

.cybeignore filters every finding produced by the SAST/IaC scanner binary:

Scan type	Filtered by `.cybeignore`?
SAST	Yes
IaC	Yes
Secret	Yes
CI/CD	Yes
SCA	No — separate scanner
Container	No — separate scanner

Excluding a file also hides its secret findings. Gitleaks runs as a second pass inside the same scanner and shares the same exclusion list, so a path you exclude here stops being reported for hardcoded credentials too — including credentials a later commit adds to that file.This matters most for the patterns people reach for first. **/*.spec.ts or tests/ will silence Gitleaks across your whole test suite, which is exactly where fixture credentials — and the occasional real one pasted in by mistake — tend to live.

When only a few findings in a file are false positives, prefer inline cybedefend-ignore comments over listing the whole file here: the exclusion stays scoped to the lines you reviewed, and the rest of the file keeps being scanned.

Common Use Cases

Ignore Test Code

# .cybeignore
**/test/**
**/tests/**
**/__tests__/**
*.spec.js
*.test.js
**/*_test.py

Ignore Third-Party Code

# .cybeignore
node_modules/
vendor/
third_party/
.venv/

Ignore Demo/Example Code

# .cybeignore
**/examples/**
**/demo/**
**/samples/**
docs/code-examples/**

Ignore Configuration Templates

# .cybeignore
*.example.yml
*.template.json
config/sample_*.py

Best Practices

Use .cybeignore responsibly. Don’t ignore real vulnerabilities in production code.

Exclude Files, Not Findings You Dislike

A file-level exclusion is right when the whole file is out of scope for SAST — a test fixture, a vendored dependency, a demo. When a finding is a false positive but the file also holds production code, use an inline cybedefend-ignore comment instead, so the rest of the file stays under review.

Document Your Exclusions

Always add comments explaining why files are excluded:

# .cybeignore

# DEPENDENCIES
# Third-party code managed by maintainers
node_modules/
vendor/

# TEST CODE
# Tests intentionally contain unsafe code for testing
**/test/**

# KNOWN FALSE POSITIVES
# Ticket #123: Custom validation used
src/legacy/auth_handler.py

Include in Code Reviews

Add .cybeignore to your repository
Review changes in pull requests
Regularly audit exclusion patterns

Verify What You Wrote

.cybeignore uses the gitignore engine, so git itself can check your patterns before you commit them:

git ls-files | git -c core.excludesFile=.cybeignore check-ignore --no-index --stdin

Every path it prints is a file that will drop out of your SAST results. If a production file appears in that list, your pattern is too broad.

Monitor Impact

Check scan logs to see which file was loaded and how many vulnerabilities were filtered:

[IgnoreFilter] loaded exclusion patterns from .cybeignore
Filtered out 12 vulnerabilities based on .cybeignore patterns
After filtering: 45 vulnerabilities to report

Troubleshooting

Patterns Not Matching

Use **/ for recursive matching: **/bad/**
Ensure correct path separators (always /)
Check that .cybeignore is in the project root
Review scan logs for path details

File Not Found

Verify .cybeignore is included in your repository — it must be committed, not gitignored
Check file permissions
Ensure the file is at the project root level
If you have a .cybedefend/ directory, the legacy root file cannot exist; use .cybeignore or .cybedefend/ignore

Nothing Is Being Filtered

Look for the loader line in your scan logs. [IgnoreFilter] no .cybeignore file found means no candidate was readable at all — most often the file was never committed, or it sits in a subdirectory rather than the project root.

Example Configuration

Here’s a comprehensive example:

# .cybeignore

# ============================================
# THIRD-PARTY DEPENDENCIES
# ============================================
node_modules/
vendor/
.venv/
third_party/

# ============================================
# TEST CODE
# ============================================
**/test/**
**/tests/**
**/__tests__/**
**/*_test.py
**/*_test.go
*.spec.js
*.test.js

# ============================================
# EXAMPLES & DOCUMENTATION
# ============================================
**/examples/**
**/demo/**
docs/vulnerable_examples/**

# ============================================
# BUILD ARTIFACTS
# ============================================
dist/
build/
*.min.js
*.bundle.js

# ============================================
# CONFIGURATION TEMPLATES
# ============================================
*.example.yml
*.template.json
config/sample_*.py

The .cybeignore file is processed during scanning. Excluded vulnerabilities won’t appear in your reports or affect your project metrics.

CybeDefend

Platform Overview

Getting Started

Agent & AI Integration

IDE Integrations

Code Scanning

Container Scanning

Managing Vulnerabilities

Issue Tracker Integrations

Notifications

Overview

How It Works

Where CybeDefend Looks

Usage

Creating a .cybeignore File

Migrating from .cybedefend

Supported Patterns

Scope

Common Use Cases

Ignore Test Code

Ignore Third-Party Code

Ignore Demo/Example Code

Ignore Configuration Templates

Best Practices

Exclude Files, Not Findings You Dislike

Document Your Exclusions

Include in Code Reviews

Verify What You Wrote

Monitor Impact

Troubleshooting

Patterns Not Matching

File Not Found

Nothing Is Being Filtered

Example Configuration

​Overview

​How It Works

​Where CybeDefend Looks

​Usage

​Creating a .cybeignore File

​Migrating from .cybedefend

​Supported Patterns

​Scope

​Common Use Cases

​Ignore Test Code

​Ignore Third-Party Code

​Ignore Demo/Example Code

​Ignore Configuration Templates

​Best Practices

​Exclude Files, Not Findings You Dislike

​Document Your Exclusions

​Include in Code Reviews

​Verify What You Wrote

​Monitor Impact

​Troubleshooting

​Patterns Not Matching

​File Not Found

​Nothing Is Being Filtered

​Example Configuration

Overview

How It Works

Where CybeDefend Looks

Usage

Creating a .cybeignore File

Migrating from .cybedefend

Supported Patterns

Scope

Common Use Cases

Ignore Test Code

Ignore Third-Party Code

Ignore Demo/Example Code

Ignore Configuration Templates

Best Practices

Exclude Files, Not Findings You Dislike

Document Your Exclusions

Include in Code Reviews

Verify What You Wrote

Monitor Impact

Troubleshooting

Patterns Not Matching

File Not Found

Nothing Is Being Filtered

Example Configuration