# Corgea Agent Source: https://docs.corgea.app/agent AI-powered assistant for managing security vulnerabilities in your codebase ## Overview Corgea Agent is an AI-powered assistant that helps you manage security vulnerabilities in your codebase. It provides two main interaction modes: 1. **Web Chat Interface** - An interactive chat for exploring security issues, scans, and vulnerability data 2. **Pull Request Comments** - Automated responses to commands in PR comments across GitHub, GitLab, Azure DevOps, and Bitbucket *** ## Getting Started ### Prerequisites Before enabling Corgea Agent, ensure you have: * Active Corgea account with appropriate plan access * At least one integration configured (GitHub, GitLab, Azure DevOps, or Bitbucket) * Webhook events properly configured for your repository ### Initial Setup Navigate to **Settings > Agent Settings** in your Corgea dashboard and toggle the "Enable Corgea Agent" switch to activate the agent. Once enabled, the agent will begin monitoring PR comments and be available for chat. Agent Settings in Corgea Dashboard Ensure your Corgea integration has necessary permissions to: * Read pull request comments * Post comments on pull requests * Access repository content Check your integration settings to confirm webhooks are active. * Create a test PR with a security issue * Comment `hello` on any vulnerability in the PR to verify the agent responds * Access the web chat interface to ask a question about your scans *** ## Web Chat Interface ### Accessing the Chat Navigate to the **Chat** section in your Corgea dashboard to access the interactive AI assistant. Corgea Agent Web Chat Interface ### What You Can Do The Corgea Agent has deep knowledge of your security posture and can help you: Get detailed information about specific vulnerabilities, understand severity levels, and review fix suggestions Review scan results and summaries, compare scans over time, and understand scan coverage List issues by severity, project, or type, and review blocking rules and policy violations ### Example Queries ```plaintext Example Chat Queries theme={null} "Show me all critical issues in my latest scan" "What are the details for issue abc-123?" "List all SQL injection vulnerabilities in project XYZ" "Explain the security implications of CVE-2024-12345" "What blocking rules are currently active?" ``` Example Chat Session with Corgea Agent Be specific in your queries for better results. Reference issue IDs, scan IDs, or project names directly for more accurate responses. *** ## Pull Request Interactions ### How It Works When Corgea detects security issues in a pull request, the agent automatically: 1. Posts comments highlighting the vulnerabilities 2. Monitors the PR for developer responses 3. Interprets developer intent from comments 4. Takes automated actions based on commands Corgea Agent in GitHub Pull Request ### Triggering the Agent The agent responds to comments that: * Explicitly mention `@Corgea` * Reply directly to Corgea's issue comment * Contain recognizable action commands * Are directed at addressing security findings You don't need to use `@Corgea` as the agent will respond to comments to it's own. ### Supported Actions Indicate that a reported issue is not actually a vulnerability. **Example Comments:** ```plaintext theme={null} @Corgea false positive This is not a real issue, it's a false positive @Corgea this is safe code ``` **What Happens:** * Issue is marked as "False Positive" * Issue is removed from blocking status * Feedback is recorded for analysis Acknowledge a real vulnerability but accept the risk without immediate remediation. **Example Comments:** ```plaintext theme={null} @Corgea accept risk We accept this risk for now @Corgea low priority, won't fix This is acceptable for our use case ``` **What Happens:** * Issue status changes to "Accepted Risk" * Issue no longer blocks PR * Risk acceptance is logged Confirm that a vulnerability has been resolved. **Example Comments:** ```plaintext theme={null} @Corgea fixed Already fixed this in the latest commit @Corgea this is resolved ``` **What Happens:** * Issue status changes to "Fixed" * Issue no longer appears in active findings * Fix confirmation is recorded Flag an issue as a duplicate of an existing finding. **Example Comments:** ```plaintext theme={null} @Corgea duplicate This is a duplicate of issue XYZ Same as #456 ``` **What Happens:** * Issue is marked as duplicate * Linked to original issue (if specified) * Removed from active count Indicate that work is underway to fix the issue. **Example Comments:** ```plaintext theme={null} @Corgea fix in progress Working on this now We're fixing this in the next commit ``` **What Happens:** * Issue status changes to "Fix In Progress" * Tracked as actively being addressed * Team can monitor progress Ask Corgea for additional details about a vulnerability. **Example Comments:** ```plaintext theme={null} @Corgea explain this issue What's the security impact here? Can you provide more context? ``` **What Happens:** * Agent provides detailed explanation * Includes vulnerability context and remediation guidance * May suggest related resources ### Comment Interaction Examples **Scenario:** Developer disagrees with finding ```plaintext PR Comment theme={null} This input is already sanitized in the middleware layer, false positive ``` **Agent Response:** ```plaintext theme={null} ✅ Marked as False Positive This issue has been marked as a false positive based on your feedback. The issue will no longer block this PR. ``` **Scenario:** Accepting risk for legacy code ```plaintext PR Comment theme={null} This is legacy code we're deprecating next quarter. Accept the risk ``` **Agent Response:** ```plaintext theme={null} ⚠️ Marked as Accepted Risk This issue has been acknowledged as an accepted risk. It will no longer block this PR, but will remain in your security dashboard for tracking. ``` **Scenario:** Developer needs clarification ```plaintext PR Comment theme={null} Can you explain why this is considered an SQL injection vulnerability? ``` **Agent Response:** ```plaintext theme={null} [Detailed explanation of the SQL injection risk, code examples, and suggested remediation approaches] ``` ### Feedback History View all PR comment interactions in the **Feedback History** section: * See all actions taken via PR comments * Open an entry to view the original comment, AI reasoning, and the agent response in one place * Filter by action type, user, or date range * Monitor team engagement with security findings Feedback History Dashboard **Available Filters:** * Action Type (False Positive, Accepted Risk, Fixed, etc.) * GitHub/GitLab/Azure DevOps user * Date range *** ## Supported Platforms Corgea Agent works seamlessly across multiple development platforms: * Pull request comments * Issue comments * Review threads Requires: GitHub App installation with appropriate permissions * Merge request comments * Note threads Requires: GitLab integration with webhook configuration Requires: Support is coming soon * Pull request comments * Inline discussions Requires: Bitbucket integration with webhook configuration *** ## Troubleshooting **Check:** * Is the agent enabled in Settings > Agent Settings? * Are webhooks properly configured for your repository? * Did you mention `@Corgea` or reply to an agent comment? * Is your integration active and properly authenticated? **Solution:** * Verify webhook delivery in your platform's webhook settings * Check integration status in Corgea dashboard * Re-authenticate if needed **Check:** * Does your comment clearly state the intended action? * Are you commenting on the correct issue? * Do you have permissions to modify issues? **Solution:** * Use explicit commands like "@Corgea false positive" * Check the Feedback History to see how your comment was interpreted **Check:** * Browser console for JavaScript errors * Network connectivity * Account permissions **Solution:** * Refresh the page * Clear browser cache * Contact support if issue persists *** ## Best Practices **One Action Per Comment**: Keep comments focused on a single action **Provide Context**: Add reasoning to help the team understand your decision **Review Feedback History**: Periodically check how your commands are interpreted **Use Specific Identifiers**: Reference issue IDs, scan IDs, or project names **Ask Follow-Up Questions**: Drill deeper into topics with contextual queries **Leverage Search**: Filter results by severity, type, or status **Save Important Queries**: Keep track of useful queries for recurring analysis *** ## Privacy & Security All chat interactions are scoped to your company's data. The agent only accesses information your user account has permission to view. * PR comment actions are logged and auditable in Feedback History * Agent responses never expose sensitive credentials or internal implementation details * Data is processed in compliance with Corgea's security standards *** ## Support Need help with Corgea Agent? Contact us at [support@corgea.com](mailto:support@corgea.com) # Agentic Integrations Source: https://docs.corgea.app/agentic_integrations Empower your AI coding agents to scan, triage, and fix security vulnerabilities autonomously ## The Path to Autonomous Security Corgea's vision is to make application security fully autonomous — handling the heavy lifting so you can focus on building. Our platform already detects vulnerabilities, reduces false positives, and generates AI-powered fixes automatically. But some tasks still require a developer or security engineer to act on findings, apply fixes, and verify results. That's where Corgea's agentic integrations come in. By connecting Corgea directly to the AI coding agents you already use — like Cursor, Claude Code, GitHub Copilot, and OpenAI Codex — you give those agents the context and capabilities they need to handle security tasks on your behalf. The result is a development workflow where security issues are not only found but also resolved with minimal manual effort. Corgea offers two powerful agentic integrations: **Corgea Agent Skill** and **Corgea MCP**. *** ## Corgea Agent Skill [Agent Skills](https://agentskills.io/) are an open format for giving AI agents new capabilities. A skill is a structured set of instructions, commands, and context that an agent can discover and use on demand — think of it as a playbook that teaches your agent how to interact with a specific tool. The Corgea Agent Skill teaches your coding agent how to use the Corgea CLI to scan code, list issues, inspect vulnerabilities, view AI-generated fixes, and apply them — all from within your development environment. Unlike MCP (which provides read access to Corgea data), the Agent Skill gives your agent the ability to **take action**: run scans, retrieve diffs, and apply fixes directly to your codebase. Agent Skills are supported by leading AI development tools including **Cursor**, **Claude Code**, **OpenAI Codex**, **GitHub Copilot**, **VS Code**, **Roo Code**, **Windsurf**, and [many more](https://agentskills.io/). Corgea Agent Skill interaction in Cursor ### Prerequisites Before installing the skill, you need the **Corgea CLI** installed and authenticated on your machine. The skill relies on CLI commands like `corgea scan`, `corgea ls`, and `corgea inspect` to interact with Corgea. Follow the CLI installation and authentication guide to get set up. ### Skills Registry Use the Skills Registry in Corgea to create and manage company-authored Agent Skills for your teams. Add a `SKILL.md`, optionally provide a version, and submit it for review. Each version is reviewed independently before it becomes installable. Only approved skill versions can be installed through the CLI. Pending, rejected, or failed versions remain visible in the registry so your team can review status, notes, and previous versions before submitting an update. ### Install with `npx skills` The maintained public skill is [`corgea-scan`](https://github.com/Corgea/skills/tree/main/plugins/corgea/skills/corgea-scan) in the first-party [`Corgea/skills`](https://github.com/Corgea/skills) repository. The [Skills CLI](https://github.com/vercel-labs/skills) runs through `npx`, so you do not need to install it globally. It requires Node.js 18 or later and npm. The Skills CLI installs the instructions that teach your agent how to use Corgea. It does not install or authenticate the Corgea CLI itself. Complete the [Corgea CLI prerequisites](#prerequisites) first. Run the command from the root of the repository you want to scan. Choose the scope that matches how you work: Install the skill for agents working in the current repository: ```bash theme={null} npx skills add corgea/skills --skill corgea-scan ``` Project scope is the default. Use it when the skill should be repository-specific. Commit the generated skill files if other contributors should receive them when they check out the project. Install the skill for your user account across all repositories: ```bash theme={null} npx skills add corgea/skills --skill corgea-scan --global ``` Global scope is useful when you use the same coding agent across many repositories and do not want to add skill files to each project. By default, the installer detects supported agents and asks where to install the skill. Use one or more `--agent` flags when you want an explicit, repeatable target: ```bash theme={null} npx skills add corgea/skills --skill corgea-scan \ --agent claude-code \ --agent cursor \ --agent codex ``` Agent IDs include `claude-code`, `cursor`, `codex`, `opencode`, `github-copilot`, `windsurf`, and [many more](https://github.com/vercel-labs/skills#supported-agents). For an unattended installation, add `--yes`: ```bash theme={null} npx skills add corgea/skills --skill corgea-scan \ --global \ --agent codex \ --yes ``` The installer normally offers to link agents to a shared copy of the skill. If your environment does not support symlinks, add `--copy` to create independent copies instead. ##### Verify, update, or remove the skill Use the Skills CLI to inspect and maintain the installation: ```bash theme={null} # List project and global skills npx skills list # List only global skills npx skills list --global # Update the project or global installation npx skills update corgea-scan --project npx skills update corgea-scan --global # Remove the project or global installation npx skills remove corgea-scan npx skills remove --global corgea-scan ``` If your coding agent was already running during installation, restart it or open a new session. Then ask: > Scan this repository with Corgea. The agent should load `corgea-scan`, confirm that the Corgea CLI is available and authenticated, and start the scan from the current repository. Run `npx skills list` to confirm the project installation or `npx skills list --global` for a global installation. If you selected a specific agent, verify it with `npx skills list --agent `. Reinstall with the correct `--agent` and scope, then restart the agent. The skill depends on the Corgea CLI. Run `corgea --version` and `corgea login`, then repeat your request. See the [CLI installation guide](/cli) for platform-specific setup. Repeat the installation with `--copy`. This creates separate skill files for each selected agent instead of linking them to a shared copy. Remove it from the current scope, then reinstall it in the intended scope: ```bash theme={null} npx skills remove corgea-scan npx skills add corgea/skills --skill corgea-scan --global ``` ### Installation For the public Corgea Agent Skill, the skill file is hosted on GitHub: ``` https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` The fastest way to install it is with the Corgea CLI, which fetches the approved skill from the Corgea registry and places it in the right directory for your agent: ```bash theme={null} corgea skill install corgea ``` This installs into the current project for your configured default agent. Target a specific agent with `--agent` (e.g. `cursor`, `claude-code`, `codex` — see the [CLI reference](/cli#install-agent-skills) for all supported agents), choose `--scope project` or `--scope user`, or install to a custom path with `--dir`. Set a default agent for future installs with `corgea skill set-default-agent `: ```bash theme={null} corgea skill install corgea --agent cursor --scope user corgea skill set-default-agent claude-code ``` To place the file yourself instead, choose your agent below for the manual steps. Cursor discovers skills from `SKILL.md` files placed in designated directories. To install the Corgea skill: 1. Create the skills directory in your project or home folder: ```bash theme={null} mkdir -p ~/.cursor/skills/corgea ``` 2. Download the skill file: ```bash theme={null} curl -o ~/.cursor/skills/corgea/SKILL.md \ https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` Once placed, Cursor automatically loads the skill in Agent mode when your request matches a security task. You can also explicitly invoke it using `@corgea` in the chat. For project-level skills shared with your team, place the file in `.cursor/skills/corgea/SKILL.md` within your repository instead. Claude Code reads skills from the `.claude/skills/` directory. To install: 1. Create the skills directory: ```bash theme={null} mkdir -p ~/.claude/skills/corgea ``` 2. Download the skill file: ```bash theme={null} curl -o ~/.claude/skills/corgea/SKILL.md \ https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` Claude Code will automatically discover the skill and apply it when you ask about security scanning or vulnerability remediation. For project-level skills shared via git, place the file in `.claude/skills/corgea/SKILL.md` within your repository. Codex reads skills from the `~/.codex/skills/` directory. To install: 1. Create the skills directory: ```bash theme={null} mkdir -p ~/.codex/skills/corgea ``` 2. Download the skill file: ```bash theme={null} curl -o ~/.codex/skills/corgea/SKILL.md \ https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` Codex auto-discovers skills on startup. You can also add an `AGENTS.md` file to your repository root to reference the skill for project-specific use. GitHub Copilot in VS Code reads skills from `.github/skills/` or `~/.copilot/skills/`. To install: 1. Create the skills directory: ```bash theme={null} mkdir -p ~/.copilot/skills/corgea ``` 2. Download the skill file: ```bash theme={null} curl -o ~/.copilot/skills/corgea/SKILL.md \ https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` You can verify the skill is loaded by typing `/skills` in the VS Code chat panel. For project-level skills, place the file in `.github/skills/corgea/SKILL.md` within your repository. Windsurf reads skills from `.windsurf/skills/` (project) or `~/.codeium/windsurf/skills/` (global). To install globally: 1. Create the skills directory: ```bash theme={null} mkdir -p ~/.codeium/windsurf/skills/corgea ``` 2. Download the skill file: ```bash theme={null} curl -o ~/.codeium/windsurf/skills/corgea/SKILL.md \ https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` Cascade automatically invokes the skill when your request matches its description. You can also explicitly activate it using `@corgea` in the Cascade input. For project-level skills, place the file in `.windsurf/skills/corgea/SKILL.md` within your repository. Roo Code reads skills from `.roo/skills/` (project) or `~/.roo/skills/` (global). To install globally: 1. Create the skills directory: ```bash theme={null} mkdir -p ~/.roo/skills/corgea ``` 2. Download the skill file: ```bash theme={null} curl -o ~/.roo/skills/corgea/SKILL.md \ https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` Roo Code uses progressive disclosure — it reads the skill's frontmatter for discovery and loads the full instructions when your request matches the skill's description. For project-level skills, place the file in `.roo/skills/corgea/SKILL.md` within your repository. Any agent that supports the [Agent Skills](https://agentskills.io/) open format can use the Corgea skill. The general approach is: 1. Find your agent's skills directory (check your agent's documentation). 2. Create a `corgea` subdirectory inside it. 3. Download the skill file into that directory: ```bash theme={null} curl -o SKILL.md \ https://raw.githubusercontent.com/Corgea/cli/refs/heads/main/skills/corgea/SKILL.md ``` See the [Agent Skills website](https://agentskills.io/) for a full list of compatible agents and their configuration guides. ### Skills Marketplace Corgea also publishes an open marketplace of agent skills at [github.com/Corgea/skills](https://github.com/Corgea/skills). It covers more than the CLI skill above — including skills for tools that run entirely on your machine — and installs into any of the 70+ agents that support the Agent Skills format. | Skill | What it does | | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`corgea-scan`](https://github.com/Corgea/skills/tree/main/plugins/corgea/skills/corgea-scan) | Scan with Corgea's AI-powered BLAST scanner, then review and apply the AI-generated fixes. Requires a Corgea account and the CLI. | | [`sighthound`](https://github.com/Corgea/skills/tree/main/plugins/sighthound/skills/sighthound) | Run [Sighthound](https://github.com/Corgea/Sighthound), a fast tree-sitter SAST scanner with pattern and taint-flow analysis. Fully local — no account or network needed. | Install a single skill with the [skills CLI](https://github.com/vercel-labs/skills): ```bash theme={null} npx skills add corgea/skills --skill corgea-scan ``` Claude Code users can add the whole marketplace as a plugin instead, which makes every skill available at once: ``` /plugin marketplace add corgea/skills ``` The marketplace is the right choice when you want Sighthound, or when you'd rather manage skills as a set. To install just the Corgea CLI skill, `corgea skill install corgea` above is fewer steps and pulls the version approved in your Corgea registry. ### Use Cases When Corgea scans your pull request and reports vulnerabilities, you no longer need to manually inspect each finding and write fixes. Open your coding agent (Cursor, Claude Code, etc.) and ask it to fix the issues: > "Fix all the security issues Corgea found in my latest PR scan." The agent will automatically connect to Corgea, list the issues for your scan, retrieve the AI-generated diffs, and apply the fixes to your codebase — all in one step. When you're rapidly iterating on code with AI assistance (vibe coding), security can easily slip through the cracks. Use the agent to run a security check before every commit: > "Scan my uncommitted changes for security issues and fix anything you find." The agent will run `corgea scan --only-uncommitted`, review the results, and apply fixes — ensuring your fast-moving code stays secure without slowing you down. Focus the scan on the files or directories you've been working on: > "Scan the src/auth/ directory for security vulnerabilities." The agent runs a targeted BLAST scan using `--target src/auth/`, reviews the findings, and can apply fixes on the spot. When you want to understand a finding before deciding whether to fix it: > "Show me the details and fix for issue ISSUE\_ID." The agent retrieves the full issue details, explains the vulnerability, and presents the AI-generated fix with a diff — letting you make an informed decision. *** ## Corgea MCP The [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) is an open standard that lets AI agents securely connect to external tools and data sources. Corgea's MCP server exposes your scan results, vulnerability details, SCA findings, and blocking rules directly to any MCP-compatible agent. With Corgea MCP, your AI agent can query scan results, retrieve issue details, list vulnerabilities filtered by severity or project, and check policy configurations — all without you having to copy-paste data or switch between tools. Full setup instructions, available tools, and client configuration for Claude Desktop, Cursor, and more. ### Use Cases * **Contextual code review**: Ask your agent "What critical vulnerabilities were found in the last scan?" and get actionable answers grounded in real scan data. * **Vulnerability triage**: Let the agent prioritize which issues to fix first based on severity, exploitability, and your organization's blocking rules. * **Remediation planning**: Ask the agent to generate a fix plan for all open high-severity issues in a specific project or scan. * **Dependency risk assessment**: Query SCA findings to understand which third-party libraries have known vulnerabilities and what versions to upgrade to. *** ## Agent Skill vs. MCP — When to Use Which | | **Corgea Agent Skill** | **Corgea MCP** | | --------------------- | --------------------------------------------------------- | --------------------------------------------------- | | **Best for** | Running scans and applying fixes | Querying and analyzing existing scan data | | **Capabilities** | Run scans, list issues, inspect findings, apply fix diffs | Read scan results, issues, SCA data, blocking rules | | **Requires** | Corgea CLI installed and authenticated | API token + MCP client | | **Agent interaction** | Agent executes CLI commands in your terminal | Agent queries Corgea's API via MCP protocol | | **Ideal workflow** | "Scan and fix my code" | "What vulnerabilities exist?" | Use **both together** for the most comprehensive experience: the Agent Skill for taking action on findings, and MCP for querying and understanding your security posture. *** ## Getting Started Follow the [CLI installation guide](/cli) to install and authenticate. Add the Corgea skill to your coding agent using the installation instructions above. Connect your AI agent to Corgea's MCP server for security data access. See the [MCP setup guide](/modelcontextprotocol). Ask your agent to scan your code, review findings, and apply fixes — all from natural language. # Get Failed Login Attempts Source: https://docs.corgea.app/api-reference/authentication/get-failed-login-attempts /api-reference/openapi.json get /auth/failed-logins Retrieve failed login attempts for users # Get Login Attempts Source: https://docs.corgea.app/api-reference/authentication/get-login-attempts /api-reference/openapi.json get /auth/logins Retrieve successful login attempts for users # Get User Failed Login Attempts Source: https://docs.corgea.app/api-reference/authentication/get-user-failed-login-attempts /api-reference/openapi.json get /users/{user_id}/failed-logins Retrieve failed login attempts for a specific user # Get User Login Attempts Source: https://docs.corgea.app/api-reference/authentication/get-user-login-attempts /api-reference/openapi.json get /users/{user_id}/logins Retrieve successful login attempts for a specific user # Verify Token Source: https://docs.corgea.app/api-reference/authentication/verify-token /api-reference/openapi.json get /verify Verify the API token and optionally return user information # Verify Token (Deprecated) Source: https://docs.corgea.app/api-reference/authentication/verify-token-deprecated /api-reference/openapi.json get /verify/{token} # Get Dependencies Source: https://docs.corgea.app/api-reference/dependencies/get-dependencies /api-reference/openapi.json get /dependencies Retrieve software dependencies (SBOM) from the latest matching processed scan. # Get Dependencies for Scan Source: https://docs.corgea.app/api-reference/dependencies/get-dependencies-for-scan /api-reference/openapi.json get /scan/{scan_id}/dependencies Retrieve software dependencies (SBOM) for a specific scan. # API Reference Source: https://docs.corgea.app/api-reference/introduction Get started with the Corgea API # Welcome to the Corgea API The Corgea API allows you to programmatically interact with Corgea's application security platform. Automate vulnerability scanning, retrieve security issues, manage fixes, and integrate Corgea into your development workflow. ## What can you do with the Corgea API? Initiate security scans, upload scan results, and monitor scan progress Retrieve vulnerability details, manage issue status, and track remediation Access AI-generated security fixes and patches for identified vulnerabilities Integrate security scanning into your continuous integration pipelines ## API Capabilities ### Authentication & Authorization * **Token Verification**: Verify API tokens and retrieve user information * **Authorization Flow**: Exchange authorization codes for API tokens ### Scanning APIs * **Start Scan**: Initiate new blast scans with chunked file uploads for large codebases * **Upload Scan Results**: Submit scan reports from external security tools * **Get Scans**: Retrieve scan history with filtering and pagination * **Get Scan Details**: Access detailed information about specific scans * **Scan Reports**: Generate HTML, SARIF, or Markdown reports for scans ### Issue Management APIs * **Get Issues**: List all security issues with filtering options * **Get Issue Details**: Retrieve comprehensive information about specific vulnerabilities * **SCA Issues**: Access Software Composition Analysis (SCA) vulnerabilities * **Issue Filtering**: Filter by project, repository, urgency, and more ### Policy Management * **Blocking Rules**: Define and manage security policies * **Rule Validation**: Check if scans violate blocking rules * **Policy Enforcement**: Prevent deployments based on security policies ## Base URL All API requests should be made to either: Our multi-tenant environment ``` https://www.corgea.app/api/v1 ``` Or your single tenant environment ``` https://.corgea.app/api/v1 ``` ## Authentication The Corgea API uses API key authentication. Include your API token in the request header: ```bash theme={null} CORGEA-TOKEN: your_api_token_here ``` ### Getting Started with Authentication 1. **Obtain an API Token**: Get your API token from your Corgea account settings 2. **Verify Your Token**: Use the `/verify` endpoint to confirm your token is valid 3. **Optional User Info**: Include `?user_info=true` to get user and company details ### Authentication Methods **Header-based Authentication** (Recommended): ```bash theme={null} curl -H "CORGEA-TOKEN: your_api_token_here" \ https://www.corgea.app/api/v1/verify ``` **Path-based Authentication** (Deprecated): ```bash theme={null} curl https://www.corgea.app/api/v1/verify/your_token_here ``` ### Authorization Flow For applications that need to authenticate users: 1. Redirect users to Corgea's authorization page 2. Users authorize your application and receive an authorization code 3. Exchange the code for an API token using `/authorize?code=your_code` Some endpoints (like `/verify/{token}` and `/authorize`) don't require authentication. Check individual endpoint documentation for specific requirements. ## Response Format All API responses are returned in JSON format. Successful responses include a `status` field: ```json theme={null} { "status": "ok", "data": { } } ``` Error responses include descriptive messages: ```json theme={null} { "status": "error", "message": "Description of the error" } ``` ## HTTP Status Codes The API uses standard HTTP status codes: | Code | Description | | ----- | ------------------------------------------------ | | `200` | Request successful | | `400` | Bad request - invalid parameters or request body | | `401` | Unauthorized - invalid or missing authentication | | `404` | Resource not found | | `429` | Rate limit exceeded | | `500` | Internal server error | ## Pagination Endpoints that return lists support pagination using query parameters: * `page`: Page number (default: 1) * `page_size`: Number of results per page (default: 20, max: 50) Paginated responses include: ```json theme={null} { "status": "ok", "page": 1, "total_pages": 5, "data": [] } ``` ## Need Help? Learn how to authenticate your API requests Contact our support team for assistance ## Quick Start Get started with the Corgea API in three steps: 1. **Get your API token** from your Corgea account settings 2. **Verify your token** using the `/verify` endpoint with header authentication 3. **Make your first request** to [upload a scan report](https://docs.corgea.app/api-reference/uploading-3rd-party-scan/upload-scan) or [list security issues](https://docs.corgea.app/api-reference/issues/list-all-issues) Explore the API endpoints in the sidebar to learn more about available functionality. # Get Code Quality Issues for Scan Source: https://docs.corgea.app/api-reference/issues/get-code-quality-issues-for-scan /api-reference/openapi.json get /scan/{scan_id}/issues/quality Retrieve code quality findings for a specific scan. # Get IaC Issues Source: https://docs.corgea.app/api-reference/issues/get-iac-issues /api-reference/openapi.json get /issues/iac Retrieve Infrastructure-as-Code (IaC) security issues from the latest matching processed scan. # Get IaC Issues for Scan Source: https://docs.corgea.app/api-reference/issues/get-iac-issues-for-scan /api-reference/openapi.json get /scan/{scan_id}/issues/iac Retrieve Infrastructure-as-Code (IaC) security issues for a specific scan. # Get Issue Source: https://docs.corgea.app/api-reference/issues/get-issue /api-reference/openapi.json get /issue/{issue_id} Retrieves details of a specific issue # Get Issues for Scan Source: https://docs.corgea.app/api-reference/issues/get-issues-for-scan /api-reference/openapi.json get /scan/{scan_id}/issues Retrieves a list of issues for a specific scan # Get SCA Issue Source: https://docs.corgea.app/api-reference/issues/get-sca-issue /api-reference/openapi.json get /issues/sca/{issue_id} Retrieve details for a specific Software Composition Analysis (SCA) issue, including dependency reachability information. # Get SCA Issues Source: https://docs.corgea.app/api-reference/issues/get-sca-issues /api-reference/openapi.json get /issues/sca Retrieve a list of Software Composition Analysis (SCA) issues # Get SCA Issues for Scan Source: https://docs.corgea.app/api-reference/issues/get-sca-issues-for-scan /api-reference/openapi.json get /scan/{scan_id}/issues/sca Retrieve SCA issues for a specific scan # List All Issues Source: https://docs.corgea.app/api-reference/issues/list-all-issues /api-reference/openapi.json get /issues Retrieve a list of all security issues for the authenticated user's company # List Code Quality Issues Source: https://docs.corgea.app/api-reference/issues/list-code-quality-issues /api-reference/openapi.json get /issues/code-quality Retrieve code quality findings separately from security issues. Classification values are code quality labels, such as Maintainability, rather than CWEs. # List Company Notification Defaults Source: https://docs.corgea.app/api-reference/notifications/list-company-notification-defaults /api-reference/openapi.json get /notifications/company-defaults Retrieve company-level email and webhook defaults for active notification types. Company admin access is required. # List Notification Preferences Source: https://docs.corgea.app/api-reference/notifications/list-notification-preferences /api-reference/openapi.json get /notifications/preferences Retrieve resolved email notification preferences for the authenticated user. # List Notification Types Source: https://docs.corgea.app/api-reference/notifications/list-notification-types /api-reference/openapi.json get /notifications/types Retrieve active notification types available to the authenticated user. # Update Company Notification Default Source: https://docs.corgea.app/api-reference/notifications/update-company-notification-default /api-reference/openapi.json post /notifications/company-defaults/{type_code} Partially update company-level email or webhook defaults for a notification type. Use null to inherit the platform default. Company admin access is required. # Update Company Notification Default Source: https://docs.corgea.app/api-reference/notifications/update-company-notification-default-1 /api-reference/openapi.json patch /notifications/company-defaults/{type_code} Partially update company-level email or webhook defaults for a notification type. Use null to inherit the platform default. Company admin access is required. # Update Notification Preference Source: https://docs.corgea.app/api-reference/notifications/update-notification-preference /api-reference/openapi.json post /notifications/preferences/{type_code} Set or reset the authenticated user's email preference for a notification type. Use null to inherit the company default. # Update Notification Preference Source: https://docs.corgea.app/api-reference/notifications/update-notification-preference-1 /api-reference/openapi.json patch /notifications/preferences/{type_code} Set or reset the authenticated user's email preference for a notification type. Use null to inherit the company default. # Create Policy Source: https://docs.corgea.app/api-reference/policies/create-policy /api-reference/openapi.json post /policies Create a policy for the authenticated user's company. # Deactivate Policy Source: https://docs.corgea.app/api-reference/policies/deactivate-policy /api-reference/openapi.json delete /policies/{policy_id} Deactivate a policy by ID. # Get Policy Source: https://docs.corgea.app/api-reference/policies/get-policy /api-reference/openapi.json get /policies/{policy_id} Retrieve a policy by ID. # List Blocking Rules Source: https://docs.corgea.app/api-reference/policies/list-blocking-rules /api-reference/openapi.json get /blocking-rules Retrieve all blocking rules for the authenticated user's company # List Policies Source: https://docs.corgea.app/api-reference/policies/list-policies /api-reference/openapi.json get /policies Retrieve policies for the authenticated user's company. Results are ordered by newest first. # Update Policy Source: https://docs.corgea.app/api-reference/policies/update-policy /api-reference/openapi.json patch /policies/{policy_id} Partially update a policy. Updates to policy content create a new version; changing only active status updates the same policy. # List Projects Source: https://docs.corgea.app/api-reference/projects/list-projects /api-reference/openapi.json get /projects Retrieve a list of projects for the authenticated user's company # Update Project Tags Source: https://docs.corgea.app/api-reference/projects/update-project-tags /api-reference/openapi.json patch /projects/{project_id}/tags Add, remove, or replace tags for a project. Incoming tags are trimmed, lowercased, empty values are ignored, and duplicate values are removed before the update is applied. # Check Blocking Rules Source: https://docs.corgea.app/api-reference/scans/check-blocking-rules /api-reference/openapi.json get /scan/{scan_id}/check_blocking_rules Check if scan issues violate any blocking rules # Get Scan Source: https://docs.corgea.app/api-reference/scans/get-scan /api-reference/openapi.json get /scan/{scan_id} Retrieves details of a specific scan # Get Scan Report Source: https://docs.corgea.app/api-reference/scans/get-scan-report /api-reference/openapi.json get /scan/{scan_id}/report Retrieve scan report in HTML, SARIF, or Markdown format # Get Scans Source: https://docs.corgea.app/api-reference/scans/get-scans /api-reference/openapi.json get /scans Retrieves a list of scans for the authenticated user's company # Get Skill Source: https://docs.corgea.app/api-reference/skills/get-skill /api-reference/openapi.json get /skills/{slug} Retrieve a single skill by slug. By default, the latest approved version is returned when one exists. A specific version can be requested with the version query parameter. Version content is included only when the selected version is approved. # List Skills Source: https://docs.corgea.app/api-reference/skills/list-skills /api-reference/openapi.json get /skills Retrieve skills in the authenticated user's company. Use status=approved to return only skills with an approved, installable version. # Check Upload Status Source: https://docs.corgea.app/api-reference/starting-corgea-scan/check-upload-status /api-reference/openapi.json head /start-scan/{transfer_id} Check the current status of an upload # Continue Scan Upload Source: https://docs.corgea.app/api-reference/starting-corgea-scan/continue-scan-upload /api-reference/openapi.json patch /start-scan/{transfer_id} Continue uploading chunks for an existing scan # Start New Scan Source: https://docs.corgea.app/api-reference/starting-corgea-scan/start-new-scan /api-reference/openapi.json post /start-scan Initiates a new BLAST scan with file upload. Accepts one or more files for scanning. # Upload CI/CD Data Source: https://docs.corgea.app/api-reference/uploading-3rd-party-scan/upload-cicd-data /api-reference/openapi.json post /ci-data-upload Upload CI/CD pipeline metadata and context information for a specific scan run. # Upload Git Config Source: https://docs.corgea.app/api-reference/uploading-3rd-party-scan/upload-git-config /api-reference/openapi.json post /git-config-upload Upload Git configuration data for a specific scan run to help with repository URL parsing and analysis. # Upload Scan Source: https://docs.corgea.app/api-reference/uploading-3rd-party-scan/upload-scan /api-reference/openapi.json post /scan-upload Upload a completed scan report from CLI tools. This endpoint receives pre-generated scan results from Semgrep, Snyk, Checkmarx, CodeQL, and Fortify and integrates them into the system. # Upload Source Code File Source: https://docs.corgea.app/api-reference/uploading-3rd-party-scan/upload-source-code-file /api-reference/openapi.json post /code-upload Upload individual source code files for a specific scan run. This is used to upload the actual source files that will be analyzed. # Azure DevOps Source: https://docs.corgea.app/azure_devops Comprehensive Guide to Configuring Azure DevOps with Corgea The integration of Azure DevOps with Corgea empowers users to seamlessly scan projects and initiate pull requests for code fixes directly from the Corgea platform. Access your Azure DevOps account and generate a personal access token (PAT) with both read and write permissions. Create Personal Access Token Token Permissions Proceed to the Integrations page on Corgea. Click the "+" button within the Azure DevOps section and ensure the token is securely saved. Add Token to Corgea After configuration, navigate to the Projects page. Your Azure DevOps project will be displayed with a Windows icon. Click the "+" in the action column to initiate the first scan, or select the project name and click "New Scan" to commence a new scan. Search Projects From any issue page associated with Azure DevOps projects in Corgea, you can submit a pull request to address an issue. Issue Pull Request ## Optional: Webhook Configuration To enable scans when pull requests are created or updated, configure two webhooks (one for each event). Ensure you possess the requisite permissions to set up webhooks for your project. Select "Project settings" located at the bottom left of the Azure DevOps interface. Project Settings Click on "Service Hooks". Multiple clicks may be necessary if it does not load immediately. Service Hooks Click the "+" button and choose "Web Hooks". Web Hooks Select "Pull request created" as the trigger event, configure any optional settings, and click "Next". Trigger Event In the Settings section, input the URL as [https://www.corgea.app/azure\_webhook/](https://www.corgea.app/azure_webhook/) or `https://your_instance.corgea.app/azure_webhook/` for private deployments. Webhook URL Open a new browser tab, navigate to the Corgea integrations page, and locate your Azure integration. Copy the X-CORGEA-UUID value. X-CORGEA-UUID Return to the Azure DevOps Webhook configuration page and populate the headers section with: * X-CORGEA-UUID: (UUID value you copied) * X-WEB-TOKEN: (legacy/optional; include only if your external infrastructure requires it) Headers Configuration Click "Finish" to save the configuration. Disregard the "Test" button as it may attempt to trigger scans for files you do not have access to. Repeat the same steps to add a second webhook with "Pull request updated" as the trigger event. Use the same URL and headers as the first webhook. Pull request updated trigger event Validate the setup by creating or updating a pull request. A successful configuration will display a successful event in the webhook history and trigger a new scan on the Corgea Scans page at [https://www.corgea.app/scans/](https://www.corgea.app/scans/). Webhook History Corgea Scans ## Enable Azure DevOps pull request comment responses Corgea can receive and respond to comments on Azure DevOps pull requests. ### Prerequisites * Corgea Agent is enabled for your organization. * Azure DevOps is connected to Corgea. * The integration PAT has `Code: Read & write` permission. * You can create service hook subscriptions in the Azure DevOps project. ### Configure the service hook 1. In Azure DevOps, open your project. 2. Go to `Project settings` -> `Service hooks`. 3. Select `Create subscription` or `+`. 4. Choose `Web Hooks`, then select `Next`. 5. Select `Pull request commented on` as the trigger. 6. Optionally restrict the hook to a repository or target branch. 7. Enter the webhook URL: * Corgea Cloud: `https://www.corgea.app/azure_webhook/` * Private deployment: `https:///azure_webhook/` 8. Add this HTTP header: `X-CORGEA-UUID: ` The UUID is available on Corgea's Integrations page. 9. Set `Resource details to send` to `All`. 10. Test the subscription, then select `Finish`. Service hooks are project-specific. Repeat these steps for every Azure DevOps project that should support comment responses. ### Verify the integration 1. Open a pull request containing a Corgea finding. 2. Reply directly to a Corgea comment, or address Corgea in the comment. 3. Confirm that: * The delivery succeeds under `Project settings` -> `Service hooks`. * Corgea posts its response in the same comment thread. ### Troubleshooting * Confirm the service hook is enabled and uses `Pull request commented on`. * Confirm `X-CORGEA-UUID` matches the correct Corgea integration. * Ensure `Resource details to send` is set to `All`. * Verify that the Azure DevOps PAT has not expired and has `Code: Read & write` access. * Confirm Corgea Agent is enabled for the organization. `X-WEB-TOKEN` is not consumed by the Corgea application for this flow. Only keep that header if your external infrastructure requires it. # Bitbucket Source: https://docs.corgea.app/bitbucket Comprehensive Guide to Configuring Bitbucket with Corgea The Bitbucket integration with Corgea enables you to scan projects and create pull requests for code fixes directly from the Corgea platform. While not required, we recommend creating a dedicated Bitbucket user account for Corgea integration. This helps distinguish Corgea's automated actions from your personal account activity and provides better auditability. Create Bitbucket User Navigate to the Atlassian API Tokens page and click "Create API token with scopes" to begin. **API tokens are not the same as workspace tokens.** API tokens are associated with your Atlassian user account. You can generate and manage your personal API tokens from the link provided above. Create API Token Provide a descriptive name for your token and set the expiration date to one year from today. This ensures the token remains valid for an extended period while maintaining security best practices. Token Name and Expiration Select **Bitbucket** from the applications list to grant Bitbucket access to this token. Select Bitbucket App Configure the required scopes for Corgea integration. Enable the following scopes:
Required Scopes:
  • Repositories: "read:repository:bitbucket", "write:repository:bitbucket"
  • Pull requests: "read:pullrequest:bitbucket", "write:pullrequest:bitbucket"
  • Webhooks: "read:webhook:bitbucket", "write:webhook:bitbucket", "delete:webhook:bitbucket"
  • General Info: "read:user:bitbucket", "read:workspace:bitbucket"
