diff --git a/images/advanced_search.png b/images/advanced_search.png new file mode 100644 index 0000000..dfd02af Binary files /dev/null and b/images/advanced_search.png differ diff --git a/images/advanced_search_location.png b/images/advanced_search_location.png new file mode 100644 index 0000000..5891ea0 Binary files /dev/null and b/images/advanced_search_location.png differ diff --git a/images/branch_picker.png b/images/branch_picker.png new file mode 100644 index 0000000..885b70b Binary files /dev/null and b/images/branch_picker.png differ diff --git a/images/cwe_filters.png b/images/cwe_filters.png index 489fdfa..a211bbe 100644 Binary files a/images/cwe_filters.png and b/images/cwe_filters.png differ diff --git a/images/file_ignore_rules.png b/images/file_ignore_rules.png index c231c4c..aa670f0 100644 Binary files a/images/file_ignore_rules.png and b/images/file_ignore_rules.png differ diff --git a/images/policies_view.png b/images/policies_view.png new file mode 100644 index 0000000..4b6fc28 Binary files /dev/null and b/images/policies_view.png differ diff --git a/images/scan_log.png b/images/scan_log.png new file mode 100644 index 0000000..9821f32 Binary files /dev/null and b/images/scan_log.png differ diff --git a/images/scan_settings.png b/images/scan_settings.png new file mode 100644 index 0000000..b5b755a Binary files /dev/null and b/images/scan_settings.png differ diff --git a/mint.json b/mint.json index c4172a3..d8f2409 100644 --- a/mint.json +++ b/mint.json @@ -82,7 +82,7 @@ "false_positive", "issue_assignment", "issue_export", - "project_settings" + "project" ] }, { diff --git a/project.mdx b/project.mdx new file mode 100644 index 0000000..aee0396 --- /dev/null +++ b/project.mdx @@ -0,0 +1,120 @@ +--- +title: 'Project Management' +description: 'Configure scanning behavior for your project including CWE filters and file ignore rules' +--- + +## Overview + +Corgea’s project management live inside each project’s dashboard. Use this page to tailor scanning behavior so it aligns with your codebase, compliance needs, and team workflows. You can block noisy files, ignore irrelevant CWEs, document policies, and see the operational views you need to keep your application secure. + +Every change you make here applies to future scans for the selected branch. If you’re new to these controls, start with the Default Settings and gradually refine the filters after reviewing a few scan reports. + +## File Ignore Rules + +File ignore rules help you keep scanning focused on the code that matters. We already exclude common build artifacts, dependency folders, and generated files, so you typically only need to add rules that are unique to your project structure. + +### Default exclusions + +- **Test files**: `*_test.*`, `test_*.*`, `*.test.*`, `*.spec.*`, `*__tests__/*`, `*test/*`, `*tests/*` +- **Dependencies**: `*node_modules/*`, `*python*/site-packages/*` +- **Generated code**: `*generated.*`, `*.gen.go`, `*.pb.*`, `*.designer.cs`, `*.d.ts` +- **Build artifacts**: `*build/*`, `*dist/*`, `*coverage/*` +- **Configuration**: `tsconfig.json`, `webpack.config.js`, `pnpm-lock.yaml`, `*compose*.yml` +- **Other common folders**: `*migrations/*`, `*mock/*`, `*mocks/*`, `*fixtures*`, `*tmp/*`, `*log/*`, `*logs/*` + +### How to add custom ignores + + + + From the project dashboard, click **Settings** and choose **File ignore rules** from the sidebar. + Scan Settings + + + Use glob syntax to include paths (`src/tools/`) or directories (`**/legacy/**`). Each line accepts a single pattern, so you can mix directories, files, and wildcard expressions. + + File Ignore Rules Configuration + + + + Save the rule list and run a test scan to make sure the behavior matches your expectations. Revisit this list whenever you add new generated outputs or temporary directories. + + + +### When to add rules + +- **Internal tooling**: Scripts or utilities that should never be scanned (e.g., internal deploy scripts or CLI helpers). +- **Legacy or deprecated code**: Modules you’re no longer shipping but still keep for reference. +- **Vendor or third-party artifacts**: Files provided by hardware vendors or partners that don’t change and you don’t control. +- **Documentation or content**: Rule out large doc folders when only code matters. +- **Custom output**: Non-standard build directories created during CI or local experimentation. + +Always explain why a rule exists so teammates know why a folder is skipped during future reviews. + +## CWE Filters + +CWEs let you align Corgea’s findings with your project’s threat model. Think of this section as your security policy in code: you can disable specific vulnerability families that you’re already protecting through other controls or that don’t apply to your stack. + +### How to configure filters + + + + In the project settings sidebar, open the **CWE filters** tab. + + + Browse the list grouped by category (e.g., Injection, Authentication) or search for a specific CWE identifier. Toggle off entries that should no longer surface in new scan results. + + CWE Filters Configuration + + + + Add an internal note explaining why each rule exists—this helps new contributors understand whether the filter should remain in place. + + + +### Common scenarios + +- **Focus on critical paths**: Temporarily mute low-impact CWEs until you finish triaging high-severity findings. +- **Framework-level protection**: Skip CWEs covered by built-in framework hardening (e.g., managed auth providers). +- **Compliance tailoring**: Disallow CWEs that violate organizational policies while keeping scans manageable. +- **Early-stage development**: Move fast by hiding noise but re-enable the filters later before shipping. + +> Tip: Periodically re-run scans with the full CWE list enabled so you don’t miss regressions when filters change. + + +## Project Views and Controls + +### Trigger a Scan for a Specific Branch + +Select the branch you care about from the branch picker at the top of the dashboard before hitting **Scan now**. Corgea locks the scan to that branch's latest commit and stores branch metadata so you can compare results across lines of development. + + + Branch picker in project dashboard + + + +### Scan Log + +The Scan Log tracks every run you kick off. It records status, duration, branch, and who triggered each scan. Use this page to rerun scans, compare results side by side, and jump into the findings that caused failures. + + + Scan log view listing scan runs + + + +### Advanced Vulnerability Search + +Click the **Advanced** button on the project page to open the Advanced Vulnerability Search page and zero in on findings across every scan run. The view surfaces totals plus severity counts at the top, and you can expand any project to reveal its files, CWE badges, urgency levels, detection times, and other context without leaving the list. + +- **Filters**: Narrow results by Vulnerability Category, Urgency, Confidence, Status, Fix Status, Scan Type, Project, Branch, policies, or other metadata. A Date Range (preset or custom) is required so the system knows which span of time to examine. +- **Date reminder**: The interface highlights what’s missing if you try to run a search without selecting a date range, and keeps the controls disabled until you pick a preset or custom window. +- **Results exploration**: Click any row to load more context in the side panel while keeping your active filters in place. This lets you review evidence, remediation guidance, and related scan details without disrupting the list. + + + + + Advanced search location + + + Advanced vulnerability search screen + + diff --git a/project_settings.mdx b/project_settings.mdx deleted file mode 100644 index 2d3839f..0000000 --- a/project_settings.mdx +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: 'Project Settings' -description: 'Configure scanning behavior for your project including CWE filters and file ignore rules' ---- - -## Overview - -Project Settings allow you to customize how Corgea scans your codebase. You can configure which security vulnerabilities (CWEs) to ignore and which files or directories to exclude from scanning. These settings help you tailor the scanning process to your project's specific needs and reduce noise from irrelevant findings. - -## File Ignore Rules - -File ignore rules allow you to exclude additional project-specific files or directories from security scanning. Corgea already ignores common patterns like test files, dependencies, generated code, and build artifacts by default, so you only need to specify files unique to your project structure. - -### What's Already Ignored by Default - -Corgea automatically excludes these common patterns from scanning: - -- **Test Files**: `*_test.*`, `test_*.*`, `*.test.*`, `*.spec.*`, `*__tests__/*`, `*test/*`, `*tests/*` -- **Dependencies**: `*node_modules/*`, `*python*/site-packages/*` -- **Generated Code**: `*generated.*`, `*.gen.go`, `*.pb.*`, `*.designer.cs`, `*.d.ts` -- **Build Artifacts**: `*build/*`, `*dist/*`, `*coverage/*` -- **Configuration**: `tsconfig.json`, `webpack.config.js`, `pnpm-lock.yaml`, `*compose*.yml` -- **Other**: `*migrations/*`, `*mock/*`, `*mocks/*`, `*fixtures*`, `*tmp/*`, `*log/*`, `*logs/*` - -### How to Configure Additional File Ignore Rules - - - - Go to your project's settings page from the project dashboard. - - - Locate the File Ignore Rules section where you can specify additional files or directories to exclude from scanning. - - File Ignore Rules Configuration - - - - Define project-specific file paths, directory patterns, or glob patterns to exclude from scanning. Add multiple rules as needed for your unique project structure. - - - -### When to Add Custom Ignore Rules - -Consider adding custom file ignore rules for: - -- **Internal Tools**: Scripts or utilities specific to your development workflow -- **Legacy Code**: Deprecated code sections not actively maintained -- **Vendor-Specific Files**: Custom third-party integrations or frameworks -- **Documentation**: Internal wikis, design documents, or markdown files specific to your project -- **Data Files**: Sample data, fixtures, or seed files unique to your application -- **Custom Build Output**: Non-standard build directories or generated files - - -## CWE Filters - -CWE (Common Weakness Enumeration) filters allow you to exclude specific types of security vulnerabilities from your scan results. This is useful when certain vulnerability types are not applicable to your project or when you want to focus on specific security concerns. - -### How to Configure CWE Filters - - - - Go to your project's settings page from the project dashboard. - - - Locate the CWE Filters section where you can manage which vulnerability types to include or exclude from scanning. - - CWE Filters Configuration - - - - Choose the specific CWE categories you want to exclude from your scan results. Any vulnerabilities matching these CWE types will not appear in your scan reports. - - - -### Common Use Cases for CWE Filters - -- **Focus on Critical Issues**: Filter out lower-priority vulnerability types to focus on critical security concerns -- **Framework-Specific Filtering**: Exclude CWEs that are handled by your application framework's built-in security features -- **Compliance Requirements**: Align scanning with your organization's specific compliance and security policies -- **Development Phase**: Temporarily filter certain CWEs during early development phases and re-enable them later - - -### Best Practices - -- **Focus on Project-Specific Needs**: Only add rules for files unique to your project; common patterns are already handled -- **Keep Security-Critical Paths**: Ensure authentication, authorization, and data handling code is never excluded -- **Be Specific**: Use precise patterns to avoid accidentally excluding important security-relevant code -- **Regular Review**: Periodically review your ignore rules to ensure they're still appropriate as your project evolves -- **Team Alignment**: Document your custom ignore rules and ensure the team understands why specific files are excluded - -## Managing Settings - -### Saving Changes - -After configuring your CWE filters and file ignore rules, make sure to save your changes. The new settings will apply to all future scans of the project. - -### Impact on Existing Scans - -- Settings changes only affect **new scans** performed after the configuration is saved -- Historical scan results remain unchanged and continue to show all previously detected issues -- To apply new settings to your codebase, trigger a new scan after saving your configuration - -### Project-Specific Settings - -All settings are configured at the project level, allowing you to: -- Maintain different configurations for different projects -- Customize scanning behavior based on project requirements -- Apply organization-wide policies while allowing project-specific adjustments - -## Tips for Optimal Configuration - -1. **Start Broad, Then Refine**: Begin with minimal filtering and gradually add rules based on actual scan results -2. **Document Your Choices**: Maintain documentation explaining why certain CWEs or files are excluded -3. **Balance Coverage and Noise**: Find the right balance between comprehensive scanning and actionable results -4. **Review Regularly**: Revisit your configuration as your project evolves and security requirements change -5. **Test Configuration Changes**: After modifying settings, run a test scan to verify the results match your expectations -