Token Scopes Review your configuration and click "Create token" to generate the access token. Create Token After the token is created, click the copy button to copy the token value. You'll need this token in the next step, and it won't be displayed again. Copy Token Access your Corgea dashboard at `corgea.app` or `{your-instance}.corgea.app` and navigate to the Integrations page using the sidebar or integrations link. Corgea Integrations Page In the "Code Repository Integrations" section, locate Bitbucket and click the plus (+) icon to create a new integration. New Integration Complete the integration form with the following information: * **Workspace slug**: Your Bitbucket workspace identifier * **Email address**: The email associated with the Bitbucket account used to generate the API token * **Access token**: The API token you copied in the previous step * **Integration name** (optional): A custom name to identify this integration if you manage multiple Bitbucket workspaces Create Integration Modal Corgea validates your credentials automatically. If any information is incorrect, you'll receive an error message with details about what needs to be corrected. Validation Upon successful validation, you'll see a confirmation message indicating that the integration is complete. Webhooks are automatically configured during this process, so no manual webhook setup is required. You can view the integration details, including webhook status, from the integrations page. Success Message # AI-native SAST Source: https://docs.corgea.app/blast Comprehensive vulnerability coverage in Corgea ## Overview AI-native SAST is Corgea's next-generation code scanning solution, designed to detect and fix security vulnerabilities in application code, with a particular emphasis on business logic, authentication and code flaws. Unlike traditional Static Application Security Testing (SAST) tools, AI-native SAST uses advanced AI-driven techniques to enhance detection accuracy, reduce false positives, and provide actionable insights for developers and security teams. By leveraging the power of Large Language Models (LLMs) combined with static analysis, AI-native SAST delivers a deeper contextual understanding of code, allowing it to detect vulnerabilities that standard SAST tools might miss. This document provides a technical overview of how AI-native SAST works, what it can detect, and how it integrates into development workflows. ## Key Features * Combines the reasoning capabilities of LLMs with static code analysis * Accurately detects vulnerabilities with contextual understanding * Identifies both business logic and traditional SAST vulnerabilities * Low false positive rate reduces noise in scanning results * Actionable insights with clear explanations * Seamless integration with CI/CD pipelines and pull requests * Business logic vulnerability detection * Authentication and authorization flaws * Comprehensive vulnerability detection across multiple categories ## Vulnerability Classes Detected AI-native SAST excels at detecting business logic vulnerabilities, which are often missed by traditional SAST tools. Below are some of the specific vulnerabilities detected by AI-native SAST: * **Broken Access Control (CWE-639)**: Missing authorization checks allowing unauthorized access * **Insecure Direct Object References (CWE-639)**: Direct access to objects without proper authorization * **Path Traversal (CWE-22)**: Directory traversal attacks accessing unauthorized files * **Insecure Authorization (CWE-285)**: Weak access controls * **Privilege Escalation (CWE-269)**: Improper privilege management * **Missing Function Level Access Control (CWE-285)**: Unprotected administrative functions * **SQL Injection (CWE-89)**: Unsanitized SQL queries allowing database manipulation * **Command Injection (CWE-78)**: OS command injection vulnerabilities * **Cross-Site Scripting (XSS) (CWE-79)**: Injection of malicious scripts into web pages * **LDAP Injection (CWE-90)**: LDAP query manipulation * **XML Injection (CWE-91)**: XML content manipulation * **Code Injection (CWE-94)**: Dynamic code execution vulnerabilities * **Expression Language Injection (CWE-917)**: Injection in expression languages * **Template Injection (CWE-1336)**: Server-side template injection * **Insecure Authentication (CWE-287)**: Missing MFA or insecure token management * **Broken Authentication (CWE-287)**: Weak authentication mechanisms * **Improper Session Management (CWE-384)**: Session ID mismanagement * **Credential Management (CWE-255)**: Improper credential storage or transmission * **Weak Password Requirements (CWE-521)**: Insufficient password complexity enforcement * **Insecure Data Storage (CWE-311)**: Weak encryption or plaintext storage * **Weak Cryptography (CWE-327)**: Use of broken or risky cryptographic algorithms * **Insufficient Entropy (CWE-330)**: Predictable random number generation * **Hardcoded Secrets (CWE-798)**: Embedded credentials * **Sensitive Data Exposure (CWE-200)**: Information leaks * **Improper Certificate Validation (CWE-295)**: SSL/TLS validation failures * **Unhygienic Data Handling (CWE-20)**: Poor input validation * **Improper Output Encoding (CWE-116)**: Inadequate output sanitization * **Mass Assignment (CWE-915)**: Binding of request parameters to internal objects * **XML External Entity (XXE) (CWE-611)**: XML parser vulnerabilities * **Deserialization of Untrusted Data (CWE-502)**: Insecure object deserialization * **Security Misconfiguration (CWE-16)**: Improper security settings * **Default Configurations (CWE-1188)**: Use of insecure default settings * **Missing Security Headers (CWE-693)**: Absence of protective HTTP headers * **Verbose Error Messages (CWE-209)**: Information disclosure through errors * **Directory Listing (CWE-548)**: Exposed directory contents * **Business Logic Vulnerabilities (CWE-840)**: Flaws that allow users to manipulate or bypass critical processes * **Code Logic Vulnerabilities (CWE-633)**: Errors in conditions or loops leading to unexpected behavior * **Context Dependent Vulnerabilities (CWE-696)**: Time-based or state-dependent errors * **Race Conditions (CWE-362)**: Uncontrolled timing/ordering of operations * **Timing Attacks (CWE-208)**: Time-based information leaks * **SSRF (CWE-918)**: Server-side request forgery allowing unauthorized internal requests * **URL Redirection (CWE-601)**: Unvalidated redirects and forwards * **DNS Rebinding (CWE-350)**: DNS-based SSRF attacks * **Improper Logging (CWE-532)**: Sensitive data in logs * **Insufficient Logging (CWE-778)**: Missing security event logging * **Improper Error Handling (CWE-209)**: Information leaks in error messages * **Improper Exception Handling (CWE-248)**: Security risks from poor exception management * **Missing Audit Trail (CWE-778)**: Inadequate activity tracking * **Malicious Code (CWE-506)**: Unauthorized harmful actions * **Backdoors (CWE-288)**: Hidden access mechanisms * **Time Bombs (CWE-511)**: Triggered malicious actions * **Supply Chain Attacks (CWE-1357)**: Compromised dependencies or updates * **Data Exfiltration (CWE-319)**: Unauthorized data transmission * **Unethical Data Collection (CWE-359)**: Improper data gathering * **Malicious Network Activity (CWE-293)**: Suspicious connections * **Crypto Mining (CWE-400)**: Unauthorized resource usage * **Resource Exhaustion (CWE-400)**: Denial of service through resource consumption In addition to business logic vulnerabilities, AI-native SAST can also detect common security flaws found in regular SAST scanning, covering approximately **900 Common Weakness Enumerations (CWEs)**. Corgea also provides comprehensive secret scanning capabilities to detect hardcoded credentials, API keys, and sensitive data. Learn more about secret detection and secure storage alternatives. ## Comprehensive Vulnerability Coverage Corgea's AI-native SAST provides extensive vulnerability coverage that goes beyond industry standards like the OWASP Top 10 and the Top 25 CWEs. Our platform continuously expands its vulnerability database to stay ahead of emerging threats and address a wide range of security issues across different programming languages and frameworks. ### Depth and Breadth of Coverage Our vulnerability coverage spans multiple dimensions to ensure thorough analysis of your codebase: Corgea understands the nuances of different programming languages and their unique security challenges. Our AI models are trained to identify vulnerabilities specific to each supported language, from memory management issues in C/C++ to dynamic typing challenges in Python and Ruby. Popular frameworks introduce their own set of security concerns. Corgea's analysis accounts for the intricacies of frameworks like .NET, Django, Ruby on Rails, Gin, Express.js, and Spring, providing targeted vulnerability detection and remediation. Beyond language-specific issues, our platform addresses vulnerabilities that can occur across multiple languages, such as: * Insecure cryptographic practices * Improper input validation * Race conditions * Authentication and authorization flaws Our AI models are continuously updated to stay ahead of the curve, ensuring detection and remediation of new vulnerabilities as they emerge in the ever-evolving security landscape. ### Why Comprehensive Coverage Matters Minimize the risk of security breaches, data leaks, and other potential threats by addressing a wide range of vulnerabilities Meet industry-specific security requirements and regulatory standards, reducing the risk of non-compliance penalties Streamline security review processes with AI-powered false positive detection and automated fixing capabilities Stay protected as the security landscape evolves with continuously expanding vulnerability database and threat intelligence ## Endpoint Reachability Analysis For eligible full AI-native SAST scans, Corgea supplements each finding with static endpoint reachability analysis. Corgea discovers the application's HTTP routes, resolves their handlers, and traces function calls from those handlers to the finding's source location. A finding is **reachable** when Corgea identifies at least one static call path from a discovered endpoint to the vulnerable code. Each result can include the endpoint's HTTP method and path, the intermediate functions and files, code snippets, and the total path depth. Reachability indicates that an endpoint can invoke code containing the finding. It does not prove that the finding is exploitable. Authentication, authorization, middleware, validation, runtime configuration, and data flow can still prevent exploitation. Similarly, no reachability data does not prove that a finding is unreachable. Dynamic dispatch, runtime-generated routes, unresolved handlers, unsupported code patterns, or incomplete source context can prevent static analysis from finding a path. ### How the analysis works Corgea detects the web frameworks in the repository and inventories routes with their HTTP methods, paths, handlers, source locations, and sub-projects where applicable. Corgea indexes functions, methods, imports, and calls for supported application languages. Reachability currently analyzes eligible findings in Python, JavaScript, TypeScript, Go, Java, C#, and PHP. For each eligible SAST finding with a source location, Corgea searches for static call paths from the relevant endpoint handlers to the finding. When a path is found, Corgea associates the endpoint with the finding and stores the pathway steps, code locations, and depth for review. Endpoint reachability is available when the feature is included in your plan and runs on full AI-native SAST scans. Results depend on support for the repository's language, framework, and routing patterns. ### Prioritize reachable findings Open the findings for a completed full AI-native SAST scan. Enable the **Reachable** toggle to show only findings with at least one endpoint-to-finding call path. The filter is preserved in the URL so you can bookmark or share the filtered view. Select **Endpoint** to group findings by HTTP method and route. For monorepos, the sub-project is shown when available. Each endpoint group shows its issue count and severity distribution. When call graphs are available, it also shows the maximum path depth and number of graphs. Expand a group to review its findings. The Endpoint view can also list discovered endpoints without associated findings and group findings that have no associated endpoint under **No endpoints**. ### Inspect a finding's call paths Select a reachable finding from the scan results, then click **Open Full View**. Select the **Reachability** tab. Corgea displays a graph from the reachable endpoints, through intermediate functions, to the vulnerability target. Endpoint nodes are blue, function nodes are green, and the vulnerability target is red. Click an endpoint or target node to highlight its connected paths. Use **Reset View** or **Center** to reposition the graph. The pathway list shows the endpoint and depth. Use **Previous** and **Next**, or the left and right arrow keys, to move between multiple pathways. Expand a step to inspect its file, function, line number, and available code snippet. Treat path depth as a description of the call chain, not a severity or confidence score. Use reachability to prioritize likely externally exposed findings, then review the finding's controls and [Taint Analysis](#reviewing-taint-analysis) to determine whether attacker-controlled data can reach the vulnerable operation. ## Reviewing Taint Analysis For code issues where Corgea can identify a data flow, **Full View** includes a **Taint Analysis** tab. Use it to follow how untrusted data moves from its source through the application to the vulnerable sink, including flows that cross multiple files. From a scan's issue list, click an issue row to open the issue details sidebar. In the sidebar, click **Open Full View**. The Taint Analysis tab is available in Full View, not in the sidebar preview. Issue quick view sidebar with the Open Full View button highlighted Select **Taint Analysis**. Corgea loads an ordered trace of the data flow. The first time you open the tab, generation may take a few seconds. Each step shows its role, file path, line number, and a short description. Click a step to open that file in the inline code viewer and jump to the relevant line. Taint Analysis tab in issue Full View showing source, propagation, and sink steps beside an inline code viewer The trace is grouped into three step types: * **Source** — where untrusted input enters the application * **Propagation** — intermediate functions or files that pass the tainted value along * **Sink** — where the data reaches the vulnerable operation Depending on what Corgea has for the issue, the trace may come from scan-time data flow (for example from Semgrep, SARIF, or Checkmarx findings), a reachability call graph, or an AI-generated analysis when no scan-time trace is available. The tab header indicates which source was used. ## Technology Behind AI-native SAST AI-native SAST is powered by Corgea's proprietary CodeIQ technology, combining AI with Abstract Syntax Trees (ASTs) for comprehensive analysis: AI-native SAST parses the entire project to build a complete picture of code component interactions, ensuring no vulnerabilities are missed. The AI engine understands code context, including middleware, configurations, and templates. Context and logic understanding reduces false positives common in traditional tools. ### Comparison to Traditional Methods Traditional static analysis techniques have significant limitations: * Source-sink analysis misses validation steps * Call-graphs miss runtime behaviors * Vector search and RAG suffer from overgeneralization ## Integration and Workflow * **CI/CD Pipelines**: Automatic scanning at commits/PRs * **Pull Request Reviews**: Pre-merge vulnerability analysis * **IDE Integration**: Real-time feedback during development ## Supported Languages and Frameworks Corgea provides comprehensive support for scanning, false positive detection, and auto-fixing across multiple programming languages and their popular frameworks, covering approximately 900 Common Weakness Enumerations (CWEs). ### Language Support **Native Language Support**: Robust support for C# language constructs, including LINQ, async/await patterns, and generics. **Frameworks**: .NET, ASP.NET Core, Blazor Corgea excels in securing enterprise-level .NET applications, addressing vulnerabilities like improper authentication, insecure deserialization, and CSRF. **Native Language Support**: Analyzes Python-specific features such as decorators, context managers, and comprehensions. **Frameworks**: Django, Flask, FastAPI Focuses on both web applications and backend services, tackling issues such as SQL injections, XSS, and insecure direct object references. **Native Language Support**: Understands Ruby's dynamic nature, including metaprogramming features and blocks. **Frameworks**: Ruby on Rails, Sinatra Specializes in identifying and fixing Ruby-specific vulnerabilities, including mass assignment issues, unprotected routes, and insecure file uploads. **Native Language Support**: Analyzes Go-specific constructs like goroutines, channels, and interfaces. **Frameworks**: Gin, Echo, Fiber Targets Go-specific security concerns, such as race conditions, improper error handling, and insecure use of cryptographic functions. **Native Language Support**: Supports both JavaScript and TypeScript, including features like async/await, closures, and TypeScript's type system. **Frameworks**: Node.js, Express.js, Next.js, NestJS, Angular, React, Vue.js Covers both client-side and server-side security, addressing issues like prototype pollution, insecure dependencies, and DOM-based XSS. **Native Language Support**: Analyzes Java-specific features such as generics, annotations, and lambda expressions. **Frameworks**: Spring, Jakarta EE, Play Framework Focuses on enterprise Java ecosystems, tackling vulnerabilities such as XML external entity (XXE) attacks, LDAP injection, and insecure object deserialization. **Native Language Support**: Handles PHP's unique syntax and language constructs, including traits and attributes. Addresses common web application vulnerabilities like remote code execution, file inclusion vulnerabilities, and SQL injection attacks. **Native Language Support**: Analyzes Kotlin-specific features including null safety, coroutines, and extension functions. Specializes in Android and server-side application security, addressing issues like improper data exposure and insecure communication. **Native Language Support**: Analyzes Swift-specific features including optionals, protocol extensions, generics, and value types. Enhances security in iOS and macOS application development, addressing vulnerabilities like insecure data storage, improper SSL/TLS validation, and insecure inter-process communication. **Native Language Support**: Handles low-level programming constructs including pointers, memory management, and templates. Focuses on memory-related vulnerabilities, buffer overflows, and system-level security issues common in C/C++ applications. *Enabled for false positive detection and auto-fixing. Coming to scanning soon.* ### Key Capabilities Advanced algorithms scan your codebase to identify potential security vulnerabilities, covering a wide range of CWEs AI-powered system accurately distinguishes between genuine vulnerabilities and false positives Provides actionable, context-aware fixes that can be applied automatically or reviewed before implementation Understands the nuances of different frameworks within each language for targeted security insights ## Intelligent File Filtering To optimize scan performance and accuracy, Corgea automatically excludes files that are not relevant to security analysis: ### Files We Skip * Media files (images, videos, fonts) * Style files (CSS, SCSS, LESS) * Documentation and markdown files * Configuration archives and compressed files * Test files and test directories * Mock and fixture data * Code coverage reports * Auto-generated code files * Minified or bundled code * Database migration files * Type definition files * Compiled binaries and build outputs ### Files Used for Context While not directly scanned for vulnerabilities, Corgea may reference certain files to provide better analysis context, including README files, configuration examples, and application settings files. ### Custom Configuration You can further customize scanning behavior using a `corgea.yaml` configuration file in your repository root: ```docs/corgea.yaml#L1-3 theme={null} ignore_paths: - "path/to/exclude/*" - "legacy-code/*" ``` This allows you to exclude specific directories or file patterns based on your project's needs. ### Why We Filter Our intelligent filtering approach: * **Improves accuracy** by focusing on actual application code * **Reduces noise** from test files and third-party code * **Optimizes performance** for faster scan results * **Prioritizes findings** in code you maintain **Coming Soon**: Rust language support # Blocking Rules Source: https://docs.corgea.app/blocking_rules Blocking rules help enforce security and quality standards by preventing non-compliant code from being merged. ## Overview ### What it Does Blocking rules are powerful guardrails that allow you to define specific conditions under which pull requests should be blocked from being merged. This helps ensure that your codebase adheres to your organization's security and quality standards by preventing potentially risky or non-compliant code changes from being merged. You can create two types of blocking rules: * **Code Vulnerability Rules**: Block PRs based on security vulnerabilities, code-quality findings, or both * **Dependency Vulnerability Rules**: Block PRs based on vulnerable dependencies found by SCA scanning ### Who it's For Blocking rules are primarily designed for: * Development teams * Project managers * Security professionals This feature is particularly useful for organizations with strict compliance requirements or those working on mission-critical applications where code quality and security are paramount. ## Key Features and Benefits Define rules based on Common Weakness Enumerations (CWEs) to block pull requests that introduce specific types of vulnerabilities or code quality issues. Assign urgency levels (e.g., critical, high, medium, low) to different types of issues, allowing you to prioritize and handle them accordingly. For dependency vulnerability rules, define an inclusive CVSS score range to block vulnerable dependencies based on their CVSS score. Apply blocking rules to specific projects, project tags, or across your entire organization, giving you granular control over which projects are subject to which rules. Easily create, edit, and delete blocking rules through a user-friendly interface, ensuring your rules stay up-to-date with your evolving requirements. Toggle the status of blocking rules to temporarily enable or disable them as needed, without losing their configurations. ## Rule Types Blocking rules support two distinct types to provide comprehensive security coverage: Blocks pull requests based on **security vulnerabilities**, **code-quality findings**, or both. Configure by: * Selecting an issue type: All, Vulnerabilities, or Code Quality * Selecting specific CWE (Common Weakness Enumeration) categories * Setting urgency/severity levels Use this to prevent issues like SQL injection, XSS, insecure cryptography, and other code-level vulnerabilities. Blocks pull requests based on **vulnerable dependencies** found by software composition analysis (SCA). Configure by: * Setting urgency/severity levels (Critical, High, Medium, Low) * Or setting an inclusive CVSS score range from 0.0 to 10.0 Use this to prevent the introduction of packages with known security vulnerabilities, ensuring your supply chain remains secure. ## How it Works with GitHub **Prerequisite** You must have installed and configured the [Corgea GitHub App](github) with appropriate repository permissions. Developer submits a pull request with code changes System analyzes code changes against active blocking rules If violations are found, pull request is automatically blocked Developer receives detailed notification about rule violations Developer must fix violations and mark them as Fixed, or mark them as False Positive or Accepted Risk before merge is allowed ## How it Works with Azure DevOps **Prerequisite** Make sure the [Azure DevOps integration](azure_devops) with Corgea is configured and you have the necessary permissions. A developer submits a pull request with code changes in Azure DevOps. The system evaluates the code changes against the active blocking rules set in Corgea. If violations are found, the pull request is automatically blocked. Developer cannot merge the PR until it is resolved. The developer receives a link to view detailed information about the failed issues on the Corgea Scan page. The developer must resolve the violations by fixing them or marking them as False Positive or Accepted Risk before the merge can proceed. ## Usage Guide ### Creating a New Blocking Rule Click the "Add Blocking Rule" button Select the type of blocking rule: * **Code Vulnerability**: Block pull requests based on code security issues (SAST findings) * **Dependency Vulnerability**: Block pull requests based on vulnerable dependencies (SCA findings) Enter rule name and description For **Code Vulnerability** rules: Choose an **Issue Type** to apply the rule to **All** findings, **Vulnerabilities** only, or **Code Quality** findings only. **All** is the default and preserves the behavior of existing rules. Then select urgency levels (Critical, High, Medium, or Low) and/or target CWEs; at least one of these must be defined for the rule to be valid. For **Dependency Vulnerability** rules: Choose whether to filter by severity or CVSS score. Select urgency levels (Critical, High, Medium, or Low), or enter a minimum and maximum CVSS score from 0.0 to 10.0 to block vulnerable dependencies within that inclusive range. Choose applicable projects and/or project tags (optional). A rule applies when a project is selected directly or has any selected tag. If no projects or tags are selected, the rule applies to all projects. Review and click "Create" ### Managing Existing Rules Use search to find rules by name or settings, or use the project tag filter to show rules that apply to projects with a specific tag. In the rules table, the Projects column shows selected projects and project tags as chips; rules without a project or tag scope show **All Projects**, and longer scope lists are grouped behind a **+N more** tooltip. 1. Locate rule in table 2. Click "Edit" button 3. Modify settings as needed 4. Click "Update" to save 1. Find rule in table 2. Click "Toggle Status" 3. Confirm status change 1. Click on rule name 2. Review comprehensive information 3. Close modal when done ### Viewing Rules on scans You can view blocking rules that apply to your scans in two places: 1. On the scan details page, you'll see a "Blocking Rules" section showing all rules that were evaluated: 2. For individual issues, you can see which blocking rules were triggered in the issue details: This makes it easy to understand which rules are affecting your scans and specific issues, helping you identify why certain changes may be blocked. ## Examples **Rule Type:** Code Vulnerability Create a rule targeting CWE-326 (Inadequate Encryption Strength) and CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) with "Critical" urgency to prevent weak encryption usage. **Rule Type:** Code Vulnerability Select **Code Quality** as the issue type, then set up a rule for CWE-398 (Indicator of Poor Code Quality) and CWE-477 (Use of Obsolete Functions) with "Medium" urgency to maintain code standards. **Rule Type:** Dependency Vulnerability Create a rule with "Critical" and "High" urgency levels selected to automatically block any pull request that introduces dependencies with critical or high-severity vulnerabilities. This ensures your supply chain remains secure and prevents known vulnerable packages from entering your codebase. **Rule Type:** Dependency Vulnerability Create a rule that filters by CVSS score, such as 7.0 to 10.0, to block pull requests that introduce vulnerable dependencies within that score range. ## Best Practices * Start with essential rules and gradually expand * For **Dependency Vulnerability rules**, begin with Critical severity only or a focused CVSS range, then expand as your team adjusts * For **Code Vulnerability rules**, focus on the most impactful CWEs first (e.g., injection flaws, authentication issues) * Regular review and updates * Clear documentation and team training * Encourage feedback and collaboration * Strategic use of urgency levels * Consider project tags when the same rule should cover a group of related projects ## Troubleshooting If a pull request is unexpectedly blocked, verify the active rules and their configurations first. * Unexpected blocking behavior * Rule targeting issues * Project scope problems * Check rule configurations * Verify CWE targeting * Confirm project settings * Contact support if needed # Changelog Source: https://docs.corgea.app/changelog Product updates and announcements **UI & Experience:** * Fixed scheduled scan forms so project names, headings, selections, and summaries remain readable in both light and dark themes. — [Learn more](/scheduled-scans) * Improved page title alignment so subtitles and badges display consistently. **Reliability & Stability:** * Improved GitHub pull request scan reliability by preserving and retrying webhook events when background processing is temporarily unavailable. — [Learn more](/webhooks) * Improved IaC finding performance, reducing load times for scans with large result sets. **New Features:** * Added a Vulnerability Workbench with finding-type tabs, drill-down views, detailed drawers, filtered CSV exports, and bulk assignment and triage actions. — [Learn more](/false_positive) * Added CI-specific Blocking Rules that can be selected by rule ID, plus license-compliance rules for restricting dependency license families. — [Learn more](/blocking_rules) * Added read-only scan metadata across scan lists, scan details, issue views, API responses, and MCP results, with filtering for metadata keys and values. — [Learn more](/cli) **UI & Experience:** * Added pull request scan scope guidance to Scan Logs, clarifying that only files in the pull request are shown. * Added scanner-provided Fortify metadata to issue details, making uploaded findings easier to trace back to their source. — [Learn more](/upload-report) * Improved company notification settings by removing the ambiguous `Inherit` option. — [Learn more](/notifications) * Fixed project scan pagination so large scan histories no longer overflow the page. **Reliability & Stability:** * Improved large project deletion so projects with extensive scan history can be removed without disrupting the database. — [Learn more](/project) * Fixed SCA findings whose paths contain `tmp` so dependency tables and finding details continue to load correctly. — [Learn more](/sca) * Improved scan completion processing so pull request checks and SCA comments update more reliably during heavy activity. * Expanded webhook URL support for longer endpoints. — [Learn more](/webhooks) * Improved API scan attribution when no client source is supplied, and added clearer validation when report uploads do not include source code. — [Learn more](/api-reference/introduction) **New Features:** * Added dynamic team access based on project tags and repository URL fragments, so teams automatically gain access to matching projects. — [Learn more](/teams) * Added IaC and container scanning to scheduled scans, allowing teams to include infrastructure and container security checks in recurring scans. — [Learn more](/scheduled-scans) **UI & Experience:** * Fixed scan details controls and results so they refresh when a scan completes, making export and new scan actions available without reloading the page. **New Features:** * Added failure reasons and scanner-level errors to scan API responses, making incomplete or partially successful scans easier to diagnose. — [Learn more](/api-reference/introduction) **UI & Experience:** * Improved in-progress SCA and IaC results so available findings remain visible alongside accurate tab counts and scan status. — [Learn more](/sca) * Fixed the loading indicator shown during the final Dropsite upload step so its status text no longer spins. **Reliability & Stability:** * Improved pull request scanning by skipping binary files when building diff artifacts, preventing unsupported file content from interrupting scans. * Fixed bulk Content Access Management updates for large project and member selections, preventing request failures. — [Learn more](/content-access-management) * Improved dependency usage analysis so incomplete or oversized usage details no longer leave findings stuck in repeated triage attempts. — [Learn more](/sca) **New Features:** * Added agent-skill onboarding to the Add Project flow, with copyable commands for installing the Corgea scan skill in a project or globally. — [Learn more](/agentic_integrations) **UI & Experience:** * Improved Jira and Linear integration dialogs so error messages display clearly, clear when the dialog closes, and do not reappear when it is reopened. * Fixed the New Scan menu position on scan details pages so scan options appear directly below the button. **Reliability & Stability:** * Fixed SARIF exports so result identifiers conform to the SARIF schema and import reliably into compatible tools. — [Learn more](/issue_export) * Improved GitHub sign-in handling so email lookup failures show clear guidance, only verified email addresses are used, and organization sign-in requirements are applied consistently. * Fixed dependency usage analysis for findings with long file paths or many affected lines, so results are saved reliably. — [Learn more](/sca) * Fixed scan webhook delivery when pull request identifiers are numeric, so scan events continue to include the pull request context. — [Learn more](/webhooks) **New Features:** * Added a Linear integration, allowing teams to connect Linear and create tickets directly from vulnerability and dependency findings. — [Learn more](/linear) * Added issue-type filtering to code Blocking Rules, so teams can target vulnerabilities, code quality findings, or both. — [Learn more](/blocking_rules) * Added a self-service SSO group mapping editor, giving admins a guided way to map identity-provider groups to Corgea roles and project access. — [Learn more](/sso) * Added email alerts to project owners and company admins when a project fails the same scheduled scan three times in a row, and Corgea now skips that project on the schedule's automatic runs until a scan succeeds or you retry with Run Now. — [Learn more](/notifications#scheduled-scan-consecutive-failures) **UI & Experience:** * Added repository paths to scan lists and scan details, making similarly named repositories easier to distinguish across source-control providers. * Improved webhook configuration by keeping the webhook type selector visible and adding a human-readable message to event payloads. — [Learn more](/webhooks) **Reliability & Stability:** * Improved pull request fix suggestions for GitHub and GitLab so invalid suggestion ranges no longer produce syntax-breaking changes. * Fixed vulnerability report loading for large result sets, reducing timeout failures. **Reliability & Stability:** * Fixed Jira ticket creation for findings with long summaries, while preserving useful finding context in the ticket title. — [Learn more](/jira) * Expanded SAML group recognition for additional identity-provider attributes, improving group-based access assignment during sign-in. — [Learn more](/sso) * Fixed the Projects list so repositories with the same name remain distinct while duplicate entries for the same project are removed. **New Features:** * Added branded PDF exports for scan findings, with issue type and urgency filters, severity summaries, and direct links back to findings. * Added code quality findings to the API and MCP, so teams and connected assistants can list and inspect code quality results programmatically. — [Learn more](/modelcontextprotocol) * Added support for self-hosted GitLab instances, including custom hosts and an option to include accessible projects beyond the token owner's direct memberships. * Added commit SHA tracking and scan metadata for CLI scans, making it easier to identify prior results and avoid redundant scan work. — [Learn more](/cli) **UI & Experience:** * Streamlined onboarding into a guided connect-and-scan flow, added a sample project option, and improved upgrade guidance when a feature requires a different plan. * Added searchable assignee selection for code findings and fixed navigation when opening findings from issue views. * Added a user-selectable display timezone and improved consistency across forms, tables, filters, pagination, dialogs, and loading states. * Improved user administration with clearer account details, newest-first sorting, and compact team badges with a full team-membership view. * Updated project pages to prefer the latest full-project scan, preserving the most representative project-wide results. * Expanded repository URL support for longer source-control URLs. **Reliability & Stability:** * Improved SAML sign-in by matching email domains case-insensitively, supporting Duo Security metadata, and allowing first-time users whose identity-provider groups satisfy group restrictions. — [Learn more](/sso) * Improved GitHub Team Sync by matching members to Corgea users by email and handling member-fetch failures without clearing existing team membership. * Improved Azure DevOps pull request comments by bounding reply lookups, reducing delays on pull requests with large comment histories. — [Learn more](/azure_devops) * Improved GitLab project discovery with more efficient, retry-aware requests. * Fixed pagination totals so counts remain accurate after navigating beyond the final page. * Improved large scan result processing to reduce memory-related failures and retry temporary storage errors more reliably. * Improved MCP service stability by removing unsupported SSE endpoint handling. — [Learn more](/modelcontextprotocol) **New Features:** * Added scan coverage visibility for SAST and SCA, including skipped-file auditing, dependency resolution coverage, per-engine file status in Scan Logs, and processed-file progress while scans run. — [Learn more](/sca) * Added malicious dependency classification and Blocking Rules that can stop pull requests when known-malicious packages are detected. — [Learn more](/sca) * Expanded Advanced Vulnerability Search and exports to include SCA and IaC findings, and added filtered CSV export from the Dependencies dashboard. — [Learn more](/sca) * Enriched SARIF exports with finding guidance, security severity, policy taxonomies, call-graph context, fingerprints, and available remediation details. * Added Harness source-control integration provisioning through the API. **UI & Experience:** * Redesigned Policy Playground with a resizable editor and preview workspace, improved file and classification selection, persistent context, clearer loading states, and more useful test results. * Refreshed the Corgea interface with a more consistent design system across tables, forms, filters, cards, navigation, and empty states. * Improved scan details with a unified repository, branch, commit, and scan-type header, clearer lifecycle statuses, and dedicated errors and warnings visibility. * Added the current Corgea release version and a changelog link to User Settings. * Fixed incremental CLI scan code previews, diff viewer line alignment, scan auto-refresh tooltips, and duplicate script loading on project pages. * Improved AI Penetration Testing run controls to prevent accidental duplicate runs and keep page actions consistently positioned. **Reliability & Stability:** * Improved scheduled scans by preventing duplicate registrations, surfacing launch failures, and making Run Now reliably include eligible projects after older successful runs. * Improved Azure DevOps pull request scan handling when branches are deleted or commit lookups are unavailable. — [Learn more](/azure_devops) * Improved GitHub Team Sync for large organizations with rate-limit-aware processing, and fixed authentication edge cases during GitHub connection setup. * Fixed Bitbucket pull request comment retrieval after credentials expire, allowing refreshed credentials to be used without lingering failures. * Prevented case-variant repository names from creating duplicate projects and consolidated existing duplicates more safely. * Improved fix delivery, webhook notifications, and scan launch responsiveness during periods of heavy scan activity. **UI & Experience:** * Added reporting metrics for fixes generated and report-upload duplicates removed, giving teams clearer visibility into estimated hours saved through remediation support and duplicate-finding triage. **Reliability & Stability:** * Improved GitHub check-run updates so temporary GitHub server errors are retried more reliably when Corgea updates pull request checks. **New Features:** * Added AI Penetration Testing, giving teams autonomous external assessments with target management, live run visibility, finding revalidation, completion emails, and technical or executive PDF reports. * Added dependency inventory tools to the Corgea Agent, so teams can list dependencies and generate CSV export links directly from agent conversations. — [Learn more](/agentic_integrations) * Added comments to project file ignore rules and CWE filters, making it easier to document why project-specific exclusions exist and update those notes later. **Security & Permissions:** * Added proactive expired-credential detection and admin email notifications for GitLab, Azure DevOps, Bitbucket, and Harness integrations, helping teams renew tokens before scans and repository access are interrupted. **UI & Experience:** * Improved Security Review recommendations so pending and processing reviews refresh automatically as recommendations become available. * Added pagination to Content Access Management, improving load times and navigation for workspaces with many projects. * Fixed scan detail pages so the selected scan tab, dependency tab redirects, filters, and badges render cleanly before Alpine finishes loading. **Reliability & Stability:** * Improved GitHub Team Sync for large organizations by syncing teams in smaller background jobs, reducing timeouts during organization-wide syncs. * Improved Azure DevOps pull request diff handling so findings in edited files are matched against the scanned PR diff more accurately. * Improved source-control webhook handling for GitHub and Bitbucket, reducing noisy retry and comment-thread failures. * Fixed GitHub branch loading errors so repository branch fetch failures show the affected repository name correctly. **New Features:** * Added GitHub Team Sync to Content Access Management, so teams can provision Corgea teams, project access, and membership from GitHub organization teams. * Added Harness Service Account Token support, allowing Harness integrations to connect with SAT credentials as well as personal access tokens. * Added SCA as a Custom Security Scan option in the web app, CLI, and API, so teams can run dependency analysis as part of targeted scans. * Added multi-file data-flow click-through in issue details, making it easier to trace source-to-sink paths across related files. **Security & Permissions:** * Improved Policy Management access so project-scoped users can view and manage only the policies available to their projects, with clearer validation in Policy Center and Policy Playground. — [Learn more](/policies) * Changed policy deletion to preserve historical issue and fix references while removing deleted policies from active policy lists, scans, and API results. — [Learn more](/policies) * Improved user deactivation and group cleanup so project, team, and company permission group assignments stay consistent. **UI & Experience:** * Added scan type badges to scan details, making it easier to distinguish full scans, CLI scans, and pull request scans. * Improved static HTML scan reports so scan category tabs, SAST, SCA, IaC, code quality sections, and issue group views render without indefinite loading. * Fixed user group displays so the user table, detail drawer, CSV export, and group changes stay in sync. * Fixed scan attribution for API token-triggered scans so the scan shows the token owner's name instead of `Automated Run`. **Reliability & Stability:** * Improved pull request scan downloads across source control integrations by resolving archive downloads more reliably and gracefully skipping branches or commits that are no longer available. * Improved scheduled dependency scans so reachability status is included when SCA is selected. — [Learn more](/scheduled-scans) * Fixed personal-account GitHub scans so personal GitHub App installations resolve correctly for their owner. * Fixed policy selection consistency across scan execution, scan details, and policy APIs. — [Learn more](/policies) * Fixed source-sink analysis handling for malformed or empty data so affected issue views continue loading. * Improved Corgea Agent tracing reliability when trace access is unavailable. **New Features:** * Added multi-file taint analysis with click-through in issue Full View, so teams can follow cross-file data flows from source to sink without leaving Corgea. — [Learn more](/blast#reviewing-taint-analysis) **New Features:** * Added a Skills Registry, giving teams a versioned workflow for creating, reviewing, approving, and installing agent skills. * Added API access for policies, so teams can list, create, update, and deactivate policies programmatically. * Added SLA status filtering to Advanced Vulnerability Search, making it easier to find issues that are within SLA, overdue, or escalated. — [Learn more](/sla_management) * Added bulk actions to Content Access Management, so admins can add or remove members and teams, replace owners, and clean up inactive users across selected projects more efficiently. — [Learn more](/content-access-management) * Added editing for Jira integrations, allowing teams to update existing Jira connection details without recreating the integration. — [Learn more](/jira) **UI & Experience:** * Improved scheduled scan Run Now so scans start in the background and return users to the scan list while the scan begins. * Fixed issue detail previews so switching between findings shows the selected issue content instead of stale content. * Fixed Harness pull request scans so PR numbers and links appear consistently on scan views. * Fixed code quality scan views so plan-based access is applied consistently. **Reliability & Stability:** * Improved incremental full scans for projects with many issues or fixes, reducing scan processing slowdowns. * Improved SCA dependency parsing for Maven SBOMs so direct dependencies are classified more accurately. — [Learn more](/sca) * Improved scheduled scan create and edit flows for large project selections, reducing form submission failures. * Improved GitHub pull request checks and PR comments so check runs update more reliably and duplicate comments are reduced. * Improved pull request scan precision by ignoring lines changed only by formatting. * Improved large scan upload and ingestion reliability, reducing memory-related failures and returning clearer validation errors for missing scan run IDs. **New Features:** * Added branch filtering to Reporting, so teams can narrow vulnerability, SCA, IaC, code quality, and developer insight metrics to the branch they are investigating. * Added team scoping for company notification defaults, allowing admins to limit email notifications to selected teams while keeping webhook defaults separate. * Added direct repository file links in issue details, making it faster to jump from a finding to the affected file and line in source control. * Added pull request links to Agent feedback history, so teams can trace feedback entries back to the PR or merge request where they came from. **Security & Permissions:** * Blocked an additional disposable email domain during sign-up to reduce low-quality or abusive account creation. **UI & Experience:** * Improved the plan override admin widget so it renders cleanly in dark and light admin themes. * Improved expired integration messages for Azure DevOps, Bitbucket, and Harness scans, giving users clearer guidance to update the integration and retry. **Reliability & Stability:** * Improved issue selection, scan details, and scan list performance for workspaces with large issue volumes. * Fixed source-sink analysis handling when fix data needs to be generated on demand. **New Features:** * Added on-demand fix generation, so issues marked `On Demand` can generate a suggested fix when opened instead of waiting for fixes to be prepared ahead of time. — [Learn more](/fixes) * Added advisory details to SCA issue pages, making it easier to review the underlying security advisories behind dependency findings. **UI & Experience:** * Added severity filtering to IaC scan results, so teams can narrow infrastructure findings by Critical, High, Medium, or Low severity. * Added pull request links to the scans list, making it faster to jump from a PR scan back to the originating pull request. **Reliability & Stability:** * Improved GitHub retry handling so temporary GitHub rate limits and permission responses no longer hold scan workers for extended periods. * Fixed SLA Slack notifications so channel alerts are sent once per SLA event, retry more reliably, and handle Slack rate limits more gracefully. — [Learn more](/slack) **Reliability & Stability:** * Fixed Dropsite scan runs so teams can start scans from uploaded code or connected repositories more reliably. **Reliability & Stability:** * Fixed GitHub pull request scan handling for organization-owned GitHub App installations, so PR scans continue reliably when the installation is associated with a company instead of a specific user. **Reliability & Stability:** * Improved scan result ingestion reliability for large uploads, reducing memory-related failures during batch processing. * Improved GitHub pull request scan handling when GitHub temporarily returns missing PR data, so scans fail more gracefully and retry on the next push. **UI & Experience:** * Added quicker project tag editing from the Projects list, including an inline add action, cleaner chip overflow, and a themed typeahead for selecting existing tags. **Reliability & Stability:** * Fixed incremental scan handling when stored fix data is missing, so follow-up scans and reachability updates can continue without failing. **UI & Experience:** * Fixed Select All in scheduled scan project selection so teams can reliably select and deselect all eligible projects when configuring project-scoped schedules. — [Learn more](/scheduled-scans) **New Features:** * Added SCA support to SLA Management, so dependency findings can have remediation and escalation deadlines, assignees, due dates, status tracking, email summaries, and webhook alerts. — [Learn more](/sla_management) * Added daily scheduled scan reports for new findings, with notification preferences and webhook delivery controls for scheduled scan summaries. — [Learn more](/notifications) * Added Markdown support for Security Reviews, so pasted design documents and additional context render with richer formatting. **Security & Permissions:** * Added Security Review permissions to existing Admin permission groups, so admins can manage Security Review workflows without manual permission updates. **UI & Experience:** * Improved Reporting page developer feedback comments so longer comments are easier to view and recent feedback changes refresh more consistently. — [Learn more](/reporting) **Reliability & Stability:** * Fixed scheduled scan create and edit validation so unavailable scan types are hidden and rejected consistently. — [Learn more](/scheduled-scans) * Replaced legacy scan-complete alerts with the newer notification and webhook delivery model for scan and SLA events. — [Learn more](/webhooks) **New Features:** * Added Security Design Review beta support, giving teams a dedicated workflow for design-review analysis, recommendations, and security standards. * Added API and MCP access to Infrastructure-as-Code issues and dependency inventory, including filters for scan, project, repository, branch, severity, provider, package, license, and dependency type. — [Learn more](/modelcontextprotocol) * Added reachability details to issue APIs and MCP responses, helping teams and AI assistants prioritize findings based on reachable code paths. — [Learn more](/modelcontextprotocol) * Added repository, branch, and pull request ID filters to scan listing APIs and MCP, making it easier to find the exact scan behind a repository, branch, or PR. — [Learn more](/modelcontextprotocol) * Added auto learning for policy recommendations, so teams can review suggested policy improvements from product usage and feedback. — [Learn more](/policies) **UI & Experience:** * Improved PR rule tables with clearer project and tag chips, source-control icons, overflow tooltips, and better behavior on narrow screens. — [Learn more](/blocking_rules) * Improved plan-controlled feature updates so access changes from plan overrides take effect immediately after they are changed. * Fixed manual full-scan triggering for affected source-control projects, with clearer repository selection feedback while scans start. **Security & Permissions:** * Fixed SCIM-provisioned users so they are assigned to the SAM Default group when created. **Reliability & Stability:** * Improved SBOM processing reliability by preventing repeated generation loops when processing cannot complete. * Improved batched API ingestion reliability to reduce database contention during large scan result uploads. **Reliability & Stability:** * Fixed Blocking Rule create and edit workflows so selected projects, project tags, and classifications are saved and shown consistently. — [Learn more](/blocking_rules) * Fixed Scan & Comment Rule create and edit workflows so selected projects, project tags, classifications, and integrations are preserved reliably. — [Learn more](/policies) **New Features:** * Added scheduled scan filters for webhooks, so teams can subscribe endpoints to scan events from specific scheduled scans instead of receiving every scan event. — [Learn more](/webhooks) **UI & Experience:** * Improved scheduled scan editing by showing the projects already selected for a schedule, making it easier to review, remove, or clear selected projects. * Improved issue fix downloads so download actions only appear when a suggested fix is ready, reducing confusion for issues without an available fix. — [Learn more](/fixes) **Reliability & Stability:** * Improved SCA pull request comments so they show direct or transitive dependency context and focus on dependency findings tied to files touched in the pull request. * Optimized the Projects page so larger workspaces load local projects faster while remote repository data refreshes separately. * Improved code scan issue cleanup to reduce duplicate active findings in scan results. **Scanning Engine Improvements:** * Improved scan summaries so results are clearer and more consistent. * Expanded code analysis coverage for additional languages, improving issue detection and false-positive identification. * Reduced duplicate secret scan findings for cleaner results. **Reliability & Stability:** * Improved dependency scan reliability by preventing repeated retries when a scan cannot continue. * Fixed dependency issue triage reporting so unsuccessful triage attempts are reflected correctly. * Improved engine dependency handling for more consistent scan execution. **New Features:** * Added project tag scoping for Blocking Rules, so teams can apply pull request blocking policies to tagged groups of projects without maintaining long project lists. — [Learn more](/blocking_rules) * Added project tag scoping for Scan & Comment Rules, so teams can control PR scan behavior across tagged project groups more easily. — [Learn more](/policies) * Added options in Advanced Vulnerability Search to include issues marked as false positives by status or fix status when those results need to be reviewed. * Added Harness pull request links on PR scans, making it easier to jump from a Corgea scan back to the originating Harness PR. **UI & Experience:** * Improved PR rule setup with clearer field tooltips, direct documentation links, better tag-based rule counts, and Critical/High selected by default when adding new PR rules. — [Learn more](/policies) * Improved scan download controls so CSV, SARIF, SBOM, and dependency exports are disabled until scan processing completes, with clearer guidance when downloads are not ready. **Reliability & Stability:** * Improved policy retrieval so prework-generated policies are included where applicable, keeping policy review and dependency policy views consistent. — [Learn more](/policies) * Fixed Bitbucket PR comment handling so Corgea recognizes hyphenated bot mentions correctly. * Improved source-control project selection error messages when an integration is unavailable or cannot be reached. * Improved project creation and deletion cache handling so plan limits and repository lists update more consistently after project changes. * Improved production asset cache busting so updated JavaScript, CSS, animations, and email assets load reliably after deployments. **Scanning Engine Improvements:** * Enhanced secret scanning accuracy with improved context analysis, reducing false positives while maintaining comprehensive coverage * Upgraded endpoint discovery engine for better API detection and call graph analysis * Improved SBOM generation reliability and accuracy across multiple package managers * Enhanced language detection for secret scanning with support for additional file extensions **Performance & Reliability:** * Optimized batch processing for large-scale scans, improving throughput for enterprise environments * Enhanced error handling and recovery mechanisms for more robust scan execution * Improved memory efficiency for processing large codebases * Better handling of incremental vs full scan detection logic **Bug Fixes & Maintenance:** * Fixed issues with scan metadata reporting and GPT error breakdown tracking * Resolved edge cases in file processing that could cause scans to fail * Improved parent dependency false positive checking * General stability improvements and performance optimizations **UI & Experience:** * Fixed repository selection for workspaces where Harness is the only connected source control integration, so Harness repositories now appear correctly when creating or selecting projects. — [Learn more](/harness) **New Features:** * Added Harness Code integration support, so teams can connect Harness repositories, run pull request scans, receive Corgea comments and status checks, and create fix pull requests directly in Harness. — [Learn more](/harness) **UI & Experience:** * Added Git service icons to Content Access project selection, making it easier to distinguish GitHub, GitLab, Azure DevOps, Bitbucket, and local projects. * Fixed code highlighting in false-positive explanations so inline code renders clearly and safely in issue details. * Improved scan log file path display and added Scan ID filtering to Advanced Vulnerability Search for more precise scan investigation. **Reliability & Stability:** * Improved agent pull request comment handling so Corgea responds more accurately to direct mentions and replies while avoiding comments intended for teammates. * Corrected duplicate project detection so repositories with the same name in different namespaces are no longer treated as duplicates. * Improved GitHub retry behavior for transient server and rate-limit responses. **New Features:** * Added cross-project dependency management so teams can review approved dependencies and automated suggestions across projects. **Reliability & Stability:** * Improved full-incremental scans so copied issues preserve detection history, keeping issue timelines consistent across follow-up scans. **New Features:** * Added CVSS score range support for dependency blocking rules, so teams can block SCA findings by precise score ranges instead of severity alone. — [Learn more](/blocking_rules) **UI & Experience:** * Improved issue debug details by showing when a dependency false-positive policy was applied, making policy-driven triage easier to understand. **Reliability & Stability:** * Improved file ignore rule enforcement so ignored paths are consistently excluded when new issues are created. * Improved SBOM processing so dependency relationships are parsed more reliably from stored CycloneDX data. — [Learn more](/sca) * Improved batch API reliability for issue and scan file-log ingestion, reducing contention during large scan result uploads. **Reliability & Stability:** * Improved upgrade reliability for issue analysis tracking data, reducing migration risk when moving to this release. **New Features:** * Added Fortify FPR upload support for third-party scan imports. * Added SCA dependency-type visibility for dev and optional dependencies, including filters, badges, issue details, and CSV exports. — [Learn more](/sca) **UI & Experience:** * Improved scan list counts by separating code issues from dependency issues and keeping dependency-only scans visible when filtering out empty scans. * Improved scan policy visibility so policies applied to a scan remain visible even when older or archived versions were used. * Fixed IaC scan cards so Critical counts display correctly. * Fixed sidebar account-menu behavior so users can reliably open account actions and log out. **Reliability & Stability:** * Improved scan ingestion performance and reliability with batch handling for SCA issues, IaC issues, and scan file logs. * Improved SCA result deduplication and lookup performance to reduce duplicate findings during high-volume scan processing. — [Learn more](/sca) * Improved scan API resilience so deleted scans and Rootly heartbeat timeouts no longer cause avoidable server errors. **UI & Experience:** * Improved the Dependencies page by making the “Scans Affected” count clickable, opening a detailed modal with affected scans, detection dates, and direct vs. transitive dependency context. * Improved SCA results visibility with clearer direct/transitive dependency indicators in scan results and package group summaries. * Improved SCA issue details with sub-dependency count visibility for affected packages. **UI & Experience:** * Fixed scheduled scan scope tab switching so Projects, Project Tags, and Teams tabs open correctly during schedule setup. **Reliability & Stability:** * Increased supported security-pattern file path length so long paths are stored correctly. **UI & Experience:** * Fixed scheduled-scan scope tab switching so changing between Projects, Tags, and Teams consistently shows the correct targeting options. **UI & Experience:** * Fixed an issue where Teams did not appear on the Scheduled Scan creation page, so team-scoped schedules can now be configured reliably. **UI & Experience:** * Improved Policies page filtering and search usability, including support for searching policies by ID. **Reliability & Stability:** * General bug fixes and performance improvements. **New Features:** * Added team-based scheduled scan targeting, so you can schedule scans for all projects assigned to selected teams. * Added support for Corgea-managed read-only policies, including clearer handling for immutable default policy workflows. **Security & Permissions:** * Fixed service-principal JWT authentication for Blocking Rules API requests. — [Learn more](/jwt-token) * Improved Entra JWT issuer handling by normalizing missing trailing slashes in issuer configuration, reducing token-validation setup errors. — [Learn more](/jwt-token) * Fixed a SAML provider compatibility issue that caused sign-in failures for affected SSO configurations. **UI & Experience:** * Fixed issue details metadata presentation by removing incorrect query-name fallback values. * Fixed issue details rendering regressions so explanation and fix content display reliably. * Fixed First Detected timestamps so issue views and issue APIs now reflect the true first detection time. **Reliability & Stability:** * Improved pull request scan behavior by superseding older pending scans when many commits arrive quickly, so the latest commit scan is prioritized. * Fixed scheduled-scan execution reliability by correcting cron command path handling and ensuring next-run calculation updates after schedule changes. **Security & Permissions:** * Expanded domain-level registration restrictions to cover additional domains and their visually similar homograph variants as part of ongoing abuse prevention controls. **UI & Experience:** * Fixed scheduled scan list day-of-week display so weekly schedules now show the correct weekday. — [Learn more](/scheduled-scans) **UI & Experience:** * Fixed sidebar account-menu display for users with long names, so profile names no longer overflow or crowd navigation controls. **New Features:** * Added filtering on the Policies page so teams can narrow large policy lists faster by relevant criteria. — [Learn more](/policies) * Added scan-type scoping for scan responses, so API consumers can request only the scan categories they need. **UI & Experience:** * Added policy-page access enforcement based on content access controls, so users only see policy data for projects they can access. — [Learn more](/policies) * Added policy and scan-settings permission gating so users without `change_project` access no longer see or can open restricted project-setting controls. — [Learn more](/project) * Fixed code-quality CSV/SARIF export behavior and improved filter dropdown spacing for a cleaner export and filtering workflow. — [Learn more](/issue_export) **Reliability & Stability:** * Improved SBOM handling by shifting parsing to background workers, reducing request-path load during scan processing. * Improved CI SCA reporting to focus on packages changed in the pull request, reducing dependency-noise in automated results. * Fixed scan attribution so automation-triggered runs are consistently labeled as automation. * Improved scheduled-scan timing so runs respect each schedule's local timezone. — [Learn more](/scheduled-scans) * Improved GitHub webhook ingestion to handle unsupported Unicode payload edge cases more safely. * Improved SSO compatibility for strict XML-validation provider configurations. **UI & Experience:** * Improved SAML setup with a more guided configuration form, including ready-to-copy IdP URLs and one-click metadata fetch/populate support for core SAML fields. **Reliability & Stability:** * Improved SAML sign-in compatibility by falling back to NameID when email attributes are not provided by the identity provider, reducing failed login scenarios for affected SSO configurations. **New Features:** * Enabled incremental scans by default for all organizations, so new and existing workspaces get faster follow-up scan coverage automatically. * Expanded Policy Playground workflows so teams can open supported policies directly in Playground, edit and version them in-place, and scope policies with file glob patterns. — [Learn more](/policies) **UI & Experience:** * Improved login behavior so already authenticated users are redirected directly to the Projects page. * Improved profile administration with company auto-complete on profile edits, including clearer company ID selection behavior. **Reliability & Stability:** * Improved CLI upload compatibility for repositories without configured integrations, reducing avoidable upload/prework flow failures. * Improved policy editing stability with clearer no-change handling during Playground-based policy updates. * General bug fixes and performance improvements. **Reliability & Stability:** * Improved prework scan handling so standard scan selection consistently excludes prework-only and policy-playground scans, reducing incorrect scan context in scan views. — [Learn more](/policies) * Improved API request tracking coverage for versioned endpoints to provide more consistent monitoring visibility. * General bug fixes and performance improvements. **New Features:** * Added policy-generation prework runs from the Policies page, so teams can trigger targeted policy generation directly from the UI. — [Learn more](/policies) **Security & Permissions:** * Added OAuth2 JWT bearer authentication with service-principal permission mapping for API access, enabling secure machine-to-machine workflows without user-bound API keys. — [Learn more](/jwt-token) **UI & Experience:** * Improved Service Principal setup guidance for Entra and Okta token configuration, including clearer issuer/audience/application ID instructions. — [Learn more](/jwt-token) * Improved prework-only scan presentation with clearer scan naming and prework-focused status messaging in scan views. **Reliability & Stability:** * Improved full-scan performance for integration-backed repositories, reducing end-to-end scan time in supported cases. * General bug fixes and performance improvements. **New Features:** * Added JIRA ticket creation directly from SCA issue details, including quick access to created ticket links for faster dependency-vulnerability triage. — [Learn more](/jira) **Reliability & Stability:** * General bug fixes and performance improvements. **New Features:** * Added project-level filtering in Content Access so teams can quickly narrow access reviews to a specific project. * Added scan trigger-source tracking for CLI and IDE initiated scans, improving visibility into how scans are launched and which client tools are being used. — [Learn more](/cli) * Added Checkmarx `Path Id` visibility in issue details to improve triage context for scanner-specific findings. **UI & Experience:** * Improved the scan comparison experience with custom scan labels, richer false-positive visibility, and new filters for reachability and hold-reason changes. **Reliability & Stability:** * Improved pull request diff handling so legitimate findings are less likely to be skipped in automated commenting, including better Bitbucket diff coverage. * Fixed add-issue flow failures when pull request file metadata is unavailable. * Improved policy API error handling and validation, including better project-based policy retrieval behavior and clearer invalid-input responses. — [Learn more](/policies) **New Features:** * Added scanner metadata to issue API responses, including normalized custom scanner fields, so teams can preserve third-party scanner context during triage. — [Learn more](/api-reference/introduction) * Added scan-scope filtering for issues APIs by scan type and triggering user, so issue listings reflect the latest matching scan instead of defaulting to unrelated scan runs. — [Learn more](/api-reference/introduction) * Added support to reconstruct source ZIPs for third-party scanner workflows, improving recovery and reprocessing for uploaded scans. — [Learn more](/upload-report) **UI & Experience:** * Improved scan policy issue links and counts so false-positive and fix policies open directly to the associated filtered issue views for the selected scan. — [Learn more](/policies) **Reliability & Stability:** * Improved scan pipeline throughput by allowing prework and scan processing to run in parallel, reducing queue delays. * Fixed content access exports so project access CSVs include complete user/team coverage and explicit entries for projects with no assigned access. **New Features:** * Added company domain join controls so organizations can allow users with matching business email domains to join automatically. — [Learn more](/sso) * Added CWE ignore glob pattern support, so teams can scope ignore rules to specific file paths instead of applying them globally. — [Learn more](/policies) **UI & Experience:** * Improved scan filtering with clearer labels, better layout fit, and added scanner options. * Improved issue details and scan details behavior, including clearer file path display and better filter isolation across tabs. **Security & Permissions:** * Added dedicated reporting access control, so reporting pages are now gated by a specific reporting permission. **Reliability & Stability:** * Improved webhook delivery and redelivery reliability to reduce duplicate or missed webhook events. — [Learn more](/webhooks) * Fixed SCIM user provisioning idempotency to prevent duplicate-key failures when the same user payload is sent more than once. — [Learn more](/sso) * Improved prework scan eligibility handling and related company-setting defaults for more predictable scan behavior. * Improved stale CI scan cancellation reporting for better operational visibility. **New Features:** * Added policy guidance notes, so teams can attach internal instructions that appear directly in related issue details. * Added prework-driven policy generation controls, including optional review behavior before generated policies are activated. **UI & Experience:** * Improved scan page filtering with reorganized controls and cleaner interactions. * User search now works globally across all pages instead of only filtering the currently visible page. **Reliability & Stability:** * Improved webhook receiver reliability and delivery handling for more consistent event processing. — [Learn more](/webhooks) * Added safer issue/query limits for heavy search, export, blocking-rule, and scan comparison flows to reduce out-of-memory failures. * Improved GitHub integration resilience with custom retry behavior for transient API failures. * Updated policy API versioning behavior so newly updated policies are versioned cleanly while older active versions are archived. * Improved handling when duplicate projects are detected during project lookup to reduce incorrect matching issues. **New Features:** * Added customizable webhook request body templates with safe placeholder support, giving you more control over webhook payload formats. — [Learn more](/webhooks) **UI & Experience:** * Reachability details are now shown only for direct dependencies, reducing noise when reviewing transitive SCA findings. — [Learn more](/sca) **Security & Permissions:** * Improved SAML onboarding and group sync behavior, including fixes for SAML config registration, first-login redirects, and consistent team naming from incoming SAML groups. **Reliability & Stability:** * Improved GitLab integration resilience by handling transient connection resets more reliably. — [Learn more](/gitlab) * Reduced unnecessary integration error logging for cleaner operational visibility. **Security & Permissions:** * Improved authentication flow to prevent unauthorized redirects. — [Learn more](/cli) **Reliability & Stability:** * Fixed an edge case where SCA triage updates could fail to save in certain scenarios. — [Learn more](/sca) * Improved reliability of SAML group sync and group mapping behavior. * Routine dependency updates. **New Features:** * Added project tag management through the Projects API, plus `repo_url` filtering/support in project responses for easier project automation workflows. — [Learn more](/project) * Added CVSS scores to SCA issues API responses to help prioritize dependency vulnerabilities more accurately. — [Learn more](/sca) **UI & Experience:** * Fixed the JIRA ticket modal trigger on issue details pages for a more reliable ticket creation flow. * Improved navigation bar behavior and responsiveness across layouts. **Security & Permissions:** * Hardened user group APIs to prevent vertical privilege escalation and improve access safety. — [Learn more](/permission_groups) **Reliability & Stability:** * Scan upload API now returns a clear `400` error when required fields are missing, improving API feedback for failed uploads. — [Learn more](/upload-report) * Improved scan operations with manual scan triggering support for timeout recovery scenarios. * Fixed vulnerability aging report errors to ensure the page loads reliably. * Included missing database migrations and resolved migration conflicts for smoother upgrades. * Improved test execution throughput and coverage reporting to support release stability. **New Features:** * Added SBOM (Software Bill of Materials) generation and dependencies view for better visibility into your project components. * Enhanced vulnerability filtering with the ability to filter SCA dependency vulnerabilities by criticality in the scan view. **UI & Experience:** * Improved user interface elements for a better experience. * Fixed various button interactions and display issues. **Reliability & Stability:** * Resolved CLI and IDE integration issues to ensure proper connectivity. * Enhanced security detection capabilities with expanded vulnerability coverage. * General bug fixes and improvements for better stability. **Developer Tools:** * Updated change log pipeline for improved release documentation. **New Features:** * Added support for Coverity integration to expand security scanning capabilities. * Introduced self-service billing management for easier subscription control. * Enhanced feedback system to track and display AI agent response history. **UI & Experience:** * Improved project navigation when accessing Projects from the Teams page. * Enhanced dependency filtering to help you better manage project dependencies. **Reliability & Stability:** * Improved error handling and logging for better system stability. * General bug fixes and performance improvements. **New Features:** * Added project filter to dependencies view for easier navigation and management * Added Reachable toggle for endpoint findings filters to help prioritize security issues **UI & Experience:** * Fixed Policy Playground line highlighting issue after security scans * Improved code review diff parsing for better accuracy in change detection **Reliability & Stability:** * General bug fixes and improvements **New Features:** * Added AI-powered Software Composition Analysis (SCA) for enhanced dependency scanning. * Implemented user login audit logs for improved security monitoring. * Added webhook support for user-related events with asynchronous processing. * Enhanced reporting capabilities with additional metrics and insights. **Integrations:** * Improved Azure Repos integration with better URL mapping support. * Fixed SAML group synchronization for more reliable identity management. **UI & Experience:** * Improved color contrast for better accessibility and readability. * Updated styling for ticket and pull request creation workflows. * Enhanced issue filtering functionality to work more reliably. * Fixed logs page to auto-refresh automatically. * Resolved text display issues throughout the interface. **Security & Permissions:** * Enhanced authorization controls for project management operations. * Improved role-based access control (RBAC) enforcement for API operations. * Standardized group permission handling for consistent behavior. **Reliability & Stability:** * General bug fixes and performance improvements. * Enhanced test coverage for better system reliability. **New Features:** * [Added SCIM Token visibility](/sso#sso-scim-provider-configuration) in the SSO configuration modal for easier identity management setup. **Reliability & Stability:** * Improved scan tracking and pull request monitoring with enhanced timeout handling. * General bug fixes and performance improvements. **Documentation:** * Enhanced automated documentation generation for better resource availability. **New Features:** * Added support for Glob Pattern configuration in policies, now accessible through the user interface * Introduced API grouping support for better organization and data management * Added Agent integration support for Azure DevOps **UI & Experience:** * Enhanced dependency view data loading for improved performance * Improved rendering of tables in security findings markdown display * Enhanced email validation during sign-up process **Bug Fixes:** * Fixed issue where duplicate projects could be created under certain conditions * Resolved false positive feedback form submission issues * Fixed database migration issues affecting permissions **Reliability & Stability:** * Optimized database queries with new indexing for better performance * General bug fixes and improvements for enhanced system stability **New Features:** * Enhanced webhook notifications now include a summary of scan findings for easier integration and monitoring. **UI & Experience:** * Improved clarity for Software Composition Analysis (SCA) issues caused by auto-generated lock files. * Enhanced the issue detail view page for better readability of SCA findings. * Policy-only scans now properly display all skipped items for better visibility. **Reliability & Stability:** * General bug fixes and improvements for enhanced application stability. **New Features:** * Added project-tag search capability across all search fields in Zapier integration * Introduced new API to retrieve projects programmatically * Added feedback link for issues **UI & Experience:** * Updated code vulnerability side panel to match the improved SCA (Software Composition Analysis) design * Fixed double search bar display issue in the dependencies tab * Resolved rendering issues where some SCA issues appeared without titles **Security:** * Enhanced content security enforcement on the dependencies page * Implemented authentication improvements for critical functions * Strengthened authorization controls to prevent bypass vulnerabilities * Applied additional security hardening measures **Reliability & Stability:** * Improved PR comment formatting for quality scanner results * Enhanced issue history tracking and fingerprinting * Resolved multiple error conditions reported through monitoring * Fixed development environment setup issues * Improved logging for better troubleshooting and diagnostics * General bug fixes and performance improvements **Reliability & Stability:** * Improved system logging and error tracking for better monitoring and diagnostics. * General bug fixes and performance improvements. **New Features:** * Added SAML group import and configuration for enhanced team access control. * Added support for filtering issues by branch. * Introduced new permissions for updating issue status. * Added pull request search filtering on scan page. **UI & Experience:** * Improved issue quick view for better usability. * Enhanced the fix debug section with clearer documentation. * Fixed back button navigation on issue pages when changing decisions. * Resolved pagination issues for the issues list. * Fixed double scrollbar issue in Advanced search. * Improved diff viewer performance and loading behavior. **Scanning & Code Quality:** * Code quality scans are no longer enabled by default on full scans. * Enhanced scanning logs for better visibility and diagnostics. **Reliability & Stability:** * Fixed SAML metadata endpoint access issues. * Resolved SAML SSO issue that could create duplicate companies. * Improved GitHub integration compatibility. * General bug fixes and performance improvements. **Bug Fixes:** * Resolved an issue where Infrastructure as Code (IaC) scan results were not displaying correctly for users. **Improvements:** * Enhanced overall system stability and performance. **New Features:** * Added support for enhanced Checkmarx integration with improved scan metadata tracking. * Enabled large SAST scan file upload capability through the CLI for better handling of comprehensive security scans. **Reliability & Stability:** * Improved performance and handling of large security scan uploads. * General bug fixes and improvements. **Bug Fixes:** * Fixed an issue with the false positive filter not working correctly on the new scan page. **UI & Experience:** * Scan view now defaults to showing only open issues for easier issue management and improved focus on active security concerns. **Reliability & Stability:** * Resolved database integrity issues to improve data consistency and application stability. * General bug fixes and improvements. **New Features:** * Added the ability to cancel scans in progress, giving you more control over your workflow. **Reliability & Stability:** * Resolved database migration conflicts for improved system stability. * General bug fixes and performance improvements. **New Features:** * Added direct dependencies filtering option with new UI controls * Enhanced issue filtering capabilities for MCP server and agent * Improved Azure repository integration with custom rules for better project identification * Added Infrastructure as Code (IaC) support **UI & Experience:** * Refreshed scanner page design for improved usability * Updated integration page with consistent styling and expiration indicators **Performance:** * Optimized advanced search queries for faster results **Reliability & Stability:** * General bug fixes and improvements * Enhanced system stability and performance **Improvements:** * Enhanced admin interface compatibility and performance. * General bug fixes and stability improvements. **Bug Fixes:** * Fixed an issue with advanced search default scan type settings. * Resolved errors in GitHub webhook processing to ensure reliable integration. * General bug fixes and stability improvements. **Reliability & Stability:** * Enhanced error handling for improved system reliability. * Performance optimizations and backend improvements. **Search Improvements:** * Fixed an issue with advanced search when using the false positive filter, ensuring more accurate search results. **Reliability & Stability:** * General bug fixes and improvements to enhance platform performance. **New Features:** * Added filter view for better organization and navigation. * Introduced the ability to add teams to projects and projects to teams for improved collaboration. * Added exclude button for scanning to give you more control over what gets scanned. **UI & Experience:** * Project names and repository URLs are now case-insensitive for easier management. **Reliability & Stability:** * Improved error handling for GitLab integrations. * Enhanced user creation process for better reliability. * Improved logging for Bitbucket authentication issues. **Improvements:** * Enhanced cookie handling for better session management and security. * General bug fixes and performance improvements. **UI & Experience:** * Improved the SCA (Software Composition Analysis) page display and functionality. * Added cookie consent management for better privacy controls. **Reliability & Stability:** * General bug fixes and improvements for enhanced application performance. **Integrations:** * Improved Jira ticket creation visibility - tickets are now accessible regardless of fix status. **Reliability & Stability:** * Enhanced system performance and stability. * General bug fixes and improvements. **Performance & Monitoring:** * Enhanced application performance monitoring with improved latency tracking capabilities. **Reliability & Stability:** * Resolved issues to improve overall system stability and reliability. * General bug fixes and improvements. **UI & Experience:** * Redesigned the clear filters button for a cleaner, more intuitive interface * Removed confidence filtering from the UI to streamline the issue management workflow **Performance & Reliability:** * Improved performance when adding new issues to your dashboard * General bug fixes and stability improvements **Reliability & Stability:** * Improved logging and system diagnostics for better performance monitoring. **Reliability & Stability:** * Improved status update handling to prevent errors in edge cases. * Enhanced data processing reliability. **New Features:** * Added export functionality for advanced vulnerability search results. **Security & Authentication:** * Enhanced token security with encryption and expiration management. * Improved password reset validation to support additional special characters. **Reliability & Stability:** * Resolved issue creation errors and improved system performance. * General bug fixes and improvements for enhanced stability. **New Features:** * Added [Bitbucket integration support](bitbucket) for seamless workflow automation with your Bitbucket repositories. **Reliability & Stability:** * General bug fixes and performance improvements. **New Features:** * Added Quick View for viewing security issues with improved navigation * Introduced Dependency Vulnerability Details page for comprehensive vulnerability analysis * Added markdown support for enhanced documentation and formatting * New filter to display only scans with identified issues * Enhanced policy configuration with support for [append instructions](policies#policy-structure) * Improved scanner timing metadata for better performance tracking **UI & Experience:** * Enhanced vulnerability search with loading indicators for better user feedback * Fixed sticky navigation and centered navigation buttons for improved layout * Reorganized scan display with better prioritization of top issues * Added date information to scan history expansion view * Improved navigation layout and responsiveness **Team & Access Management:** * Enhanced webhook functionality to include user comments from issue history **Pull Request Improvements:** * Deactivated PR rules can now be reactivated as needed * SCA (Software Composition Analysis) issues on PRs are now properly sorted **Reliability & Stability:** * Improved error messaging for SAML authentication issues * Enhanced handling when fix summaries are unavailable * Quality scanner enhancements for more reliable results * General bug fixes and performance improvements **New Features:** * Added advanced vulnerability search capability to help you find and filter security issues more efficiently. * Introduced intelligent false positive detection to reduce noise in your security findings. **UI & Experience:** * Enhanced pagination controls now properly maintain your selected filters as you navigate through pages. * Streamlined and optimized the user interface for better performance. **Integrations:** * Improved Azure DevOps integration performance for faster and more reliable operations. **Reliability & Stability:** * General bug fixes and performance improvements across the platform. * Backend optimizations for enhanced stability. **New Features:** * Enhanced dependency filtering capabilities for better project management. **Integrations:** * Improved Azure DevOps integration with better handling of pull request differences. **Reliability & Stability:** * Fixed filtering functionality to ensure consistent behavior. * General bug fixes and performance improvements. **New Features:** * Scheduled scans are now enabled by default for all projects. * Added filtering capabilities for scheduled scanning to help you manage your scan configurations. * Introduced support for container scanning (only available per request). * Enhanced project tagging functionality for better organization. **Improvements:** * Improved scheduled scan editing experience on initial load. * Enhanced GitLab scheduled scan integration to properly detect branch names. * Better handling of tag management in scheduled scans. **UI & Experience:** * Fixed font rendering issues in SCA (Software Composition Analysis) views. * Resolved layout display issues in SCA interface. **Reliability & Stability:** * Fixed several issues with scan error handling and API responses. * Improved content access management workflows. * General bug fixes and performance improvements. **Bug Fixes & Improvements:** * Resolved an issue with editing scheduled scans to ensure configuration changes are properly saved. * Improved text formatting and structure in policy descriptions for better readability. **Improvements:** * Enhanced repository connection reliability and error handling. * Improved PolicyIQ feature accessibility across different plan types. **Bug Fixes:** * Resolved credential validation issues when accessing repositories. * Fixed plan verification logic for PolicyIQ features. **New Features:** * Added [blocking rules capability to Software Composition Analysis (SCA)](/blocking_rules#rule-types) for enhanced security control. **Reliability & Stability:** * General improvements and bug fixes for better platform performance. **Authentication & Access:** * Improved SAML login group validation for more reliable authentication. **Reliability & Stability:** * Enhanced version comparison logic for software composition analysis. * General bug fixes and performance improvements. **New Features:** * Added ability to edit SAML configuration settings for enhanced authentication management. **Reliability & Stability:** * General improvements and bug fixes to enhance platform stability. **Authentication & Access:** * Enhanced Single Sign-On (SSO) authentication with improved group-based access controls and configuration options. **Reliability & Stability:** * General bug fixes and improvements for enhanced system performance. **New Features:** * SCA license information is now optional, giving you more flexibility in compliance workflows. * Email addresses are now automatically normalized to lowercase during sign-up and registration for consistency. **Access Control Improvements:** * Admin users now have full access to all projects, even when access controls are enabled. * Enhanced content access control functionality across the platform. * Resolved issues with access control permissions not applying correctly. **Integrations:** * Improved Azure DevOps integration to handle pull request links more gracefully. * Fixed GitLab comment posting functionality. * Enhanced error handling for git operations. **Bug Fixes & Improvements:** * Fixed counting accuracy issues in reporting. * Resolved performance issues in dependency analysis. * General stability improvements and bug fixes. **Integrations:** * Enhanced third-party scanner integration support for improved compatibility. **Authentication & Security:** * Improved Single Sign-On (SSO) authentication flow for better reliability. **Reliability & Stability:** * General bug fixes and improvements for enhanced system performance. **New Features:** * Added support for scheduled scans on remote projects that haven't been fully onboarded yet. **Reliability & Stability:** * Resolved security vulnerabilities to improve application safety. * General bug fixes and improvements for enhanced stability. **Authentication & Security:** * Improved Google authentication and single sign-on experience. **UI & Experience:** * Enhanced pagination controls for easier navigation through content. * Improved project selection in scheduled scan settings. **Reliability & Stability:** * General bug fixes and performance improvements. **New Features:** * Added dropdown menu to PR rule management page for easier configuration. **UI & Experience:** * Enhanced CSV export functionality for SAST findings with additional data fields. * Improved project search functionality on content access page. **Reliability & Stability:** * Fixed issues with pull request commenting to prevent duplicate comments. * Resolved project lookup errors that could occur in certain scenarios. * Improved endpoint discovery processing for more accurate results. * General bug fixes and performance improvements. **New Features:** * Added CVSS scoring display for dependency vulnerabilities to help you better assess risk levels. * Introduced webhook subscriptions for automated workflow integrations. * Added support for multi-select projects in content access management for easier permission configuration. **UI & Experience:** * Restored code view in advanced search functionality. * Improved classification display for long security issue names. * Enhanced permission management with an improved checkbox experience. * Refreshed user interface on the users page for better clarity. * Added fix date tracking and improved related UI elements. **Reliability & Stability:** * Fixed issue tracking to properly handle cases where previously fixed issues are detected again. * Improved fix history management - previous fixes are now automatically archived when new fixes are added. * General bug fixes and performance improvements. **New Features:** * Added new [Teams](teams) & [Content Access Controls](content-access-management) for project-level access. **UI & Experience:** * Improved several interface elements for a smoother workflow. * Fixed issues with "Add Group" buttons not responding as expected. **Reliability & Stability:** * Updating pull-request status will no longer interrupt or fail a running scan. **Developer Workflow Enhancements:** * Automatically sets a default branch when no current branch is detected to ensure uninterrupted scanning and smoother onboarding. **New Defaults & Onboarding:** * New AI-native SAST scanner version **UI Improvements:** * Added export functionality on the user list page. * General UI refinements to improve clarity and consistency. **Integrations & Reliability:** * Fixed an issue causing file fetch failures for Azure DevOps repositories. **General Improvements:** * Minor formatting and maintenance updates for overall stability. **New Features:** * Introduced the Corgea Agent, enabling expanded automation and improved scan workflows. **Access Control:** * Added new permissions for the Integrations page, giving administrators more granular control. **Notifications & UI:** * Improved notifications for assigned issues. * Additional UI fixes to ensure a smoother user experience. **Developer Workflow:** * Improved logic for handling PR updates and fallbacks when commit data is missing. **General Improvements:** * Overall reliability enhancements and background maintenance. **Improved UI & Developer Experience:** * Refined the width of the user detail slide-out for a cleaner layout. * Enhanced filter controls and applied several UI polish updates across the platform. * Corrected the "View More Details" link in check-run views for smoother navigation. * Improved the Azure DevOps experience by fixing URLs, improving the new-scan interaction, and displaying project names accurately. **3rd party scanners:** * Fixed policy bug 3rd party scanners **Platform Stability & Data Integrity:** * Prevented the creation of duplicate projects within the same company. **Configuration Enhancements:** * Added support for new ignore rules in scan configuration to give teams more control over scan output. **UI & Workflow Improvements:** * Corrected filtering behavior for dependency views to ensure accurate and intuitive results. **User Interface Enhancements:** * Relocated the user search bar to provide a more intuitive navigation experience. * Removed an incorrect warning message that appeared for public-repository projects. **Scanning & Reporting Improvements:** * Improved CI review comments by using a more concise and helpful summary. * Expanded internal issue tracking with additional properties for better reporting and analytics. **Platform Stability:** * Fixed agent-related actions to ensure consistent scan execution. * Prevented project tag updates from unintentionally overwriting existing values. **Improvements:** * Fixed error because of long file path. **Bug Fixes:** * Fixed an issue with dropdown menus not displaying correctly. **Platform Stability:** * Improved GitHub reliability by handling user error cases. * Updated button styling for better visual consistency. **New Features:** * Added a SAML tab on the users list page for easier identity management. **UI & UX Improvements:** * Fixed page shifting when creating new scans or interacting with menu icons. * Improved redirection logic for admin users to ensure smoother navigation. * Fixed an issue where policies were not displaying properly in the policies view. **New Features:** * Added support for "New Scan" on projects uploaded as ZIP files. * Enabled "New Scan" functionality for public repository URLs. **UX Enhancements:** * Improved the inbox page with search functionality and cleaner spacing. * Updated redirection logic to send users without permissions to the inbox page. **Stability:** * Suppressed unnecessary Slack webhook error messages for a cleaner log experience. **New Features:** * Vulnerability Source from OSV: Added detailed vulnerability source information powered by the OSV database, enhancing transparency and traceability in scan results. **Improvements:** * History View: Enhanced the history view for a clearer, more streamlined experience. * Commenting Experience: Improved commenting interface and added AI-powered LLM explanations for better context understanding. * Repository Dropdown: Fixed overlapping UI elements between the repository dropdown and navigation bar. * Search Bar on Projects Page: Refined search functionality for smoother navigation and quicker access to projects. * Case-Insensitive Branch Search: Dropsite branch search is now case-insensitive for easier usability. **Bug Fixes & Stability:** * Resolved issues with project list visibility for GitHub repositories. * Improved handling of missing Git user info to prevent failures. * Addressed GitLab "branch not found" errors gracefully. * General bug fixes and performance improvements. **New Features:** * Scan Audit History: Added a dedicated tab for viewing detailed scan audit history. **Improvements:** * Enhanced messaging and consistency across various pages. * Displayed a proper 404 error page for invalid scan or issue links. **Bug Fixes & Stability:** * Fixed inaccurate counts on the scan page for non-BLAST scans. * Improved API handling for invalid or missing scan IDs. * Stability fixes for integration tests and backend reliability. **Bug Fixes & Stability:** * Fixed versioning display to ensure accurate build tracking. * General fixes and optimizations for smoother performance. **New Features & Enhancements:** * Enhanced Export Capabilities: Added support for exporting CSV reports that include false positive data for comprehensive security analysis. * Advanced API Filtering: Introduced filtering and sorting capabilities in the API to provide more flexible data access and integration options. * Third-Party Scanner Integration: Improved support for third-party security scanners with enhanced deep linking capabilities for seamless workflow integration. * Checkmarx Integration: Added additional context support for Checkmarx scans to provide more detailed security insights. **Performance & Usability Improvements:** * Scan List Optimization: Significantly improved page load times for the scan list to provide faster navigation and better user experience. * Enhanced Issue Management: Fixed issues with false positive visibility controls to ensure accurate issue filtering and management. * Improved Scan Organization: Code quality scans are now properly excluded from the main scan list for cleaner project organization. **Platform Reliability:** * Enhanced Monitoring: Improved system monitoring with heartbeat functionality for better service reliability. * Issue Status Management: Fixed issue status inheritance to ensure consistent status tracking across projects. * Jira Integration: Resolved Jira integration issues for seamless ticket management. * File Type Handling: Improved file type detection and processing for more accurate scan results. **General Improvements:** * Various bug fixes and performance enhancements across the platform. * Improved user experience based on customer feedback. * Enhanced system stability and reliability. **New Features & Enhancements:** * Project Management: Added permissions to allow authorized users to delete projects when needed. * CWE Filtering: Introduced an option to filter vulnerabilities by CWE category directly in project settings. * SAML Integration: Added support for assigning default groups when users log in via SAML. * Language Detection: The platform now automatically detects the programming language for imported scans, improving compatibility and accuracy. * Endpoint Discovery: Enhanced the endpoint discovery engine with support for PHP and C# projects. * Feedback System: Added the ability to provide feedback on false positives to continuously improve detection accuracy. **Platform Improvements:** * Improved GitLab and Azure DevOps scheduled scan reliability. * Enhanced GitHub app installation handling to support webhook timing edge cases. * Ensured all project types can be deleted consistently. * Prevented unnecessary processing of privileged users during webhook callbacks. * Streamlined project linking using project IDs for more consistent behavior. **General Fixes & Maintenance:** * Fixed minor UI issues such as button alignment and whitespace handling. * General performance, stability, and reliability improvements across the platform. **New Features:** * Risk Management Enhancements: Added automatic expiry options for accepted risks, making it easier to manage ongoing security decisions. * Project Settings Update: Improved project settings interface for a smoother configuration experience. **AI & Automation Improvements:** * False Positive Detection: Upgraded the false-positive detection system to use GPT-5, providing smarter and more accurate results. * Automated QA Checks: Added issue codes for quality assurance checks and improved retry handling when checks fail. * Improved Ignore File Support: Added support for ignore files (corgea.yaml) within project settings for more flexible configurations. **Usability & Interface Improvements:** * Search Bar Enhancements: Added a "Clear" button and improved multi-select behavior in the search bar. * CWE Filter Fix: Enhanced auto-search functionality for CWE filters to deliver more accurate filtering. * Improved Error Messages: Cleaned up and clarified various error messages for better readability. * Projects Page Fixes: Improved layout and stability on the Projects page for smoother navigation. * Webhook Settings: Fixed Azure webhook link display for easier configuration. **Stability & Performance:** * Scan Overview API: Fixed an issue that could cause server errors when loading scan overviews. * Command-Line Scans: Improved handling for CLI-based scans to ensure smoother operations. * General Bug Fixes & Improvements: Various performance and reliability enhancements across the platform. **Major Platform Updates:** * Complete UI Redesign: Overhauled the entire user interface with modern design principles and improved user experience. * Performance Optimization: Significantly improved platform performance with faster load times and smoother interactions. * Mobile Responsiveness: Enhanced mobile experience with responsive design improvements across all pages. **Security Enhancements:** * Advanced Vulnerability Detection: Upgraded security scanning algorithms to detect more sophisticated threats. * Real-time Security Monitoring: Added continuous security monitoring capabilities for immediate threat detection. * Enhanced Compliance Reporting: Improved compliance reporting features with more detailed analytics and export options. **Integration Improvements:** * New API Endpoints: Added 1new API endpoints for better third-party integrations. * Webhook Enhancements: Improved webhook reliability and added support for custom payload formats. * CI/CD Pipeline Integration: Enhanced integration with popular CI/CD platforms for seamless security scanning. **Developer Experience:** * Improved Documentation: Comprehensive updates to API documentation and developer guides. * Better Error Handling: Enhanced error messages and debugging capabilities throughout the platform. **Infrastructure & Reliability:** * Scalability Improvements: Enhanced platform scalability to handle increased user load. * Monitoring & Alerting: New monitoring systems and alerting mechanisms for better system reliability. * New scans page to view all scans with filters * Filtering on the reporting page * Fix feedback redesign * New Dropsite * New User management views * Admin and user token rotation * New reporting page * Signin redesign * Registration redesign * New issue view. View by CWE, File or all the issues. * Diff viewer line-by-line or side-by-side * Added Additional Instructions to inform engineers of additional steps needed * Advanced False Positive Detection * Launched Corgea [VS Code](/vsc_extension) plugin * Support to fix Checkmarx SAST scan findings * New Dropsite to upload code and vulnerability data without the Corgea CLI * Added [Azure DevOps Integration](/azure_devops) * Updated Github PR comment * Added Projects pagination * Corgea CLI [pypi package](https://pypi.org/project/corgea-cli/) * Improvements that increased fix coverage by 10% * New Projects view to see all projects * Introduced Corgea Verified to show quality checks * Improved fix quality * White consistency improvements * CLI improvements * Added filter tags for Date & Issue type on the Issues table * Introduction of Single tenant support * CLI authentication checks before scan * Shortened Fix explanations to improve legibility * Security fixes * GitHub Oauth login and registration * [GitHub App for Corgea](https://github.com/apps/corgea) * Improved how to fix vulnerable code in large functions * Updated Fix and Quality models to increase fix quality * Added Projects to the filter criteria on the Issues list page * C# language support * Sorting and filtering of issues * New CLI tool * Additional fix quality checks * CodeQL support * Github integration for issuing fixes * Ruby language support * Java language support * Go language support * Added download fix as a git diff and a full file * Added email notification when fixes are available * Added ability to delete issue * Code integrity improvements # CLI Source: https://docs.corgea.app/cli Supercharge your security from the command line ## Introduction Corgea CLI is a powerful developer tool that helps you find and fix security vulnerabilities in your code. Using our AI-powered scanner (BLAST) and platform, Corgea identifies complex security issues like business logic flaws, authentication vulnerabilities, and other hard-to-find bugs. The CLI provides commands to scan your codebase, inspect findings, interact with fixes, and much more - all designed with a great developer experience in mind. **Power up your AI coding agent.** The Corgea CLI also serves as the foundation for our [Agentic Integrations](/agentic_integrations) — install the Corgea Agent Skill and let your AI agent (Cursor, Claude Code, Copilot, and more) scan, triage, and fix vulnerabilities on your behalf. ## Features * **Multiple Scanner Support**: Scan with BLAST (our AI-powered scanner), and upload reports from Semgrep, Snyk, Checkmarx, CodeQL, Fortify, and Coverity. * **Issue Management**: List, inspect, and manage security findings. * **Fix Integration**: View and apply AI-generated fixes for vulnerabilities right from your terminal. * **Dependency Scanning**: Build offline dependency inventories, inspect dependency graphs, generate SBOMs, and evaluate dependency policy with [`corgea deps`](/cli/deps). * **Package Advisory Checks**: Look up known advisories before selecting or installing an npm or PyPI package. * **Package Manager Install Gate**: Vet `npm`, `yarn`, `pnpm`, `pip`, and `uv` installs for known-vulnerable, malicious, or suspiciously fresh packages before they land — see [Package Manager Install Gate](#package-manager-install-gate). * **Flexible Output**: Support for both human-readable and JSON output formats for easier CI integrations. * **CI/CD Integration**: Fail builds based on severity levels or custom blocking rules. * **Scan Management**: Track scan progress and results across your projects. * **Agent Skill Installation**: Install approved agent skills from the Corgea registry into supported coding agents. ## Prerequisites * **Corgea account**: An active Corgea account. * **Token for authentication**: A valid Corgea API token or JWT access token. The offline `corgea deps scan`, `graph`, `explain`, `diff`, `sbom`, and `policy init` commands do not require a Corgea account, token, configuration, or network access. ## Installation Guide ### Install with npm ```bash theme={null} npm install -g @corgea/cli ``` The npm package bundles native binaries for supported platforms and selects the correct binary for your OS and architecture at runtime. ### Install with uv For Python users, this is the preferred installation method. `uv tool install` creates an isolated tool environment from the PyPI package and exposes the CLI as `corgea` on your `PATH`. ```bash theme={null} uv tool install corgea-cli ``` If `uv` reports that its tool directory is not on your `PATH`, run: ```bash theme={null} uv tool update-shell ``` ### Install with pip If you do not use `uv`, you can install the Corgea CLI with Python's package installer, pip: ```bash theme={null} pip install corgea-cli ``` This command fetches the Corgea CLI package from PyPI (Python Package Index) and installs it on your system. You can find more details about the package on its PyPI page: [https://pypi.org/project/corgea-cli/](https://pypi.org/project/corgea-cli/). ### Install with Homebrew To install the Corgea CLI tool using Homebrew, first add the Corgea tap and then install the CLI: ```bash MacOS theme={null} brew tap Corgea/cli brew install corgea-cli ``` ### Install Manually Download the archive for your platform from the [latest release](https://github.com/Corgea/cli/releases/latest), unzip it, and move the `corgea` binary onto your `PATH`. The `latest/download` URLs below always resolve to the most recent release. ```bash macOS (Apple Silicon) theme={null} curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-aarch64-apple-darwin.zip -o corgea.zip && unzip corgea.zip chmod +x corgea sudo mv corgea /usr/local/bin ``` ```bash macOS (Intel) theme={null} curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-x86_64-apple-darwin.zip -o corgea.zip && unzip corgea.zip chmod +x corgea sudo mv corgea /usr/local/bin ``` ```bash Linux (x86_64) theme={null} curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-x86_64-unknown-linux-gnu.zip -o corgea.zip && unzip corgea.zip chmod +x corgea sudo mv corgea /usr/local/bin ``` ```bash Linux (ARM64) theme={null} curl -L https://github.com/Corgea/cli/releases/latest/download/corgea-aarch64-unknown-linux-gnu.zip -o corgea.zip && unzip corgea.zip chmod +x corgea sudo mv corgea /usr/local/bin ``` ```bash Windows (x64) theme={null} # Download the latest Windows build, extract it, and move corgea.exe to a directory on your PATH: https://github.com/Corgea/cli/releases/latest/download/corgea-x86_64-pc-windows-msvc.zip ``` A statically linked Linux build is also published as `corgea-x86_64-unknown-linux-musl.zip`. ## Authentication ### Login with your cli To authenticate with the CLI, use the following command. This will redirect you to the web application to authorize the CLI: ```bash theme={null} corgea login ``` #### Login with custom scope (for customers with Single-Tenant Instance) **Hint:** Your company scope is the Corgea subdomain, for example: `https://your-company.corgea.app` ```bash theme={null} corgea login --scope your-company ``` #### Login with token (API token or JWT) For automated pipelines and CI/CD environments, use token authentication for a reliable, non-interactive login flow. You can pass either a Corgea API token or a JWT access token: ```bash theme={null} corgea login YOUR_TOKEN ``` You can also set the token in an environment variable: ```bash MacOS/Unix theme={null} export CORGEA_TOKEN="your-token-here" corgea login ``` ```bash Windows theme={null} $env:CORGEA_TOKEN="your-token-here" corgea login ``` #### Point To A Single-Tenant Instance Customers using a single-tenant instance need to configure the CLI to point to their specific instance using the `--url` option: ```bash theme={null} corgea login --url https://<>.corgea.app YOUR_TOKEN ``` You can also set the URL in an environment variable and the CLI will automatically detect it: ```bash MacOS/Unix theme={null} export CORGEA_URL="https://<>.corgea.app" export CORGEA_TOKEN="your-token-here" corgea login ``` ```bash Windows theme={null} $env:CORGEA_URL="https://<>.corgea.app" $env:CORGEA_TOKEN="your-token-here" corgea login ``` ## Usage ### Commands and Options #### Check Package Advisories Use `corgea advisories check` to review known advisories before choosing or installing an npm or PyPI package. A package-only check lists its advisory history; add an exact version to get a verdict for that release. ```bash theme={null} corgea advisories check npm axios corgea advisories check npm axios@0.21.0 corgea advisories check pypi requests==2.31.0 ``` The ecosystem can be `npm` or `pypi` (`pip` is also accepted as an alias). npm versions must use a complete, exact version such as `1.2.3`; ranges, tags, and partial versions are not supported. PyPI checks accept either `package@version` or pip-style `package==version` syntax. Package-only results help you review advisory history before selecting a version. Exact-version results include known advisory details, fixed-version information when available, and a safe-version recommendation when all reported advisories have fixes. This command is read-only and requires network access; the [package manager install gate](#package-manager-install-gate) remains the enforcement step. Use `--json` for a machine-readable schema version 1 response. The command exits with code `0` when no advisories are found, `1` when advisories are found, and `2` for an error. A package not present in the advisory database exits with code `0`. #### Package Manager Install Gate Use `corgea npm`, `corgea yarn`, `corgea pnpm`, `corgea pip`, or `corgea uv` to run supported package-manager install commands through Corgea before dependencies are installed. ```bash theme={null} corgea npm install axios@0.21.0 corgea yarn add lodash corgea pnpm install express corgea pip install requests==2.31.0 corgea uv add requests ``` Corgea checks each resolved version for known-vulnerable or malicious releases against public vulnerability data — no token required — and blocks unusually fresh releases (see **Recency gate** below). Vulnerable, malicious, or too-recent versions block the install before the package manager runs. Place wrapper flags between the manager name and its command, for example `corgea pip --force install requests`. | Flag | Description | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--force` | Proceed despite any finding (vulnerable, malicious, unverifiable, or too-recent). Also bypasses pre-flight refusals: a detected wrong package manager and externally managed Python environments. | | `--json` | Emit one machine-readable report (with `verdict_mode` as `public` or `authenticated`) instead of human-readable text (see below). | **Recency gate.** Beyond vulnerability data, Corgea blocks any named install target whose resolved version was published within a recency window — catching just-shipped typosquats and hijacks before advisory feeds catch up. It is **on by default** with a 14-day window. Configure it in `~/.corgea/config.toml` (`recency_gate = false` to disable, `recency_threshold_days` to retune the window), or with the `CORGEA_RECENCY_GATE` and `CORGEA_RECENCY_THRESHOLD_DAYS` environment variables. Packages whose publish date can't be determined never trip the gate, a vulnerable or malicious verdict takes precedence over freshness, and `--force` bypasses it for a single install. **Coverage.** `pip install` and `npm install` resolve the full would-install set, including transitive dependencies, so a vulnerable transitive dependency blocks the command; if the dry-run resolver fails, Corgea warns and falls back to named-target checks. `npm ci` is gated from the project lockfile and `uv sync` from `uv.lock`, so the full locked set is checked even though those commands name no packages. The `uv` gate also covers named `uv add ...` and `uv pip install ...` targets, while `uv lock` passes through because it installs nothing. `yarn` and `pnpm` check named targets only — they have no safe dry-run resolver. **Bare installs.** Bare `npm install` is gated from the project's `package.json`. Bare `yarn`, `pnpm`, and install-shaped `uv` commands cannot be checked first, so Corgea prints a note and runs them unchecked. ```bash theme={null} corgea npm install corgea yarn install corgea pnpm install corgea uv add ``` **Public vs authenticated.** Without a token the gate runs in public mode: vulnerable and malicious packages still block, but unverifiable packages and lookup failures only warn and let the install continue (repeated failures collapse into one summary line). With a token from `CORGEA_TOKEN` or `corgea login` on the default vulnerability API, the gate runs in authenticated mode and fails closed — unverifiable packages, dependency-resolution failures, vulnerability-API outages, and degraded tree coverage on managers that normally resolve the full tree (`pip`, `npm`, `uv`) block the install unless you pass `--force`. **Custom vulnerability API.** If you point `CORGEA_VULN_API_URL` at a custom endpoint, Corgea does not send your token there, so the gate stays in public mode. Set `CORGEA_VULN_API_SEND_TOKEN_TO_CUSTOM_URL=1` to enable authenticated enforcement against an endpoint you trust. **Externally managed Python.** For `pip`, Corgea refuses installs into externally managed environments (PEP 668) before registry checks run. Activate a virtual environment, or pass `--force` to bypass. Corgea runs the matching package manager from your `PATH`. For `corgea pip ...`, it tries `pip3` when `pip` is missing; if neither exists, the CLI exits `127` and names the missing binary. **Findings.** When a resolved package is vulnerable, tree findings show its origin: * `(from requirements)` — requested through a pip requirements file. * `(already in package.json)` — already a direct npm dependency. * `(transitive)` — pulled in through another dependency. When the named package is clean but the resolved tree already contains a vulnerable package, the refusal identifies the existing tree as the source. Advisory lines show the advertised fixed version, or that none is known; when every advisory on a package has fix data, Corgea prints `safe version: axios@0.21.2`, and for vulnerable direct npm dependencies it may print `fix with: corgea npm install package-name@version (advertised fix)`. Vulnerability counts and exit behavior follow the original install target. **JSON output.** `--json` returns one report on stdout and redirects the package manager's stdout to stderr so Corgea owns stdout. Schema version **2** reports `manager`, `subcommand`, `args`, `recency_threshold_days` (the active recency window, or `null` when the gate is off — pair it with each result's `age_seconds`), a `summary` split into `named` and `tree` counts, `verdict_mode`, a `results` array, and a `tree` object when tree resolution ran. Tree entries carry an `origin` of `requested`, `pre-existing`, or `transitive`. Known-malicious packages report a distinct verdict `status` of `malicious`, a per-match `malware` boolean, and a separate `malicious` count in each summary object. Their `remediation` is always `null` because the package should be removed rather than upgraded; vulnerable verdicts continue to report a safe version only when it covers every advisory. #### Install Agent Skills Install an approved skill from the Corgea registry into your coding agent's skills directory: ```bash theme={null} corgea skill install corgea --agent cursor --scope user ``` Supported agent IDs are `cursor`, `claude-code`, `codex`, `github-copilot`, `gemini-cli`, `windsurf`, `opencode`, and `universal`. Use `--scope project` to install into the current repository, `--scope user` to install for your user account, or `--dir` to install into a custom skills directory. To install a specific version, append it to the skill name: ```bash theme={null} corgea skill install corgea@1.0.0 --agent cursor --scope user ``` You can also save a default agent for future installs: ```bash theme={null} corgea skill set-default-agent cursor corgea skill install corgea --scope user ``` #### Upload a Scan Report Upload a scan report to Corgea via STDIN or a file (JSON, SARIF, FPR, or Coverity XML): ```bash theme={null} corgea upload path/to/report.json ``` To control the project name shown in Corgea for uploaded reports, use `--project-name`. If omitted, the CLI defaults to the git repository name when available, and falls back to the current directory name. ```bash theme={null} corgea upload path/to/report.json --project-name my-service ``` For large reports, the CLI uploads data in chunks. During chunked uploads, the CLI verifies server upload progress and exits with a non-zero status if the server reports an unexpected offset or if the upload completes without returning a scan ID. #### Scan Your Codebase To scan your current directory using the default BLAST scanner: ```bash theme={null} corgea scan ``` To specify a different scanner, such as Semgrep: ```bash theme={null} corgea scan semgrep ``` You can also use `--fail-on` with one or more comma-separated conditions: `CR`, `HI`, `ME`, `LO`, or `malicious`. Severity conditions match findings at that severity or higher; for example, `ME` also matches `HI` and `CR` findings. The `malicious` condition matches a dependency finding classified as malicious. The command exits with a non-zero status when any listed condition matches. Examples: ```bash theme={null} corgea scan --fail-on CR ``` ```bash theme={null} corgea scan --fail-on malicious ``` ```bash theme={null} corgea scan --fail-on HI,malicious ``` Or fail based on blocking rules defined in the web app: ```bash theme={null} corgea scan --fail ``` By default, the scan command scans the entire project. However, if you only want to scan your changes before committing, you can use the --only-uncommitted option. ```bash theme={null} corgea scan --only-uncommitted ``` You can also target specific files or subsets of your project (BLAST scans only) with the `--target` option. This accepts comma-separated values and supports file paths, directory paths, glob patterns, git selectors, or stdin. Examples: ```bash theme={null} corgea scan --target src/,pyproject.toml ``` ```bash theme={null} corgea scan --target "src/**/*.py" ``` ```bash theme={null} corgea scan --target git:diff=origin/main...HEAD ``` ```bash theme={null} corgea scan --target git:staged,git:modified,git:untracked ``` ```bash theme={null} corgea scan --target - ``` ```bash theme={null} git ls-files -z | corgea scan --target -0 ``` You can exclude files from BLAST scans with the `--exclude` option. This accepts comma-separated glob patterns and can be used with or without `--target`. ```bash theme={null} corgea scan --exclude "tests/**,**/*.test.ts" ``` ```bash theme={null} corgea scan --target "src/" --exclude "**/*.md,**/*.spec.js" ``` Note: `--only-uncommitted` and `--target` cannot be used together. To skip files during a BLAST scan, use `--exclude` with comma-separated glob patterns. It can be combined with `--target` to scan a subset while excluding matches within it. ```bash theme={null} corgea scan --exclude "tests/**,**/*.spec.js" ``` To control the project name shown in Corgea, use `--project-name`. If omitted, the CLI defaults to the git repository name when available, and falls back to the current directory name. ```bash theme={null} corgea scan --project-name my-service ``` To attach custom metadata to a BLAST scan, repeat `--metadata` with `KEY=VALUE` pairs. These values are included with the scan and in JSON scan-list output. ```bash theme={null} corgea scan --metadata pipeline_url=https://ci.example/run/123 --metadata artifact_version=1.2.3 ``` `--metadata` is supported only by the BLAST scanner. Each entry must have a non-empty key; if the same key is supplied more than once, the last value is used. The regular BLAST scan includes multiple scans: * Blast Base AI Scan * PolicyIQ Scan * Malicious Code Detection Scan * Secrets Detection Scan * Personally identifiable information (PII) Detection Scan By default, all these scans run (if they are enabled for your company account plan). However, the CLI provides the flexibility to run a scan targeting one or more types with the --scan-type option. ```bash theme={null} corgea scan --scan-type secrets ``` or multipe types ```bash theme={null} corgea scan --scan-type blast,malicious,policy,secrets,pii ``` To target specific policies with a policyIQ scan, use the --policy option. This allows you to focus on one or more policies by passing their ID(s). ```bash theme={null} corgea scan --scan-type policy --policy 1 ``` #### Export Scan Report The Corgea CLI allows you to export scan results to a file, which is particularly useful when running the tool within a CI pipeline. You can do this using the --out-format and --out-file options. ```bash theme={null} corgea scan --out-format=json --out-file=report.json ``` The CLI currently supports HTML, JSON, SARIF, and Markdown as output formats. ```bash theme={null} corgea scan --out-format=html --out-file=report.html ``` ```bash theme={null} corgea scan --out-format=sarif --out-file=report.sarif ``` #### Dependency Inventory Use `corgea deps` to build an offline dependency inventory from npm, Python, and Java manifests and lockfiles. The command evaluates dependency pinning policy, can fail CI based on findings, and does not require login or network access. ```bash theme={null} corgea deps scan ``` Common dependency inventory commands: ```bash theme={null} corgea deps scan --format human corgea deps scan --format json corgea deps scan --format quiet --fail-on high corgea deps scan --out-format sarif --out-file deps.sarif corgea deps graph --format json corgea deps explain lodash --format human corgea deps diff --base origin/main --format json corgea deps sbom --format cyclonedx --out bom.json corgea deps policy init --exist-ok ``` Use `--format human`, `agent`, `json`, or `quiet` to control terminal output for `scan`, `graph`, `explain`, `diff`, and `policy init`. In detected agent environments, `corgea deps` defaults to the compact `agent` format; pass `--format human` to force normal terminal output. For `corgea deps scan`, use `--out-format table`, `json`, or `sarif` with optional `--out-file` when exporting a report. Do not combine `--format` and `--out-format` on the same `deps scan` command. To customize dependency policy, initialize `.corgea/deps.yml`: ```bash theme={null} corgea deps policy init ``` The generated policy controls whether lockfiles are required, missing or stale lockfiles fail, and direct dependencies using wildcards, `latest`, or semver ranges are reported. See [Dependency Scanning](/cli/deps) for CI examples, policy configuration, and troubleshooting. #### Wait for a Scan To wait for the latest in-progress scan: ```bash theme={null} corgea wait ``` Or specify a scan ID to wait for: ```bash theme={null} corgea wait SCAN_ID ``` #### List Scans, Issues or SCA Issues To list all scans for a current directory (paginated by default): ```bash theme={null} corgea ls ``` To list issues for a specific scan: ```bash theme={null} corgea ls --issues --scan-id SCAN_ID ``` You can also control the pagination: ```bash theme={null} corgea list --page 1 --page-size 10 ``` Note: The `--json` option is available for commands like `list` and `inspect` to output results in JSON format, which is useful for integrations and automation. ```bash theme={null} corgea list --page 1 --page-size 10 --json ``` The scan table includes the first eight characters of each scan's commit SHA, or `N/A` when no SHA is available. JSON output includes the complete `git_sha` value and any scan `metadata` returned by Corgea. To list SCA for a project or a scan use `--sca-issues` or '-c' shorthand ```bash theme={null} corgea list --sca-issues --page 1 --page-size 10 --json ``` or ```bash theme={null} corgea list -c --page 1 --page-size 10 --json ``` #### Inspect a Scan or Issue To inspect a specific scan: ```bash theme={null} corgea inspect SCAN_ID ``` To inspect issues with detailed output: ```bash theme={null} corgea inspect --issue --json --summary ISSUE_ID ``` For fix explanations or diffs: ```bash theme={null} corgea inspect --issue --fix ISSUE_ID corgea inspect --issue --diff ISSUE_ID ``` ### Integrating with GIT Hooks To ensure code quality and security, you can integrate Corgea CLI with your Git workflow using pre-commit hooks. This feature allows you to scan your code changes before committing or pushing them. To set up the pre-commit hook, simply run ```bash theme={null} corgea setup-hooks ``` When setting up the pre-commit hook, you will be prompted to enter your preferred configurations for the scan. To quickly set it up with the default settings, which include scan types for PII and secrets, and fail levels set to CR, HI, ME, and LO, you can run ```bash theme={null} corgea setup-hooks --default-config ``` To bypass the pre-commit check when committing, use the following command: ```bash theme={null} git commit --no-verify ``` ### Debug Mode To enable debug logs, set `CORGEA_DEBUG=1` before running a command. ```bash MacOS/Unix theme={null} CORGEA_DEBUG=1 corgea scan ``` ```bash Windows (PowerShell) theme={null} $env:CORGEA_DEBUG="1" corgea scan ``` When debug mode is enabled, failed upload requests include the HTTP status and response body in debug output, which helps with troubleshooting. ### Additional Options For more options and commands, use: ```bash theme={null} corgea --help ``` ## Release Notes For full release notes, please visit our [GitHub releases page](https://github.com/corgea/cli/releases). # Dependency Scanning (CLI) Source: https://docs.corgea.app/cli/deps Build offline dependency inventories, dependency graphs, SBOMs, and policy checks with corgea deps ## Overview `corgea deps` builds an offline dependency inventory from npm, Python, and Java manifests and lockfiles. It can inspect dependency graphs, explain why a package is present, compare dependency changes, generate a CycloneDX SBOM, and evaluate dependency policy. `corgea deps` does not require a Corgea account, token, or network access. ## Inventory Run an offline dependency scan from the project root: ```bash theme={null} corgea deps scan ``` Common commands: ```bash theme={null} corgea deps scan --format human corgea deps scan --format json corgea deps scan --format quiet --fail-on high corgea deps scan --out-format sarif --out-file deps.sarif corgea deps graph --format json corgea deps explain lodash --format human corgea deps diff --base origin/main --format json corgea deps sbom --format cyclonedx --out bom.json corgea deps policy init --exist-ok ``` Use `--format human`, `agent`, `json`, or `quiet` to control terminal output for `scan`, `graph`, `explain`, `diff`, and `policy init`. In detected agent environments, `corgea deps` defaults to the compact `agent` format; pass `--format human` to force normal terminal output. For `corgea deps scan`, use `--out-format table`, `json`, or `sarif` with optional `--out-file` when exporting a report. Do not combine `--format` and `--out-format` on the same `deps scan` command. ## Policy Initialize `.corgea/deps.yml`: ```bash theme={null} corgea deps policy init ``` The generated policy controls whether lockfiles are required, missing or stale lockfiles fail, and direct dependencies using wildcards, `latest`, or semver ranges are reported. ```yaml theme={null} dependency_policy: require_lockfile: true fail_on_missing_lockfile: true fail_on_stale_lockfile: true direct_dependencies: fail_on_wildcard: true fail_on_latest: true warn_on_semver_range: true ```

CI Integration

Copy this workflow into `.github/workflows/dependencies.yml`. ```yaml theme={null} name: Dependency inventory on: pull_request: push: branches: [main] jobs: corgea-deps: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '20' - run: npm install -g @corgea/cli - name: Check dependency policy run: corgea deps scan --format quiet --fail-on high ``` To fail only when a pull request adds new high-severity dependency findings: ```bash theme={null} corgea deps diff --base origin/main --fail-on-new high --format quiet ``` ## Reference ### Commands | Command | Purpose | Key flags | | --------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------- | | `corgea deps scan [PATH]` | Scan manifests and lockfiles, build inventory, evaluate policy | `--fail-on`, `--format`, `--out-format`, `--out-file` | | `corgea deps graph [PATH]` | Print the dependency graph | `--format` | | `corgea deps explain [PATH]` | Explain why a package is present | `--format` | | `corgea deps diff --base [PATH]` | Compare dependency graph against a git ref | `--base`, `--fail-on-new`, `--format` | | `corgea deps sbom [PATH]` | Generate a CycloneDX SBOM | `--format`, `--out` | | `corgea deps policy init [PATH]` | Write a starter `.corgea/deps.yml` policy file | `--exist-ok`, `--format` | ### Formats | Flag | Values | Commands | | -------------- | --------------------------------- | ------------------------------------------------- | | `--format` | `human`, `agent`, `json`, `quiet` | `scan`, `graph`, `explain`, `diff`, `policy init` | | `--out-format` | `table`, `json`, `sarif` | `scan` only | | `--format` | `cyclonedx` | `sbom` only | ### Exit Codes | Exit | Condition | | ----- | -------------------------------------------------------------------------------------------------------------------- | | **0** | Command completed without a failing policy threshold | | **1** | `deps scan --fail-on` or `deps diff --fail-on-new` found matching findings | | **2** | Invalid arguments, unsupported formats, bad severity values, missing packages for `explain`, or other command errors | ### Severity Values `--fail-on` and `--fail-on-new` accept `info`, `low`, `medium`, `high`, or `critical`. ## Troubleshooting ### Format Conflict `deps scan` rejects commands that combine `--format` with `--out-format`. ```text theme={null} deps failed: --format cannot be used with --out-format; choose one output selector ``` Use `--format` for terminal rendering and `--out-format` for exported scan reports. ### Package Not Found `deps explain` exits with code **2** when the package is not present in the scanned dependency graph. ```text theme={null} deps failed: package not found: package-name ``` # Code Quality Source: https://docs.corgea.app/code-quality-scanner AI-powered code review tool for maintainability, readability, and performance The **Corgea Code Quality Scanner** is an AI-powered code review tool that identifies maintainability, readability, performance, and correctness issues in your codebase. Unlike [our security vulnerability scanners](/blast) that focus on security threats, the Code Quality Scanner acts as an expert software engineer reviewing your code to help maintain high standards and prevent technical debt. ## What It Does The Code Quality Scanner analyzes your source code files to identify concrete issues that impact your codebase's long-term health. Think of it as having an experienced senior engineer reviewing every file, catching issues that might slip through manual code reviews while focusing on practical, actionable improvements. ### Key Capabilities * **Automated Code Review**: Performs thorough analysis of your code, checking for common quality issues that affect maintainability * **Language-Aware Analysis**: Understands the context and conventions of different programming languages * **Framework Detection**: Recognizes common frameworks and applies framework-specific best practices * **Severity Classification**: Prioritizes issues based on their impact (High, Medium, Low) * **CWE Mapping**: Maps issues to Common Weakness Enumeration (CWE) standards for standardized categorization *** ## What It Can Find The Code Quality Scanner identifies a comprehensive range of code quality issues. All findings are mapped to CWE standards for consistent categorization. * **Typos and spelling errors** in code comments, variable names, and strings (CWE-1078) * **Inaccurate or misleading comments** that contradict actual code behavior or may be outdated (CWE-1116) ```javascript example.js theme={null} // Bad: Misleading comment // Calculate the sum of two numbers function multiply(a, b) { return a * b; // Actually multiplying, not adding } ``` * **Empty code blocks** that serve no purpose (CWE-1071) * **Unused variables, imports, and dead code** that clutter the codebase (CWE-563, CWE-1041) * **Empty exception blocks** that silently swallow errors (CWE-1069, CWE-390) * **Unreachable code** that can never execute (CWE-561) ```python example.py theme={null} # Bad: Empty exception block silently swallows errors try: risky_operation() except Exception: pass # Error is hidden! ``` * **Duplicate code** that should be refactored into shared functions (CWE-1041) * **Duplicate keys or literals** in objects and magic numbers that should be constants (CWE-1078) * **Non-DRY code** - repeated logic that increases maintenance burden * **String concatenation in loops** that degrades performance (CWE-1046) * **Inefficient operations** and unnecessary resource consumption (CWE-1050) * **Performance bottlenecks** in frequently-executed code paths ```java Example.java theme={null} // Bad: String concatenation in loop String result = ""; for (int i = 0; i < 1000; i++) { result += data[i]; // Creates new string object each iteration } ``` * **Functions with too many parameters** (>5 parameters) indicating poor design (CWE-1064) * **Overly complex function signatures** that are difficult to use correctly * **Circular dependencies** between modules (CWE-1047) * **Violations of SOLID principles** * **Complex one-liners** that should be broken down for clarity (CWE-1120) * **Deeply nested logic** with excessive branching that's hard to understand * **Overly generic helper functions** that obscure intent * **Violations of KISS principle** * **Inconsistent naming conventions** that make code harder to follow (CWE-1099) * **Generic, non-descriptive variable names** like 'obj', 'x', 'data' * **Mixed naming styles** (e.g., camelCase and snake\_case in the same codebase) * **Logic errors** that cause incorrect behavior (CWE-670) * **Incorrect data processing** that produces wrong results * **Code that won't work as intended** due to implementation mistakes * **TODO comments** and placeholder code (CWE-1071) * **Half-finished features** that may cause issues * **Incomplete implementations** that need attention *** ## How It Works ### 1. File Analysis The scanner processes each file in your codebase individually, analyzing the complete source code with full context of the file's structure, language, and detected frameworks. ### 2. AI-Powered Review Using advanced language models specifically trained for code review, the scanner examines your code against established software engineering principles and best practices. The AI understands: * Language-specific idioms and conventions * Framework patterns and best practices * Code complexity and maintainability metrics * Industry-standard software design principles ### 3. Issue Identification When a potential issue is found, the scanner: * Pinpoints the exact lines of code involved * Classifies the issue type using CWE standards * Assigns an appropriate severity level * Generates a clear explanation of the problem and its impact ### 4. High-Confidence Detection * The scanner only reports issues it's at least 90% confident about. This high threshold ensures that findings are actionable and accurate, not speculative. * The 90% confidence threshold significantly reduces noise and false positives, so you can trust that reported issues are worth addressing. *** ## False Positive Suppression The Code Quality Scanner includes sophisticated [false positive suppression](/false_positive) mechanisms to ensure you receive only meaningful, actionable findings: ### Built-In Filters **Security Issue Exclusion**: The scanner explicitly excludes security vulnerabilities (SQL injection, XSS, authentication issues, etc.) as these are handled by Corgea's [dedicated security scanners](/blast). This prevents overlap and confusion between code quality and security findings. **Style Preference Filtering**: Minor style preferences such as brace placement, indentation, and whitespace are not reported. The scanner focuses on substantive quality issues, not formatting preferences. ### Contextual Understanding The scanner understands code context to avoid false positives: * Recognizes when "empty" blocks are intentional (e.g., placeholder implementations) * Understands framework-specific patterns that might otherwise look problematic * Considers language idioms that are acceptable in specific programming languages *** ## Automated Remediation When code quality issues are identified, Corgea provides [automated remediation capabilities](/fixes) to help you fix problems quickly and consistently: ### What Gets Remediated The automated remediation system can fix many common code quality issues, including: * Removing unused variables and imports * Converting magic numbers to named constants * Fixing typos in variable names and comments * Consolidating duplicate code into shared functions * Simplifying overly complex expressions * Breaking down complex one-liners * Improving variable and function names * Adding proper error handling * Implementing framework-specific patterns ### How Remediation Works 1. **Issue Context**: The system analyzes the full context around each issue, understanding not just the problematic code but its role in the broader codebase 2. **Safe Fixes**: Automated fixes are designed to be safe and maintain existing functionality 3. **Code Style Preservation**: Fixes respect your existing code style and conventions 4. **Review Before Apply**: You maintain full control over which fixes to apply *** ## Separate from Vulnerability Scanning The Code Quality Scanner is completely separate from Corgea's [security vulnerability scanning](/blast) capabilities. ### Key Differences | Code Quality Scanner | [Vulnerability Scanner](/blast) | | -------------------------------------------------------- | --------------------------------------------------------- | | Focuses on maintainability, readability, and correctness | Focuses on security threats and exploitable weaknesses | | Identifies technical debt and design issues | Identifies SQL injection, XSS, authentication flaws, etc. | | Helps improve long-term code health | Helps protect against security breaches | | Uses CWEs related to code quality | Uses CWEs related to security | ### Why Both Matter * **Security** keeps your application safe from attackers * **Code Quality** keeps your codebase maintainable, performant, and reliable Both are essential for a healthy software project, but they address different concerns. A codebase can be secure but unmaintainable, or well-structured but vulnerable. Corgea provides both to give you complete visibility into your code's health. *** ## Severity Levels Explained Issues that **will cause crashes, severe performance problems, or critical bugs**: * Empty catch blocks that hide errors * Infinite loops * Logic that always fails * Critical performance bottlenecks **Action**: Fix immediately Issues that **impact maintainability or performance**: * Code duplication * Unused code cluttering the codebase * String concatenation in loops * Confusing logic that slows development **Action**: Address in your next refactoring cycle **Minor issues that reduce code quality**: * Inconsistent naming * Unnecessary complexity * Minor readability improvements **Action**: Fix when convenient or during related work *** ## Getting Started The Code Quality Scanner integrates seamlessly into your development workflow: Link your code repository to Corgea using [GitHub](/github), [GitLab](/gitlab), [Azure DevOps](/azure_devops), or [Bitbucket](/bitbucket) The scanner analyzes your files automatically Browse identified issues with clear explanations and severity levels in the [project dashboard](/project) Use [automated remediation](/fixes) or fix issues manually Monitor improvements in code quality over time *** ## Related Documentation Learn about Corgea's security vulnerability scanning capabilities Explore how automated remediation works across all scan types Manage and suppress false positives effectively Track and manage all issues across your projects *** ## Support For assistance, contact us at [support@corgea.com](mailto:support@corgea.com) # Container Image Scanning Source: https://docs.corgea.app/container-scanning Container image scanning identifies known security vulnerabilities in the base images your project depends on, including operating system packages, system libraries, and other software installed within the image layers. ## Overview * **What it Does**: Container image scanning identifies known security vulnerabilities in the container images your project uses. This includes vulnerabilities in base operating system packages, system libraries, and application packages installed within the image layers. By scanning images before deployment, you can catch security risks in containerized applications early. * **Who it's For**: Security teams, developers, and DevOps engineers who ship containerized applications and want visibility into the vulnerabilities they inherit from base images. ## How It Works Corgea automatically discovers the container images referenced in your project and scans each one against known vulnerability databases. Corgea scans your project for `Dockerfile` and Docker Compose files, then extracts the image references from them: * **Dockerfiles**: base images declared with `FROM` (for example, `FROM python:3.11-slim`) * **Docker Compose**: images declared under `image:` for each service (for example, `image: postgres:15`) Discovered images are de-duplicated and mapped back to the file that referenced them. Each image is pulled and its layers are analyzed to build an inventory of installed software — including OS/distribution packages (Debian, Ubuntu, Alpine, and others) and application packages installed inside the image. The discovered packages are cross-referenced against known vulnerability databases, and any matches are reported alongside your other scan results. ## Supported Registries Corgea scans images hosted on public registries: * Docker Hub * GitHub Container Registry (GHCR) * Google Container Registry (GCR) * Quay.io * Microsoft Container Registry (MCR) * Amazon ECR Public * GitLab Container Registry Container image scanning is automatically enabled when Docker files are detected in your project. No configuration is required. ## Limitations * **Public registries only**: Images hosted on private registries are skipped. * **Maximum image size**: Images larger than 1000 MB (1 GB) are skipped. * Only images referenced in `Dockerfile` and Docker Compose files are discovered. ## Best Practices Use specific image tags (for example, `python:3.11.5-slim`) instead of `latest` for consistent, reproducible scan results. * **Use Specific Tags**: Avoid `latest` tags; pin exact versions so scans are reproducible. * **Prefer Minimal Base Images**: Use slim, Alpine, or distroless variants to reduce the attack surface. * **Regular Updates**: Keep base images updated to pick up security patches. * **Multi-Stage Builds**: Minimize the final image size and the set of packages it includes. ## Related * [Dependency Scanning (SCA)](/sca) — scan your application's third-party dependencies * [Malicious Package Detection](/malware-scanning) — detect known malicious or compromised packages # Content Access Management Source: https://docs.corgea.app/content-access-management Control project access for different teams and members. Content Access Management is Corgea's project-level access control system. It allows you to control who in your organization can view and interact with specific projects and their security data. Content Access Management relies on Teams and is available on plans that include Team Management. By default, all users in your company can access all company projects. With Content Access Management enabled, users only see projects granted through direct assignments, team assignments, or dynamic team selectors. This feature is essential for organizations that need to: * Separate access between different teams or departments * Restrict sensitive projects to specific individuals * Comply with security policies that require access segregation * Manage contractor or external consultant access ## How Does It Work? Content Access Management operates at two levels: ### Company-Level Setting Your company has a **Project Access Control** toggle that determines the overall access model: * **Disabled (Default)**: Open access model - all users in your company can access all company projects * **Enabled**: Restricted access model - users can only access projects granted directly or through a team ### Project-Level Access When Project Access Control is enabled, users gain access to a project through direct user access or member-level access inherited from a team: Users who belong to a team assigned explicitly to the project automatically receive member-level access. This provides the same permissions as direct members but is managed at the team level rather than per-project. Learn more about teams in our [Teams Guide](teams). A team can grant member-level access to sets of projects using: * **Project tags**: Any project carrying one of the team's selected tags * **Repository URL fragments**: Any project whose repository URL contains one of the team's configured fragments These selectors are evaluated dynamically. Newly created or re-tagged projects begin matching without a separate assignment step. Manage these selectors programmatically with the [Teams API](/api-reference/teams/list-teams). Members can access project data but have limited administrative capabilities: * View all security issues and vulnerabilities * Access scan results and historical data * Review and interact with fixes * Participate in issue discussions * Cannot modify project settings or delete the project Owners have full control over a project, including: * Viewing all project security data (issues, scans, fixes) * Configuring project settings * Managing project integrations * Adding/removing other users and teams * Deleting the project ### Special Cases **API Access**: Access control applies to both the web interface and API calls. Users can only access project data through the API if they have proper permissions. ## How to Implement Content Access Management **Required Permission**: Company administrator access 1. Navigate to your **Company Settings** 2. Locate the **Project Access Control** setting 3. Enable the toggle for "Project Access Control" 4. Save your changes Once enabled, users immediately lose access to projects not covered by a direct assignment, team assignment, or team selector. Plan your rollout accordingly. **Required Permission**: `Change Project` permission or project owner role After enabling Project Access Control, you need to grant users access to projects: 1. Navigate to the **Content Access** page 2. Search by project or member, or filter by team and project to narrow the list 3. For each project, you can: * View current members and teams * Add new users as owners or members * Add teams to the project * Remove existing access 4. Use **Edit Members** to apply access changes across multiple projects at once 1) Click on the project you want to manage 2) Select **Add Member** or **Add Owner** 3) Choose the user from your company's user list 4) Select their role: * **Owner**: Full project control * **Member**: View and interact with security data 5) Confirm the addition 1. Click on the project you want to manage 2. Select **Add Team** 3. Choose the team from your company's teams list 4. Confirm the addition 5. All current and future members of that team will have member-level access Learn how to create and manage teams in our [Teams Guide](teams). 1. Click **Edit Members** 2. Filter or search for the projects you want to update 3. Select the projects in scope 4. Choose an action: * Add users as members or owners * Remove users from members and owners * Add or remove teams * Replace one owner with another owner * Remove inactive users from selected projects 5. Confirm the update After assigning access: 1. Review the Content Access page to ensure assignments are correct 2. Test with a user account to verify they can access appropriate projects 3. Check that users without access cannot see restricted projects As your organization evolves: * **New Projects**: Assign owners and members, or make sure the project matches the intended team selectors * **New Users**: Add them to relevant projects or teams * **Role Changes**: Update access when people change roles, including replacing project owners in bulk * **Departures**: Deactivated users are hidden from active access lists, and you can remove inactive users from selected projects in bulk ## Best Practices Before turning on Project Access Control: * Document which users should have access to which projects * Consider creating teams first to simplify assignment * Communicate the change to your organization * Consider starting with a pilot group of projects For projects with multiple users, use teams instead of individual assignments: * ✅ Add "Backend Team" to 10 projects (10 operations) * ❌ Add 15 individual users to 10 projects (150 operations) Teams also make ongoing management much easier. Every project should have at least one owner who can: * Manage project settings * Add/remove other users * Handle project-specific configuration Without an owner, projects become difficult to manage. Use ownership strategically: * **Owners**: Project leads, managers, senior engineers responsible for the project * **Members**: Contributors, reviewers, stakeholders who need visibility Don't make everyone an owner—it reduces accountability and increases security risk. Schedule periodic reviews of project access: * Quarterly or bi-annually, review who has access to each project * Remove access for users who no longer need it * Update access for users whose roles have changed * Use bulk actions to clean up stale assignments across filtered projects * Export access data for compliance purposes The Content Access page includes search and filters: * Quickly find specific projects * Search for active or inactive users to see which projects they are assigned to * Filter by team or project before reviewing access or applying bulk changes **Required Permission**: Content access view permission Export your access configuration for: * Compliance audits * Security reviews * Documentation purposes * Backup before making bulk changes Use the **Export** button on the Content Access page to download a CSV of active project access assignments. Match your access control to how your organization actually works: * If teams are siloed (separate frontend/backend/mobile), use strict access control * If teams are fluid and collaborative, you might prefer open access * Use a hybrid approach: open access for most projects, restricted access for sensitive ones (though this requires keeping some projects in a separate company space) When modifying access: * Inform affected users before removing their access * Explain why access is being granted or revoked * Document your access policies so users understand the rules When in doubt: * Grant member access instead of owner access * Users can always request elevated permissions if needed * It's easier to grant additional access than to revoke it ## Frequently Asked Questions They immediately lose access to projects where they are not owners, direct members, explicit team members, or members of a team whose selectors match. Plan accordingly before enabling the feature. No. Project Access Control is a company-wide setting. It's either enabled for all projects or disabled for all projects within your company. Owners can configure project settings, manage access, and delete projects when they also have the `Can delete project` permission. Members can view and interact with security data but cannot modify project configuration or manage access. They have access through both paths. Removing them from the team doesn't affect their direct member access, and vice versa. No. When Project Access Control is enabled, users can only see projects they have access to. Projects they cannot access are completely hidden. Yes. API calls and integrations respect the same access control rules as the web interface. Yes, you can toggle Project Access Control on and off. However, each time you disable and re-enable it, you'll need to verify access assignments are still appropriate. Project owners can manage access for their specific projects. Company administrators can manage access for all projects. Regular members cannot manage access. Deactivated users are no longer shown as active project owners or members in the Content Access table, members modal, or CSV export. Company administrators can use **Edit Members** to remove inactive users from selected projects in bulk. No. Access control only affects who can *view* projects and their data. It doesn't change how Corgea scans repositories or generates fixes. *** **Related Documentation:** * [Teams Guide](teams) - Learn how to create and manage teams for efficient access control * [User Management](user_management) - Managing users in your organization **Need Help?** Contact Corgea support for assistance with setting up or managing Content Access Management for your organization. # False Positive Detection Source: https://docs.corgea.app/false_positive Corgea Auto-detects False Positives Corgea uses AI to analyze potential vulnerabilities and determine if they are likely to be false positives. The false positive analysis considers various factors, such as the context of the code, the nature of the vulnerability, and any relevant coding patterns or best practices. The model then provides a result indicating whether the vulnerability is likely to be "valid" or a "false positive", along with a reasoning explaining its assessment. When the model determines that a vulnerability is a false positive, the reasoning provides an explanation for this assessment. By providing this false positive analysis alongside the vulnerability explanation and proposed fix, Corgea aims to help developers quickly identify and prioritize genuine vulnerabilities while avoiding unnecessary effort on false positives. ## Popular examples of False Positives Corgea can detect These are a sample of some of the false positives that Corgea can detect: * Cross-Site Scripting: Checks if user input is properly sanitized or encoded before being reflected in the webpage using established libraries or frameworks. * SQL Injection: Checks if database queries use fully sanitized parameterized statements or prepared statements in a best-practice manner, without including any user-provided or external input that could be manipulated. * Information Exposure: Checks if the sensitive information disclosed is generic or occurs in a development environment. * Uncaught Exception: Checks if the unexpected condition or status is handled through alternative means like logging or monitoring in non-critical parts of the application. * Hard-Coded Password: Checks if the hard-coded password is intended for a non-production environment or used for automated testing. * Password in Configuration File: Checks if the storage of the plaintext password is protected through alternative security measures like encrypted storage or access controls. * Hard-Coded Cryptographic Key: Checks if the hard-coded cryptographic key is used for testing purposes only. * Cross-Site Request Forgery: Checks if anti-CSRF tokens are implemented and validated on the server-side, or if the code is an API where CSRF protection is not applicable. * Missing Support for Integrity Check: Checks if the integrity check is implemented through alternative means like digital signatures or hash validations. * Hard-Coded Credentials: Checks if the hard-coded credentials are used for testing purposes only. * Code Injection: Checks if the code injection point is limited to a controlled environment or if input validation and output encoding are applied. And many more... # Issue Fingerprinting Source: https://docs.corgea.app/fingerprint Learn how Corgea uniquely identifies and tracks security vulnerabilities across scans ## What is Fingerprinting? Fingerprinting is Corgea's intelligent method of uniquely identifying security vulnerabilities in your codebase. Think of it as a "DNA" for each security issue—a unique identifier that allows Corgea to recognize the same vulnerability across different scans, even if the code changes slightly over time. Fingerprinting works automatically in the background. You don't need to configure or maintain it—it's designed to "just work" from the moment you start scanning your code. ## How Does It Work? When Corgea scans your code and identifies a security issue, it creates a fingerprint based on key characteristics of that issue, including: * **Location**: The file path and line number where the issue occurs * **Context**: The specific line of code and its surrounding structure * **Classification**: The type of security vulnerability (e.g., SQL Injection, XSS, etc.) These elements are combined to create a unique, consistent identifier that persists across multiple scans of your codebase. ### AST-Based Intelligence Corgea uses **Abstract Syntax Tree (AST)** analysis to make fingerprinting more intelligent and resilient to code changes. An Abstract Syntax Tree is a structural representation of your code that understands the meaning and relationships between different code elements—not just the text itself. Traditional fingerprinting methods that only look at exact text or line numbers can break easily when you: * Add or remove blank lines or comments * Reformat your code (change indentation, spacing, etc.) * Refactor variable names or function signatures **Why AST matters for you:** By incorporating AST information into fingerprints, Corgea can: * **Recognize the same vulnerability** even when superficial code changes occur * **Focus on semantic meaning** rather than just text matching * **Maintain tracking** through code reorganization and refactoring * **Reduce false positives** when similar-looking but different issues appear AST-based fingerprinting means you get more stable, reliable tracking of security issues throughout your development lifecycle—even as your code evolves. ## Where Is Fingerprinting Used? When you run multiple scans over time, Corgea uses fingerprints to recognize when an issue has: * **Persisted** from previous scans * **Been fixed** and is no longer detected * **Reappeared** after being resolved Fingerprints prevent duplicate issue reporting. If the same vulnerability appears in multiple scans or branches, Corgea recognizes them as the same issue and avoids cluttering your dashboard with duplicates. Every issue's fingerprint is linked to a history that tracks: * When the issue was first detected * Status changes over time * Who was assigned to fix it * Resolution actions taken This gives you a complete audit trail for compliance and security tracking. Your Corgea dashboards and reports use fingerprints to show: * **Unique vulnerability counts** (not inflated by duplicates) * **Trend analysis** over time * **Project-level security metrics** * **Category-based issue distribution** ## When and Why Fingerprints Change While Corgea's fingerprinting is designed to be stable through minor code changes, there are legitimate scenarios where a fingerprint will change. Understanding these helps you interpret your scan results correctly. Understanding when fingerprints change is important for accurate issue tracking and security management. ### Situations That Will Generate a New Fingerprint **What happens:** If you move a file to a different directory or rename it, the vulnerability will get a new fingerprint. **Example:** Moving `src/utils/database.py` to `src/core/db.py` creates a new fingerprint even if the vulnerable code is identical. **Why:** The file path is a core component of the fingerprint. This is intentional—it helps track where vulnerabilities exist in your project structure. **What you'll see:** The old issue may appear as "fixed" and a new issue will be detected in the new location. If you're doing large-scale file reorganization, coordinate with your security team so they understand the context. **What happens:** Major refactoring that changes the structure or context of the vulnerable code will generate a new fingerprint. **Example:** Converting a vulnerable inline SQL query into a database helper function with the same vulnerability would change the AST structure significantly. **Why:** While AST-based fingerprinting handles minor refactoring, substantial structural changes indicate the code context has meaningfully changed. **What you'll see:** The original issue closes and a new one appears, even though the underlying vulnerability pattern remains. When doing major refactoring, treat these as opportunities to fix the vulnerability rather than just moving it. **What happens:** Large insertions or deletions that significantly shift where the vulnerable code sits may change the fingerprint. **Example:** Adding 200 lines of new code above a vulnerability might shift its context enough to change the fingerprint. **Why:** While fingerprinting is resilient to small line number changes, dramatic shifts suggest the code's context within the file has changed. **What you'll see:** The issue might appear to resolve and reappear at a different line number. This is rare due to AST intelligence, but if it happens, verify the issue is truly the same before marking it as a duplicate. **What happens:** If Corgea's analysis determines that an issue should be reclassified (e.g., from "Potential SQL Injection" to "Confirmed SQL Injection"), it gets a new fingerprint. **Example:** Additional context in later scans might elevate or change how a vulnerability is classified. **Why:** The classification is part of what makes an issue unique. Different classifications may require different remediation approaches. **What you'll see:** One issue closes and another with a different severity or type appears at the same location. Pay attention to classification changes—they often indicate important new information about the security risk. **What happens:** Modifying the actual vulnerable line of code (even without fixing it) may change the fingerprint. **Example:** Changing this: ```python theme={null} query = "SELECT * FROM users WHERE id=" + user_id ``` To this: ```python theme={null} query = "SELECT id, name FROM users WHERE id=" + user_id ``` Maintains the SQL injection vulnerability but changes the fingerprint. **Why:** The specific code context is part of the fingerprint. This is actually helpful—it shows that someone touched the code, and it's an opportunity to fix it properly. **What you'll see:** The old issue appears resolved, and a new, similar issue appears. When modifying vulnerable code, take the opportunity to fix the security issue properly rather than just changing it superficially. ### Situations That Won't Change the Fingerprint The following changes typically **won't** affect the fingerprint: * Adding or removing comments * Changing whitespace or indentation * Renaming local variables (in most cases) * Adding code before or after the vulnerable line (within reason) * Reformatting according to style guides * Adding logging or debugging statements nearby ### How to Handle Fingerprint Changes Corgea tracks all historical events by fingerprint, so you can see the timeline of the original issue. Use your version control system to understand what changed between scans. If you're tracking issues in external systems (JIRA, etc.), you may need to update references. A changed fingerprint often means someone modified the vulnerable code—this is a perfect time to ensure the fix is complete and proper. If you believe a fingerprint changed incorrectly or unexpectedly, our team can help investigate. You might wonder: "Why not keep the same fingerprint no matter what?" Here's why Corgea's approach is beneficial: * **Accuracy**: When code context genuinely changes, a new fingerprint ensures you're tracking the current reality of your codebase. * **Visibility**: Fingerprint changes highlight that code was modified, which is valuable information for security teams. * **Flexibility**: It prevents "stale" issue tracking where an issue is marked as fixed but the vulnerability persists in a slightly different form. * **Compliance**: Audit trails are more accurate when they reflect actual code changes, not just continued existence. ## Key Benefits Get an accurate understanding of your security posture without false inflation from duplicate detections. Understand when code changes affect tracked vulnerabilities. Avoid confusion about which issues need attention and which have already been addressed. Continue refactoring and improving code without losing track of security issues. Receive reliable metrics for tracking security improvement over time and demonstrating compliance efforts. Understand the true impact of code changes on security posture. ## Questions? If you have questions about how fingerprinting affects your specific use case, notice unexpected fingerprint changes, or want to understand more about how issues are tracked in your environment, please reach out to your Corgea support team. Contact our support team for assistance with fingerprinting or any other questions. # Applying Fixes Source: https://docs.corgea.app/fixes Start fixing vulnerable code. ## Scanning your repository **Prerequisite** You [registered](https://www.corgea.app/registration/) in Corgea **Prerequisite** You have completed a [scan](/quickstart) Depending on the size of the results in the scan, it may take sometime for results to show up. For a couple of hundred findings, it should take 10 mins. Go to [scanning](/quickstart) to learn more. * Navigate to the [projects](https://www.corgea.app/projects/) page. * Choose a project. * Click on a Scan. * Find an issue row with the `Fix Available` or `On Demand` status. * Click the issue row to open the issue details sidebar. Review the suggested fix in the issue details sidebar before applying it. If the issue is marked `On Demand`, Corgea starts generating the fix when you open the issue. This usually takes 15-30 seconds. Corgea generates fixes using AI and runs quality checks before making them available. We still strongly recommend reviewing the suggested change for correctness and fit in your codebase before applying it. If the fix seems appropriate, there are two ways to apply fixes: * **Option 1**: Corgea Web Application In the issue details sidebar, click on the `Create Pull Request` button. To issue a pull-request from Corgea, you need to setup the appropriate integration with [GitHub](github) or [Azure DevOps](azure_devops). Corgea automatically generates a pull request with issue and fix context. Wait for PR creation to complete, then click `View Pull Request`. Alternatively, use `Download Fix` and select one of the available options: * `Download Git Patch` * `Download Fixed File` * **Option 2**: Corgea IDE Extensions Corgea supports applying fixes locally using our IDE extensions. Corgea supports [Visual Studio Code](vsc_extension), [Visual Studio 2022](vs2022_extension), and [JetBrains IDEs](jetbrains_extension). In Visual Studio Code, click a vulnerability in the sidebar to open issue details, review the suggested fix, then click `Apply Fix` and save the updated files. In a JetBrains IDE, click a finding in the Corgea tool window to open its details, review the suggested fix, then click `Apply Fix` and save the updated files. If the fix is good or bad, please leave a vote, and ideally a comment. We review your feedback and use it to make Corgea better, so we greatly appreciate them. Click `Give Feedback` to open the feedback modal. In the modal, you can select a thumbs up or thumbs down, add an optional comment, and click `Submit`. ## Troubleshooting For issues marked `On Demand`, open the issue details sidebar to generate the fix. If generation fails, or if a previously available fix needs to be regenerated, click `Try Again`. For issues still marked as processing, it might take several minutes to hours for a fix to be generated based on the backlog of other fixes that you sent. Please leave a vote using the thumbs up and down icons, and ideally a comment. We review your feedback and use it to make Corgea better, so we greatly appreciate them. # GitHub Source: https://docs.corgea.app/github Start generating fixes for your repository ## Setup Currently Corgea supports GitHub repositories via the [Corgea GitHub App](https://github.com/apps/corgea). This page will help you setup the GitHub App so Corgea can issue pull requests to scan and fix vulnerabilities. You can install the Github App from our [integrations](https://www.corgea.app/integrations/) page or from an issue as seen in the following steps: Click on the Install button next to the GitHub logo on the Integrations page. Select only one organization to install for and make sure that the organization you selected matches what your typed in previously. GitHub will ask you to accept permissions and select which repositories are accessible. Only repositories that are made accessible to Corgea will be capable of recieving pull requests from Corgea. ## Using Corgea with GitHub Great! You've now connected Corgea with GitHub. The GitHub app will now scan every PR to find and provide suggested fixes, and you can now issue PRs to fix vulnerabilities from Corgea. ## Scanning PRs Corgea scans each pull request for potential vulnerabilities and suggests actionable fixes. PR comments are only placed on lines that are part of the PR diff. For multi-line issues, Corgea anchors the comment to the first changed line within the affected code range. ## Issuing PRs from Corgea You can now issue a PR that fixes an issue from any issue page in Corgea. Click the Create Pull Request button (branch icon). A new tab will open with the pull request created. You may need to disable your pop-up blocker. ## GitHub Permissions When you install the Corgea GitHub App, you'll be asked to grant the following permissions: ### Read access to metadata and repository hooks * **Metadata**: Access basic repository information to identify and track repositories * **Repository hooks**: Receive pull request and push events to automatically trigger security scans ### Read and write access to checks, code, issues, and pull requests * **Checks**: Create and update check runs on pull requests to report security findings and enforce merge-blocking policies * **Code**: Read repository source code for security analysis and write commits when creating fix pull requests * **Issues**: Read issue metadata to provide context for security findings * **Pull requests**: Read pull request metadata and create or update pull requests containing security fixes generated by Corgea ### User Permissions ### Read access to email addresses Used to associate your GitHub account with your Corgea account for authentication and notifications ## Troubleshooting You may not have full permissions in GitHub to install a GitHub App by yourself. In this instance the admin or owner of the GitHub Organization will recieve a request from you in their notifcations. During this waiting period will display that the install is pending. When the Organization owner/admin accepts the request Corgea will recieve a webhook and update your account. You may have chosen the wrong base branch to merge into. In order to change this, close the existing pull request and delete the branch created in GitHub. Currently, you will have to message Corgea support to reset the Issue/Fix for you. In the future, you will be able to delete and reset from the Corgea interface. This is on the roadmap for development. # GitLab Source: https://docs.corgea.app/gitlab Setting up a GitLab Integration in Corgea # Setting up the GitLab Integration with Corgea Corgea's GitLab integration allows you to seamlessly connect your GitLab repositories with Corgea's powerful vulnerability scanning and remediation capabilities. With this integration, you can automatically scan your code for security vulnerabilities during merge requests, and Corgea will provide detailed comments with identified issues and suggested fixes. You can also add repositories from GitLab to Corgea using the Dropsite feature and create Merge Requests directly from Corgea for identified issues. ## Prerequisites Before setting up the GitLab integration, ensure that you have the following: 1. A Corgea account 2. A GitLab account with a repository you want to integrate ## Setting up the Integration Log in to your Corgea account and navigate to the "Integrations" section. Click on the "Add Integration" button and select "GitLab" from the list of available integrations. In the "Add GitLab Integration" form, provide the following information: * **Name**: A descriptive name for your GitLab integration. * **GitLab URL**: The base URL of your GitLab instance (for example, `https://gitlab.com` or `https://gitlab.example.com` for a self-hosted instance). * **Secure Token**: A personal access token with the necessary permissions to access your GitLab repository. You can generate a new token by following the [GitLab documentation](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html). * **Only list member projects**: This option is enabled by default and limits repository selection to projects where the token owner is a member. Disable it to also list other projects the token can access, such as public projects or projects available through administrator or auditor access. * **Comment on Merge Requests**: Check this option if you want Corgea to automatically comment on merge requests with identified vulnerabilities and suggested fixes. Click "Save" to create the GitLab integration. ## Setting up GitLab To enable Corgea to scan your repositories and comment on merge requests, you'll need to configure a few settings in GitLab: **Recommended**: Create a dedicated Corgea user in GitLab so that comments and merge requests appear to come from Corgea. **Option 1: Personal Access Token (under Corgea user)** 1. Create a new GitLab user account named "Corgea" (or similar) 2. Log in to the Corgea user account 3. Go to User Settings > Access Tokens 4. Create a new token with the following scopes: * `api` (Read/Write API access) * `read_api` * `read_repository` * `write_repository` 5. Copy the generated token - you'll need this for the Corgea integration setup **Option 2: Group Access Token** 1. Go to your group's Settings > Access Tokens 2. Create a new group access token with the same scopes as above 3. This token will apply to all projects in the group 4. Copy the generated token - you'll need this for the Corgea integration setup For Project-level webhook: 1. Go to your project's Settings > Webhooks 2. Add a new webhook with the following settings: * URL: `https://www.corgea.app/gitlab_webhook/` (or your provided webhook URL) * Custom header: Add `X-Corgea-UUID` with the value found under the integrations setting page > GitLab > View All * Select triggers: * Merge request events * Comments 3. Click "Add webhook" For Group-level webhook: 1. Go to your group's Settings > Webhooks 2. Follow the same steps as above 3. The webhook will apply to all projects in the group 1. Create a test merge request 2. Verify that Corgea receives the webhook and comments on the merge request 3. Check the webhook's recent deliveries in GitLab to ensure successful communication ## Adding Repositories from GitLab using the Dropsite Log in to your Corgea account and navigate to the Dropsite section. In the "Add your code" step, select the "Connect Corgea" option. Choose the "GitLab" integration from the list of available integrations. Select the repository and branch you want to scan from your GitLab account. Click "Confirm" to initiate the scan. Corgea will retrieve the code from the selected repository and branch, and perform a comprehensive security scan. ## Creating Merge Requests from Corgea Issues When Corgea identifies a security issue and generates a fix, you can create a Merge Request directly from the Issue Details page: 1. Navigate to the Issue Details page for the vulnerability you want to fix 2. Look for the "Issue MR" option in the dropdown menu 3. Click "Issue MR" to have Corgea automatically: * Create a new branch based on your configured base branch * Commit the fix with a descriptive message * Create a Merge Request with the changes * Add a detailed comment explaining the vulnerability and fix (if enabled) The MR link will be displayed on the Issue Details page for easy access. You can then follow your normal GitLab workflow to review and merge the changes. ## How the Integration Works Once the GitLab integration is set up, Corgea will automatically scan your code for vulnerabilities whenever a new merge request is created or updated. Here's how the integration works: 1. When a merge request is created or updated in your GitLab repository, Corgea receives a webhook notification from GitLab. 2. Corgea retrieves the code changes from the merge request and performs a comprehensive security scan. 3. If any vulnerabilities are detected, Corgea will post a comment on the merge request with details about the identified issues and suggested fixes. Comments are only placed on lines that are part of the merge request diff. For multi-line issues, Corgea anchors the comment to the first changed line within the affected code range. 4. You can review the comments and apply the suggested fixes to remediate the vulnerabilities before merging the code. ## Benefits of the GitLab Integration By integrating Corgea with your GitLab repository, you can enjoy the following benefits: * **Automated Security Scanning**: Corgea automatically scans your code for vulnerabilities during the merge request process, ensuring that security issues are caught early in the development cycle. * **Detailed Vulnerability Reports**: Corgea provides detailed information about identified vulnerabilities, including their severity, location, and potential impact. * **Suggested Fixes**: Corgea not only identifies vulnerabilities but also provides suggested fixes to help you remediate the issues quickly and efficiently. * **Seamless Integration**: The GitLab integration seamlessly integrates with your existing development workflow, minimizing disruptions and ensuring a smooth security review process. * **Improved Code Quality**: By addressing security vulnerabilities early in the development cycle, you can improve the overall quality and security of your codebase. * **Flexible Scanning Options**: In addition to automatic merge request scanning, you can use the Dropsite feature to scan repositories from GitLab on-demand. * **One-Click Fix Implementation**: Create Merge Requests directly from Corgea's Issue Details page to implement fixes with minimal effort. By leveraging Corgea's GitLab integration and the Dropsite feature, you can enhance the security of your applications while streamlining your development processes, ultimately delivering more secure and reliable software to your users. # Harness Source: https://docs.corgea.app/harness Comprehensive Guide to Configuring Harness Code with Corgea The Harness Code integration with Corgea lets you scan repositories hosted in Harness Code, receive automated security reviews on every pull request, and create pull requests for code fixes directly from the Corgea platform. Corgea integrates with **Harness Code** (the Git-based SCM inside the Harness platform). It does not require — and is independent of — Harness CI/CD pipelines. Sign in to Harness, then click your username at the bottom-left of the navigation bar and choose **Profile Overview**. Open Harness profile Scroll down to the **My API Keys** section of your profile and click **+ API Key** to create a new key. Create a new Harness API key For production setups we recommend creating a dedicated **Service Account** in Harness (Account Settings → Access Control → Service Accounts) and generating the API key under that account. This keeps Corgea's actions clearly attributable and lets you rotate credentials without affecting any individual user. Give the key a descriptive name such as `corgea-integration`, then click **Save**. Name the Harness API key The API key itself does not authenticate requests — you need to generate a **token** under it. Expand the API key you just created and click **+ Token**. Add a token to the Harness API key Give the token a name (for example `corgea-token`) and an expiration date, then click **Generate Token**. Harness only displays the token value once. Make sure you copy it before closing the dialog — you will not be able to retrieve it later. Generate the Harness token Copy the generated token to your clipboard, then close the dialog. Corgea supports Harness Personal Access Tokens (PATs) in the format `pat...` and Service Account Tokens (SATs) in the format `sat...`. Corgea automatically derives your account ID from the token, so you don't need to provide it separately. Copy the generated Harness token Sign in to Corgea at `corgea.app` (or `{your-instance}.corgea.app` for self-hosted deployments) and open the **Integrations** page from the sidebar. In the **Code Repository Integrations** section, click the **+** button next to **Harness**. Open the Corgea integrations page Paste the PAT or SAT you copied from Harness into the **API Token** field. By default Corgea discovers repositories across the Harness organizations and projects the token can see. If you want to limit which orgs Corgea looks at, enter a comma-separated list of org identifiers in the **Org allowlist** field (for example `default,my-other-org`). Leave it blank to allow all visible orgs. Add Harness integration in Corgea Expand **Optional settings** if you need to adjust any of the defaults: * **Name** — a friendly label for the integration. Useful when connecting multiple Harness accounts. * **Base URL** — defaults to `https://app.harness.io` for Harness SaaS. Override this if you are connecting to a self-hosted Harness installation. * **Gateway prefix** — defaults to `/gateway` (the SaaS prefix). Some self-hosted deployments drop this prefix; in that case clear the field. When you're done, click **Connect**. Optional Harness integration settings Corgea validates your token immediately. On success the integration card will show your Harness account name and you can start binding repositories from the [Projects](https://www.corgea.app/projects/) page — Harness repos appear with the `H` icon and a `//` label. ## How it works * **Repository discovery** — Corgea calls the Harness Code API to list every repository under the orgs/projects your token can access (filtered by the allowlist if you set one). New repositories show up automatically; you can force a refresh from the Projects page. * **Pull request scans** — when you bind a Corgea project to a Harness repo, Corgea registers a per-repo webhook on Harness Code. Subsequent PR opens, reopens, and pushes trigger an incremental scan and post the results as inline review comments on the diff. Corgea also writes a commit status check (`corgea-security-scan`) so PR rules can require it before merging. * **Apply fixes as PRs** — from any Corgea-detected issue you can click **Create Pull Request** to have Corgea push the fix to a new Harness branch and open a PR back into the issue's source branch. * **Corgea Agent** — replies to Corgea's PR comments are routed through the Corgea Agent (when enabled for your company), which can mark issues as false positives, assign them, or answer follow-up questions, threaded under the original review comment. ## Permissions The user or service account that owns the API key must have at least the **Org View** role and **Code Admin** role for the Harness orgs and projects you want Corgea to access. See the [Harness RBAC documentation](https://developer.harness.io/docs/platform/role-based-access-control/rbac-in-harness) for details. ## Supported Harness deployments | Deployment | Supported | Notes | | ------------------------------- | --------- | ------------------------------------------------------------------------- | | Harness SaaS (`app.harness.io`) | ✅ | Works out of the box with the defaults. | | Harness Self-Managed Enterprise | ✅ | Override **Base URL** and, if needed, clear the **Gateway prefix** field. | # Infrastructure as Code (IaC) Scanning Source: https://docs.corgea.app/iac IaC Scanning automatically detects security misconfigurations and exposed secrets in your infrastructure code before deployment. It analyzes configuration files for Kubernetes, Terraform, Docker, CloudFormation, and other IaC tools to identify security risks, compliance violations, and best practice deviations. ## Overview * **What it Does**: IaC Scanning analyzes your infrastructure configuration files to identify security misconfigurations, policy violations, and hardcoded secrets before they reach production. It scans various IaC formats including Kubernetes manifests, Terraform files, Dockerfiles, CloudFormation templates, and more, providing detailed findings with severity ratings and remediation guidance. * **Who it's For**: This feature is designed for DevOps engineers, cloud architects, security teams, and platform engineers who manage infrastructure as code. It's essential for teams adopting cloud-native practices, implementing GitOps workflows, or maintaining compliance requirements in their infrastructure deployments. ## Key Features and Benefits * **Comprehensive IaC Coverage**: Scans infrastructure code across multiple platforms and formats including Kubernetes, Docker, Terraform, CloudFormation, Azure ARM Templates, and Helm charts * **Dual Detection Capabilities**: * **Misconfiguration Detection**: Identifies insecure configurations, missing security controls, excessive permissions, and compliance violations * **Secret Detection**: Finds hardcoded credentials, API keys, tokens, and sensitive data embedded in infrastructure code * **Rich Finding Intelligence**: Provides detailed information including: * Configuration issue descriptions and security impact * Severity ratings (Critical, High, Medium, Low) * Affected resources and file locations * Remediation guidance and best practice recommendations * **Smart Detection**: Automatically identifies IaC files in your repository and applies appropriate security checks based on file type ## Supported Infrastructure Types **File Patterns**: `*.yml`, `*.yaml`, `*.json` Detects issues like: * Privileged containers and insecure capabilities * Missing resource limits and security contexts * Exposed secrets in manifests * Network policy misconfigurations **File Patterns**: `Dockerfile`, `Containerfile` Detects issues like: * Running as root user * Missing health checks * Exposed secrets in build arguments * Insecure base images **File Patterns**: `*.tf`, `*.tf.json`, `*.tfvars`, `tfplan`, `*.tfplan` Detects issues like: * Publicly accessible cloud resources * Unencrypted storage and databases * Overly permissive IAM policies * Missing logging and monitoring **File Patterns**: `*.yml`, `*.yaml`, `*.json` Detects issues like: * Open security groups * Unencrypted S3 buckets * Missing CloudTrail logging * Insecure AWS resource configurations **File Patterns**: `*.json` Detects issues like: * Public blob containers * Disabled encryption * Weak network security rules * Missing diagnostic settings **File Patterns**: `*.yaml`, `*.tpl`, `*.tar.gz` Detects issues in Helm templates similar to Kubernetes manifest checks ## Setup Instructions IaC scanning is not enabled by default. Contact support to enable this feature for your company account. Project must contain at least one supported IaC file to enable infrastructure scanning. ### Configuration Steps Ensure your project contains supported infrastructure files in any of the formats listed above Choose whether to include IaC scanning in full or partial scans Configure alerts for critical misconfigurations and exposed secrets ## Usage Guide ### Key Workflows 1. **Automatic Discovery**: The system automatically identifies IaC files in your repository 2. **Configuration Analysis**: Applies security checks and compliance rules based on file type 3. **Misconfiguration Detection**: Identifies security issues, policy violations, and best practice deviations 4. **Secret Detection**: Scans for hardcoded credentials and sensitive information 5. **Issue Creation**: Creates trackable security issues for each finding 6. **Reporting**: Generates comprehensive reports with prioritized remediation guidance ### Common Misconfiguration Examples ```yaml Kubernetes - Insecure Container theme={null} # ❌ Insecure apiVersion: v1 kind: Pod spec: containers: - name: app image: myapp:latest securityContext: privileged: true # High severity issue ``` ```dockerfile Docker - Running as Root theme={null} # ❌ Insecure FROM ubuntu:latest RUN apt-get update && apt-get install -y myapp CMD ["myapp"] # Running as root ``` ```hcl Terraform - Public S3 Bucket theme={null} # ❌ Insecure resource "aws_s3_bucket" "data" { bucket = "my-data-bucket" acl = "public-read" # Critical severity issue } ``` ### Severity Breakdown **Critical**: Immediate action required, exposes sensitive data or allows unauthorized access * **High**: Should be addressed before deployment, significant security risk * **Medium**: Should be addressed in regular maintenance, moderate security impact * **Low**: Best practice improvements, minimal immediate risk ## Best Practices Integrate IaC scanning into your CI/CD pipeline to catch issues before deployment. * **Shift Left Security**: Scan infrastructure code during development, not just before deployment * **Policy as Code**: Define and enforce organization-specific security policies * **Version Control**: Store all infrastructure code in version control for audit trails * **Least Privilege**: Configure minimal necessary permissions for all resources * **Encryption**: Enable encryption at rest and in transit for all sensitive resources * **Regular Reviews**: Periodically review and update IaC security policies * **Secret Management**: Use secret management tools (Vault, AWS Secrets Manager) instead of hardcoding * **Compliance Alignment**: Map findings to relevant compliance frameworks (CIS, SOC2, etc.) ## Troubleshooting **Solution**: Verify that IaC files are in supported formats and contain valid configuration syntax **Check**: Ensure files are not corrupted or contain parsing errors **Solution**: Focus on Critical and High severity issues first, then address lower severity items **Check**: Consider adjusting severity thresholds based on your organization's risk tolerance **Solution**: Review the specific configuration context - some findings may not apply to your use case **Check**: Use suppression comments or policy exceptions for intentional configurations **Solution**: Check that file extensions match supported patterns **Check**: Verify files are not in ignored directories (.gitignore) ## Related Features * [Secret Scanning](secret-scanning) - Dedicated secret detection across all file types * [Dependency Scanning (SCA)](sca) - Vulnerability scanning for third-party dependencies * [AI-native SAST (BLAST)](blast) - Application security testing for source code # Introduction Source: https://docs.corgea.app/introduction Welcome to Corgea's documentation. ## A letter from the Corgea team Welcome to Corgea, Corgea is an AI-powered application security agent platform built for developers. We help you find and fix security vulnerabilities in your code with precision and speed. In developer terms, think of Corgea as an **AI-powered security agent** that integrates directly into your workflow. We built Corgea because application security tools were designed for security teams, not developers. Yet developers are the ones responsible for securing their applications. This disconnect creates friction, noise, and wasted time. Our AI doesn't just detect vulnerabilities; it understands your code's context, reduces false positives, and generates fixes that actually work. What makes Corgea special is our use of advanced AI combined with static code analysis to detect and fix hard-to-find vulnerabilities—including business logic flaws, authentication issues, and complex code vulnerabilities that traditional tools miss. We're excited to have you here and to be part of your security journey. Sincerely, [The Corgea Team](https://corgea.com/about) ## What can Corgea do? Our flagship scanner uses advanced AI to detect security vulnerabilities that traditional SAST tools miss. BLAST excels at finding: * **Business logic vulnerabilities**: Authentication flaws, authorization issues, and complex business logic bugs * **Code vulnerabilities**: SQL injection, XSS, command injection, and 100+ other vulnerability types * **Context-aware detection**: Understands your code's context to minimize false positives [Learn more about AI-native SAST](blast) Automatically identify known security vulnerabilities in your third-party dependencies across 25+ programming languages and ecosystems. Get detailed CVE information, CVSS scores, and remediation guidance. Supports 25+ programming languages and ecosystems [Learn more about Dependency Scanning](sca) Detect security misconfigurations and exposed secrets in your infrastructure code before deployment. Supports Kubernetes, Terraform, Docker, CloudFormation, Azure ARM Templates, and Helm charts. [Learn more about IaC Scanning](iac) Detect hardcoded credentials, API keys, tokens, and sensitive information in your codebase before they reach production. Uses pattern matching, entropy analysis, and AI-powered contextual understanding. [Learn more about Secret Scanning](secret-scanning) For every vulnerability detected, Corgea generates context-aware fixes that integrate with your existing codebase. Our AI analyzes your code patterns, frameworks, and security controls to provide fixes that actually work. [Learn more about Fixes](fixes) Corgea automatically analyzes vulnerabilities to identify false positives, considering your infrastructure, security controls, and code context. This dramatically reduces noise and lets you focus on real issues. [Learn more about False Positive Detection](false_positive) Enrich Corgea with your business context, security architecture, and environment-specific requirements. Custom policies help Corgea understand your unique infrastructure and generate more accurate findings and fixes. [Learn more about PolicyIQ](policies) ## Get Started Get started with Corgea in less than 5 minutes Connect your GitHub repositories and start securing your code Review the features below to configure Corgea for your team's specific needs and security requirements. ## Learn More Learn how to review and apply AI-generated security fixes Enforce security standards by blocking non-compliant PRs Add team members and manage access permissions Learn about our security practices and compliance # Issue Assignment & Status Management Source: https://docs.corgea.app/issue_assignment Assign and track security issues across your team This feature allows users to assign issues to specific team members and track the status of each issue throughout its lifecycle. It also introduces a new user inbox where users can view and manage their assigned issues. ## Who it's For This feature is designed for development teams, project managers, and anyone involved in the software development process who needs to collaborate on identifying, prioritizing, and resolving issues. ## Key Features and Benefits * Assign code and dependency issues to specific team members for accountability and efficient task management * Track the status of issues, such as "not fixed," "fixed," "false positive," "accepted risk," and more * User inbox provides a centralized location for users to view and manage their assigned issues * Filter and sort issues in the user inbox based on SLA status (due, overdue, escalated) for better prioritization * Streamlined communication through email notifications when issues are assigned or updated ## How to Access This feature is integrated into the main application interface. Users can access the issue assignment and status tracking functionality from the issue details page and the user inbox. ## Setup Instructions No specific setup is required for this feature. It is enabled by default for all users with the appropriate permissions. ## Usage Guide ### Assigning Issues Go to the issue details page Locate the "Assignment & Status" section Select the desired assignee from the dropdown menu The assignee will receive an email notification with the issue details ### Updating Issue Status On the issue details page, locate the "Actions" section Select the appropriate status for the issue (e.g., "fixed," "false positive," "accepted risk") Optionally, provide a comment explaining the status update Click "Update Status" to save the changes ### Managing Accepted Risk Issues When marking an issue as "Accepted Risk," you can optionally set an expiry date. When this date passes, the issue automatically reverts to Open status and a notification is sent. Select "Accepted Risk" from the status dropdown Click the expiry date field to select when this risk status should expire, or leave it empty if you don't want it to expire Click "Update Status" to apply the changes Accepted Risk Expiry Date Input ### Using the User Inbox Navigate to the user inbox from the main navigation menu Review the list of issues assigned to you Filter issues by SLA status using the dropdown menu (due, overdue, escalated) Click on an issue to view its details and take further action ## Examples Here are some common scenarios for using issue assignment and tracking: ### Assigning a Critical Issue A developer discovers a critical security vulnerability in the codebase. They create an issue and assign it to the lead security engineer for immediate attention. ### Marking an Issue as False Positive After investigating a reported issue, a team member determines that it is a false positive. They update the issue status to "false positive" and provide an explanation in the comment section. ### Prioritizing Overdue Issues A project manager filters the user inbox to view only overdue issues. They prioritize these issues based on severity and assign them to available team members for resolution. ## Best Practices * Regularly review and update issue statuses to ensure accurate tracking * Encourage team members to provide clear and concise comments when updating issue statuses * Leverage the user inbox filters to prioritize and focus on critical or overdue issues * Foster a culture of accountability by consistently assigning issues to responsible team members ## Troubleshooting * If you encounter issues with assigning or updating issues, ensure that you have the necessary permissions * If email notifications are not being received, check your spam or junk folder, and verify your email settings * If you experience any other issues, consult the support documentation or contact the support team for assistance # Issue Export Source: https://docs.corgea.app/issue_export Export security findings in various formats including SARIF, CSV, and PDF ## Overview Corgea provides multiple export options for your security findings, allowing you to integrate with various tools and workflows. You can export scan results in industry-standard formats for further analysis, reporting, or integration with other security tools. ## Export Formats ### SARIF Export SARIF (Static Analysis Results Interchange Format) is an industry-standard format for representing the output of static analysis tools. Corgea supports exporting scan results in SARIF 2.1.0 format, making it easy to integrate with various security tools and CI/CD pipelines. #### How to Export to SARIF Go to your project's scan results page, where you can see all detected security issues. Open the export menu from the download icon at the end of the filter row above the issues list. The menu appears on the **SAST**, **Logic & Auth**, **Secret**, and **Code Quality** tabs. Choose **Export to SARIF** to download your security findings in SARIF format. The export honors the filters currently applied to the issues list. Export to SARIF option in the scan export menu The export menu is only enabled after a scan completes. While a scan is still running, the download button is disabled with the tooltip *Downloads are available after the scan completes*. Disabled download button while a scan is still running #### SARIF Report Structure The exported SARIF report follows the SARIF 2.1.0 specification and includes: * **Tool Information**: Details about Corgea as the scanning tool * **Rules**: Definitions of security vulnerabilities, including CWE classifications, a numeric `security-severity` score, and help text * **Results**: Individual security findings with locations, descriptions, and metadata * **Code Flows**: Source-to-sink traces, including propagation steps, when flow context is available for a finding * **Taxonomies**: Project tags and applicable code blocking rules for CI/CD policy evaluation Code flows help compatible tools display the path that untrusted input takes through the application. Each step is labeled `source`, `propagation`, or `sink`. Findings without available flow context are still included with their primary location and description. Each result is mapped to the scanned project's tags through the `corgea_project_tags` taxonomy. Results that violate an active code blocking rule are also mapped to that rule through the `corgea_pr_policies` taxonomy, allowing CI/CD platforms that support SARIF taxonomies to identify policy violations and gate builds. Blocking-rule taxonomies are included only when the person exporting the report has permission to view blocking rules. Each security rule in the SARIF report includes: ```json theme={null} { "id": "CWE-89", "name": "SQL Injection", "shortDescription": { "text": "SQL Injection" }, "fullDescription": { "text": "CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')" }, "helpUri": "https://cwe.mitre.org/data/definitions/89.html", "help": { "text": "CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')\n\nUser-controlled input is concatenated into a SQL query without parameterization.", "markdown": "## SQL Injection\n\nUser-controlled input is concatenated into a SQL query without parameterization." }, "defaultConfiguration": { "level": "warning" }, "properties": { "security-severity": "5.0", "tags": ["security", "corgea", "sast", "CWE-89", "python"] } } ``` The `level` and `security-severity` values are derived from the finding's urgency: critical and high map to `error`, medium to `warning`, and low and informational to `note`. #### Sample SARIF Report You can view a complete sample SARIF report here: [Sample SARIF Report](/samples/corgea_a45fca2d-3684-4586-951e-d8181e78df19.sarif) The sample contains 27 findings across 14 rules, including: * SQL Injection (CWE-89) * OS Command Injection (CWE-78) * Cross-site Scripting (CWE-79) * Path Traversal (CWE-22) * Deserialization of Untrusted Data (CWE-502) * Server-Side Request Forgery (CWE-918) * And other common security vulnerabilities Twelve of the findings carry a `codeFlows` entry, so the sample also shows what source-to-sink traces look like in practice alongside findings that have no flow context. ### CSV Export CSV (Comma-Separated Values) format provides a simple, spreadsheet-compatible export option for your security findings. This format is ideal for: * Creating custom reports and dashboards * Importing into business intelligence tools * Sharing findings with stakeholders who prefer tabular data * Performing bulk analysis in spreadsheet applications When you export from the **Code Quality** view, Corgea applies code quality filters automatically so the CSV contains code quality findings for the selected filters. When you export SCA dependencies, the CSV includes a **Dependency Type** column so you can distinguish direct, transitive, dev, and optional dependencies. The CSV export includes key information about each security finding such as: * Issue ID and Scan ID for tracking * Project name and classification details * Vulnerability type (CWE classification) and urgency level * File location, line number, and programming language * Issue description and severity ratings * Assignee email and name, when an issue is assigned #### Sample CSV Report You can view a complete sample CSV report here: [Sample CSV Report](/samples/corgea_a45fca2d-3684-4586-951e-d8181e78df19.csv) The CSV format includes these columns: * **Issue ID**: Unique identifier for each security finding * **Scan ID**: Identifier linking findings to specific scan runs * **Project Name**: Name of the scanned project * **Classification ID**: CWE identifier (e.g., CWE-89 for SQL Injection) * **Issue Classification**: Human-readable vulnerability name * **Urgency**: Priority level (CR=Critical, HI=High, ME=Medium) * **File**: Path to the affected source code file * **Line Number**: Specific line where the issue was detected * **Language**: Programming language of the affected file * **Assignee Email**: Email address for the assigned user, when available * **Assignee Name**: Name of the assigned user, when available The **Assignee Email** and **Assignee Name** columns are also included when you export findings from the **Advanced Vulnerability Search** page. ### PDF Export PDF export produces a branded, formatted report of a scan's findings that you can share with stakeholders who don't use Corgea. Unlike SARIF and CSV, which are raw data formats built for tooling, the PDF is a presentation-ready document with a cover page, a severity breakdown, and a findings table. #### How to Export to PDF On the scan details page, open the export menu and select **Export as PDF**. The option appears on the **SAST**, **Logic & Auth**, and **Secret** tabs. Export as PDF option in the scan export menu Filter the findings by **Issue types** and **Urgency**. All issue types and urgencies are selected by default. **Findings to export** updates as you change the filters so you can see how many findings the report will contain. Export as PDF modal with issue type and urgency filters Click **Generate PDF**. Corgea builds the report in the background and shows its progress, then the download starts automatically once the file is ready. The file is named `corgea_scan__findings.pdf`. The export menu is only enabled after a scan completes. While a scan is still running, the button is disabled with the tooltip *Downloads are available after the scan completes*. #### What's Included The report always covers the whole scan, so it contains SAST, Logic & Auth, and Secret findings regardless of which tab you opened the export menu from. The **Issue types** and **Urgency** filters in the modal are the only filters applied, and they're independent of the filters set on the scan details page. Corgea always excludes the following from the report: * **False positives**, whether the issue was marked as a false positive or put on hold as one * **Code quality findings**, which is why PDF export isn't offered on the **Code Quality** tab Findings are included regardless of their triage status, so open, fixed, and accepted-risk issues all appear in the report. #### Report Contents The cover page is marked **Confidential** and summarizes the scan: * **Organization**: Your Corgea organization name * **Repository**: The repository URL, or the project name when no URL is available * **Branch** and **Commit**: The branch and commit SHA that was scanned * **Scan date**: When the scan completed * **Total findings**: The number of findings in the report * **Exported**: When the report was generated The findings section that follows contains a severity summary with **Critical**, **High**, **Medium**, and **Low** counts, then a table of every included finding: * **Severity**: The urgency of the finding * **Issue type**: The CWE classification * **File & line**: The affected file path and line number * **Description**: A shortened description of the finding * **Link**: An **Open** link back to the full issue in Corgea Findings are sorted by severity, from Critical down to Low. #### Limits PDF reports are capped at 5,000 findings. If more findings match your filters, Corgea includes the highest-severity findings first and the modal warns you how many findings matched in total. For larger data sets, use the CSV or SARIF export instead, which are capped at 25,000 findings. The **Generate PDF** button is disabled when no findings match your filters. Generated reports are available for one hour, after which the download link expires and you'll need to generate the report again. PDF export is only available in the Corgea web app. The scan report API and the CLI don't produce PDF output, so use SARIF for automated reporting workflows. ### Dependency Exports The **Container** and **Dependencies** tabs have their own export controls rather than the SARIF, CSV, and PDF menu described above, because they list packages instead of code findings. Viewing dependencies, downloading SBOM files, and exporting dependency CSVs require the **View SCA Issue** permission. See [Software Composition Analysis](/sca) for the full dependency workflow. #### Findings CSV The download icon at the end of the filter row exports the dependency findings that match your current search and filters, including the ecosystem, reachability, dependency type, and criticality selections. Export findings to CSV on the Dependencies tab #### SBOM **Project Dependencies** opens a modal listing every dependency Corgea resolved for the scan, whether or not it has a vulnerability. Project Dependencies button on the Dependencies tab Click **Export SBOM** in that modal to download a software bill of materials for the scan. Export SBOM button in the Project Dependencies modal #### Dependency Coverage When dependency coverage is enabled for your organization, the **Dependencies** tab also shows a **Dependency Coverage** panel with an **Export coverage** button. This CSV reports which manifests Corgea parsed and which dependencies it could not resolve, which is useful for confirming that a scan covered everything you expected. The coverage panel and its export are specific to the **Dependencies** tab. The **Container** tab offers only the findings CSV. ## Integration Benefits ### SARIF Integration Advantages * **Tool Compatibility**: SARIF files can be consumed by various security tools, IDEs, and CI/CD systems * **GitHub Integration**: GitHub natively supports SARIF for security alerts and code scanning * **Standardized Format**: Industry-standard format ensures compatibility across different platforms * **Rich Metadata**: Includes detailed location information, severity levels, and remediation guidance When exporting from the **Code Quality** view, SARIF export follows the same scoped filtering and includes only code quality findings that match your current selection. ### Use Cases * **CI/CD Pipeline Integration**: Automatically process SARIF reports in your build pipeline * **Security Dashboard Integration**: Import findings into centralized security management platforms * **Compliance Reporting**: Generate standardized reports for security audits and compliance requirements * **Developer Workflow**: Integrate with IDEs that support SARIF for inline security feedback ## Best Practices * **Regular Exports**: Set up regular exports to track security improvements over time * **Version Control**: Store exported reports alongside your code for historical tracking * **Automated Processing**: Use SARIF exports in automated workflows for continuous security monitoring * **Tool Integration**: Leverage SARIF compatibility to integrate with your existing security toolchain ## Technical Specifications ### SARIF Version Corgea exports use SARIF version 2.1.0, ensuring compatibility with the latest tools and platforms. ### File Size Considerations Large projects may generate substantial SARIF files. Consider filtering results or exporting specific vulnerability types for very large codebases. ### Schema Validation All exported SARIF files conform to the official SARIF 2.1.0 JSON schema, ensuring reliable parsing by compatible tools. # JetBrains IDEs Source: https://docs.corgea.app/jetbrains_extension Bring Corgea to IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains IDEs ## Introduction Corgea is a plugin for IntelliJ-based IDEs that finds insecure code in your project and applies AI-generated fixes without leaving the editor. It works with IntelliJ IDEA, PyCharm, WebStorm, GoLand, PhpStorm, RubyMine, CLion, Rider, DataSpell, DataGrip, and Android Studio. For any issues or support, please email [support@corgea.com](mailto:support@corgea.com). ## Features * **Security Scanning**: Scan the whole project, or only your uncommitted changes. * **Code Vulnerabilities**: Browse findings grouped by file, with severity and line numbers. * **Dependency Vulnerabilities**: Browse SCA findings grouped by package, with CVE identifiers and fix versions. * **Editor Highlighting**: Vulnerable lines are underlined and marked with a gutter icon. * **Finding Details**: Read the explanation for a finding and preview the suggested fix as a diff. * **One-Click Fixes**: Apply an AI-generated patch from the gutter, the context menu, or `Alt+Enter`. * **Live Scan Progress**: Watch each scan step and its CLI output while results stream into the tool window. * **OAuth and API Key Authentication**: Sign in with either method, including on enterprise and self-hosted servers. ## Prerequisites Before installing the Corgea plugin, ensure you have the following: * **Corgea account**: have an active Corgea account. * **A JetBrains IDE (2024.3 or later)**: any IntelliJ-based IDE, including Android Studio Meerkat (2024.3.1) and later. * **Corgea CLI**: required to run scans from the IDE. Browsing findings from existing scans does not require it. See the [CLI installation guide](/cli#installation-guide). ## Installation Guide ### Step 1: Open the Plugins Settings 1. Open your JetBrains IDE. 2. Go to `Settings` > `Plugins`. ### Step 2: Install the Plugin 1. Select the `Marketplace` tab and search for "Corgea". 2. Click `Install`. You can also install the plugin from its [JetBrains Marketplace page](https://plugins.jetbrains.com/plugin/33252-corgea). ### Step 3: Restart the IDE 1. Click `OK` to close the settings dialog. 2. Restart the IDE when prompted so the plugin loads. ### Step 4: Login 1. Open the `Corgea` tool window from the right sidebar. 2. Confirm your Corgea URL. If you are using the default URL (corgea.app), it will be prefilled. Customers on a single-tenant instance should enter their own server URL. 3. Click `Login with OAuth` and authorize the plugin in your browser. The IDE picks up the token automatically. 4. To use an API key instead, click `Login with API Key`. This key can be obtained from your Corgea dashboard under the integrations section. Your credentials are stored in the IDE's password safe. ## Usage ### Running a Scan * Open the `Scanning` tab in the Corgea tool window. * Click `Full Scan` to scan the entire project, or `Scan Uncommitted Changes` to scan only modified files. * You can also start a scan from `Tools` > `Corgea` > `Full Scan` or `Tools` > `Corgea` > `Scan Uncommitted Changes`. * While a scan runs, the tab shows each step as it completes along with the CLI output, and the results tabs refresh themselves as findings arrive. ### Viewing Code Vulnerabilities * The `Code` tab lists vulnerabilities grouped by file, with a severity label and the affected line number. * Click a finding to jump to the affected line in the editor. Vulnerable lines are underlined and marked with a gutter icon. ### Viewing Finding Details * Click a finding to open its details in a new editor tab. The details view shows the classification, severity, an issue explanation, and a fix explanation. * When Corgea has generated a fix, the `Suggested Change` section shows it as a side-by-side diff so you can review it before applying anything. * Click `Open Source` to jump to the vulnerable code, or `Open in Corgea` to view the finding in the web application. ### Applying Fixes * To apply a fix, click the `Apply Fix` button in the details view. Corgea updates the related files automatically. * You can also apply a fix directly from the editor: click the gutter icon on a highlighted line, press `Alt+Enter` and select `Apply Corgea fix`, or right-click and choose `Corgea` > `Apply Corgea Fix`. * Corgea generates fixes with AI and runs quality checks before surfacing them, but you should still validate the change in your codebase. * Save the updated files. ### Viewing Dependency Vulnerabilities * The `Dependencies` tab lists SCA findings grouped by package, with the severity, CVE identifier, and the version that resolves the vulnerability. * Click a finding to open its details, showing the package registry, the current and fixed versions, and a description of the vulnerability. * Click `Open in Corgea` to view the finding in the web application. ### Logging Out * To log out or sign in as another user, click `Logout` in the Corgea tool window. ## Release Notes Full release notes are found on the plugin's [JetBrains Marketplace page](https://plugins.jetbrains.com/plugin/33252-corgea/versions). # JIRA Source: https://docs.corgea.app/jira Setting up the JIRA Integration in Corgea Corgea's JIRA integration allows you to automatically create JIRA tickets for security issues found in your codebase and dependencies. This integration streamlines the process of tracking and managing security vulnerabilities within your existing JIRA workflow. ## Prerequisites Before setting up the JIRA integration, ensure that you have the following: * A JIRA account with administrative privileges * Your JIRA instance URL (e.g., `https://mycompany.atlassian.net`) * A JIRA API token ([How to create a JIRA API token](https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/)) ## Setting up the Integration Log in to your Corgea account and navigate to the "Integrations" page. Locate the "JIRA" integration and click the "Add" or "Edit" button to open the JIRA integrations page. Create JIRA Integration Click "Add Integration" and enter the following details: * **Name**: A friendly name for the integration (e.g., "My JIRA Instance") * **Base URL**: Your JIRA instance URL (e.g., `https://mycompany.atlassian.net`) * **Username**: Your JIRA username * **API Token**: Your JIRA API token * **Project Key** (optional): The default JIRA project key to use when creating issues * **Issue Type** (optional): The default JIRA issue type to use when creating issues Click "Save" to complete the integration setup. ## Creating JIRA Issues Navigate to either a code issue or dependency issue in Corgea and open the issue details page. On the issue details page, select the ticket icon button (tooltip: "Create Ticket"). Create Ticket Button If you haven't specified default values for the project key and issue type during the integration setup, you'll need to provide them here. Corgea will automatically fetch your projects and the issue types for you to select. Create Ticket Click the "Create JIRA Ticket" button. Corgea will create a new JIRA issue with the relevant details. You'll receive a confirmation message with a link to the newly created JIRA ticket. ## Customizing JIRA Ticket Details By default, Corgea populates the JIRA ticket with the following information: * **Summary**: * Code issues: issue classification and file location * Dependency issues: CVE, affected package, and affected version * Summaries that exceed Jira's length limit are automatically shortened * **Description**: * Vulnerability details (location/package, category, severity) * Issue explanation * Proposed fix (if available) * Link to the issue details page in Corgea If you need to include additional fields or customize the ticket details, you can modify the JIRA ticket after it's created in your JIRA instance. ## Managing Multiple JIRA Integrations If you have multiple JIRA instances or projects, you can set up multiple JIRA integrations in Corgea. When creating a JIRA ticket, you'll be prompted to select the appropriate integration to use. From the JIRA integrations page, you can edit an existing integration or delete an integration you no longer need. When editing an integration, leave the API token blank to keep the existing token, or enter a new token to replace it. By integrating Corgea with JIRA, you can streamline your security vulnerability management process and ensure that critical issues are tracked and addressed within your existing workflow. # JWT Auth Source: https://docs.corgea.app/jwt-token Authenticate API requests using JWT Bearer tokens issued by your identity provider (Entra ID, Okta, etc.) for system-to-system integrations. ## Overview JWT Token authentication lets you call the Corgea API using Bearer tokens issued directly by your identity provider (IdP) — such as Microsoft Entra ID or Okta — instead of a user-specific Corgea API token. This is the recommended approach for **system-to-system integrations** (CI/CD pipelines, automated scanners, internal tooling) where you want: * Tokens tied to a service principal or app registration rather than a specific user account * Token lifetime and scope controlled by your IdP * Centralized revocation through your IdP without touching Corgea A Corgea API token is always tied to an individual user. If that user leaves or their account is deactivated, any automation using their token breaks. JWT Auth decouples authentication from user accounts entirely. ## How It Works 1. Your system requests an access token from your IdP using client credentials (client ID + secret). 2. The IdP returns a signed JWT containing claims such as `iss` (issuer) and `aud` (audience). 3. Your system passes the token as a `Bearer` token in the `Authorization` header when calling the Corgea API. 4. Corgea validates the token signature against the IdP's public keys and checks that the `iss`, `aud`, and `appid`/`cid` claims match your registered configuration. ## Using JWT with Corgea CLI You can use a JWT access token directly with the CLI login flow: ```bash theme={null} corgea login YOUR_JWT_TOKEN ``` Or set it via environment variable: ```bash macOS / Linux theme={null} export CORGEA_TOKEN="your-jwt-access-token" corgea login ``` ```powershell Windows theme={null} $env:CORGEA_TOKEN="your-jwt-access-token" corgea login ``` ## Setting Up JWT Auth in Corgea Navigate to **Settings → Integrations** and click **+ Add** in the **JWT Auth** section. Add JWT Auth Configuration form in Corgea Fill in the following fields: | Field | Description | | --------------------------- | ----------------------------------------------------------------------------------- | | **Name** | A descriptive label for this configuration (e.g., `Entra CICD Pipeline`). | | **Issuer** | The token issuer URL — must match the `iss` claim in the access token. | | **Audience** | Must match the `aud` claim in the access token. | | **Allowed Application IDs** | One client ID per line — the application that is allowed to use this configuration. | Use [jwt.io](https://jwt.io) to decode an access token from your IdP and verify the exact values of `iss`, `aud`, and `appid`/`cid` before filling in this form. **Provider-specific values:** * **Entra ID issuer**: `https://sts.windows.net/{your-tenant-id}/` * **Entra ID audience**: your app's Application ID URI (e.g., `api://{client_id}`) — set via **Expose an API** in Entra * **Okta issuer**: `https://{domain}.okta.com/oauth2/default` * **Okta audience**: `api://default` (or the custom authorization server audience) ## Microsoft Entra ID Setup In the [Azure portal](https://portal.azure.com), go to **Microsoft Entra ID → App registrations → New registration**. Give the app a descriptive name (e.g., `corgea-cicd`) and register it. Go to **Expose an API** in your app registration. Set or confirm the **Application ID URI** — this becomes the `aud` claim in tokens issued for this app. Expose an API in Microsoft Entra Copy the Application ID URI (e.g., `api://5d63c8f0-c9a8-4195-90ee-a9e27e4510b8`) — you will enter this as the **Audience** in Corgea. Go to **Certificates & secrets → New client secret**. Add a description and set an expiry, then click **Add**. Add a client secret in Microsoft Entra Copy the secret **Value** immediately — it is only shown once. Store it securely (e.g., in your CI/CD secrets store). Your system requests a token from Entra using the client credentials flow: ```bash macOS / Linux theme={null} curl -X POST \ https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token \ -d "grant_type=client_credentials" \ -d "client_id={client-id}" \ -d "client_secret={client-secret}" \ -d "scope=api://{client-id}/.default" ``` ```powershell Windows theme={null} Invoke-RestMethod -Method Post ` -Uri "https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token" ` -Body @{ grant_type = "client_credentials" client_id = "{client-id}" client_secret = "{client-secret}" scope = "api://{client-id}/.default" } ``` The response contains an `access_token`. Pass this as a Bearer token when calling Corgea: ```bash macOS / Linux theme={null} curl -H "Authorization: Bearer {access_token}" https://www.corgea.app/api/... ``` ```powershell Windows theme={null} Invoke-RestMethod -Uri "https://www.corgea.app/api/..." ` -Headers @{ Authorization = "Bearer {access_token}" } ``` Replace `https://www.corgea.app` with `https://your_instance.corgea.app` if you are on a private deployment. In Corgea's **Add JWT Auth Configuration** form, enter: * **Issuer**: `https://sts.windows.net/{your-tenant-id}/` * **Audience**: the Application ID URI from Step 2 (e.g., `api://5d63c8f0-...`) * **Allowed Application IDs**: the **Application (client) ID** from your app registration Click **Add** to save. ## Testing with Postman If you prefer a GUI over curl, you can test the token request and API call directly in Postman. **Import a curl command** Postman can convert any of the curl commands above into a request. Click **Import** in the top-left, paste the curl command, and Postman will populate the method, URL, headers, and body automatically. Importing a curl command into Postman **Request an access token** Fill in your `tenant-id`, `client_id`, `client_secret`, and `scope` in the body fields, then send the request. Copy the `access_token` value from the response. Requesting an access token in Postman using client credentials **Call the Corgea API with the token** Create a new request to the Corgea endpoint. Under the **Authorization** tab, set the type to **Bearer Token** and paste the `access_token`. Calling the Corgea API with a Bearer token in Postman If your company restricts outbound network access, you may need to configure a proxy. In Postman, go to **Settings → Proxy** and add your corporate proxy. For curl, set the `HTTPS_PROXY` environment variable or pass `--proxy https://your-proxy:port`. ## Verifying Your Token Use [jwt.io](https://jwt.io) to decode an access token before configuring Corgea. Paste your token in the debugger and inspect the **Decoded Payload** to confirm the `iss`, `aud`, and `appid` values. Decoding a JWT token at jwt.io to verify iss and aud claims The highlighted `aud` and `iss` fields are exactly what Corgea checks when validating incoming requests. ## Troubleshooting * **401 Unauthorized**: Decode your token at jwt.io and confirm `iss`, `aud`, and `appid` exactly match the values in your Corgea JWT Auth configuration. * **Token rejected after rotation**: If you rotated your client secret, ensure the new secret is updated in your CI/CD environment. The Corgea configuration itself does not need to change since it validates token claims, not the secret. * **Multiple environments**: Create a separate JWT Auth configuration in Corgea for each application or environment (e.g., staging vs. production) using distinct app registrations with different client IDs. ### Network connectivity issues If the token request or API call fails with a connection error, use these commands to investigate whether a firewall or proxy is blocking the traffic. ```bash macOS / Linux theme={null} # Check DNS resolution nslookup login.microsoftonline.com nslookup www.corgea.app # Check TCP connectivity on port 443 nc -zv login.microsoftonline.com 443 nc -zv www.corgea.app 443 # Trace the network path traceroute login.microsoftonline.com # Test with verbose curl output (shows TLS handshake and redirect chain) curl -v https://login.microsoftonline.com # Test through a proxy if required curl -v --proxy https://your-proxy:port https://login.microsoftonline.com ``` ```powershell Windows theme={null} # Check DNS resolution Resolve-DnsName login.microsoftonline.com Resolve-DnsName www.corgea.app # Check TCP connectivity on port 443 Test-NetConnection -ComputerName login.microsoftonline.com -Port 443 Test-NetConnection -ComputerName www.corgea.app -Port 443 # Trace the network path tracert login.microsoftonline.com # Test with verbose curl output curl.exe -v https://login.microsoftonline.com # Test through a proxy if required curl.exe -v --proxy https://your-proxy:port https://login.microsoftonline.com ``` If the TCP connection test fails or traceroute stops at an internal hop, contact your network or security team to allow outbound HTTPS (port 443) to `login.microsoftonline.com` and `www.corgea.app`. # Legal Source: https://docs.corgea.app/legal Corgea's Legal Documents ## Terms of Service Our [Terms of Service](terms-of-service) outline the rules and guidelines for using our platform. This document is vital to understand your rights and responsibilities as a user, helping you make the most of our services in a secure and compliant manner. ## Privacy Policy Your privacy matters. Dive into our [Privacy Policy](privacy-policy) to understand how we collect, use, protect, and handle your personal information. This is crucial for ensuring that you feel safe and informed while using our services. For support on legal matters please [email us](mailto:legal@corgea.com). # Linear Source: https://docs.corgea.app/linear Setting up the Linear Integration in Corgea Corgea's Linear integration allows you to automatically create Linear issues for security issues found in your codebase and dependencies. This integration streamlines the process of tracking and managing security vulnerabilities within your existing Linear workflow. ## Prerequisites Before setting up the Linear integration, ensure that you have the following: * A Linear workspace you have access to * A Linear personal API key, created in Linear under **Settings > API** ([How to create a Linear API key](https://linear.app/docs/api-and-webhooks)) * The **Manage Integration** permission in Corgea to add, edit, or delete an integration, and **View Integration** to see the ones already configured (see [Permission Groups](/permission_groups)) A Linear personal API key inherits your own permissions in the workspace. Create the key from an account whose access matches what you want Corgea to be able to do. Corgea stores the key encrypted and never displays it again after you save it. Only personal API keys are supported. OAuth is not currently available. The Linear integration is available on the Starter plan and above. On the Free plan, Corgea prompts you to upgrade instead of opening the Linear integrations page. ## Setting up the Integration Log in to your Corgea account, navigate to the "Integrations" page, and find "Linear" under **Ticketing Integrations**. Linear listed alongside JIRA under Ticketing Integrations Click "Add" to open the Linear integrations page. Once you have at least one integration configured, this button reads "Edit" and shows how many are set up. The Linear integrations page before any integration has been added Click "Add Integration" and enter the following details: * **Name**: A friendly name for the integration (e.g., "My Linear Workspace") * **API Key**: Your Linear personal API key * **Team Default** (optional): The ID of the Linear team to preselect when creating issues * **Project Default** (optional): The ID of the Linear project to preselect when creating issues Both defaults take a Linear ID rather than a name. Leave them blank to choose a team and project each time you create a ticket. The Add Linear Integration dialog Click "Save" to complete the integration setup. Corgea verifies the API key against Linear before saving, so an invalid key is rejected immediately and nothing is stored. The Add Linear Integration dialog showing an invalid API key error ## Creating Linear Issues Navigate to either a code issue or dependency issue in Corgea and open the issue details page. In the issue sidebar, select the signpost icon button (tooltip: "Create Linear Ticket"). If you also have JIRA connected, its button sits alongside this one. The Create Linear Ticket button in the issue sidebar Select the integration to file against, then the team. If you haven't specified default values for the team and project during the integration setup, you'll need to provide them here. Corgea will automatically fetch your teams, and selecting a team loads that team's projects. The project is optional. Select "No project" to file the issue against the team without a project, or to undo a project you already picked. The Create Linear Ticket dialog with integration, team, and project selectors Click the "Create Ticket" button. Corgea will create a new Linear issue with the relevant details. The new Linear issue opens in a new browser tab and Corgea shows a confirmation notification. The issue details page then displays a "View Ticket" link to the Linear issue. Creating a ticket sends the finding's explanation, file path, and proposed fix to Linear, so it follows the same access rules as the finding itself: you need permission to view the finding and access to the project it belongs to. If you can't open the finding in Corgea, you can't file it to Linear. If Corgea cannot reach Linear or the API key lacks permission to create issues, the error is shown in the dialog and no ticket is recorded. If Linear creates the issue but Corgea cannot link it back to the finding, the dialog shows an "Open in Linear" link to the new issue and disables "Create Ticket" so a retry cannot create a duplicate. Reload the issue details page once you have noted the Linear issue. "Create Ticket" also stays disabled while Corgea is loading teams and projects, so a ticket is never filed before your default project has been applied. ## Customizing Linear Issue Details By default, Corgea populates the Linear issue with the following information: * **Title**: * Code issues: issue classification and file location * Dependency issues: CVE, affected package, and affected version * **Description**: * Vulnerability details (location/package, category, severity) * Issue explanation * Proposed fix, including the code diff when Corgea generated one. Long diffs are truncated, and the section reads "Corgea couldn't generate an auto-fix" when no fix is available. * Project information: project name, scan ID, and scan date (code issues) * References: links to the MITRE CWE entry, the Corgea CWE database, and the affected file in GitHub or GitLab where available (code issues) * Link to the issue details page in Corgea The description is written as Markdown, so Linear renders the headings, links, and diff block natively. If you need to include additional fields or customize the issue details, you can modify the Linear issue after it's created in your Linear workspace. ## Managing Multiple Linear Integrations If you have multiple Linear workspaces, you can set up multiple Linear integrations in Corgea. When creating a Linear issue, you'll be prompted to select the appropriate integration to use. ### Editing an integration On the Linear integrations page, select the pencil icon on the integration you want to change. The edit button on a Linear integration Leave the API key blank to keep the existing key, or enter a new key to replace it. Because Corgea never returns a stored key to the browser, this field always starts empty rather than showing the current value. The Edit Linear Integration dialog ### Deleting an integration Select the trash icon on the integration you want to remove. The delete button on a Linear integration Corgea opens a confirmation page naming the integration before removing it. Deleting an integration only disconnects the workspace from Corgea. The Linear issues it already created are left untouched. The confirmation page shown before deleting a Linear integration By integrating Corgea with Linear, you can streamline your security vulnerability management process and ensure that critical issues are tracked and addressed within your existing workflow. # Malicious Package Detection Source: https://docs.corgea.app/malware-scanning Malicious package detection flags known malicious and compromised packages in your dependencies, such as typosquats, hijacked releases, and backdoored versions, before they reach production. ## Overview * **What it Does**: As part of dependency scanning, Corgea flags **known malicious and compromised packages** in your project's dependencies. Unlike a typical vulnerability, a malicious package is one that has been intentionally crafted or tampered with to harm the systems that install it — for example through data exfiltration, credential theft, backdoors, or cryptocurrency mining. * **Who it's For**: Security teams and developers who want to protect their software supply chain from malicious open-source packages. ## What It Detects Malicious package detection covers packages that are known to be harmful, including: * **Typosquats**: Packages named to imitate popular libraries so they get installed by mistake * **Hijacked releases**: Legitimate packages whose maintainer account or pipeline was compromised to publish a malicious version * **Backdoored versions**: Package versions that contain intentionally hidden malicious functionality * **Protestware and sabotage**: Packages modified to intentionally disrupt or damage the systems that install them ## How It Works Malicious package detection runs as part of [Dependency Scanning (SCA)](/sca). Corgea resolves your direct and transitive dependencies and checks them against authoritative databases of known-malicious packages, including the **OpenSSF Malicious Packages** database and related advisory feeds. When a match is found, Corgea reports it alongside your other dependency findings. ## Supported Ecosystems Malicious package detection applies to the same package ecosystems as dependency scanning, including npm, PyPI, RubyGems, Maven, and more. See the full list in [Dependency Scanning (SCA)](/sca). ## How It Surfaces * Malicious packages appear in your scan results alongside other dependency findings. * They are treated as high-priority issues because a confirmed malicious package represents an active threat rather than a potential weakness. * The affected package, version, and the manifest that introduced it are shown so you can trace where it came from. ## Remediation A confirmed malicious package should be treated as an urgent issue. Remove it as soon as possible. * **Remove or replace** the malicious package with a trusted alternative. * If the malicious behavior was introduced in a specific version, **pin to a known-good version** that predates the compromise. * For transitive dependencies, identify the parent package that pulled it in and upgrade or replace that parent. See [transitive dependencies](/sca#transitive-dependencies) for how to trace the dependency path. * Rotate any secrets or credentials that may have been exposed while the package was installed. ## Related * [Dependency Scanning (SCA)](/sca) — scan your application's third-party dependencies * [Container Image Scanning](/container-scanning) — scan base images for vulnerabilities # Model Context Protocol (MCP) Source: https://docs.corgea.app/modelcontextprotocol Connect AI assistants to Corgea using the Model Context Protocol Corgea supports the [Model Context Protocol (MCP)](https://modelcontextprotocol.io/), allowing AI assistants like Claude to directly interact with your security scans, issues, and policies. MCP enables AI models to understand your security context and provide more relevant assistance. ## What is MCP? The Model Context Protocol is an open standard that enables AI models to securely connect to external data sources and tools. With Corgea's MCP integration, AI assistants can: * Query your security scan results * Retrieve vulnerability details * List and filter security issues * List and filter code quality issues * Access SCA, IaC, and dependency inventory data * Check blocking rules and policies ## Getting Started ### Prerequisites * A Corgea API token (get it from your account settings) * An MCP-compatible client (e.g., Claude Desktop, Continue, or any MCP client) ### Connection Details **MCP Server URL:** ``` https://www.corgea.app/mcp ``` Or for single-tenant deployments: ``` https://.corgea.app/mcp ``` **Authentication:** All MCP requests require authentication using your Corgea API token in the `CORGEA-TOKEN` header. Corgea supports stateless MCP requests over POST with JSON responses. Standalone server-sent event (SSE) streams are not supported. ## Available Tools Corgea's MCP server provides the following tools for AI assistants: ### get\_scan\_info Get detailed information about a specific SAST scan. **Parameters:** * `scan_id` (string, required): The unique identifier of the scan **Returns:** Detailed scan information including status, findings count, scan date, and repository information. **Example:** ```json theme={null} { "scan_id": "abc123", "status": "completed", "created_at": "2024-11-01T10:30:00Z", "findings_count": 15, "project": "my-project", "repository": "https://github.com/myorg/myrepo" } ``` *** ### get\_issue\_info Get detailed information about a specific security issue. **Parameters:** * `issue_id` (string, required): The unique identifier of the issue * `include_reachability` (boolean, optional): Include endpoint reachability details for the issue **Returns:** Comprehensive issue details including vulnerability type, severity, location, fix recommendations, remediation status, and optional endpoint reachability details. **Example:** ```json theme={null} { "issue_id": "issue-456", "title": "SQL Injection", "severity": "high", "file": "src/database.py", "line": 42, "description": "User input not properly sanitized", "fix_available": true } ``` *** ### get\_sca\_issue\_info Get detailed information about a specific Software Composition Analysis (SCA) issue. **Parameters:** * `issue_id` (string, required): The unique identifier of the SCA issue **Returns:** SCA issue details including package, severity, CVE, fix version, file location, and dependency reachability analysis. **Example:** ```json theme={null} { "status": "ok", "issue": { "id": "sca-789", "package": { "name": "lodash", "version": "4.17.15", "ecosystem": "npm", "fix_version": "4.17.21" }, "cve": "CVE-2021-23337", "severity": "high", "reachability": { "status": "vulnerable_usage_reachable", "description": "Vulnerable function is reachable from application code", "usages": [] } } } ``` *** ### list\_security\_issues List security issues with optional filtering. **Parameters:** * `scan_id` (string, optional): Filter issues by scan ID * `project` (string, optional): Filter issues by project name * `repo` (string, optional): Filter issues by repository URL * `include_reachability` (boolean, optional): Include endpoint reachability summary for each issue **Returns:** List of security issues matching the specified filters. **Example:** ```json theme={null} { "status": "ok", "count": 25, "issues": [ { "id": "issue-123", "title": "Cross-Site Scripting (XSS)", "severity": "medium", "status": "open" } ] } ``` *** ### list\_code\_quality\_issues List code quality findings separately from security issues, with optional filtering. **Parameters:** * `scan_id` (string, optional): Filter issues by scan ID * `project` (string, optional): Filter issues by project name * `repo` (string, optional): Filter issues by repository URL * `filters` (object, optional): Filter by `urgency`, `status`, `confidence`, `language`, `file_path`, `classification`, `sla_status`, `branch`, `show_false_positives`, or `sort_by` * `page` (integer, optional): Page number * `page_size` (integer, optional): Number of results per page, up to 50 The `classification` field contains the code quality label, such as `Maintainability`, rather than a CWE. False positives are excluded by default. **Returns:** Only code quality issues matching the specified scope and filters. *** ### list\_sca\_security\_issues List Software Composition Analysis (SCA) security issues with optional filtering. **Parameters:** * `scan_id` (string, optional): Filter issues by scan ID * `project` (string, optional): Filter issues by project name * `repo` (string, optional): Filter issues by repository URL * `filters` (object, optional): Filter by fields such as `severity`, `package`, `ecosystem`, `cve`, `path`, `has_fix`, `branch`, `reachability`, or `sort_by` * `include_reachability` (boolean, optional): Include dependency reachability status and description for each SCA issue Supported `reachability` filter values are `not_direct_dependency`, `pending`, `vulnerable_usage_reachable`, `vulnerable_usage_unreachable`, and `dead_dependency`. **Returns:** List of SCA issues including vulnerable dependencies, CVEs, and version information. **Example:** ```json theme={null} { "status": "ok", "count": 12, "sca_issues": [ { "id": "sca-789", "package": "lodash", "current_version": "4.17.15", "fixed_version": "4.17.21", "cve": "CVE-2021-23337", "severity": "high" } ] } ``` *** ### list\_iac\_security\_issues List Infrastructure-as-Code (IaC) security issues with optional filtering. **Parameters:** * `scan_id` (string, optional): Filter issues by scan ID * `project` (string, optional): Filter issues by project name * `repo` (string, optional): Filter issues by repository URL * `filters` (object, optional): Filter by `severity`, `provider`, `service`, `iac_type`, `rule_id`, `avd_id`, `path`, `search`, `sort_by`, or `branch` * `page` (integer, optional): Page number * `page_size` (integer, optional): Number of results per page, up to 50 **Returns:** List of IaC issues including severity, affected service, rule identifiers, file location, and scan context. **Example:** ```json theme={null} { "status": "ok", "page": 1, "total_pages": 1, "total_issues": 1, "issues": [ { "id": "11111111-1111-1111-1111-111111111111", "title": "Public S3 bucket", "severity": "HIGH", "provider": "aws", "service": "s3", "iac_type": "terraform", "location": { "path": "infra/main.tf", "start_line": 10 } } ] } ``` *** ### list\_dependencies List software dependencies discovered during a scan with optional filtering. **Parameters:** * `scan_id` (string, optional): Filter dependencies by scan ID * `project` (string, optional): Filter dependencies by project name * `repo` (string, optional): Filter dependencies by repository URL * `filters` (object, optional): Filter by `name`, `version`, `type`, `path`, `purl`, `license`, `dep_type`, `search`, `sort_by`, or `branch` * `page` (integer, optional): Page number * `page_size` (integer, optional): Number of results per page, up to 50 **Returns:** List of dependencies including package name, version, package URL, license data, dependency relationship, and scan context. **Example:** ```json theme={null} { "status": "ok", "page": 1, "total_pages": 1, "total_dependencies": 1, "dependencies": [ { "id": "22222222-2222-2222-2222-222222222222", "name": "django", "version": "4.2.0", "type": "pypi", "purl": "pkg:pypi/django@4.2.0", "path": "requirements.txt", "licenses": ["BSD-3-Clause"], "is_direct": true } ] } ``` *** ### list\_scans List all SAST scans with optional filtering. **Parameters:** * `project` (string, optional): Filter scans by project name * `repo` (string, optional): Filter scans by repository URL substring * `branch` (string, optional): Filter scans by exact branch name * `pull_request_id` (string, optional): Filter scans by exact pull request or merge request identifier **Returns:** List of scans with basic information including scan ID, date, status, and findings count. **Example:** ```json theme={null} { "status": "ok", "count": 50, "scans": [ { "id": "scan-001", "project": "web-app", "created_at": "2024-11-01T09:00:00Z", "status": "completed", "findings": 8 } ] } ``` *** ### get\_blocking\_rules Get all blocking rules configured for your organization. **Parameters:** None **Returns:** List of blocking rules that prevent deployments based on security policies. **Example:** ```json theme={null} { "status": "ok", "rules": [ { "id": "rule-1", "name": "Block Critical Vulnerabilities", "condition": "severity >= critical", "action": "block", "enabled": true } ] } ``` ## Setting Up MCP Clients ### Claude Desktop Add Corgea to your Claude Desktop configuration: 1. Open Claude Desktop settings 2. Navigate to the "Developer" section 3. Edit your MCP configuration file 4. Add the Corgea MCP server: ```json theme={null} { "mcpServers": { "corgea": { "command": "npx", "args": [ "-y", "mcp-remote", "https://www.corgea.app/mcp", "--header", "CORGEA-TOKEN: ${CORGEA_TOKEN}" ], "env": { "CORGEA_TOKEN": "your_api_token_here" } } } } ``` 5. Restart Claude Desktop for the changes to take effect ### Cursor IDE Add Corgea to your Cursor MCP configuration: 1. Open Cursor Settings (Cmd/Ctrl + Shift + J) 2. Navigate to "Cursor Settings" → "Models" → "MCP" 3. Or directly edit your MCP settings file at: * **macOS/Linux**: `~/.cursor/mcp.json` * **Windows**: `%APPDATA%\Cursor\User\mcp.json` 4. Add the Corgea MCP server: ```json theme={null} { "mcpServers": { "corgea": { "command": "npx", "args": [ "-y", "mcp-remote", "https://www.corgea.app/mcp", "--header", "CORGEA-TOKEN: ${CORGEA_TOKEN}" ], "env": { "CORGEA_TOKEN": "your_api_token_here" } } } } ``` **Alternative Configuration (Direct HTTP):** If you're using a custom MCP client that supports direct HTTP connections: ```json theme={null} { "mcpServers": { "corgea": { "url": "https://www.corgea.app/mcp", "headers": { "CORGEA-TOKEN": "your_api_token_here" } } } } ``` ### Continue IDE Extension Add Corgea to your Continue configuration: ```json theme={null} { "contextProviders": [ { "name": "corgea", "params": { "serverUrl": "https://www.corgea.app/mcp", "headers": { "CORGEA-TOKEN": "your_api_token_here" } } } ] } ``` ## Use Cases ### Security-Aware Code Review Connect your AI assistant to Corgea and ask questions like: * "What are the critical security issues in my last scan?" * "Show me all SQL injection vulnerabilities in the authentication module" * "Are there any high-severity SCA issues in my dependencies?" ### Vulnerability Analysis Let AI help you understand and prioritize vulnerabilities: * "Explain the security issue in issue-456 and suggest how to fix it" * "Which vulnerabilities should I fix first based on severity and exploitability?" * "What are the blocking rules that would prevent this deployment?" ### Automated Remediation Planning Use AI to plan security fixes: * "Create a remediation plan for all high-severity issues in scan-123" * "What dependencies need to be updated to fix SCA issues?" * "Generate a report of all open security issues grouped by file" ## Best Practices * Never commit your API token to version control * Rotate tokens periodically * Use environment variables or secure secret managers * Revoke tokens immediately if compromised * Use project, repo, branch, and pull request filters to narrow results * Start with specific scans when debugging * Filter by severity when prioritizing work * Request only the data you need * Use specific issue/scan IDs when possible * Cache results when appropriate * Respect rate limits ## Authentication All MCP tool calls require a valid Corgea API token passed in the `CORGEA-TOKEN` header. **Getting Your Token:** 1. Log in to your Corgea account 2. Navigate to Settings → API Keys 3. Generate a new API token 4. Copy the token and add it to your MCP client configuration Keep your API token secure. Anyone with access to your token can query your security data through the MCP interface. ## Response Format All MCP tool responses follow the standard Corgea API response format: **Success Response:** ```json theme={null} { "status": "ok", "data": { } } ``` **Error Response:** ```json theme={null} { "status": "error", "message": "Description of the error", "error": "Detailed error information" } ``` ## Rate Limits MCP requests are subject to the same rate limits as standard API requests: * 100 requests per minute per token * 1000 requests per hour per token If you exceed rate limits, you'll receive a `429 Too Many Requests` response. ## Troubleshooting ### Connection Issues **Problem:** Cannot connect to MCP server **Solutions:** * Verify your API token is valid using the `/verify` endpoint * Check that the `CORGEA-TOKEN` header is correctly configured * Ensure your network allows HTTPS connections to corgea.app ### Authentication Errors **Problem:** Receiving 401 Unauthorized responses **Solutions:** * Verify your API token hasn't expired * Check that the token is passed in the `CORGEA-TOKEN` header (not Authorization) * Ensure your token has the necessary permissions ### Empty Results **Problem:** Queries return no data **Solutions:** * Verify data exists in your Corgea account * Check filter parameters (scan\_id, project, repo, branch, pull\_request\_id) are correct * Ensure you're querying the correct environment (multi-tenant vs single-tenant) ## Support Learn more about the Corgea API Get help from the Corgea community Learn about API authentication Read the official MCP documentation ## Next Steps 1. **Get your API token** from your Corgea account settings 2. **Configure your MCP client** with the Corgea server URL and token 3. **Test the connection** by asking your AI assistant about your scans 4. **Explore use cases** like security analysis and vulnerability remediation Start integrating Corgea's security intelligence into your AI-powered development workflow today! # Notifications Source: https://docs.corgea.app/notifications Stay informed about important security events with email and webhook notifications ## Overview Corgea keeps you in the loop on important security events through **email** and **webhook** notifications, so you don't have to keep checking the platform. You can manage your notification preferences from **Settings → Notifications**. ## How It Works Notification preferences in Corgea follow a simple two-level model: 1. **Company defaults** — set by company admins, these apply to everyone in the company. 2. **Personal preferences** — each user can override the company default for their own email notifications. If you haven't set a personal preference, you'll inherit whatever the company admin has configured. ## For Company Admins If you're a company admin, you'll see a **Company Defaults** section at the top of the notifications page. This is where you decide what's turned on by default for your whole company — for both email and webhook delivery. For email notifications sent to everyone in the company, you can also use **Limit to teams** to restrict delivery to members of selected teams. If no teams are selected, Corgea uses the normal audience for that notification type. Team limits do not change webhook delivery, and users in the selected audience can still use their personal email preferences. Notification preferences page for company admins, showing the Company Defaults section ## For Other Users If you're not a company admin, you won't see the Company Defaults section — just your own personal preferences. You can still turn notifications on or off for yourself, or leave them set to inherit from your company's defaults. Notification preferences page for a non-admin user, without the Company Defaults section Webhook delivery requires a configured webhook subscribed to the matching event. See [Webhooks](webhooks) to set one up. ## Available Notifications Corgea currently sends the following notifications. Each one can be turned on or off per company and per user from **Settings → Notifications**. ### Daily Scan Report A daily summary email (and optional webhook) sent when scheduled scans have run, listing new issues found across all scan runs in the last 24 hours. * **Who receives it:** All users in the company (admins can change the company default; individuals can override for themselves) * **Channels:** Email and webhook * **Default:** On for both email and webhook * **Team limits:** Company admins can limit email delivery to selected teams For the webhook payload, see [Webhooks](webhooks#scheduled-scan-daily-report). ### Scheduled Scan Consecutive Failures Sent when a project fails the same scheduled scan three consecutive times because of a persistent configuration problem, such as a missing branch, expired credentials, or invalid repository settings. Corgea sends one email for each failure streak and pauses automatic attempts for that project until you fix the problem and successfully retry it with **Run Now**. * **Who receives it:** Project owners and company admins who have email enabled for this notification * **Channels:** Email * **Default:** On * **Team limits:** Not applicable See [Scheduled Scans](scheduled-scans) for help resolving scan failures and running a schedule again. ### SLA Violation Sent when one or more issues pass their remediation or escalation deadline as set in your [SLA Management](sla_management) configuration. * **Who receives it:** All users in the company (admins can change the company default; individuals can override for themselves) * **Channels:** Email and webhook * **Default:** Email on, webhook off * **Team limits:** Company admins can limit email delivery to selected teams Per-SLA webhook delivery is configured in [SLA Management](sla_management). For the webhook payload, see [Webhooks](webhooks). ### Accepted Risk Expired Sent when an issue that was previously marked as "accepted risk" reaches its expiry date and is automatically reverted to open. * **Who receives it:** Company admins only * **Channels:** Email * **Default:** On ### AI Pentest Completed Sent when an AI penetration test finishes, with a summary of findings and severity breakdown. * **Who receives it:** Company admins only * **Channels:** Email * **Default:** On # Pentesting Source: https://docs.corgea.app/pentesting Run AI-driven penetration tests against configured web application targets Pentesting is currently in beta and must be enabled for your company. If you do not see **Pentests** in the sidebar, contact your Corgea administrator or Corgea contact. Pentesting helps your team run AI-driven penetration tests against web application targets that you configure in Corgea. Use it to test running applications for authentication and authorization issues, business logic flaws, injection risks, and other exploitable behavior that may not be visible from source code alone. ## Targets A target is a reusable pentest configuration. Each target includes a name, URL, optional credentials, optional instructions, and a default scan mode. In Corgea, select **Pentests** from the sidebar. Click **New target**, then enter the target name and URL. Add credentials when the test should cover authenticated areas. Use **Additional instructions** for rules of engagement, scope exclusions, or endpoints the agents should focus on. Select **Balanced** for a faster run or **Deep** for a more thorough assessment. Only add targets that your organization is authorized to test. Credentials are encrypted at rest and used only when a run is picked up for that target. ## Start a Run From the target list, start a new run for the target you want to test. You can use the target's default scan mode or override it for a single run. * **Balanced** runs a faster assessment using the standard pentest agents. * **Deep** runs a more thorough assessment and uses additional red-team coverage. * **Instruction override** replaces the target's additional instructions for that run only. Pentest usage is controlled by your company's plan. If a scan mode is unavailable or out of quota, Corgea disables that option or shows an error when you try to start the run. ## Review Results The run detail page shows progress while agents are working and lists findings as they are reported. Findings are grouped by CWE and endpoint, with severity counts across all findings and focused categories such as Auth & AuthZ, Business Logic, and Injection. Open a finding to review its description, proof of concept, technical analysis, remediation guidance, target, endpoint, agent source, and detection history. You can update the finding status, add comments, and track re-detections across later pentest runs. ## Export Reports When a run completes, use **Export report** to download a PDF report. * **Technical report** includes detailed finding evidence and remediation information. * **Executive report** summarizes the assessment for less technical audiences. Company admins can also receive an **AI Pentest Completed** email notification with a summary and severity breakdown when a pentest finishes. ## Revalidate Findings After a run completes, use **Revalidate Findings** to re-test open or fixed findings from that run. Revalidation checks whether previously reported findings still reproduce, closes findings that no longer reproduce, and keeps the source run's findings available from the validation run page. # Permission Groups Source: https://docs.corgea.app/permission_groups This document provides a comprehensive overview of all permissions available for assignment to permission groups in the Corgea platform. Permissions control what actions users can perform within the system. ## What are Role-Based Permissions? Role-based permissions (also known as Role-Based Access Control or RBAC) is a security model that restricts system access based on a user's role within an organization. Instead of assigning permissions to individual users, permissions are assigned to roles, and users are then assigned to appropriate roles based on their job functions. ### Key Benefits * **Simplified Management**: Assign permissions once to a role, then add users to that role rather than managing permissions for each individual user * **Consistency**: Ensures all users with the same role have identical access rights * **Scalability**: Easy to onboard new team members by assigning them to pre-configured roles * **Security**: Follows the principle of least privilege by granting only the permissions necessary for each role * **Audit & Compliance**: Simplifies access reviews and compliance reporting by organizing permissions around job functions ### How It Works in Corgea In Corgea, you create **Permission Groups** that correspond to different roles in your organization (e.g., Admin, Developer, Security Manager). Each Permission Group is assigned a specific set of permissions that define what actions users in that role can perform. Users are then added to one or more Permission Groups, inheriting all permissions from those groups. Permissions are **additive** - if a user belongs to multiple Permission Groups, they receive all permissions from all groups they are a member of. ## Role-Based Permission Recommendations Based on the permissions defined in the Corgea platform, here's a recommended permission matrix for different roles. ### Role Descriptions Full system access - can manage all aspects of the platform including company settings, users, permissions, and all security features. Can manage development teams, users, projects, and view all security issues. Can initiate scans and manage team assignments but cannot modify security policies. Read access to issues, scans, policies, and teams. Can initiate scans for their projects but has limited management capabilities. Focus on viewing and understanding security issues in their code. Operational focus with full control over integrations, scheduled scans, agent settings, and PR automation rules. Can manage scans and view issues but cannot modify security policies or delete issues. Comprehensive security management including all policy controls, SLAs, blocking rules, and user/team management. Cannot delete permission groups or modify company settings. Hands-on security role with full control over security issues, policies, scans, and agent settings. Focus on day-to-day security operations but without user/team management responsibilities. ### Permission Groups Overview The following are suggested Permission Groups to setup. Corgea comes with the Admin permission out of the box. | Permission | Admin (Default) | Security Manager | Security Engineer | Development Manager | Developer | DevOps | | ------------------------------- | :-------------: | :--------------: | :---------------: | :-----------------: | :-------: | :----: | | **User Management** | | | | | | | | Create User | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | | Edit User | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | | Delete User | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | View User | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | **Issue Management (SAST)** | | | | | | | | Create Issue | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | View Issue | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Delete Issue | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | **SCA Issue Management** | | | | | | | | Create SCA Issue | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | View SCA Issue | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Edit SCA Issue | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | Delete SCA Issue | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | **SAST Scan Management** | | | | | | | | Create SAST Scan | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | View SAST Scan | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Delete SAST Scan | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | | **Project Management** | | | | | | | | Modify Project Tags | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | | Edit Project | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | | Delete Project | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | | **API Token Management** | | | | | | | | View API Token | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Manage API Token | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | | **Policy Management** | | | | | | | | Create Policy | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | Edit Policy | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | View Policy | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Delete Policy | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | **Issue SLA Management** | | | | | | | | Create Issue SLA | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | Edit Issue SLA | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | View Issue SLA | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Delete Issue SLA | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | **Blocking Rule Management** | | | | | | | | Create Blocking Rule | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | Edit Blocking Rule | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | View Blocking Rule | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Delete Blocking Rule | ✓ | ✓ | ✓ | ✗ | ✗ | ✗ | | **PR Scan & Comment Rules** | | | | | | | | Create PR Scan & Comment Rule | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | Edit PR Scan & Comment Rule | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | View PR Scan & Comment Rule | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Delete PR Scan & Comment Rule | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | **Scheduled Scan Management** | | | | | | | | Create Scheduled Scan | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | Edit Scheduled Scan | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | View Scheduled Scan | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | Delete Scheduled Scan | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | **Integration Management** | | | | | | | | View Integration | ✓ | ✓ | ✓ | ✓ | ✗ | ✓ | | Manage Integration | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | | **Permission Group Management** | | | | | | | | Create Permission Group | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | | Edit Permission Group | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | | View Permission Group | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | | Delete Permission Group | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | **Company Management** | | | | | | | | View Company Settings | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | | Edit Company Settings | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | **Corgea Agent Settings** | | | | | | | | View Agent Settings | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | Edit Agent Settings | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | **Skills Registry** | | | | | | | | Create Skill | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | Edit Skill | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | View Skill | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | Delete Skill | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | Approve Skill | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | **Team Management** | | | | | | | | View Team | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | Create Team | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | | Edit Team | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | | Delete Team | ✓ | ✗ | ✗ | ✓ | ✗ | ✗ | | **Content Access Management** | | | | | | | | Manage Content Access | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | ## Best Practices Determine the specific roles and responsibilities within your organization (e.g., Security Analyst, Developer, Manager). Assign only the minimum required permissions for each role to follow the principle of least privilege. Create permission groups that correspond to organizational roles and assign the appropriate permissions. Add users to the appropriate permission groups based on their role and responsibilities. Regularly audit permission assignments to ensure they align with current organizational needs Remove unused permissions and clean up deprecated permission groups Use integration user permissions only for automated systems, not human users Implement regular reviews of high-privilege permissions like user management and policy changes If a user cannot perform an expected action, check their permission group assignments and individual permissions Use the view permissions to audit what access a user or group currently has Remember that permissions are additive - users get all permissions from all groups they belong to ## Permissions Reference Below is a complete reference of all available permissions in the Corgea platform with their descriptions and use cases. ### User Management Permissions | Permission | Description | Use Case | | ------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | **Can add user** | Create new user accounts in the system | Register new team members and set up their accounts | | **Can change user** | Modify existing user account information and settings | Update user profiles, change email addresses, modify user roles, or update account details | | **Can delete user** | Remove user accounts from the system | Deactivate or permanently delete user accounts when team members leave or accounts are no longer needed | | **Can view user** | View user account information and profiles | Access user details, view team member information, or check user status | ### Issue Management Permissions (SAST) | Permission | Description | Use Case | | -------------------- | ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | **Can add issue** | Create new security issues or manually report vulnerabilities | Allow security team members to manually create issues for discovered vulnerabilities or security concerns | | **Can view issue** | View security issues, vulnerabilities, and their details | Access issue reports, review vulnerability details, or monitor security status across projects | | **Can delete issue** | Remove security issues from the system | Clean up false positives, remove resolved issues, or manage issue lifecycle | ### SCA Issue Management Permissions | Permission | Description | Use Case | | ------------------------ | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- | | **Can add sca issue** | Create new SCA issues or manually report dependency vulnerabilities | Manually flag dependency issues, report newly discovered vulnerabilities in third-party components | | **Can view sca issue** | View Software Composition Analysis issues and dependency vulnerabilities | Review third-party library vulnerabilities, check dependency security status, or analyze open source component risks | | **Can change sca issue** | Modify SCA issue details, status, or resolution information | Update issue status, add resolution notes, or modify vulnerability assessment details | | **Can delete sca issue** | Remove SCA issues from the system | Clean up false positives, remove resolved dependency issues, or manage SCA issue lifecycle | ### SAST Scan Management Permissions | Permission | Description | Use Case | | ------------------------ | ---------------------------------------------------- | ------------------------------------------------------------------------------------- | | **Can add SAST Scan** | Initiate new SAST security scans on projects | Start security scans, trigger manual scans, or schedule new security analysis runs | | **Can view SAST Scan** | View SAST scan results, reports, and scan history | Review scan results, analyze security findings, or monitor scan progress and outcomes | | **Can delete SAST Scan** | Remove SAST scan records and results from the system | Clean up old scan data, remove failed scans, or manage scan history storage | ### Project Management Permissions | Permission | Description | Use Case | | --------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- | | **Can modify project tags** | Add, remove, or modify tags associated with projects | Organize projects with custom tags, categorize projects by team or technology, or improve project management and filtering | | **Can edit project** | Modify project settings and configuration | Update project details, change project settings, or adjust project parameters | | **Can delete project** | Remove projects from the system (requires project access when Project Access Control is enabled) | Clean up old projects, remove deprecated projects, or manage project lifecycle | ### API Token Management Permissions | Permission | Description | Use Case | | -------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | **Can view token** | View API tokens and their associated permissions and usage | Review token usage, audit API access, or check token permissions and status | | **Can change token** | Modify API tokens, including regeneration, expiration, or permission changes | Update token permissions, regenerate compromised tokens, or modify token expiration settings | ### Policy Management Permissions | Permission | Description | Use Case | | --------------------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Can add Policy** | Create new security policies and compliance rules | Define new security standards, create compliance policies, or establish organizational security guidelines | | **Can change Policy** | Modify existing policies, rules, and compliance settings | Update policy requirements, adjust compliance rules, or modify security standards as organizational needs change | | **Can view Policy** | View policies, compliance rules, and security standards | Review current policies, understand compliance requirements, or audit security standards | | **Can delete Policy** | Remove policies and compliance rules from the system | Clean up outdated policies, remove deprecated compliance rules, or manage policy lifecycle | ### Issue SLA Management Permissions | Permission | Description | Use Case | | ------------------------ | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **Can add Issue SLA** | Create new issue SLA definitions and response time requirements | Define response time requirements for different types of security issues, set up escalation procedures | | **Can change Issue SLA** | Modify existing issue SLA settings and response time requirements | Update SLA requirements, adjust response times, or modify escalation procedures | | **Can view Issue SLA** | View issue SLA settings and response time requirements | Review SLA requirements, check response time commitments, or audit SLA compliance | | **Can delete Issue SLA** | Remove issue SLA definitions from the system | Clean up outdated SLA requirements or remove deprecated response time standards | ### Blocking Rule Management Permissions | Permission | Description | Use Case | | ---------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | **Can add blocking rule** | Create new blocking rules to prevent specific actions or deployments | Set up rules to block deployments with critical vulnerabilities, prevent releases with compliance violations | | **Can change blocking rule** | Modify existing blocking rules and their conditions | Update blocking criteria, adjust rule conditions, or modify deployment restrictions | | **Can view blocking rule** | View blocking rules and their current configurations | Review current blocking rules, understand deployment restrictions, or audit rule effectiveness | | **Can delete blocking rule** | Remove blocking rules from the system | Clean up outdated rules, remove unnecessary restrictions, or manage rule lifecycle | ### PR Scan Comment Rule Permissions | Permission | Description | Use Case | | ----------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | **Can add pr scan comment rule** | Create new rules for automated comments on pull request scans | Set up automated feedback for developers, create custom comment templates for different scan results | | **Can change pr scan comment rule** | Modify existing PR scan comment rules and templates | Update comment templates, adjust feedback rules, or modify automated communication settings | | **Can view pr scan comment rule** | View PR scan comment rules and their configurations | Review current comment rules, understand automated feedback settings, or audit communication policies | | **Can delete pr scan comment rule** | Remove PR scan comment rules from the system | Clean up outdated comment rules, remove unnecessary automated feedback, or manage rule lifecycle | ### Scheduled Scan Management Permissions | Permission | Description | Use Case | | ----------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | | **Can add Scheduled Scan** | Create new scheduled security scans with custom timing and parameters | Set up regular security scans, create automated scan schedules, or establish recurring security assessments | | **Can change Scheduled Scan** | Modify existing scheduled scan settings, timing, or parameters | Update scan frequency, adjust scan parameters, or modify scheduling configurations | | **Can view Scheduled Scan** | View scheduled scan configurations and their current settings | Review scan schedules, check upcoming scans, or audit automated scanning configurations | | **Can delete Scheduled Scan** | Remove scheduled scans from the system | Clean up outdated scan schedules, remove unnecessary automated scans, or manage scan lifecycle | ### Integration Management Permissions | Permission | Description | Use Case | | -------------------------- | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | **Can view integration** | View integration configurations and connection details | Review current integrations, check integration status, or audit external connections | | **Can manage integration** | Create, modify, and configure integrations with external systems | Set up new integrations, update integration settings, or manage external system connections | ### Permission Group Management Permissions | Permission | Description | Use Case | | ------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | **Can add Permission Group** | Create new permission groups with custom permission sets | Set up role-based access control by creating groups like "Developers", "Security Team", or "Managers" with specific permissions | | **Can change Permission Group** | Modify existing permission group settings and assigned permissions | Update group permissions, change group names, or adjust access levels as organizational needs evolve | | **Can view Permission Group** | View permission group configurations and assigned permissions | Review current group settings, audit permissions, or understand access control structure | | **Can delete Permission Group** | Remove permission groups from the system | Clean up unused groups or remove deprecated role configurations | ### Company Management Permissions | Permission | Description | Use Case | | ---------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | **Can view company** | View company information, settings, and billing usage | Access company details, review organizational information, or check company-wide settings, policies, and billing limits | | **Can change company** | Modify company settings, billing, configuration, and organizational details | Update company information, manage billing settings, modify organizational policies, or adjust company-wide configurations | ### Corgea Agent Settings Permissions | Permission | Description | Use Case | | --------------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------- | | **Can view agent settings** | View Corgea Agent configuration and settings | Review agent configurations, check agent status, or audit agent settings | | **Can edit agent settings** | Modify Corgea Agent configuration and settings | Update agent parameters, change agent behavior, or adjust automation settings | ### Skills Registry Permissions | Permission | Description | Use Case | | --------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | | **Can add skill** | Create new skills in the Skills Registry | Author company skills and submit their initial versions for review | | **Can change skill** | Modify skills and submit new skill versions | Update skill instructions, publish a new version, or resubmit after review feedback | | **Can view skill** | View skills, versions, review status, and installability | Browse available skills, inspect version history, and check whether a skill is approved for installation | | **Can delete skill** | Remove skills from the registry | Retire outdated or unwanted skills from the organization | | **Can approve skill** | Approve or reject skill versions | Complete a skill version review before it becomes installable | ### Team Management Permissions | Permission | Description | Use Case | | ------------------- | ------------------------------------------------- | ------------------------------------------------------------------------------------------ | | **Can view team** | View team information, members, and assignments | Access team details, review team composition, or check team assignments | | **Can create team** | Create new teams within the organization | Set up new development teams, security teams, or organizational units | | **Can edit team** | Modify team information, members, and assignments | Update team details, add or remove team members, or adjust team configurations | | **Can delete team** | Remove teams from the system | Clean up disbanded teams, remove deprecated organizational units, or manage team lifecycle | ### Content Access Management Permissions | Permission | Description | Use Case | | ----------------------------- | ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Can manage content access** | Control access to content and resources within the platform | Define who can access specific projects, repositories, or security data; manage content visibility and access controls | # PII/PHI Scanning Source: https://docs.corgea.app/pii PII/PHI Scanning automatically detects and identifies Personally Identifiable Information (PII) and Protected Health Information (PHI) in your codebase. It scans source code, configuration files, and documentation to find sensitive data patterns like credit card numbers, social security numbers, email addresses, medical records, and other personal information that could pose privacy and compliance risks. ## Overview * **What it Does**: PII/PHI Scanning automatically detects and identifies Personally Identifiable Information (PII) and Protected Health Information (PHI) in your codebase. It scans source code, configuration files, and documentation to find sensitive data patterns like credit card numbers, social security numbers, email addresses, medical records, and other personal information that could pose privacy and compliance risks. * **Who it's For**: This feature is designed for security teams, compliance officers, developers, and organizations that handle sensitive personal data. It's particularly valuable for healthcare organizations, financial institutions, e-commerce platforms, and any business that must comply with privacy regulations like GDPR, HIPAA, CCPA, or PCI DSS. ## Key Features and Benefits * **Comprehensive Data Detection**: Identifies over 50 types of sensitive information including: * Personal identifiers (SSN, passport numbers, driver's license) * Financial data (credit card numbers, bank account numbers, IBAN) * Contact information (email addresses, phone numbers, addresses) * Medical information (patient IDs, medical record numbers, diagnosis codes) * Government identifiers (tax IDs, national IDs, military IDs) * Biometric data (fingerprints, facial recognition data) * Authentication credentials (passwords, API keys, tokens) * **Multi-Language Support**: Scans both code and text files across a wide range of supported languages and file types. * **False Positive Detection**: After detecting PII in the codebase, we run the results through our AI-powered false positive detection system to minimize the number of inaccurate findings. ## How to Access ### Prerequisites * Project must contain source code files to scan * Appropriate permissions to run security scans * Access to the scanning service ## Usage Guide ### Key Workflows 1. **Automated Scanning**: The system automatically scans new code commits and pull requests 2. **Manual Scanning**: Initiate on-demand scans for specific files or directories 3. **Batch Processing**: Scan entire codebases for comprehensive privacy audits 4. **Continuous Monitoring**: Set up scheduled scans to catch new sensitive data as it's added 5. **Issue Tracking**: Automatically create and track remediation tasks for detected issues ### Supported Data Types The PII/PHI scanner detects the following categories of sensitive information: * **Personal Identifiers**: SSN, passport numbers, driver's license, national ID * **Financial Information**: Credit card numbers, bank accounts, routing numbers, IBAN * **Contact Details**: Email addresses, phone numbers, physical addresses * **Medical Data**: Patient IDs, medical record numbers, diagnosis codes, prescription data * **Government Data**: Tax IDs, military IDs, government employee numbers * **Authentication**: Passwords, API keys, access tokens, private keys * **Biometric Data**: Fingerprints, facial recognition data, voice patterns * **Location Data**: GPS coordinates, device identifiers ### Multi-Project Example ``` Healthcare Application: ├── patient-portal/ │ ├── src/ │ │ ├── patient-data.js ✓ Patient records │ │ ├── billing-api.py ✓ Payment information │ │ └── auth-service.go ✓ Authentication tokens │ ├── config/ │ │ └── database.yml ✓ Connection strings │ └── docs/ │ └── api-spec.md ✓ API documentation ├── admin-dashboard/ │ └── src/ │ └── user-management.js ✓ Admin credentials └── mobile-app/ └── src/ └── location-service.js ✓ GPS coordinates ``` ### Severity Classification * **Critical**: Highly sensitive data (SSN, credit cards, medical records) exposed in production code * **High**: Personal identifiers or financial data in development/test environments * **Medium**: Contact information or location data that could be aggregated * **Low**: Public information or properly anonymized data ## Examples ### Example 1: Credit Card Detection ```javascript theme={null} // ❌ High Risk - Credit card number in code const paymentData = { cardNumber: "4111-1111-1111-1111", expiryDate: "12/25", cvv: "123" }; // ✅ Safe - Masked or tokenized data const paymentData = { cardToken: "tok_1234567890", lastFour: "1111" }; ``` ### Example 2: Email Address Handling ```python theme={null} # ❌ Medium Risk - Email in configuration DATABASE_CONFIG = { "host": "db.example.com", "user": "admin@company.com", "password": "secret123" } # ✅ Safe - Environment variables DATABASE_CONFIG = { "host": os.getenv("DB_HOST"), "user": os.getenv("DB_USER"), "password": os.getenv("DB_PASSWORD") } ``` ### Example 3: Medical Data Protection ```java theme={null} // ❌ Critical Risk - Patient data in code public class PatientRecord { private String patientId = "P12345"; private String diagnosis = "Diabetes Type 2"; private String ssn = "123-45-6789"; } // ✅ Safe - Proper data handling public class PatientRecord { private String patientToken = generateSecureToken(); private String diagnosisCode = "E11.9"; // ICD-10 code private String maskedSsn = "***-**-6789"; } ``` ## Additional Resources * **Privacy Regulations**: [GDPR](https://gdpr.eu/), [HIPAA](https://www.hhs.gov/hipaa/index.html), [CCPA](https://oag.ca.gov/privacy/ccpa), [PCI DSS](https://www.pcisecuritystandards.org/) * **Secure Coding Guidelines**: [OWASP Secure Coding Practices](https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/) * **Data Protection**: [NIST Privacy Framework](https://www.nist.gov/privacy-framework) # PolicyIQ Source: https://docs.corgea.app/policies Enriching Corgea with Business Context through Policies **Prerequisite** You have completed a [scan](/quickstart), and you have PolicyIQ enabled. Reach out to your Corgea contact to enable PolicyIQ. Corgea comes pre-configured with a comprehensive set of policies designed to provide immediate value and maximize your security analysis experience. These built-in policies cover common security patterns, frameworks, and infrastructure setups. You can further customize and extend these policies to enrich the platform with additional business, network, and environmental context to improve the accuracy of vulnerability detection, false positive identification, and fix generation. By providing this context through policies, you can help Corgea better understand your specific security requirements and infrastructure.