# 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 **1. Enable Corgea Agent** Navigate to **Settings → Automation → [Corgea Agent](https://www.corgea.app/settings/company/corgea-agent/)** 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. ![The Corgea Agent page under Settings with the Enable Corgea Agent toggle](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/corgea_agent.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=2c6c0cdf130b472c83f7866f545dfb3f) **2. Verify Permissions** 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. **3. Test the Connection** * 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 Open **Corgea Agent** in the sidebar to access the interactive AI assistant. Web chat requires the **Can view Corgea Agent** permission and a plan that includes Corgea Agent. This permission is separate from viewing or editing agent settings. Access to agent settings and **Feedback History** still requires permission to view agent settings. ![Corgea Agent Web Chat Interface](https://mintcdn.com/corgea/1zTIBpc0LYfu4dh5/images/agent/web_agent_view.png?fit=max\&auto=format\&n=1zTIBpc0LYfu4dh5\&q=85\&s=1952a261ea3249efb87f1313a13971d2) ### What You Can Do The Corgea Agent has deep knowledge of your security posture and can help you: > **Explore Security Issues** > > Get detailed information about specific vulnerabilities, understand severity levels, and review fix suggestions > **Analyze Scans** > > Review scan results and summaries, compare scans over time, and understand scan coverage > **Query Vulnerability Data** > > 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](https://mintcdn.com/corgea/1zTIBpc0LYfu4dh5/images/agent/web_agent_view_chat_session.png?fit=max\&auto=format\&n=1zTIBpc0LYfu4dh5\&q=85\&s=39d9571b55a487374756c122db324e8d) > [!TIP] > > Be specific in your queries for better results. Reference issue IDs, scan IDs, or project names directly for more accurate responses. ### Documentation, Charts, and Downloads Ask the agent how to use Corgea features. It can consult Corgea documentation and include relevant links and screenshots in its answers. You can also ask for charts of scans, scan duration, findings introduced versus resolved, average time to fix by severity, open code findings by severity, or the most common open finding types. Specify a project and time range when relevant. Charts require reporting permission and a plan that includes reporting, and use only projects you can access. Ask for a CSV download of a completed scan's security or code quality findings. Dependency exports are also available. Downloads respect your scan and project access. To return to a conversation, open it from chat history or bookmark its URL. You can open a history link in a new tab. Conversations are private to your account within your current company. ### Context Documents Company admins can add guidance under **Settings → Automation → Corgea Agent → Context Documents**. Use these documents for your organization's processes, policies, and coding standards; the web chat agent reads relevant enabled documents when answering. Choose **Add document**, enter a title and content, and optionally describe when the document should be used. Content can be plain text or Markdown, up to 50,000 characters per document. Each company can store up to 50 documents. Admins can edit, enable, disable, or delete them. Context documents guide answers; they do not grant permissions or bypass triage approvals. *** ## 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](https://mintcdn.com/corgea/SJGVp9kfrwLaikff/images/agent/agent_in_github.png?fit=max\&auto=format\&n=SJGVp9kfrwLaikff\&q=85\&s=b9380d0f17e8fc0d6d46227031d0f6ae) ### Acknowledgements and Fix Feedback On GitHub and GitLab, a successfully recorded status change or fix-feedback comment is normally acknowledged with a 👍 reaction instead of a text reply. This means the action was recorded, including negative feedback about a fix. Questions, requests for a reason, and refused actions still receive text replies. If the reaction cannot be added, Corgea falls back to a text reply. With Corgea Agent enabled, react with 👍 or 👎 to Corgea's finding comment to give feedback on the suggested fix. These reactions vote on the fix; they do not change the finding's status. GitHub reactions may take a few minutes to appear in Corgea. For GitLab, enable the **Emoji events** webhook trigger. Reaction feedback is visible in **Feedback History**. If the agent declines to change a finding's status or request another fix from a comment, use the Corgea app to perform that action. ### 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 > [!NOTE] > > You don't need to use `@Corgea` as the agent will respond to comments to it's own. ### Supported Actions > **Mark as False Positive** > > Explain why the reported issue is not a real vulnerability. A bare “false positive” request is not enough; Corgea asks for more detail and leaves the issue unchanged until you provide a meaningful reason. See [Triage Justifications](/triage_justifications). > > **Example Comments:** > > ```plaintext theme={null} > @Corgea false positive, the query is parameterized on line 44 > This is not a real issue, that input is the signed JWT claim > @Corgea this is safe, the value never leaves our allowlist > ``` > > **What Happens:** > > * Issue is marked as "False Positive" > * Issue is removed from blocking status > * Feedback is recorded for analysis > **Mark as Accepted Risk** > > Acknowledge a real vulnerability but accept the risk without immediate remediation. > > Include the reason. A bare "accept risk" is answered with a request for one—see [Triage Justifications](/triage_justifications). > > **Example Comments:** > > ```plaintext theme={null} > @Corgea accept risk until the 2.0 upgrade next quarter > We accept this, the endpoint is internal-only behind the VPN > @Corgea won't fix, this service is decommissioned in March > ``` > > **What Happens:** > > * Issue status changes to "Accepted Risk" > * Issue no longer blocks PR > * Risk acceptance is logged > **Mark as Fixed** > > 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 > **Mark as Duplicate** > > 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 > **Mark as In Progress** > > 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 > **Request More Information** > > 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 **False Positive** **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. ``` **Accepted Risk** **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. ``` **Dismissal Without a Reason** **Scenario:** Developer asks to dismiss a finding but does not say why ```plaintext PR Comment theme={null} @Corgea false positive ``` **Agent Response:** ```plaintext theme={null} I can't record that without a reason. Tell me what makes this safe - the validation or control in the way, or why the path can't be reached - and I'll mark it. ``` The status is left unchanged. Reply with the reason and the agent records the decision. **Request Context** **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** tab under **Settings → Automation → Corgea Agent**: * 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](https://mintcdn.com/corgea/1zTIBpc0LYfu4dh5/images/agent/feedback_history.png?fit=max\&auto=format\&n=1zTIBpc0LYfu4dh5\&q=85\&s=ebf62162a94057fb4aafeaa094e7d891) **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: **GitHub** * Pull request comments * Issue comments * Review threads > [!NOTE] > > Requires: GitHub App installation with appropriate permissions **GitLab** * Merge request comments * Note threads > [!NOTE] > > Requires: GitLab integration with webhook configuration **Azure DevOps** > [!NOTE] > > Requires: Support is coming soon **Bitbucket** * Pull request comments * Inline discussions > [!NOTE] > > Requires: Bitbucket integration with webhook configuration *** ## Troubleshooting > **Agent Not Responding to PR Comments** > > **Check:** > > * Is the agent enabled in **Settings → Automation → Corgea Agent**? > * 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 > **Action Not Applied to Issue** > > **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, the input is escaped by the template engine"—a dismissal needs a reason > * Check the Feedback History to see how your comment was interpreted > **Chat Not Loading or Responding** > > **Check:** > > * Browser console for JavaScript errors > * Network connectivity > * Account permissions > > **Solution:** > > * Refresh the page > * Clear browser cache > * Contact support if issue persists *** ## Best Practices **PR Comments** > [!TIP] > > **One Action Per Comment**: Keep comments focused on a single action > [!TIP] > > **Provide Context**: Add reasoning to help the team understand your decision > [!TIP] > > **Review Feedback History**: Periodically check how your commands are interpreted **Web Chat** > [!TIP] > > **Use Specific Identifiers**: Reference issue IDs, scan IDs, or project names > [!TIP] > > **Ask Follow-Up Questions**: Drill deeper into topics with contextual queries > [!TIP] > > **Leverage Search**: Filter results by severity, type, or status > [!TIP] > > **Save Important Queries**: Keep track of useful queries for recurring analysis *** ## Privacy & Security > [!WARNING] > > 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](https://mintcdn.com/corgea/Wbjiz74ZJir_JYJV/images/agentic_interaction_skill_cursor.png?fit=max\&auto=format\&n=Wbjiz74ZJir_JYJV\&q=85\&s=9a570833aca8db50be03ba27e346a47a) Corgea Agent Skill in action — scanning and fixing vulnerabilities directly from 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. > **[Install the Corgea CLI](/cli)** > > 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. > [!NOTE] > > 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: **Project** 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. **Global** 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. > **The agent does not find corgea-scan** > > Try this first: a newly installed skill is not picked up by a session that is already open. Reload the window and start a new chat. Reinstalling does not help when this is the cause. > > If it still does not appear, 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 agent reports that corgea is not installed or authenticated** > > 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. > **The installer cannot create symlinks** > > Repeat the installation with `--copy`. This creates separate skill files for each selected agent instead of linking them to a shared copy. > **The skill was installed at the wrong scope** > > 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 > ``` ### Install with the Corgea CLI The Corgea CLI 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 target a specific agent's skills directory, pass `--agent` to either installer rather than placing files by hand. Both `corgea skill install` and `npx skills add` know where each supported agent expects its skills, so you do not need to create the directories yourself. ### 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, apply AI-generated fixes, check packages before installation, and inventory dependencies. Requires a Corgea account and the CLI. | | [`corgea-mcp`](https://github.com/Corgea/skills/tree/main/plugins/corgea-mcp/skills/corgea-mcp) | Connect an agent to Corgea MCP to query scans, findings, dependencies, and blocking rules, or export the dependency inventory as CSV. Reads only — it never starts a scan. Requires a Corgea account. | | [`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. | | [`sighthound-rules`](https://github.com/Corgea/skills/tree/main/plugins/sighthound/skills/sighthound-rules) | Write, test, and debug custom [Sighthound](https://github.com/Corgea/Sighthound) detection rules in RON format. | 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 npx skills add corgea/skills --skill corgea-mcp npx skills add corgea/skills --skill sighthound npx skills add corgea/skills --skill sighthound-rules ``` Claude Code users can add the whole marketplace as a plugin instead, which makes every skill available at once: ``` /plugin marketplace add corgea/skills /plugin install corgea-mcp@skills ``` > [!NOTE] > > 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 > **Fix vulnerabilities from a PR scan** > > 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. > **Scan and fix before committing vibe-coded changes** > > 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. > **Targeted security scan on specific files** > > 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. > **Review and understand a vulnerability** > > 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. The fastest setup is the Corgea CLI (1.13.0 or later): ```bash theme={null} corgea mcp install --agent cursor ``` If you do not have the CLI installed, run the same commands with `npx`. For a single-tenant instance, pass `--url`: ```bash theme={null} npx @corgea/cli login --url https://.corgea.app && npx @corgea/cli mcp install --agent cursor ``` > **[Corgea MCP Setup Guide](/modelcontextprotocol)** > > 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 | Corgea CLI (`corgea mcp install`) or an 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 **1. Install the Corgea CLI** Follow the [CLI installation guide](/cli) to install and authenticate. **2. Install the Corgea Agent Skill** Add the Corgea skill to your coding agent using the installation instructions above. **3. Set up Corgea MCP** Run `corgea mcp install --agent `, or `npx @corgea/cli login --url https://.corgea.app && npx @corgea/cli mcp install --agent ` if the CLI is not installed. See the [MCP setup guide](/modelcontextprotocol). **4. Start using it** 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} # Chunked scan upload Source: https://docs.corgea.app/api-reference/chunked-scan-upload Upload large BLAST scans in chunks with the Start Scan API # Chunked scan upload The Start Scan API uploads large codebases across multiple requests. BLAST scanning must be enabled for your company, and you upload a single source archive. Use this guide for the upload sequence. Request fields and status codes live on the OpenAPI pages for `POST /start-scan`, `PATCH /start-scan/{transfer_id}/`, and `HEAD /start-scan/{transfer_id}/`. ## Upload sequence 1. **Start the transfer** with `POST /start-scan`. Send `scan_type=blast` as a form field and a `files` part that includes the archive name and an empty body. The archive name must use one of `.zip`, `.tar`, `.json`, `.fpr`, `.sarif`, or `.xml`. The response includes a `transfer_id`. 2. **Read the current offset** with `HEAD /start-scan/{transfer_id}/`. The `Upload-Offset` response header is the next byte to send. An unknown or empty transfer returns `0`. 3. **Upload each chunk** with `PATCH /start-scan/{transfer_id}/`. Send the next bytes as `chunk_data`, and include these request headers: * `Upload-Offset`: current byte offset * `Upload-Length`: total file size in bytes * `Upload-Name`: archive file name 4. **Finish when the last PATCH returns `scan_id`.** Intermediate PATCH responses include `Upload-Offset` (the next byte) and do not include `scan_id`. When the last chunk completes the archive, the JSON body includes `scan_id` and `project_id`. That completing response does not set `Upload-Offset`. Use `scan_id` with the scan and issue APIs. HEAD does not return `scan_id`. You can also send `project_name`, `branch`, `repo_url`, `sha`, `files_to_scan`, `dirty`, `scan_configs`, and `target_policies` on each PATCH request. Omit `partial_scan` for a full scan. Send `partial_scan=true` only for a partial scan. ## Authentication Include your API token on every request: ```http theme={null} CORGEA-TOKEN: your_api_token_here ``` ## Scan metadata `metadata` is an optional JSON object string, for example `{"pipeline_url": "https://ci.example/run/123"}`. Corgea validates it on every chunk request and attaches it to the scan when the upload completes, so send the same value with each chunk. The object must be at most 16,384 bytes. ## Python example This script starts a BLAST upload or resumes one with `--transfer_id`. It follows `Upload-Offset` on intermediate chunks. The last PATCH returns `scan_id` instead of `Upload-Offset`. ```python theme={null} import argparse import os import requests API_BASE_URL = "https://www.corgea.app/api/v1/start-scan" CHUNK_SIZE = 5 * 1024 * 1024 # 5 MB example; the CLI uses 50 MB. Any size is valid. TOKEN_HEADERS = {"CORGEA-TOKEN": ""} def transfer_url(transfer_id): """HEAD and PATCH continue URLs require a trailing slash.""" return f"{API_BASE_URL}/{transfer_id}/" def require_upload_offset(headers): """Return the server's next-byte offset. Fail if the header is missing.""" value = headers.get("Upload-Offset") if value is None: raise RuntimeError("Response is missing the required Upload-Offset header.") return int(value) def initiate_upload(file_path): """Start the transfer with the file name and an empty first part.""" file_name = os.path.basename(file_path) response = requests.post( API_BASE_URL, data={"scan_type": "blast"}, files={"files": (file_name, b"")}, headers=TOKEN_HEADERS, ) response.raise_for_status() transfer_id = response.json().get("transfer_id") if not transfer_id: raise RuntimeError("Start-scan response is missing transfer_id.") print(f"Upload initiated. Transfer ID: {transfer_id}") return transfer_id def check_upload_status(transfer_id): """Return the next byte offset from the Upload-Offset header.""" response = requests.head( transfer_url(transfer_id), headers=TOKEN_HEADERS, ) response.raise_for_status() return require_upload_offset(response.headers) def upload_chunk( file_path, transfer_id, chunk_offset, chunk_data, project_name, branch, repo_url, sha, partial_scan, files_to_scan, metadata="", ): headers = { "Upload-Offset": str(chunk_offset), "Upload-Length": str(os.path.getsize(file_path)), "Upload-Name": os.path.basename(file_path), **TOKEN_HEADERS, } form_data = {} if project_name: form_data["project_name"] = project_name if branch: form_data["branch"] = branch if repo_url: form_data["repo_url"] = repo_url if sha: form_data["sha"] = sha if partial_scan: form_data["partial_scan"] = "true" if files_to_scan: form_data["files_to_scan"] = files_to_scan if metadata: form_data["metadata"] = metadata response = requests.patch( transfer_url(transfer_id), headers=headers, files={"chunk_data": ("chunk", chunk_data, "application/octet-stream")}, data=form_data, ) response.raise_for_status() return response.json(), response.headers def upload_file_in_chunks( file_path, project_name, branch, repo_url, sha, partial_scan=False, files_to_scan="", transfer_id=None, metadata="", ): file_size = os.path.getsize(file_path) if transfer_id: print(f"Resuming transfer {transfer_id}") else: transfer_id = initiate_upload(file_path) offset = check_upload_status(transfer_id) print(f"Uploading {file_path} ({file_size} bytes) from offset {offset}") scan_id = None with open(file_path, "rb") as handle: while offset < file_size: handle.seek(offset) chunk_data = handle.read(CHUNK_SIZE) if not chunk_data: break payload, response_headers = upload_chunk( file_path, transfer_id, offset, chunk_data, project_name, branch, repo_url, sha, partial_scan, files_to_scan, metadata, ) scan_id = payload.get("scan_id") if scan_id: break message = payload.get("message") or "" if ( payload.get("status") == "ok" and "already in progress" in message.lower() ): print(message) return next_offset = require_upload_offset(response_headers) if next_offset <= offset: raise RuntimeError( f"Upload-Offset did not advance (was {offset}, now {next_offset})." ) if next_offset > file_size: raise RuntimeError( f"Upload-Offset {next_offset} exceeds file size {file_size}." ) offset = next_offset print(f"Uploaded to server offset {offset} / {file_size} bytes") if not scan_id: raise RuntimeError( "Upload finished without a scan_id. HEAD /start-scan/{transfer_id}/ does not return the scan_id after a completed transfer; look it up with the scans API." ) print(f"Upload complete. Scan ID: {scan_id}") if __name__ == "__main__": parser = argparse.ArgumentParser(description="Upload a BLAST archive in chunks.") parser.add_argument("file", help="Path to the archive to upload") parser.add_argument("--branch", required=False) parser.add_argument("--repo_url", required=False) parser.add_argument("--sha", required=False) parser.add_argument("--project_name", required=False) parser.add_argument("--partial_scan", action="store_true") parser.add_argument( "--files_to_scan", required=False, default="", help="Comma-separated files for a partial scan", ) parser.add_argument( "--transfer_id", required=False, help="Resume an existing transfer instead of starting a new one", ) parser.add_argument( "--metadata", required=False, default="", help='JSON object string sent with every chunk, e.g. {"pipeline_url":"https://ci.example/run/123"}', ) args = parser.parse_args() if not os.path.isfile(args.file): raise SystemExit(f"File '{args.file}' does not exist.") upload_file_in_chunks( args.file, args.project_name, args.branch, args.repo_url, args.sha, args.partial_scan, args.files_to_scan, args.transfer_id, args.metadata, ) ``` Example: ```bash theme={null} python upload_scan_chunks.py \ --branch main \ --repo_url https://github.com/example/repo \ --sha 21jio112j3 \ --project_name projectX \ /path/to/source.zip ``` To resume an interrupted upload, pass the existing transfer ID: ```bash theme={null} python upload_scan_chunks.py \ --transfer_id c9b0a8c7-f9b4-4c10-9d58-cd4c7e1c9c52 \ --branch main \ --repo_url https://github.com/example/repo \ --sha 21jio112j3 \ --project_name projectX \ /path/to/source.zip ``` For a partial scan, add `--partial_scan` and `--files_to_scan "vuln.py,test.py"`. To attach scan metadata, add `--metadata '{"pipeline_url":"https://ci.example/run/123"}'`. The same value is sent with every chunk. # 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. When no scan ID is supplied, prefers the newest matching processed non-PR scan covering the whole project; falls back to the newest matching scan if none exists. An explicit scan_type filter on /issues or /issues/code-quality instead selects the newest scan of that type. # 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? > **Scan Management** > > Initiate security scans, upload scan results, and monitor scan progress > **Issue Management** > > Retrieve vulnerability details, manage issue status, and track remediation > **Auto-Fix Retrieval** > > Access AI-generated security fixes and patches for identified vulnerabilities > **CI/CD Integration** > > 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](/api-reference/chunked-scan-upload) 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 or regional instance (for example `eu.corgea.app`) ``` https://.corgea.app/api/v1 ``` > [!NOTE] > > Use the same host you see in your browser when you sign in to Corgea. API tokens only work on the instance where they were created, so a valid token sent to a different instance is rejected as invalid. ## 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 **Settings → Automation → [API token](https://www.corgea.app/settings/integrations/api-token/)** 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` > [!NOTE] > > 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? > **[Authentication Guide](/api-reference/authentication)** > > Learn how to authenticate your API requests > **[Support](https://corgea-community.slack.com/join/shared_invite/zt-2cjmxat2f-Znvd06nP2gn9RYOSWrZI2A#)** > > Contact our support team for assistance ## Quick Start Get started with the Corgea API in three steps: 1. **Get your API token** from **Settings → Automation → API token** 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. By default, results are ordered by creation time, newest first, with issue ID as a tie-breaker for stable pagination. # 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. When no scan ID is supplied, prefers the newest matching processed non-PR scan covering the whole project; falls back to the newest matching scan if none exists. An explicit scan_type filter on /issues or /issues/code-quality instead selects the newest scan of that type. # 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. By default, results are ordered by creation time, newest first, with issue ID as a tie-breaker for stable pagination. # 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 When no scan ID is supplied, prefers the newest matching processed non-PR scan covering the whole project; falls back to the newest matching scan if none exists. An explicit scan_type filter on /issues or /issues/code-quality instead selects the newest scan of that type. # 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. By default, results are ordered by creation time, newest first, with issue ID as a tie-breaker for stable pagination. When no scan ID is supplied, prefers the newest matching processed non-PR scan covering the whole project; falls back to the newest matching scan if none exists. An explicit scan_type filter on /issues or /issues/code-quality instead selects the newest scan of that type. # 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. By default, results are ordered by creation time, newest first, with issue ID as a tie-breaker for stable pagination. When no scan ID is supplied, prefers the newest matching processed non-PR scan covering the whole project; falls back to the newest matching scan if none exists. An explicit scan_type filter on /issues or /issues/code-quality instead selects the newest scan of that type. # List SCA Issue Groups Source: https://docs.corgea.app/api-reference/issues/list-sca-issue-groups /api-reference/openapi.json get /issues/sca/groups Retrieve SCA issues collapsed into groups with a count per group, so a client can render a summary without downloading every issue. Accepts the same filters as GET /issues/sca. Drill into a group by re-issuing those filters against GET /issues/sca with package_exact. # List SCA Issue Groups for a Scan Source: https://docs.corgea.app/api-reference/issues/list-sca-issue-groups-for-a-scan /api-reference/openapi.json get /scan/{scan_id}/issues/sca/groups Retrieve a scan's SCA issues collapsed into groups with a count per group, so a client can render a summary without downloading every issue. Accepts the same filters as GET /scan/{scan_id}/issues/sca. # List Security Issue Groups Source: https://docs.corgea.app/api-reference/issues/list-security-issue-groups /api-reference/openapi.json get /issues/groups Retrieve security issues collapsed into groups with a count per group, so a client can render a summary without downloading every issue. Accepts the same filters as GET /issues. Drill into a group by re-issuing those filters against GET /issues with cwe or file_path_exact. # List Security Issue Groups for a Scan Source: https://docs.corgea.app/api-reference/issues/list-security-issue-groups-for-a-scan /api-reference/openapi.json get /scan/{scan_id}/issues/groups Retrieve a scan's security issues collapsed into groups with a count per group, so a client can render a summary without downloading every issue. Accepts the same filters as GET /scan/{scan_id}/issues. # Update issue status Source: https://docs.corgea.app/api-reference/issues/update-issue-status /api-reference/openapi.json patch /issue/{issue_id} Changes one accessible SAST issue. Requires `heeler.view_issue` and `heeler.change_issue_status`. Supply status and a non-empty comment explaining the decision; reopening is exempt from justification review but still requires a comment. False-positive and accepted-risk decisions by non-admins return 202 when the company requires approval, leaving the issue unchanged until approval. Company admins bypass approval; bulk count and severity thresholds do not apply. Unknown fields are rejected. # 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 a scan report in HTML, SARIF, Markdown, or PDF format. PDF reports are available after a scan completes, including scans with no findings. format=pdf accepts only urgency and classification filters; other filters return 400. Reports with more than 500 findings are generated asynchronously and return 202 with a poll_url that includes a job parameter. Poll the same endpoint with format=pdf and job until the PDF is ready. # 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}/ Return the current upload offset for a transfer. This path requires a trailing slash. Does not return `scan_id`. # 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 a BLAST chunked upload. This path requires a trailing slash. Intermediate responses include the `Upload-Offset` header and no `scan_id`. When the last chunk completes the archive, the JSON body includes `scan_id` and `project_id` and does not set `Upload-Offset`. # Start New Scan Source: https://docs.corgea.app/api-reference/starting-corgea-scan/start-new-scan /api-reference/openapi.json post /start-scan Starts a BLAST chunked upload. Send `scan_type=blast` as a form field and exactly one `files` part. The archive name must use `.zip`, `.tar`, `.json`, `.fpr`, `.sarif`, or `.xml`. The part body may be empty; send archive bytes with PATCH. BLAST scanning must be enabled for your company. # Bulk triage findings Source: https://docs.corgea.app/api-reference/triage/bulk-triage-findings /api-reference/openapi.json patch /triage/findings Preview or apply a rule-based status change to as many as 5,000 accessible SAST or SCA findings. For non-admin requests, false-positive and accepted-risk actions require approval when the corresponding company approval setting is enabled; accepted-risk actions also require approval when they meet the company's finding-count or severity threshold. These actions return 202 with status pending_approval and leave finding statuses unchanged until a different company admin approves them. Company-admin requests apply false-positive and accepted-risk actions immediately, bypassing these settings and thresholds. # Get a triage action Source: https://docs.corgea.app/api-reference/triage/get-a-triage-action /api-reference/openapi.json get /triage/actions/{action_id} Retrieve a bulk triage action and its paginated, immutable finding audit records. # Get the triage approval policy Source: https://docs.corgea.app/api-reference/triage/get-the-triage-approval-policy /api-reference/openapi.json get /triage/approval-policy Return the accepted-risk thresholds that require approval. Company admin access is required. # Review a triage action Source: https://docs.corgea.app/api-reference/triage/review-a-triage-action /api-reference/openapi.json patch /triage/actions/{action_id} Approve or reject a pending action. The reviewer must be a different company admin with permission to change every selected finding type. # Update the triage approval policy Source: https://docs.corgea.app/api-reference/triage/update-the-triage-approval-policy /api-reference/openapi.json patch /triage/approval-policy Partially update the accepted-risk approval thresholds. Set a threshold to null to disable it. Company admin access is required. # 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. Upload at least one source file with `/code-upload` for the same `run_id` before calling this endpoint. 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. **1. Generate an Azure DevOps Personal Access Token** Access your Azure DevOps account and generate a personal access token (PAT) with both read and write permissions. ![Create Personal Access Token](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-devops-1.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=88f9542152a162b66fed06a4ec6a9e64) ![Token Permissions](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-devops-2.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=10c4a67d2cce8b477c5dd59592d6a0bf) **2. Integrate the Token with Corgea** Proceed to the [Integrations](https://www.corgea.app/settings/integrations/) page on Corgea. Click the "+" button within the Azure DevOps section and ensure the token is securely saved. ![Add Token to Corgea](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-devops-modal-3.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=6f4a74071fbde89934b6b6ac24fbd5e0) **3. Identify Azure DevOps Projects in Corgea** After configuration, navigate to the [Projects](https://www.corgea.app/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](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-devops-projects-4.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=c42a658e1734ac671564acb892acd823) **4. Submit a Pull Request to Azure DevOps** From any issue page associated with Azure DevOps projects in Corgea, you can submit a pull request to address an issue. ![Issue Pull Request](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-devops-issue-pr-5.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=170ad0fb0f0473d9c1b8a8501296b621) ## 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. **Step 1** Select "Project settings" located at the bottom left of the Azure DevOps interface. ![Project Settings](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-1.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=7691ffcbb26b37bd8b6396a5c01509e3) **Step 2** Click on "Service Hooks". Multiple clicks may be necessary if it does not load immediately. ![Service Hooks](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-2.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=c7e432329a7eea7459474d5155a74bcb) **Step 3** Click the "+" button and choose "Web Hooks". ![Web Hooks](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-3.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=677f4fbb1473dbff151d0b5949678d0f) **Step 4** Select "Pull request created" as the trigger event, configure any optional settings, and click "Next". ![Trigger Event](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-4.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=87c1d1fd737c2d60538563108152d836) **Step 5** 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](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-fill-in-url.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=680bd4ede219087aaf6051e030cb446d) **Step 6** 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](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-5.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=a2a610c03862facbf2d78de5b396afab) **Step 7** 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](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-6.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=154c967cbd2113229cba93090a29cf9d) **Step 8** 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. **Step 9** 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](https://mintcdn.com/corgea/7q8wUqu2NotZ53M6/images/azure-webhook-4-updated.png?fit=max\&auto=format\&n=7q8wUqu2NotZ53M6\&q=85\&s=1e54da6dfca8f7fb24868abf4e2da1ee) **Step 10** 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](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-7.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=af6a9e70cbf68dc4a8b77a27e18718f9) ![Corgea Scans](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-webhook-8.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=4322d341d32fae066a49b6b221a5b22d) ## 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. **1. Create a Dedicated User for Corgea (Optional)** 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. > [!WARNING] > > The Bitbucket account that generates the API token must be a **workspace admin**. Webhook scopes require admin access, and a user can only grant a token the permissions they already have. If you create a dedicated Corgea user, assign that user workspace admin access first. Otherwise, generate the token from an existing workspace admin account. ![Create Bitbucket User](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_user.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=e6294580d18378439c15ea8cc252d23a) **2. Generate an API Access Token** Navigate to the [Atlassian API Tokens page](https://id.atlassian.com/manage-profile/security/api-tokens) and click "Create API token with scopes" to begin. > [!WARNING] > > **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. Generate this token while signed in as a **workspace admin** — Bitbucket only lets you assign webhook scopes if your account already has permission to manage webhooks. ![Create API Token](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_create_access_token.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=d2c2690dcd87c35b1651ece83f037c9f) 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](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_token_name.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=86506d715f1fbf86a5ef1ca858b4acc2) Select **Bitbucket** from the applications list to grant Bitbucket access to this token. ![Select Bitbucket App](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_app_selection.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=eed318e49348eea6d137a651c8b8238f) 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](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_token_scopes.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=c91333a78a6849ae68c22f5e412356c5) Review your configuration and click "Create token" to generate the access token. ![Create Token](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_create_token.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=391d9ebffbe9a06bbdcc1da964bbc0df) 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](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_copy_token.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=56a741f0624cf8e64937ab63911f2fc3) **3. Configure Bitbucket Integration in Corgea** Access your Corgea dashboard at `corgea.app` or `{your-instance}.corgea.app` and go to **Settings → Automation → Integrations**. ![Corgea Integrations Page](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_integration_page.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=bf73904b1aca7582ef3bb21b875a5df5) In the "Code Repository Integrations" section, locate Bitbucket and click the plus (+) icon to create a new integration. ![New Integration](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_new_integration.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=2540b183bd20606f310c7e707db71b67) 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](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_create_modal.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=3c61d1f0340dddd0bd12f89eede8f529) 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](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_modal_validation.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=a895ec1f7b3e0ccb9cfe3e0940e19bed) 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](https://mintcdn.com/corgea/1YT68j9GOThy2yLb/images/bitbucket_success_message.png?fit=max\&auto=format\&n=1YT68j9GOThy2yLb\&q=85\&s=bb62edb596c23ba63a62942e39112b4f) # 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 > **AI-Enhanced Detection** > > * Combines the reasoning capabilities of LLMs with static code analysis > * Accurately detects vulnerabilities with contextual understanding > * Identifies both business logic and traditional SAST vulnerabilities > **Developer Experience** > > * Low false positive rate reduces noise in scanning results > * Actionable insights with clear explanations > * Seamless integration with CI/CD pipelines and pull requests > **Security Coverage** > > * 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: > **Access Control** > > * **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 > **Injection Vulnerabilities** > > * **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 > **Authentication and Authorization** > > * **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 > **Cryptographic Failures** > > * **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 > **Data Handling and Validation** > > * **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** > > * **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 and Code Flow** > > * **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 > **Server-Side Request Forgery** > > * **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 > **Logging and Monitoring Failures** > > * **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 Detection** > > * **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 > **Privacy & Resources** > > * **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)**. > **[Secret Scanning](/secret-scanning)** > > 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: > **Language-Specific Vulnerabilities** > > 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. > **Framework-Specific Vulnerabilities** > > 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. > **Cross-Language Vulnerabilities** > > 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 > **Emerging Threats** > > 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 > **Reduced Risk** > > Minimize the risk of security breaches, data leaks, and other potential threats by addressing a wide range of vulnerabilities > **Compliance** > > Meet industry-specific security requirements and regulatory standards, reducing the risk of non-compliance penalties > **Efficiency** > > Streamline security review processes with AI-powered false positive detection and automated fixing capabilities > **Continuous Improvement** > > 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. > [!WARNING] > > 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 **1. Discover endpoints** Corgea detects the web frameworks in the repository and inventories routes with their HTTP methods, paths, handlers, source locations, and sub-projects where applicable. **2. Index application symbols** 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. **3. Trace each finding** For each eligible SAST finding with a source location, Corgea searches for static call paths from the relevant endpoint handlers to the finding. **4. Associate the results** When a path is found, Corgea associates the endpoint with the finding and stores the pathway steps, code locations, and depth for review. > [!NOTE] > > 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 **1. Open a completed scan** Open the findings for a completed full AI-native SAST scan. **2. Show reachable findings** 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. **3. Switch to Endpoint view** Select **Endpoint** to group findings by HTTP method and route. For monorepos, the sub-project is shown when available. **4. Review endpoint exposure** 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 **1. Open a finding** Select a reachable finding from the scan results, then click **Open Full View**. **2. Open Reachability** Select the **Reachability** tab. Corgea displays a graph from the reachable endpoints, through intermediate functions, to the vulnerability target. **3. Explore the graph** 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. **4. Review each pathway** 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. **1. Open an issue** From a scan's issue list, click an issue row to open the issue details sidebar. **2. Open Full View** 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](https://mintcdn.com/corgea/1OfVmGqf59iOSEPM/images/open-full-view.png?fit=max\&auto=format\&n=1OfVmGqf59iOSEPM\&q=85\&s=9ce044d4358093beb84a8a89ba0e3fba) **3. Open the Taint Analysis tab** 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. **4. Click through the trace** 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](https://mintcdn.com/corgea/1OfVmGqf59iOSEPM/images/multi-file-taint-analysis.png?fit=max\&auto=format\&n=1OfVmGqf59iOSEPM\&q=85\&s=0e996b545043d4ef01e284e2dd9a80b1) 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. The trace can also show sanitizer steps, variable names, and warnings for unresolved calls or unchecked steps. A status banner distinguishes **Verified by Corgea**, **Partially verified**, and **Analysis truncated** results. Partial or truncated traces may be incomplete. If the tab shows **No untrusted input found reaching this sink**, no path was found within the analysis budget; this does not prove the finding is safe. **No data flow applies** means the weakness is local to the flagged code and has no data flow to trace. ## 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: **1. Project-Level Analysis** AI-native SAST parses the entire project to build a complete picture of code component interactions, ensuring no vulnerabilities are missed. **2. Contextual Intelligence** The AI engine understands code context, including middleware, configurations, and templates. **3. False Positive Reduction** Context and logic understanding reduces false positives common in traditional tools. ### Comparison to Traditional Methods > [!WARNING] > > 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 > **Integration Points** > > * **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 > **C#** > > **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. > **Python** > > **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. > **Ruby** > > **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. > **Go** > > **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. > **JavaScript & TypeScript** > > **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. > **Java** > > **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. > **PHP** > > **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. > **Kotlin** > > **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. > **Swift** > > **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. > **Rust** > > **Native Language Support**: Analyzes Rust-specific constructs including ownership and borrowing, `unsafe` blocks, FFI boundaries, and error handling with `Result` and `Option`. > > **Frameworks**: Axum, Actix Web, Rocket, warp > > Targets the defects that safe Rust does not rule out, such as memory and ownership errors inside `unsafe` code and across FFI, reachable panics on untrusted input, integer truncation and release-mode overflow, SQL and command injection, and disabled TLS verification. > **C & C++** > > **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 > **Comprehensive Scanning** > > Advanced algorithms scan your codebase to identify potential security vulnerabilities, covering a wide range of CWEs > **False Positive Detection** > > AI-powered system accurately distinguishes between genuine vulnerabilities and false positives > **Automated Fixing** > > Provides actionable, context-aware fixes that can be applied automatically or reviewed before implementation > **Framework-Specific Analysis** > > 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 > **Non-Source Files** > > * Media files (images, videos, fonts) > * Style files (CSS, SCSS, LESS) > * Documentation and markdown files > * Configuration archives and compressed files > **Development and Testing** > > * Test files and test directories > * Mock and fixture data > * Code coverage reports > **Generated and Processed Code** > > * Auto-generated code files > * Minified or bundled code > * Database migration files > * Type definition files > **Build Artifacts** > > * 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-6 theme={null} ignore_paths: - "path/to/exclude/*" - "legacy-code/*" include_paths: - "**/migrations/**" ``` `ignore_paths` skips directories or file patterns. `include_paths` scans matching files that Corgea would skip because of their folder (for example a `migrations` folder). File Ignore Rules still win. You can also manage both from [project Settings](/project). ### 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 # Blocking Rules Source: https://docs.corgea.app/blocking_rules Blocking rules enforce security and quality standards in pull requests or CI pipelines. ## Overview ### What it Does Blocking rules are guardrails that define which findings should fail a pull request check or CI pipeline. This helps ensure that your codebase adheres to your organization's security and quality standards. You can create three 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 * **License Compliance Rules**: Block dependencies with specific SPDX licenses or license families ### 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 > **Enforce Coding Standards** > > Define rules based on Common Weakness Enumerations (CWEs) to block pull requests that introduce specific types of vulnerabilities or code quality issues. > **Customize Urgency Levels** > > Assign urgency levels (e.g., critical, high, medium, low) to different types of issues, allowing you to prioritize and handle them accordingly. > **Filter Dependencies by CVSS** > > For dependency vulnerability rules, define an inclusive CVSS score range to block vulnerable dependencies based on their CVSS score. > **Filter Dependencies by Reachability** > > For dependency vulnerability rules that apply to CI, narrow blocking to dependencies whose vulnerable code is actually reachable from your application, so unused and unreachable packages do not fail your pipeline. > **Enforce License Policy** > > Block dependencies by specific SPDX license IDs or by the Copyleft, Permissive, and Commercial license families. > **Project and Tag Scoped Rules** > > 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. > **Rule Management** > > Easily create, edit, and delete blocking rules through a user-friendly interface, ensuring your rules stay up-to-date with your evolving requirements. > **Rule Activation/Deactivation** > > Toggle the status of blocking rules to temporarily enable or disable them as needed, without losing their configurations. ## Rule Types Blocking rules support three distinct types to provide comprehensive security coverage: > **Code Vulnerability** > > 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. > **Dependency Vulnerability** > > 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 > * Optionally narrowing by [reachability](#reachability) (CI rules only) > > Use this to prevent the introduction of packages with known security vulnerabilities, ensuring your supply chain remains secure. > **License Compliance** > > Blocks pull requests or CI pipelines when a dependency uses a denied license. > > Configure by: > > * Selecting one or more license families: Copyleft, Permissive, or Commercial > * Entering specific SPDX license IDs, such as `AGPL-3.0` > > Use this to enforce your organization's open-source and commercial license policy. ## How it Works with GitHub > [!NOTE] > > **Prerequisite** You must have installed and configured the [Corgea GitHub App](github) with appropriate repository permissions. **1. Pull Request Submission** Developer submits a pull request with code changes **2. Automated Analysis** System analyzes code changes against active blocking rules **3. Rule Validation** If violations are found, pull request is automatically blocked ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rules_pr_blocked.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=39013c8f8163f96d432b0f9bd4abbc05) **4. Developer Notification** Developer receives detailed notification about rule violations ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rules_pr_details.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=4ac0e073341d12a425db9a4412e55b3e) **5. Resolution** 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 > [!NOTE] > > **Prerequisite** Make sure the [Azure DevOps integration](azure_devops) with Corgea is configured and you have the necessary permissions. **1. Pull Request Submission** A developer submits a pull request with code changes in Azure DevOps. **2. Automated Analysis** The system evaluates the code changes against the active blocking rules set in Corgea. **3. Rule Validation** If violations are found, the pull request is automatically blocked. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure_blocking_rules_pr_blocked.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=a85aa91d3cea8d9572197b863bafa4e4) Developer cannot merge the PR until it is resolved. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure-devops_merging_blocked.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=1ecb01eb911476a19b0265a3b56dad72) **4. Developer Notification** The developer receives a link to view detailed information about the failed issues on the Corgea Scan page. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/azure_see_details_of_issues.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=e5e94b8c2fec2b7abab7eb76a37533b1) **5. Resolution** 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 **1. Initiate Creation** Click the "Add Blocking Rule" button **2. Choose Rule Type** 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) * **License Compliance**: Block dependencies based on denied SPDX licenses or license families ![Add Blocking Rule modal with Applies To, rule types, and Issue Type](https://mintcdn.com/corgea/vl87stO-uNzXPjoi/images/blocking_rule_create.png?fit=max\&auto=format\&n=vl87stO-uNzXPjoi\&q=85\&s=8dcdba40b68a4f557b9af9b596629262) **3. Basic Information** Enter the rule name and description, then choose **Applies To**: * **Pull Requests** automatically enforces the rule in pull request checks. * **CI** enforces the rule only when a pipeline names it with `corgea scan --block-on `. CI rules do not block pull requests. New rules default to **Pull Requests**. Corgea generates the slug from the rule name and displays it in the rules list. Pull request rules only comment on actionable findings. Corgea skips comments for findings confirmed as unreachable, findings held because they are false positives or unsupported-language results, and findings in paths ignored by the project. These findings remain available in Corgea for review, but they do not block the pull request. ![Add Blocking Rule modal with CI selected and License Compliance configured](https://mintcdn.com/corgea/vl87stO-uNzXPjoi/images/blocking_rule_create_ci_license.png?fit=max\&auto=format\&n=vl87stO-uNzXPjoi\&q=85\&s=218cc233de7f4711f466cb92303eaf8c) **4. Configure Settings** 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. If the rule applies to CI, you can also select one or more **Reachability** states to narrow it further — see [Filtering by Reachability](#reachability). For **License Compliance** rules: Select at least one denied license family (Copyleft, Permissive, or Commercial) or enter one or more SPDX license IDs. A dependency is blocked when any reported license matches a selected family or specific ID. **5. Set Scope** 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. **6. Save** Review and click "Create" ### Managing Existing Rules Use search to find rules by name or settings, or filter the list by project tag or **Applies To** target. The rules table shows each rule's slug in the **ID** column and surfaces the project scope, rule type, and **Pull Requests** or **CI** target under **Triggers On**. Select a slug to copy it for use in a CI command. Rules without a project or tag scope apply to all projects, and longer scope lists are grouped behind a **+N more** tooltip. ![Blocking rules list showing slug, Triggers On chips, and CI badge](https://mintcdn.com/corgea/vl87stO-uNzXPjoi/images/blocking_rules_list.png?fit=max\&auto=format\&n=vl87stO-uNzXPjoi\&q=85\&s=fde00215e97e017b81af0100480d9ad4) ### Enforcing Rules in CI Create an active rule with **Applies To** set to **CI**, then pass its slug to the scan command. Name rules for the condition that trips them — for example `criticals`, not `no-criticals` — so `--block-on` reads as a direct assertion. `--block-on` requires Corgea CLI 1.10.0 or later. ```bash theme={null} corgea scan --block-on criticals ``` To enforce multiple CI rules, provide their slugs as a comma-separated list. The command fails when a finding violates any named rule. An unknown slug, inactive rule, or rule that applies to pull requests is treated as a configuration error rather than being skipped. `--block-on` is supported only by the BLAST scanner and cannot be combined with `--fail` or `--fail-on`. **Edit Rule** 1. Locate rule in table 2. Click "Edit" button 3. Modify settings as needed 4. Click "Update" to save **Toggle Status** 1. Find rule in table 2. Click "Toggle Status" 3. Confirm status change **View Details** 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: ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rules_scan_details.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=a132f7927273e0eaf8bdb84065bbcbf4) 2. For individual issues, you can see which blocking rules were triggered in the issue details: ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blocking_rule_issue_details.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=433dd74d99f714b953608a1e59ac973a) This makes it easy to understand which rules are affecting your scans and specific issues, helping you identify why certain changes may be blocked. ## Filtering by Reachability Most vulnerable dependencies in a project are never actually exercised by your code. Reachability filtering lets a **Dependency Vulnerability** rule block only the findings that matter, so a critical CVE in a package you never call does not fail your pipeline. > [!NOTE] > > **Available for CI rules only** Reachability is analyzed on scans you start yourself with `corgea scan`, not on the scans triggered automatically when a pull request opens. Set **Applies To** to **CI** to use this filter; the option is hidden for Pull Request rules, and reference the rule from your pipeline with `corgea scan --block-on `. > [!NOTE] > > **Prerequisite** Reachability requires **AI-Native SCA** to be enabled for your organization. Without it no dependency is analyzed, so a rule using this filter never blocks anything. The rule editor warns you when the setting is off. ![Add Blocking Rule modal with CI and Dependency Vulnerability selected and Reachable checked under Reachability](https://mintcdn.com/corgea/gpJCGMHYx471xVvQ/images/blocking_rule_create_ci_reachability.png?fit=max\&auto=format\&n=gpJCGMHYx471xVvQ\&q=85\&s=571c043010e6323e09fc1523cfd8a5b3) Select one or more of the following states: | State | Meaning | | - | - | | **Reachable** | The vulnerable function is reachable from your application code. | | **Not Reachable** | The dependency is used, but the vulnerable function is not reachable. | | **Unused Dependency** | The dependency is declared but not used anywhere in the codebase. | | **Unknown** | The dependency was analyzed but reachability could not be determined. | The reachability filter is **combined with** the severity, CVSS, or Malicious filter rather than replacing it, so a finding must match both. A rule set to Critical severity and Reachable blocks only critical vulnerabilities that are also reachable. Leaving reachability empty keeps the rule's existing behavior of blocking regardless of reachability. ### Waiting for Analysis Reachability analysis runs after the scan itself completes, so `corgea scan` keeps polling while it finishes rather than reporting a result immediately. Analysis is done once every direct dependency has been analyzed, typically a few minutes and at most 30. This filter **fails open**. If analysis cannot finish — the 30-minute window elapses, analysis fails, or AI-Native SCA is disabled — the rule reports no violation instead of failing your build. A pipeline is only ever blocked on reachability that Corgea actually determined, never on missing analysis. > [!WARNING] > > `corgea scan` fails closed on its own deadline. Corgea CLI 1.13.0 and later allow 35 minutes, comfortably outlasting the 30-minute analysis window. On an earlier CLI the deadline is 15 minutes, which can expire while Corgea is still analyzing and fail the pipeline. Either upgrade the CLI or raise the deadline with `CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS`: > > ```bash theme={null} > CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS=2100 corgea scan --block-on reachable-criticals > ``` ## Examples > **Blocking Insecure Cryptography** > > **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. > **Enforcing Code Quality** > > **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. > **Blocking Critical Dependency Vulnerabilities** > > **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. > **Blocking Dependencies by CVSS Range** > > **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. > **Blocking Only Reachable Critical Vulnerabilities** > > **Rule Type:** Dependency Vulnerability — **Applies To:** CI > > Select "Critical" and "High" urgency levels, then select **Reachable** under Reachability. The rule fails a pipeline only when a critical or high-severity vulnerability is reachable from your application code, so unused and unreachable packages do not interrupt developers. This is a good first reachability rule because it narrows an existing severity rule rather than widening what blocks. > **Blocking Unused Dependencies** > > **Rule Type:** Dependency Vulnerability — **Applies To:** CI > > Select **Unused Dependency** under Reachability on its own, with no severity or CVSS filter. The rule fails a pipeline that introduces vulnerable packages nothing in the codebase uses, prompting developers to remove the dependency instead of upgrading it. > **Blocking Copyleft Dependencies** > > **Rule Type:** License Compliance > > Select the **Copyleft** family to block dependencies whose reported licenses belong to that family. Add specific SPDX IDs when your policy needs a narrower denylist. ## Best Practices > **Implementation Tips** > > * 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 > * On **CI rules**, add a **Reachable** reachability filter to an existing severity rule to cut noise without weakening coverage of the vulnerabilities that are actually exploitable > * 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 > [!WARNING] > > If a pull request is unexpectedly blocked, verify the active rules and their configurations first. > **Common Issues** > > * Unexpected blocking behavior > * Rule targeting issues > * Project scope problems > **Resolution Steps** > > * Check rule configurations > * Verify CWE targeting > * Confirm project settings > * Contact support if needed # Changelog Source: https://docs.corgea.app/changelog Product updates and announcements **2026.10.23** v1.82.4 **New Features:** * Added a branch scan timeline in scan details to review scan history, finding counts, and changes from earlier comparable scans. * Added `GET /api/v1/scan//sbom` to download a completed scan’s CycloneDX SBOM once its dependency inventory is ready. **UI & Experience:** * Branch search now lists previously scanned branches even without a source-control integration or when the remote branch is gone. Branch names containing special characters now open correctly. * Sped up SCA package and container image browsing in the workbench. — [Learn more](/vulnerabilities) * The scans list now stays visible and dims while loading. Removed the Feedback navigation link and its dialog. * Corgea Agent feedback history now shows the actual confidence in interpreting a comment, with clearer action labels and an explanation of what confidence measures. — [Learn more](/agent) **Reliability & Stability:** * PR scan comments now anchor to changed lines within the affected code range and avoid commenting on unchanged code. — [Learn more](/github) * Corgea Agent now considers the suggested fix when responding to feedback. Requests for a different fix receive code or a clear explanation that an alternative could not be provided. — [Learn more](/agent) * GitHub fix reactions added after the initial follow-up window are now picked up on recent active PRs. — [Learn more](/agent) * Triage justification review now applies only to false-positive and accepted-risk decisions; other status changes skip this review. — [Learn more](/triage_justifications) * Scan cards, static reports, and scheduled scan emails now count only open findings, excluding false positives and fixes in progress. * `GET /api/v1/issue/` now starts fix generation only when `generate_fix=true` is supplied. — [Learn more](/fixes) * The issue API now returns auto-triage false-positive reasoning and issue explanations even when no fix exists. * Improved incremental-scan revalidation when several scans run on the same project, and prevented results whose delivery failed from changing findings at scan completion. * Fixed Harness integrations interrupting nightly project tag synchronization for other integrations. **2026.10.21** v1.82.3 **UI & Experience:** * PR Rules dropdown lists now stay next to their fields when you scroll a dialog. — [Learn more](/policies#pr-scan-and-comment-rules) * Scan findings now show a pending-approval badge when a false-positive or accepted-risk decision is awaiting review. — [Learn more](/triage_justifications) * Corgea Agent feedback history now distinguishes actions that were not applied from requests that need review in Corgea, with a direct link to the finding. — [Learn more](/agent) **Reliability & Stability:** * Incremental scans now carry revalidated findings forward only when they are confirmed still present. Inconclusive results stay on the earlier scan without being marked fixed; findings are marked fixed only on the main branch when code changes confirm their removal. — [Learn more](/cli#incremental-scans) * Failed assignee updates, including those caused by an expired session, no longer appear successful. — [Learn more](/issue_assignment) **2026.10.20** v1.82.2 **UI & Experience:** * Sped up workbench tab counts and grouped browsing across finding types, keeping group totals, expanded findings, bulk selections, and CSV exports consistent. — [Learn more](/vulnerabilities) * Workbench search now clarifies that file-path searches in SAST, Logic & Auth, Secrets, and IaC require a project filter. — [Learn more](/vulnerabilities) **Reliability & Stability:** * Findings left with no remaining detections after scan deletion, reruns, or incremental-scan cleanup are now removed from the workbench. Findings still present in other scans retain their current details. — [Learn more](/vulnerabilities) * The workbench now shows a preparation notice until your organization's findings are ready, with exports and bulk selections available once preparation completes. — [Learn more](/vulnerabilities) * Corgea Agent now uses your earlier explanations and latest requested status in PR comment threads when processing false-positive and accepted-risk decisions, without borrowing another commenter's justification. — [Learn more](/agent) **2026.10.19** v1.82.1 **New Features:** * GitHub PR scans now use changed line ranges, available patches including removed lines, and the PR description to focus reviews on the changes and their intent. **UI & Experience:** * PR review comments now lead with urgency and finding type. Code-quality comments use the review's title and explanation without repeating the same details. **Reliability & Stability:** * Findings with no remaining detections no longer linger in workbench groups or counts after deletion or regrouping. Triage decisions are retained if the finding is detected again. — [Learn more](/vulnerabilities) * Code-quality PR comments are no longer suppressed by security urgency filters or request-reachability checks, and can appear without a suggested fix when fix generation does not support the language. **2026.10.19** v1.82.0 **New Features:** * Added VB6 and VB.NET language support, including syntax highlighting in code and fix views. * Scan APIs now return `triggered_by` and `source`, with `pull_request_id` also available in scan details. Automated source-control scans return `null` for `triggered_by`. **UI & Experience:** * Workbench search and filter dropdowns now show a spinner on the control loading results. Clearing a search no longer lets recently typed text reapply the filter. — [Learn more](/vulnerabilities) * The taint analysis tab now displays the scanner's data-flow path directly. Fallback traces stay tied to the reported finding, and findings with no applicable flow no longer trigger unnecessary trace generation. — [Learn more](/blast#reviewing-taint-analysis) **Reliability & Stability:** * Triage decisions now carry over when a finding is identified more precisely or recognized as the same issue on a non-main branch, while preserving decisions already made on the target finding. — [Learn more](/vulnerabilities) * Incremental scans now preserve finding types and secret subtypes when carrying findings forward. Urgency updates also stay in sync across finding views. — [Learn more](/vulnerabilities) * Scans retain the ignore rules applied when they started. Removing or changing an ignore rule now triggers a full scan when needed, while CLI scans can stay incremental when their changed-file list includes all newly included files. The scan-list API also reports each scan's applied ignore rules. — [Learn more](/project) — [Learn more](/cli) * CLI partial scans now honor the requested file selection and scan settings without archiving unrelated pending scans. API requests for the latest project or branch results prefer scans representing the full project state. — [Learn more](/cli) * Fixed projects disappearing from the projects page when names or repository URLs are shared. — [Learn more](/project) * Fixed Harness project rescans failing when the integration is resolved from the repository URL. * Private package registries now use their main repository URL alongside additional repositories, and their actions menu is no longer clipped. * Long-running pentests can now complete their 10-hour runtime window before stuck-run cleanup applies after 11 hours. **2026.10.15** v1.81.3 **New Features:** * Scan-page CSV exports now include a Finding Type column to distinguish SAST, Secret, Logic & Auth, and Code Quality findings, including downloads requested through Corgea Agent. — [Learn more](/agent) * PR scan rules now support separate scopes for vulnerabilities and code quality, plus project exclusions for company-wide or tag-based rules. Explicitly included projects still take precedence over exclusions. — [Learn more](/policies#pr-scan-and-comment-rules) * Added support for limiting GitHub PR code-quality scans to selected pilot users. **UI & Experience:** * The approvals page now filters by Corgea's approve or reject recommendation. Pending requests whose findings the latest full scan already marked false positive are hidden by default and can be viewed with Closed by rescan; they still require a review decision. — [Learn more](/vulnerabilities) **Reliability & Stability:** * Auto-triage rules now reapply to findings reopened after accepted-risk expiry. Edited comments and expiry dates reach matching findings already in the rule's status on their next scan, and expired rules stop applying consistently across timezones. — [Learn more](/settings#triage-rules) * Fixed PR scan rule validation and CWE matching so saved selections apply consistently. — [Learn more](/policies#pr-scan-and-comment-rules) * SAST findings now keep their classification, severity, and finding type in sync when scan results are updated. — [Learn more](/vulnerabilities) * Fixed repeated dependency, container, and IaC result uploads failing to link findings or apply follow-up triage. Also reduced conflicts between rescans and triage updates. — [Learn more](/vulnerabilities) * Prevented overlapping scheduled-scan and SLA notification jobs from repeating work while an earlier run is still active. — [Learn more](/scheduled-scans) — [Learn more](/notifications) **2026.10.15** v1.81.2 **New Features:** * Added a dedicated permission to access Corgea Agent, separate from permissions to view or manage its settings. Existing users with settings-view access retain access to the agent. — [Learn more](/agent) **UI & Experience:** * The workbench bulk action bar now offers a Change status modal with all statuses supported by the active tab, including reopening findings and accepting risks. It supports risk expiry where available and respects triage approval requirements. — [Learn more](/vulnerabilities) * Sped up SCA package browsing in the workbench. Packages are now ordered by name with Previous and Next navigation instead of numbered pages and totals. — [Learn more](/vulnerabilities) **Reliability & Stability:** * Rescans now preserve assignees for SAST, dependency, and IaC findings, plus due dates and SLA status for SAST and dependency findings. IaC triage decisions also remain consistent after rescanning. — [Learn more](/vulnerabilities) * PR scan rules with no severity selected now correctly apply to all severities. — [Learn more](/policies#pr-scan-and-comment-rules) * Fixed `--disable-incremental` being ignored, so CLI scans explicitly requesting a full scan analyze every file. — [Learn more](/cli) * Scan-page CSV and SARIF exports now match the active tab and its current table filters, including status and new-findings-only selections. — [Learn more](/issue_export) * Accepted-risk expiry now reliably reopens each finding once, even with large scan histories. Expiry summaries list up to 100 findings and include the full reopened count. — [Learn more](/notifications) **2026.10.12** v1.81.1 **UI & Experience:** * Added a project filter panel with tag, integration, and team filters, an active-filter count, and a Clear button. Tag and team dropdowns support search. — [Learn more](/project) * Refreshed scan-list filters with searchable tags and clearer scanner and scan-trigger dropdowns that highlight active selections. — [Learn more](/project) **2026.10.12** v1.81.0 **New Features:** * Added APIs to list, create, and deactivate users in your organization, and list available roles. * Added API support for updating an individual SAST finding's status with a justification and optional risk expiry, honoring triage approval requirements. — [Learn more](/triage_justifications) **UI & Experience:** * Workbench filters now show loading placeholders in the results area and a spinner on the selected status filter, while keeping search focus and filter controls in place. Large pagination totals are abbreviated, with exact counts available on hover. — [Learn more](/vulnerabilities) * Improved readability of approval reasoning and code references in triage suggestions, and project labels in PR rules. Fixed policy modal loading errors. — [Learn more](/triage_justifications) **Reliability & Stability:** * Scheduled-scan email and webhook reports now distinguish new findings from open totals, match scan-page counts, and include completed runs with no new findings. — [Learn more](/scheduled-scans) * Fixed PR scans failing when the scanning user has no active API token. GitHub and Azure DevOps organization scans now use an active member when no user is assigned, and record skipped events when none is available. * Revalidation no longer carries findings with an inconclusive result into the new scan, without marking the original findings fixed. * SCA package rows now show the version that fixes all listed advisories, or indicate that no fix is available if any advisory lacks a known fix. * Fixed pagination and workbench drill-downs receiving duplicate page or filter values, including page navigation in webhook history. — [Learn more](/vulnerabilities) * Reduced loading delays for project lists and vulnerability reports. **2026.10.10** v1.80.5 **New Features:** * Added cumulative charts for vulnerabilities and fixed findings, plus an open-findings chart grouped by classification and severity. **UI & Experience:** * Reporting now supports multi-select project, team, tag, and branch filters, with an Apply button for each selection. Status filters let you choose which finding states appear in the flow chart. * Workbench grouped results now show totals and numbered page links, with Next stopping at the last available page. — [Learn more](/vulnerabilities) * Finding debug details now explain why unchanged code was rescanned and show which context or scan instructions changed. **Reliability & Stability:** * Reporting cards and charts now count each finding once across all tabs, avoiding inflated totals from repeated detections. IaC reporting counts only open findings, and chart refreshes retain the selected filters. * Fixed IaC findings marked false positive or accepted risk appearing open after a rescan. * GitLab merge request creation failures now show a clear error. Retrying can reuse a branch left by a failed attempt when it has no new commits. — [Learn more](/gitlab) * Fixed concurrent scans failing when uploading the same `corgea.yaml` policy file. Policies with a missing or invalid `type` now return a validation error instead of a server error. **2026.10.08** v1.80.4 **New Features:** * Corgea Agent now supports company context documents managed by admins, so answers can draw on your processes, policies, and standards. Conversations have bookmarkable URLs for reopening a saved chat. * Added reporting charts in Corgea Agent for fixes, scans, scan duration, MTTR, severity, and common finding types, with PNG and CSV downloads. The agent can also link to CSV exports of a scan's security and code-quality findings. **UI & Experience:** * Refreshed Corgea Agent chat with a clearer conversation history, a centered message area, syntax highlighting, and documentation screenshots. * Workbench tab counts now appear immediately when already available, with a clearer loading indicator while new counts are calculated. — [Learn more](/vulnerabilities) * Fixed assignee menus stretching across the screen instead of matching the assignment control. **Reliability & Stability:** * Approved false-positive learning policies now stay active after updates and can be reactivated from the Policy Center. * Fixed repeated loading of bulk-selection summaries and justification suggestions while the workbench false-positive panel is open. — [Learn more](/vulnerabilities) — [Learn more](/triage_justifications) * Fixed workbench page links opening the wrong page when the browser URL already contains a page number, while preserving expanded groups. Sped up Dependencies drill-downs for large finding sets. — [Learn more](/vulnerabilities) * Findings with CWEs missing from the catalog now retain their original classification label in API responses. * Corrected MTTR and resolved-finding reporting so findings first fixed before the selected date range are not counted again when fixed a second time. **2026.10.08** v1.80.3 **Reliability & Stability:** * Improved finding fingerprint updates by skipping groups that previously failed, while allowing a fresh retry or limiting updates to findings from the last day. * Fingerprint updates now save the previous fingerprint for rollback only when requested. When saved, rollback restores the fingerprint from the latest update rather than an earlier one. **2026.10.07** v1.80.2 **New Features:** * Added thumbs-up and thumbs-down reactions as fix votes on Corgea-posted finding comments in GitHub and GitLab. Removing a reaction updates the vote without overwriting feedback given in a written comment. **UI & Experience:** * The projects list's Teams column now includes active teams matched by project tags or repository URL patterns, alongside directly linked teams, without duplicates. * Corgea Agent now acknowledges recorded status changes and fix feedback with a thumbs-up reaction on GitHub and GitLab, reducing comment noise. Text replies are used when reactions are unavailable or fail. **Reliability & Stability:** * Fixed CLI-scanned projects missing their source control integration. Projects now connect automatically when their repository URL matches exactly one active integration. — [Learn more](/cli) * Improved validation of generated Python fixes to reject suggestions that accidentally turn executable code into docstring text. **2026.10.06** v1.80.1 **UI & Experience:** * Simplified the Vulnerabilities workbench by removing summary tiles and aligning its filter bar with the project scan page. * Workbench findings now open in the app's standard issue panels. Bulk triage actions are now Assign and False positive; other status changes are available in each finding's panel. * Improved workbench pagination with clearer spacing, totals, and numbered page links. Project lists show 15 rows per page and other levels show 20. Large counts are abbreviated, with exact values available on hover. * Updated group permission-change emails with a clearer summary of who made the change and how many permissions were added or removed. **Reliability & Stability:** * Sped up workbench tab counts and load them after the page renders, so counting findings no longer delays opening the page. * Fixed older findings reappearing in workbench drill-downs after a rescan changes their grouping, keeping expanded results and bulk selections consistent with group counts. * Refused assignments now show an error and restore the previous assignee instead of appearing successful. * Fixed fix generation repeatedly restarting when a saved fix cannot be loaded. The issue now shows a clear error. * Fixed replies to `@Corgea` mentions in GitHub pull request conversations and posting PR comments without Issues read permission. Also fixed GitHub scans failing when the project name includes the repository owner. — [Learn more](/github) **2026.10.06** v1.80.0 **Reliability & Stability:** * Improved SAST finding tracking so different CWEs reported on the same statement retain separate triage, history, detection dates, and explanations. New findings are correctly identified in scan results and pull request comments. * Merged SAST findings now keep the newest applicable triage decision, with the outcome recorded in their history. Expired accepted risks and findings detected again after a fix are reopened when no other standing decision applies. * Fixed incremental scans dropping a finding or failing to mark it fixed when another CWE remains on the same statement. — [Learn more](/cli#incremental-scans) * Fixed report uploads treating different CWEs at the same code location as duplicates, and CxOne triage imports applying a decision to a different CWE. * Previous false-positive verdicts and automatic learning now distinguish between CWEs on the same statement, preventing unrelated verdicts from being reused and ensuring each classification can contribute to learning. * Invalid assignee IDs now return a validation error instead of a server error for individual and bulk assignments. — [Learn more](/vulnerabilities) **UI & Experience:** * Fixed Advanced Vulnerability Search failing when many filter values are selected. * Fixed keyboard handling in searchable dropdowns and improved table scrolling and policy action menu visibility on smaller screens. * Improved checkbox, radio button, and switch contrast in light and dark themes, with clearer partial-selection indicators. **2026.10.02** v1.79.11 **Reliability & Stability:** * Prepared updated finding fingerprints based on stored source code for more consistent matching across scans, while preserving existing issue tracking and triage history. **2026.10.02** v1.79.10 **Reliability & Stability:** * Fixed incremental scans clearing accepted-risk expiry dates when carrying existing SAST findings forward. Assignees, due dates, and SLA status are also preserved. — [Learn more](/cli#incremental-scans) **2026.10.01** v1.79.8 **New Features:** * Added support for separate projects for the same repository when scanning with an explicit CLI `--project-name`, where this behavior is enabled. Scans use the named project's file include and ignore rules. — [Learn more](/cli) **Reliability & Stability:** * Reduced delays in approval suggestions by prioritizing pending requests on the page being reviewed. Opening one page does not generate suggestions for requests on another page, and requests submitted by an agent do not get a review suggestion. — [Learn more](/triage_justifications) * Fixed scheduled and manually triggered scans being assigned to a different project when multiple projects share a repository. — [Learn more](/project) **2026.10.01** v1.79.7 **Reliability & Stability:** * Fixed automatic triage rules not applying to findings carried forward during incremental scans and revalidation, so matching untriaged findings now receive the configured triage decision instead of staying open. — [Learn more](/settings) **2026.10.01** v1.79.6 **Reliability & Stability:** * Auto triage rules now apply when a later scan detects an older open SAST or SCA finding that still has no triage comment. A finding that already has a triage comment, or a status other than **Open**, stays unchanged. — [Learn more](/settings) **2026.09.30** v1.79.5 **New Features:** * Added automatic triage rules for companies where the feature is enabled. Company admins can set a default status, comment, and accepted-risk expiry for new SAST and SCA findings based on project name or repository URL patterns, while existing findings retain their triage decisions. **Reliability & Stability:** * SAST SARIF exports now exclude fixed findings, false positives, and accepted risks, so CI tools no longer re-flag these triaged findings. — [Learn more](/issue_export) * Sped up vulnerability reporting, including issue flow diagrams, mean time to remediation, and burndown charts. * Sped up retrieval of source code ZIP download links through the API. * Reduced scan-processing overhead when completing scans, looking up previous false-positive explanations, and resolving policies from dependent projects. **2026.09.30** v1.79.4 **Reliability & Stability:** * Company admins can now apply false-positive and accepted-risk decisions through the API without approval, unless approval is explicitly requested. Non-admin API requests now respect the company’s approval toggles for these decisions. — [Learn more](/triage_justifications) **2026.09.30** v1.79.3 **New Features:** * Added support for a comma-separated list of up to 50 commit SHAs in the scan list API's `sha` filter, so you can find scans for multiple commits in one request. * Issues now retain scanner metadata, such as Fortify instance IDs, which you can retrieve through the issue API with `include_metadata=true`, even when no fix is available. **2026.09.29** v1.79.2 **Reliability & Stability:** * Sped up issue pages when pull request controls are hidden, including findings without a fix or with a fix on hold. — [Learn more](/fixes) * Sped up loading of SCA, container, and IaC findings in scan results. * Sped up blocking rule checks for scans with many findings. **2026.09.29** v1.79.1 **UI & Experience:** * Fixed tooltips on shortened context file paths in issue details so hovering shows the full path. * Corrected duplicated wording in automatic false-positive messages in issue explanations and fix views. **Reliability & Stability:** * Sped up incremental scan uploads for projects with many carried-over findings, reducing upload timeouts. **2026.09.29** v1.79.0 **New Features:** * Added suggested approval and rejection responses for bulk triage requests, with editable notes and reviewer confirmation, for companies with triage suggestions enabled. — [Learn more](/vulnerabilities) * Added incremental scan revalidation for companies where it is enabled, preserving existing findings and triage decisions when code moves and marking confirmed resolved findings as fixed after a successful scan. — [Learn more](/cli#incremental-scans) **Reliability & Stability:** * Fixed project CWE filters to respect file glob patterns during scanning and when carrying findings forward, so file-specific rules no longer ignore the CWE across the entire project. — [Learn more](/project) * Fixed the company notification defaults page freezing for organizations with many teams. — [Learn more](/notifications) * Sped up issue lists retrieved through the API and CLI, including scan-specific results and fix availability. — [Learn more](/cli) **2026.09.25** v1.78.5 **UI & Experience:** * Standardized GitLab repository paths in the Projects list so discovered repositories and scanned projects use consistent labels. — [Learn more](/project) **Reliability & Stability:** * Fixed GitLab scans on branches containing slashes creating duplicate projects or failing to match the repository in the Projects list. — [Learn more](/project) **2026.09.24** v1.78.4 **Reliability & Stability:** * Fixed failures when changing SAST finding statuses, including bulk triage, while other triage actions or scan processing are running. — [Learn more](/vulnerabilities) **2026.09.24** v1.78.3 **New Features:** * Added a scan timing API and MCP tool to report scan duration and queue wait statistics, with date filters and breakdowns by project, engine, or branch. **UI & Experience:** * Added a searchable reviewer filter to the approvals queue to find requests approved or rejected by a specific reviewer. — [Learn more](/vulnerabilities) * Redesigned the Harness integrations dialog with search, status filters, and a dedicated details pane for each integration. — [Learn more](/harness) * Improved GitLab repository search with exact matches listed first, support for full repository paths, and clearer repository labels in selectors and the Projects list. — [Learn more](/project) **Reliability & Stability:** * Sped up processing of SAST and dependency findings, including repeated scans. * Reduced scan-processing delays under heavy load and prevented slow pull request diff lookups from holding up other findings for the same project. **2026.09.23** v1.78.2 **New Features:** * Added file include rules in project settings to specify files and folders to always scan, with controls to enable, disable, or delete each rule. **UI & Experience:** * Renamed the sidebar group to Agent and moved Feedback History into Corgea Agent settings. — [Learn more](/agent) * Added a close button to the feedback modal. * Improved project details with searchable member selection, clearer scan status descriptions, and accurate scan counts across all pages. * Fixed clipped dropdowns, overflowing labels, and dialogs in Advanced Vulnerability Search. — [Learn more](/project) **Reliability & Stability:** * Fixed issue sidebar controls staying in Processing after a fix is ready, and made missing-branch guidance visible when a pull request cannot be created. — [Learn more](/fixes) * Fixed blank file logs for incomplete BLAST scans, showing available file paths and an explanation when logs were not recorded. * Restored SCA and container finding history across rescans, including earlier status and assignment changes. * Reduced unnecessary rescanning when README, text, or configuration files change during incremental scans, while continuing to scan the changed files themselves. **2026.09.22** v1.78.1 **UI & Experience:** * Added a searchable team filter to the Vulnerabilities Workbench to review findings across a team's projects, with the same filter applied to exports and bulk selections. — [Learn more](/vulnerabilities) **Reliability & Stability:** * Sped up grouped findings and status counts in the Vulnerabilities Workbench, with Previous/Next navigation that remains available when triage empties the current page. — [Learn more](/vulnerabilities) * Made scan processing and SCA triage batch limits independently configurable, allowing deployments to tune processing capacity for larger workloads. **2026.09.22** v1.78.0 **UI & Experience:** * Harness integrations now show permission errors, expired tokens, and integration owners, with integrations needing attention listed first. * Improved the live pentest agent tree with clearer activity summaries, accurate agent statuses, and findings attributed to the reporting agent. — [Learn more](/pentesting) **Reliability & Stability:** * Reduced GitHub API usage during pull request scans, check updates, and fix comments. — [Learn more](/github) * GitHub check updates and fix comments now retry after rate limits reset, reducing stuck checks and missing comments. — [Learn more](/github) * Reduced memory-related failures when processing dependency inventories from large scans. — [Learn more](/issue_export) * Sped up processing of scan findings, discovered endpoints, and call paths. — [Learn more](/project) * Sped up policy lookup for projects and their dependencies. — [Learn more](/policies) **2026.09.20** v1.77.4 **New Features:** * Added API support for storing and retrieving scan file manifests and selecting an incremental baseline by scan ID, enabling compatible clients to scan only changed files in shallow clones or directories without Git history. **UI & Experience:** * Made the scans list faster to load, with in-place updates for active scans and a button to show newly available scans. * Fixed project access control and GitHub team sync toggles to show clear feedback and revert when an update fails. **Reliability & Stability:** * Improved scan processing performance when saving findings and scan logs, retrieving previous false-positive explanations, and carrying triage decisions forward across scans. **2026.09.18** v1.77.3 **Reliability & Stability:** * Sped up SAML sign-in and reduced first-login delays caused by slow signup webhooks. — [Learn more](/sso) * Improved reliability of scheduled scans, reports, and other background tasks by reducing memory-related failures. * Improved cancellation of scans superseded by a newer push to the same pull request, and prevented cancelled scans from being marked as failed or triggering scan-failed webhooks. — [Learn more](/github) **2026.09.17** v1.77.2 **UI & Experience:** * Company admins can now choose email recipients from company admins, selected teams, or everyone, including for SLA and scheduled-scan failure notifications. — [Learn more](/notifications) * Improved button and badge contrast in light and dark themes, corrected control sizing, and kept account and logout controls accessible in the mobile sidebar. * Made command palette search more responsive, with searches starting at two characters and up to 20 matching projects. **Reliability & Stability:** * Sped up vulnerability and aging reports, SCA summaries, and dependency finding lists for large accounts. * Improved loading of project scan results and findings grouped by endpoint. — [Learn more](/project) * Processed SCA and IaC findings faster, and skipped extra work on SCA scans with nothing left to triage. * Reduced delays when changing finding status while AI reviews triage explanations. * Fixed IaC status-change webhooks failing to send and ensured they include the finding's title and source file path. **2026.09.17** CLI v1.14.2 / v1.14.1 / v1.14.0 **New Features:** * Third-party `corgea upload` now automatically includes `corgea.yaml` and `corgea.yml` policy files from the repository, so repo policies apply even when the scanner report does not reference them. — [Learn more](/cli) **Reliability & Stability:** * CLI API calls automatically retry `429 Too Many Requests` responses. `502 Bad Gateway` responses are retried for read requests only, avoiding duplicate scans from retried writes. — [Learn more](/cli) **2026.09.16** v1.77.1 **New Features:** * Added a guided pentest target setup wizard with multiple login accounts and optional TOTP credentials. When email support is enabled, dedicated inboxes let agents complete email verification, password resets, and emailed login codes. — [Learn more](/pentesting) **UI & Experience:** * Fixed the fix diff viewer overflowing into the adjacent column. — [Learn more](/fixes) * Removed the hover shadow from link-style buttons for a cleaner appearance. **Reliability & Stability:** * Fixed scans that could remain stuck in cancellation when they had not started yet. * Corgea Agent now respects its enablement setting when processing pull request comments. — [Learn more](/agent) * Reduced unrelated GitHub pull request comments by limiting findings to changed code, and improved validation of suggested Python fixes. — [Learn more](/agent) * Improved SAST triage consistency across repeated detections and bulk actions, including handling duplicate findings in uploaded reports. — [Learn more](/vulnerabilities) * Fixed CWE lookups and API filtering and grouping for identifiers with leading zeros, without matching unrelated CWE IDs. **2026.09.14** v1.77.0 **New Features:** * Added on-demand CycloneDX SBOM downloads from completed scans' dependency inventories. — [Learn more](/issue_export#dependency-exports) * Added GitHub team membership sync for already-linked teams, with automatic updates when users join and a manual **Sync membership** option that preserves project links. — [Learn more](/content-access-management#github-team-sync) **Reliability & Stability:** * Fixed the Issues column on the pentest Runs tab to show findings for active, failed, and cancelled runs, and preserved finding counts in failure notifications. — [Learn more](/pentesting) * Fixed scheduled scan report titles to reflect the scan frequency, so weekly reports are no longer labeled daily. — [Learn more](/notifications) * Fixed issue pages failing to load when a scan has no recorded branch. * Improved scan status API performance for clients that frequently check scan progress. **2026.09.10** v1.76.4 **Reliability & Stability:** * Fixed missing status-change and assignment webhooks for dependency, container, and IaC findings. — [Learn more](/webhooks) **2026.09.10** v1.76.3 **UI & Experience:** * Made Corgea Agent a top-level sidebar item and moved Feedback History into its settings, with clearer command palette results. — [Learn more](/agent) * Grouped new agent learning recommendations into a daily email digest for admins, with a summary and a link to review pending recommendations. — [Learn more](/notifications#auto-learning-recommendations-digest) * Improved Advanced Vulnerability Search with inline SCA and container finding details, IaC assignment and status controls, and clearer filters and layouts on smaller screens. — [Learn more](/project#advanced-vulnerability-search) * Improved form readability in light and dark themes and made reporting charts and empty states more consistent. **Reliability & Stability:** * Restored Create PR for CLI and IDE scans of connected repositories, with clearer guidance when the scanned branch needs to be pushed. — [Learn more](/fixes) * Fixed GitHub team membership updates being missed when webhook events omit the team slug. * Harness repository discovery now keeps accessible repositories when other projects are unavailable or lack the Code module. * Sped up SBOM updates for projects with large dependency trees. * Added separate capacity settings for pull request scans and full scans so each type can run without blocking the other. **2026.09.09** v1.76.2 **New Features:** * Added API support for grouping code findings by file path and dependency findings by package, with summary counts and exact filters to review each group's findings. **UI & Experience:** * Redesigned permission-change emails with a clearer summary of who made the change, counts of added and removed permissions, and a link to review access. — [Learn more](/permission_groups) * Added feature overviews and demo booking for Security Review, Pentests, and Agent Learnings when they are not included in your plan. — [Learn more](/pentesting) **Reliability & Stability:** * Unsupported MCP streaming requests now return promptly instead of leaving connections hanging. — [Learn more](/modelcontextprotocol) * Improved handling of compressed pentest reports so they are stored correctly. — [Learn more](/pentesting) **2026.09.08** v1.76.1 **UI & Experience:** * Issue explanations and suggested fixes now show current guidance from applicable policies, including false-positive policies. — [Learn more](/policies) * Simplified JWT Auth role assignment with a role picker and the option to create a role without leaving the configuration form. — [Learn more](/jwt-token) * Centered the warning icon when a suggested fix cannot be generated. — [Learn more](/fixes) **Reliability & Stability:** * Restored original file contents in issue and fix views when large findings were uploaded without the full source code. — [Learn more](/fixes) * Improved platform stability under memory pressure and recovery of scan-related background tasks after temporary database failures. **2026.09.07** v1.76.0 **New Features:** * Added an option for API clients to wait for Generate Fix results with `wait_for_the_fix=true`, while the web interface shows progress and automatically displays the completed fix. — [Learn more](/fixes) * Added lifecycle email support through Loops.so for signup and trial milestones, keeping messages aligned with account plans and onboarding progress. **UI & Experience:** * False-positive decisions now require an explanation of why the finding is not a real vulnerability, including bulk actions and Corgea Agent comments, with guidance when more detail is needed. — [Learn more](/triage_justifications) * Improved issue-detail layouts across screen sizes and made the pilot countdown clearer in the collapsed sidebar. **Reliability & Stability:** * Preserved valid false-positive and accepted-risk decisions when duplicate findings are merged, while retaining existing assignments and due dates. * Fixed intermittent missing CWE information, including weakness names in pentest findings. — [Learn more](/pentesting) * Fixed paid accounts being downgraded when an earlier trial expires. **2026.09.04** v1.75.4 **Reliability & Stability:** * Fixed SCA triage decisions so they continue to carry forward across rescans instead of being reset by a newer finding with no triage activity. — [Learn more](/sca) **2026.09.03** v1.75.3 **New Features:** * Added configurable approval workflows for false-positive and accepted-risk decisions, with a searchable review queue, reviewer notes, history tracking, notifications, and a dedicated reviewer permission. — [Learn more](/triage_justifications) * Added Bitbucket support for running scans, including branch resolution and repository content retrieval. — [Learn more](/bitbucket) **UI & Experience:** * Scan Logs now preserve the selected File Logs or Errors, Warnings & Info tab while active scans refresh. — [Learn more](/project) * Triage justifications for false-positive and accepted-risk decisions must now provide a meaningful reason, with clear feedback when more detail is needed. — [Learn more](/triage_justifications) **Reliability & Stability:** * Improved Advanced Search performance for large result sets and ensured findings with missing metadata continue to load. — [Learn more](/project#advanced-vulnerability-search) * Improved scan processing reliability during concurrent deployments and SCA or IaC batch ingestion. * Fixed dependency finding views that could fail while displaying usage analysis. **2026.09.03** CLI v1.13.0 / v1.12.0 **New Features:** * Added `corgea mcp install` so a logged-in CLI writes the Corgea MCP server into supported agent configs (Cursor, Claude Desktop, Claude Code, Windsurf, VS Code, Gemini CLI, Continue, and OpenCode). If the CLI is not installed, use `npx` as documented on the CLI page. — [Learn more](/cli#install-mcp-server) * BLAST scans are incremental by default: the CLI diffs against the project's last clean scan locally and analyzes only changed files. Use `--disable-incremental` to analyze every file. — [Learn more](/cli) **Reliability & Stability:** * Raised the default blocking-rules wait to 35 minutes so CI gates outlast SCA reachability triage. — [Learn more](/blocking_rules) * Reports a dirty worktree only when `git status` does, so ignored or equivalent files no longer force a full scan. **2026.09.02** v1.75.2 **Reliability & Stability:** * Fixed Advanced Search so vulnerability results load reliably, including findings with incomplete metadata. * Improved Advanced Search for large result sets with pagination and caching, preventing timeouts and allowing complete CSV exports beyond the previous 30,000-finding limit. **2026.09.01** v1.75.1 **Reliability & Stability:** * Fixed SAML sign-in so first-time users can be provisioned through their identity provider when self-service registration is disabled. — [Learn more](/sso) * Improved Azure DevOps pull request processing so permission-denied responses are skipped cleanly without unnecessary error reports. — [Learn more](/azure_devops) * Improved long-running scan reliability by preventing active legacy scans from being automatically requeued or incorrectly marked as failed. **2026.08.28** v1.74.3 **UI & Experience:** * Added dependency license badges and license filtering, and reordered dependency lists and SCA results to show direct dependencies before transitive dependencies. — [Learn more](/sca) **Reliability & Stability:** * Fixed SCA triage decisions so they continue to carry forward across rescans when earlier findings were not linked in scan history. — [Learn more](/sca) **2026.08.27** v1.74.2 **New Features:** * Added support for installing the Corgea plugin for IntelliJ IDEA directly from the Integrations page. — [Learn more](/jetbrains_extension) * Added support for applying repository-defined policies during scans. **UI & Experience:** * Redesigned the sidebar and settings experience with clearer navigation and reorganized account, company, integration, notification, and agent settings. — [Learn more](/settings) * Improved content-access filters and layouts so long selections no longer overlap surrounding controls. — [Learn more](/content-access-management) * Simplified Secrets scan cards and workbench results by removing unsupported criticality and validity indicators. — [Learn more](/vulnerabilities) * Fixed pagination layouts so controls remain contained on scan and feedback pages with many results. — [Learn more](/project) **Reliability & Stability:** * Improved pull request comments so GitHub and GitLab findings anchor only to valid changed lines, while unanchorable quality comments are omitted instead of appearing on unrelated code. * Improved scan throughput and recovery by allowing multiple scans to be processed concurrently and safely reclaiming interrupted work. * Fixed scheduled scan dates and last-run times so they match the schedule's configured day and timezone. — [Learn more](/scheduled-scans) * Improved GitHub repository discovery by warming inactive caches and avoiding incorrect integration deactivation after temporary API responses. * Fixed GitHub sign-up so disabled workspace registration is enforced consistently. **2026.08.25** v1.74.1 **Reliability & Stability:** * Unified issue tracking for SCA, container, and IaC findings so triage, assignments, due dates, accepted-risk expirations, and SLA status remain consistent across rescans while views and reports show the latest detection details. — [Learn more](/sca) **2026.08.24** v1.74.0 **New Features:** * Added webhook delivery for scheduled scan failures, expired accepted risks, expired integration credentials, and completed AI pentests. — [Learn more](/webhooks) * Added support for removing company administrators from teams. **UI & Experience:** * Added page-size controls to the Scans list and scan finding tables, making it easier to review more than 20 results at a time. — [Learn more](/project) * Improved project filters with search and scrolling for long team and tag lists. — [Learn more](/project) * Improved issue explanations with clearer formatting and consistent scanner-provided details. — [Learn more](/vulnerabilities) **Reliability & Stability:** * Fixed duplicate page updates that could cause lists and controls to load or refresh twice. **2026.08.22** v1.73.3 **New Features:** * Added SCA findings to SARIF exports as a separate run alongside SAST findings, allowing compatible tools to ingest both finding types while keeping them distinct. — [Learn more](/issue_export) * Added support for signing in directly to Corgea Admin. **2026.08.19** v1.73.2 **New Features:** * Added private package registry support for Maven, PyPI, and NuGet, allowing dependency scans to resolve internal packages and their transitive dependencies. Registries can apply company-wide or to selected projects. — [Learn more](/private-package-registries) * Added reachability filtering to CI dependency Blocking Rules, so pipelines can focus enforcement on vulnerabilities based on whether affected code is reachable. **UI & Experience:** * Simplified the Scans list by removing metadata-specific filters and organizing scan metadata into expandable tags alongside clearer project and repository details. **Reliability & Stability:** * Improved Harness repository identification by unifying clone and web URLs, preventing duplicate projects and ensuring the correct integration is used for vanity domains and multiple Harness accounts. — [Learn more](/harness) **2026.08.18** v1.73.1 **Reliability & Stability:** * Fixed SCA findings so bulk-triage decisions carry forward correctly across rescans. — [Learn more](/sca) **2026.08.17** v1.73.0 **New Features:** * Added Rust support across code, secret, and dependency scanning. — [Learn more](/blast) * Added tag filtering to the Vulnerability Workbench, making it easier to focus on findings from selected projects. — [Learn more](/vulnerabilities) * Added downloadable PDF scan reports through the API, including audit-ready reports for completed scans with no code findings. * Added controlled bulk-triage write actions for agent workflows, with safeguards for higher-impact changes. — [Learn more](/api-reference/triage/bulk-triage-findings) * Added the acting user to issue status change webhook payloads, improving auditability for automated workflows. **UI & Experience:** * Fixed scan detail loading indicators so they update when a scan completes without requiring a page reload. * Improved project search performance and responsiveness for workspaces with many projects. — [Learn more](/project) * Refined team badges on project pages with more consistent, less dominant colors. * Removed the focus shadow from vulnerability accordions for a cleaner browsing experience. **Reliability & Stability:** * Improved SCA and container finding identifiers so issues remain consistently tracked across scans. — [Learn more](/container-scanning) * Fixed scan summaries so findings with `image:` identifiers are counted as container findings. — [Learn more](/container-scanning) * Prevented oversized IaC classification values from interrupting finding ingestion. * Fixed Free plan usage enforcement so unlimited scanning works as intended. * Fixed Harness integration selection and repository identification for projects created through the CLI. * Made SSO and JWT authentication availability independent of Enterprise plan checks. — [Learn more](/sso) * Improved API handling of malformed or non-UTF-8 JSON requests so they return a clear validation error. **2026.08.12** v1.72.4 **Reliability & Stability:** * Improved dependency, container, and IaC finding tracking so the same issue remains consistently identified across scans and retains its triage and assignment context. — [Learn more](/sca) * Improved web app responsiveness and database reliability by reusing healthy database connections between requests. **2026.08.12** v1.72.3 **New Features:** * Added mandatory email one-time password verification for password-authenticated users, providing an additional sign-in verification step. — [Learn more](/security) * Added an email one-time password fallback for SSO users, allowing enabled workspaces to maintain access when their identity provider is unavailable. — [Learn more](/sso) **Reliability & Stability:** * Improved Harness repository search so matching repositories appear even in projects with more than 100 repositories. **2026.08.11** v1.72.2 **New Features:** * Added bulk triage ingestion for applying and auditing status changes across SAST and SCA findings, with approval policies for higher-impact actions. — [Learn more](api-reference/triage/bulk-triage-findings) **UI & Experience:** * Added PDF exports for scans with no findings, making it possible to download and share a complete report for clean scans. **Reliability & Stability:** * Improved post-scan SCA history processing for projects with extensive scan histories, reducing delays after scans complete. **2026.08.10** v1.72.1 **Reliability & Stability:** * Improved batch IaC API performance, reducing delays when processing multiple findings. — [Learn more](/iac) **2026.08.10** v1.72.0 **New Features:** * Added an API endpoint that reports the running Corgea web app version, helping clients verify compatibility with a deployment. **UI & Experience:** * Improved pagination across scan lists and other large result sets so page controls stay compact and no longer overflow. — [Learn more](/project) * Simplified the File Logs tab by removing the Limited skip detail warning when complete skip-reason coverage is unavailable. * Updated Vulnerability Workbench access so the navigation and workbench actions are shown only when enabled for your workspace's plan. — [Learn more](/false_positive) **Reliability & Stability:** * Improved CLI scan accuracy for worktrees with uncommitted changes by automatically running a full scan instead of reusing incremental results, and added a `dirty` indicator to scan details and API responses. — [Learn more](/cli) * GitHub pull request scans are now deferred while a pull request is in draft and start when it is marked ready for review. — [Learn more](/github) * Improved IaC scan processing and triage carry-forward performance, preventing large finding histories from disrupting scan ingestion while preserving prior triage decisions. — [Learn more](/iac) **2026.08.07** v1.71.3 **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. **2026.08.06** v1.71.2 **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) **2026.08.04** v1.71.1 **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. **2026.08.03** v1.71.0 **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) **2026.07.30** v1.70.3 **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) **2026.07.29** v1.70.2 **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. **2026.07.28** v1.70.1 **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. **2026.07.27** v1.70.0 **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) **2026.07.20** v1.69.0 **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. **2026.07.06** v1.68.0 **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. **2026.07.02** v1.67.0 **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. **2026.06.25** v1.66.0 **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) **2026.06.12** v1.65.2 **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. **2026.06.04** v1.65.1 **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. **2026.06.01** v1.65.0 **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) **2026.05.29** v1.64.6 **Reliability & Stability:** * Fixed Dropsite scan runs so teams can start scans from uploaded code or connected repositories more reliably. **2026.05.29** v1.64.5 **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. **2026.05.28** v1.64.4 **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. **2026.05.28** v1.64.3 **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. **2026.05.21** v1.64.2 **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) **2026.05.21** v1.64.1 **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) **2026.05.20** v1.64.0 **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. **2026.05.19** Web v1.63.9 **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) **2026.05.19** Web v1.63.8 **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. **2026.05.18** Engine v1.20.7 **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. **2026.05.15** Web v1.63.7 **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. **2026.05.11** Engine v1.20.4 **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 **2026.05.06** Web v1.63.6 **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) **2026.05.06** Web v1.63.5 **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) **2026.05.05** Web v1.63.4 **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. **2026.04.29** Web v1.63.3 **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. **2026.04.29** Web v1.63.2 **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. **2026.04.27** v1.63.1 **Reliability & Stability:** * Improved upgrade reliability for issue analysis tracking data, reducing migration risk when moving to this release. **2026.04.27** v1.63.0 **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. **2026.04.20** v1.62.6 **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. **2026.04.17** v1.62.5 **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. **2026.04.17** v1.62.4 **UI & Experience:** * Fixed scheduled-scan scope tab switching so changing between Projects, Tags, and Teams consistently shows the correct targeting options. **2026.04.17** v1.62.3 **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. **2026.04.16** v1.62.2 **UI & Experience:** * Improved Policies page filtering and search usability, including support for searching policies by ID. **Reliability & Stability:** * General bug fixes and performance improvements. **2026.04.15** v1.62.1 **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. **2026.04.09** v1.62.0 **Security & Permissions:** * Expanded domain-level registration restrictions to cover additional domains and their visually similar homograph variants as part of ongoing abuse prevention controls. **2026.04.09** v1.61.9 **UI & Experience:** * Fixed scheduled scan list day-of-week display so weekly schedules now show the correct weekday. — [Learn more](/scheduled-scans) **2026.04.09** v1.61.8 **UI & Experience:** * Fixed sidebar account-menu display for users with long names, so profile names no longer overflow or crowd navigation controls. **2026.04.08** v1.61.7 **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. **2026.04.02** v1.61.6 **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. **2026.04.01** v1.61.5 **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. **2026.03.30** v1.61.4 **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. **2026.03.27** v1.61.3 **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. **2026.03.19** v1.61.2 **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. **2026.03.19** v1.61.1 **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) **2026.03.17** v1.61.0 **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. **2026.03.13** v1.60.8 **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. **2026.03.10** v1.60.7 **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. **2026.03.05** v1.60.6 **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. **2026.03.04** v1.60.5 **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. **2026.03.04** v1.60.4 **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. **2026.03.02** v1.60.3 **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. **2026.02.27** v1.60.2 **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. **2026.02.26** v1.60.1 **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 **2026.02.25** v1.60.0 **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. **2026.02.18** v1.59.5 **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. **2026.02.17** v1.59.4 **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 **2026.02.11** v1.59.3 **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. **2026.02.10** v1.59.2 **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 **2026.02.03** v1.59.1 **Reliability & Stability:** * Improved system logging and error tracking for better monitoring and diagnostics. * General bug fixes and performance improvements. **2026.02.03** v1.59.0 **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. **2026.01.23** v1.58.7 **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. **2026.01.22** v1.58.6 **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. **2026.01.22** v1.58.5 **Bug Fixes:** * Fixed an issue with the false positive filter not working correctly on the new scan page. **2026.01.22** v1.58.4 **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. **2026.01.21** v1.58.3 **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. **2026.01.21** v1.58.2 **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 **2026.01.19** v1.58.1 **Improvements:** * Enhanced admin interface compatibility and performance. * General bug fixes and stability improvements. **2026.01.16** v1.58.0 **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. **2026.01.15** v1.57.4 **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. **2026.01.14** v1.57.3 **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. **2026.01.13** v1.57.2 **Improvements:** * Enhanced cookie handling for better session management and security. * General bug fixes and performance improvements. **2026.01.12** v1.57.1 **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. **2026.01.12** v1.57.0 **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. **2026.01.09** v1.56.0 **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. **2026.01.08** v1.55.9 **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 **2026.01.08** v1.55.8 **Reliability & Stability:** * Improved logging and system diagnostics for better performance monitoring. **2026.01.08** v1.55.7 **Reliability & Stability:** * Improved status update handling to prevent errors in edge cases. * Enhanced data processing reliability. **2026.01.08** v1.55.6 **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. **2026.01.06** v1.55.5 **New Features:** * Added [Bitbucket integration support](bitbucket) for seamless workflow automation with your Bitbucket repositories. **Reliability & Stability:** * General bug fixes and performance improvements. **2026.01.06** v1.55.4 **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 **2025.12.17** v1.55.3 **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. **2025.12.12** v1.55.2 **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. **2025.12.11** v1.55.1 **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. **2025.12.08** v1.55.0 **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. **2025.12.05** v1.54.9 **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. **2025.12.04** v1.54.8 **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. **2025.12.04** v1.54.7 **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. **2025.12.04** v1.54.6 **New Features:** * Added ability to edit SAML configuration settings for enhanced authentication management. **Reliability & Stability:** * General improvements and bug fixes to enhance platform stability. **2025.12.04** v1.54.5 **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. **2025.12.03** v1.54.4 **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. **2025.12.03** v1.54.3 **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. **2025.12.02** v1.54.2 **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. **2025.12.01** v1.54.1 **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. **2025.12.01** v1.54.0 **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. **2025.11.25** v1.53.0 **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. **2025.11.20** v1.52.0 **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. **2025.11.19** v1.51.9 **Developer Workflow Enhancements:** * Automatically sets a default branch when no current branch is detected to ensure uninterrupted scanning and smoother onboarding. **2025.11.18** v1.51.8 **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. **2025.11.17** v1.51.7 **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. **2025.11.14** v1.51.6 **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 **2025.11.12** v1.51.5 **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. **2025.11.09** v1.51.4 **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. **2025.11.05** v1.51.3 **Improvements:** * Fixed error because of long file path. **2025.11.04** v1.51.2 **Bug Fixes:** * Fixed an issue with dropdown menus not displaying correctly. **2025.11.03** v1.51.1 **Platform Stability:** * Improved GitHub reliability by handling user error cases. * Updated button styling for better visual consistency. **2025.11.02** v1.51.0 **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. **2025.10.31** v1.50.8 **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. **2025.10.30** v1.50.7 **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. **2025.10.26** v1.50.6 **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. **2025.10.24** v1.50.5 **Bug Fixes & Stability:** * Fixed versioning display to ensure accurate build tracking. * General fixes and optimizations for smoother performance. **2025.10.22** v1.50.4 **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. **2025.10.17** v1.50.2 **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. **2025.10.09** 1.48.0 **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. **We were shipping too fast and a lot happened.** **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. **2024.08.01** * 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 **2024.07.14** * New reporting page * Signin redesign * Registration redesign **2024.06.28** * New issue view. View by CWE, File or all the issues. * Diff viewer line-by-line or side-by-side **2024.06.04** * Added Additional Instructions to inform engineers of additional steps needed * Advanced False Positive Detection **2024.05.06** * Launched Corgea [VS Code](/vsc_extension) plugin **2024.04.29** * Support to fix Checkmarx SAST scan findings * New Dropsite to upload code and vulnerability data without the Corgea CLI **2024.04.22** * Added [Azure DevOps Integration](/azure_devops) * Updated Github PR comment * Added Projects pagination * Corgea CLI [pypi package](https://pypi.org/project/corgea-cli/) **2024.04.15** * Improvements that increased fix coverage by 10% **2024.04.08** * 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 **2024.04.01** * Introduction of Single tenant support **2024.03.25** * CLI authentication checks before scan **2024.03.18** * Shortened Fix explanations to improve legibility * Security fixes **2024.03.11** * 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 **2024.02.16** * C# language support * Sorting and filtering of issues * New CLI tool * Additional fix quality checks * CodeQL support **2024.01.17** * Github integration for issuing fixes * Ruby language support * Java language support * Go language support **2024.01.04** * 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. > [!TIP] > > **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). * **Container Image Scanning**: Scan fully built container images alongside your code with `corgea scan --include-image`. * **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. * **MCP Server Installation**: Write the Corgea MCP server into supported coding agents with [`corgea mcp install`](/cli#install-mcp-server). * **Incremental Scans**: BLAST scans analyze only changed files by default (CLI 1.12.0 or later). Use `--disable-incremental` to analyze every file. ## 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 [GitHub Releases](https://github.com/Corgea/cli/releases), unzip it, and move the `corgea` binary onto your `PATH`. Release archive names now include the version. The examples below install v1.16.1; to install another release, replace the version in both the URL and filename. ```bash macOS (Apple Silicon) theme={null} curl -L https://github.com/Corgea/cli/releases/download/v1.16.1/corgea-v1.16.1-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/download/v1.16.1/corgea-v1.16.1-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/download/v1.16.1/corgea-v1.16.1-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/download/v1.16.1/corgea-v1.16.1-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 v1.16.1 Windows build, extract it, and move corgea.exe to a directory on your PATH: https://github.com/Corgea/cli/releases/download/v1.16.1/corgea-v1.16.1-x86_64-pc-windows-msvc.zip ``` The GNU Linux builds require glibc 2.17 or newer. Fully static musl builds with no libc requirement are also available for both architectures as `corgea-v1.16.1-x86_64-unknown-linux-musl.zip` and `corgea-v1.16.1-aarch64-unknown-linux-musl.zip`; use these for minimal containers and CI runners. ## 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 or regional instance (for example `https://eu.corgea.app`) 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. Non-install commands and flags are forwarded to the package manager. For example, `corgea npm --version` reports the installed npm version, while `corgea --version` reports the Corgea CLI version. **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 writes resolution and package-check progress to stderr, keeping stdout available for machine-readable output. The package manager's stdout is also redirected to stderr. 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 ``` You can also save the default while installing by adding `--set-default`, which persists the `--agent` value you passed: ```bash theme={null} corgea skill install corgea --agent cursor --set-default ``` The `CORGEA_DEFAULT_AGENT` environment variable overrides the saved default, which is useful in CI where you do not want to write to the config file. #### Install MCP Server Write the Corgea MCP server into a coding agent's config using the URL and token already stored by `corgea login` (CLI 1.13.0 or later): ```bash theme={null} corgea mcp install --agent cursor ``` If the CLI is not installed, run the same flow with `npx`. For a single-tenant instance, pass `--url`: ```bash theme={null} npx @corgea/cli login --url https://.corgea.app && npx @corgea/cli mcp install --agent cursor ``` On the multi-tenant cloud, omit `--url`: ```bash theme={null} npx @corgea/cli login && npx @corgea/cli mcp install --agent cursor ``` Supported agent IDs are `cursor`, `claude`, `claude-code`, `windsurf`, `vscode`, `gemini-cli`, `continue`, and `opencode`. Aliases include `claude-desktop`, `vs-code`, `github-copilot`, `copilot`, `gemini`, and `open-code`. Use `--scope user` (the default) or `--scope project`. Claude Desktop has no project-level MCP config. `--dir` writes to a custom path, and `--set-default` persists the `--agent` value like `corgea skill install`. Reinstalling replaces the existing Corgea entry so the URL and token stay current. Neighboring servers are left intact. A project-scope install writes the token into the file — do not commit it. Restart the agent after installing so it loads the new server. See [Model Context Protocol (MCP)](/modelcontextprotocol) for client-specific notes and available tools. #### 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 ``` Run `corgea upload` from the directory that contains your source files, usually the repository root. In CLI 1.14.0 and later, third-party scan report uploads automatically include `corgea.yaml` and `corgea.yml` policy files from the current directory and its subdirectories, even if the report does not reference them. Policy files in the current directory are included even when Git ignores them; nested files follow the usual ignore rules. Symbolic links are not included. For Fortify FPR reports, source uploads use the files where findings are reported. Bundled library files that appear only as enclosing context no longer prevent an upload when those source files are present locally. 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 ``` By default, the command returns after upload and prints the scan page URL. Add `--wait` to wait for processing to finish and print the results: ```bash theme={null} corgea upload path/to/report.json --wait ``` 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 ``` The CLI reports a dirty worktree only when `git status` does. Scans that include uncommitted changes analyze your local files even when the current commit SHA has not changed. Ignored or equivalent files do not force a full scan or mark `worktree_dirty`. BLAST scans (CLI 1.12.0 or later) are incremental by default. Corgea analyzes changed files and carries existing findings forward for everything else. The full project is still uploaded so unchanged files remain available as context. See [Incremental Scans](/cli#incremental-scans) for how the baseline is chosen, and for `--exclude` and `--disable-incremental`. To specify a different scanner, such as Semgrep: ```bash theme={null} corgea scan semgrep ``` You can also use `--fail-on` (BLAST scans only) 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 corgea scan --fail-on malicious corgea scan --fail-on HI,malicious ``` For example, `--fail-on ME` fails on `ME`, `HI`, or `CR` findings. When multiple conditions are listed, the scan fails if any condition matches. A vulnerable dependency that is not classified as malicious does not match the `malicious` condition. Or fail based on every active blocking rule defined in the web app, regardless of whether each rule applies to pull requests or CI: ```bash theme={null} corgea scan --fail ``` `--fail` is deprecated in CLI 1.10.0 and later. Prefer `--block-on` to name the CI rules a pipeline should enforce. To enforce specific rules in a CI pipeline, set each rule's **Applies To** target to **CI** in the web app and pass the generated slug to `--block-on` (CLI 1.10.0 or later): ```bash theme={null} corgea scan --block-on criticals ``` You can provide multiple slugs as a comma-separated list, for example `criticals,malicious-deps`. Only active CI rules can be used; an unknown slug, inactive rule, or pull request rule causes the command to fail with a configuration error. `--block-on` is supported only by the BLAST scanner and cannot be combined with `--fail` or `--fail-on`. `--fail` and `--fail-on` also cannot be used together. Blocking rules are evaluated in the Corgea cloud, so the command waits for that to finish — up to 35 minutes. If the wait runs out it exits `1` rather than letting an unevaluated scan through. Set `CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS` to the number of seconds to wait instead: ```bash MacOS/Unix theme={null} CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS=3600 corgea scan --block-on criticals ``` ```bash Windows (PowerShell) theme={null} $env:CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS="3600" corgea scan --block-on criticals ``` A scan that trips a blocking rule still writes any `--out-file` report and `--sbom` output before exiting. 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. In the Corgea web app, scan metadata appears as read-only labels on the Scans page, scan details, and issue details. ![Scans page showing read-only scan metadata chips on each scan](https://mintcdn.com/corgea/41uKv3zsvGZ4PWP3/images/scans/scans_metadata_chips.png?fit=max\&auto=format\&n=41uKv3zsvGZ4PWP3\&q=85\&s=5f18779bb4682441b465bda86d2684d2) ![Scan details header showing scan metadata chips](https://mintcdn.com/corgea/41uKv3zsvGZ4PWP3/images/scans/scan_details_metadata_chips.png?fit=max\&auto=format\&n=41uKv3zsvGZ4PWP3\&q=85\&s=f835431422c3d74f2d8806c828cdb6b5) ![Issue details sidebar showing scan metadata chips](https://mintcdn.com/corgea/41uKv3zsvGZ4PWP3/images/scans/issue_details_scan_metadata.png?fit=max\&auto=format\&n=41uKv3zsvGZ4PWP3\&q=85\&s=815aa30e8443af6d0196c1e892e07f6c) On the Scans page, expand the filters to filter by a metadata key, an exact key and value, or a value across all metadata. ![Scans page filter panel with Scan metadata key and value fields](https://mintcdn.com/corgea/41uKv3zsvGZ4PWP3/images/scans/scans_metadata_filters.png?fit=max\&auto=format\&n=41uKv3zsvGZ4PWP3\&q=85\&s=42b74d773017a3d8bcefb9a415445d7c) The main search also accepts `has:key` and `key:value`, for example `has:pipeline_url` or `environment:production`. ![Scans search filtered with has:version](https://mintcdn.com/corgea/41uKv3zsvGZ4PWP3/images/scans/scans_metadata_search_has_key.png?fit=max\&auto=format\&n=41uKv3zsvGZ4PWP3\&q=85\&s=a1229b876e5668ed4f45fea5b2a10523) 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 multiple 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 ``` `--scan-type` and `--policy` apply only to BLAST scans. Passing `--policy` without `--scan-type policy` still runs the other BLAST scan types and prints a warning. #### Scan Container Images By default, Corgea discovers the images your project references in `Dockerfile` and Docker Compose files. To scan a **fully built** image instead — for example one you just built in CI that has never been pushed to a registry — pass it with `--include-image`: ```bash theme={null} corgea scan --include-image myapp:1.2.3 ``` The flag is repeatable, so you can include several images in one scan: ```bash theme={null} corgea scan --include-image myapp:1.2.3 --include-image ghcr.io/acme/api:latest ``` Each image is exported by your local container engine and uploaded with your project, so it is scanned exactly as it ships. When you pass `--include-image`, Corgea scans the images you provide instead of searching your source tree for base images. Requirements and behavior: * Container scanning must be enabled for your account. * `docker` or `podman` must be available on your `PATH`. Corgea uses whichever it finds first; set `CORGEA_CONTAINER_ENGINE` to choose explicitly. * An image that is not available locally is pulled first, so images from a private registry work as long as your container engine is already authenticated to it. * `--include-image` is supported only by the BLAST scanner. See [Container Image Scanning](/container-scanning) for how container findings are reported and tracked. #### 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 ``` For BLAST scans, add `--sbom` to generate a CycloneDX SBOM after the scan completes. The default file is `bom.json`, or you can provide a path: ```bash theme={null} corgea scan --sbom corgea scan --sbom artifacts/bom.json ``` Reports and SBOMs are written before `--fail` and `--block-on` are evaluated. A scan that exits with a non-zero status because a blocking rule tripped still leaves its report and SBOM on disk, so a later CI step can always ingest them. #### Force-Including Files In CLI 1.16.1 and later, use the repeatable `--include` flag with the BLAST scanner to force a file, directory, or glob pattern into the scan when Corgea would otherwise skip it as vendored, third-party, generated, or test code. For example: ```bash theme={null} corgea scan --include src/myProj/MyClass.java corgea scan --include 'vendor/our-fork/**' --include generated/ ``` Include rules override packaging filters, `.gitignore`, `--exclude`, and Corgea’s code classification. Matching files are analyzed on every run, including incremental scans. Project rules configured under **File Include Rules** in scan settings apply automatically; `--include` adds rules for the current run. The CLI prints the paths it force-includes. Choose specific paths: whole-repository patterns such as `**`, `*`, and `/**` are rejected. At most 5,000 matching files are force-included per run; the CLI warns if this limit is exceeded. #### Incremental Scans BLAST scans are incremental by default. Corgea uploads the whole project but analyzes only files changed since the selected baseline scan; unchanged files keep their existing findings, so the result still represents the full project. With CLI 1.15.0 or later and a suitable prior scan with stored file checksums, incremental scans work in shallow clones, detached HEAD checkouts, and directories without Git history, including extracted archives. Uncommitted changes are included automatically. If stored checksums are unavailable, the CLI falls back to Git when possible; otherwise, it scans every file and explains why. It also skips incremental behavior when `--only-uncommitted` or `--target` narrows the upload. In CLI 1.16.0 or later, `--exclude` still allows incremental analysis when a suitable prior scan has usable stored file checksums. Otherwise, the CLI analyzes every included file and explains why; excluded files remain excluded. With CLI 1.16.0 or later, newly excluding files with `--exclude` removes their previous findings from the new scan results. Removing an exclusion causes those files to be analyzed again when they are included in the upload. With CLI 1.16.2 and later, Corgea first uses a suitable scan of the nearest commit among the 20 most recent commits in the checkout, regardless of branch name. If none is found, it uses a suitable scan of the current branch, then the default branch recorded by this clone, then `main` or `master`. Detached HEAD checkouts are included. Only history present in the local clone is searched. Use `--disable-incremental` to force BLAST to analyze every file, for example after changing scanner configuration outside `corgea.yaml`: ```bash theme={null} corgea scan --disable-incremental ``` When falling back to Git on a dirty worktree, `--ignore-dirty-worktree` allows an incremental scan that includes modified and untracked files. This flag is not required for incremental scans using stored file checksums. #### Reuse a Recent Scan of the Same Commit A pipeline that re-runs on an unchanged commit can reuse the scan Corgea already has instead of paying for a duplicate. Add `--skip-if-commit-scanned-recently` to a BLAST scan: ```bash theme={null} corgea scan --skip-if-commit-scanned-recently --block-on criticals ``` When the project already has a completed scan of the current commit inside the reuse window, that scan takes the new scan's place: the results table, the `--block-on` gate and its exit code, and any `--out-file` report all come from it. The pipeline behaves the same whether or not a scan actually ran. Use `--scanned-within` to set the window. It is only valid with `--skip-if-commit-scanned-recently`. It accepts values such as `90s`, `30m`, `24h`, and `7d`, and reads a bare number as hours. The default is `24h`, because unchanged code is still exposed to advisories published since it was last scanned. ```bash theme={null} corgea scan --skip-if-commit-scanned-recently --scanned-within 4h ``` To reuse a recent scan even when this worktree is dirty, or when the prior scan recorded `worktree_dirty=true`, pass `--ignore-dirty-worktree` (CLI 1.11.1 or later). A new scan still reports the real dirty status to Corgea. ```bash theme={null} corgea scan --skip-if-commit-scanned-recently --ignore-dirty-worktree --block-on criticals ``` So a later step can tell the two outcomes apart, the command prints `CORGEA_SCAN_SKIPPED=true` along with `CORGEA_SCAN_ID=` when it reused a scan, and `CORGEA_SCAN_SKIPPED=false` when a scan ran. These lines are stdout markers, not environment variables. They are not printed if the command exits because the current commit cannot be resolved. If the reuse check cannot reach the API, the CLI warns and runs a new scan. **What can be reused.** Corgea only reuses a scan that answers the same question, which is stricter than matching the commit. A candidate must be a completed BLAST scan of the current commit, run on a branch rather than a pull request, from a clean worktree, with no scanner problems reported. Anything else runs a real scan — nothing inside the window, a failed or still-running scan, or a worktree that does not match the commit. `--ignore-dirty-worktree` overrides the dirty-worktree half of that test: reuse proceeds if this worktree is dirty or the prior scan recorded `worktree_dirty=true`. A prior scan that never reported the flag is still not reused, because its scope is unknown. **Options that cannot be combined.** No API reports how an earlier scan was scoped, so `--skip-if-commit-scanned-recently` cannot be combined with `--only-uncommitted`, `--target`, `--scan-type`, `--policy`, `--include-image`, `--include`, or `--disable-incremental`, and the command fails if you pass one of them. `--exclude` is allowed but prints a warning when a scan is reused: the reused scan covers files this run would have skipped, so results can over-report, never under-report. Project include rules, or a failed lookup of those rules, also prevent reuse: the CLI runs a new scan and prints `CORGEA_SCAN_SKIPPED=false`. If the current commit cannot be resolved — the directory is not a git repository, or the repository has no commits yet — the command exits with a non-zero status instead of silently running a full scan. When a scan is reused, `--sbom` still reflects the current workspace rather than the reused scan's earlier SBOM. #### 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 ``` While waiting, the CLI checks the scan status every 3 seconds. `corgea wait`, `corgea scan`, and `corgea upload --wait` exit `1` if the scan fails, printing the reason and any scanners that reported a problem. A scan that finishes with one scanner's results missing exits `0` with a warning. Waiting stops after 10 hours, so a scan that never reports a final status cannot hold a CI job open indefinitely. On timeout the command exits with code `1`. The scan itself keeps running in the Corgea cloud. If your scans need longer, set `CORGEA_SCAN_TIMEOUT_SECONDS` to the number of seconds to wait: ```bash MacOS/Unix theme={null} CORGEA_SCAN_TIMEOUT_SECONDS=86400 corgea wait ``` ```bash Windows (PowerShell) theme={null} $env:CORGEA_SCAN_TIMEOUT_SECONDS="86400" corgea wait ``` The CLI normally resolves the project from the current repository's remote URL. Use `--repo org/repo` (or a repository URL) to resolve a different repository, or `--project-name` to query an exact Corgea project name. If you already know both IDs, `corgea wait SCAN_ID --project-id PROJECT_ID` skips project resolution. `corgea scan`, `corgea wait`, and `corgea upload --wait` all exit with a non-zero status when a scan fails, printing the reason and naming any scanners that hit problems. A scan that completes with a scanner missing exits `0` with a warning instead. Waiting gives up after 10 hours; set `CORGEA_SCAN_TIMEOUT_SECONDS` to change that budget. When `--fail` or `--block-on` is used, the CLI then waits up to 35 minutes for blocking rules to be evaluated; set `CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS` to change that one. #### List Scans, Security Issues, SCA Issues, or Code Quality 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, the nullable `worktree_dirty` value, and any scan `metadata` returned by Corgea. `worktree_dirty` is `true` when the scan included uncommitted local changes and can be `null` for scans created by older CLI versions. To list SCA issues for a project or scan, use `--sca-issues` or the `-c` shorthand. The table includes each issue's classification, and JSON output includes the `classification` field when provided. ```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 ``` To list code quality issues, use `--code-quality` (or `--quality`/`-q`). Like the other issue modes, it can be limited to a scan with `--scan-id`. ```bash theme={null} corgea list --code-quality --scan-id SCAN_ID --json ``` List commands resolve the current project from the repository remote. Use `--repo org/repo` (or a repository URL) to select another repository, or `--project-name` to query an exact Corgea project name. #### 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 ``` With CLI 1.16.2 and later, `corgea inspect --issue ISSUE_ID` and `corgea inspect --issue --summary ISSUE_ID` show a **Scanner Metadata** section when the scanner stored identifiers. Fortify findings can include `instance_id`, `class_id`, `kingdom`, `category`, `analyzer`, and `build_id`. The text view merges `issue.metadata` (identifiers from the scanner that reported the finding) and `issue.scanner_metadata` (the copy stored for fix analysis). When the same key appears in both, the scanner’s own value is shown, and empty values are left out. With `--json`, the two objects stay separate. 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 ``` ### Environment Variables | Variable | Description | | - | - | | `CORGEA_TOKEN` | API token or JWT used to authenticate. | | `CORGEA_URL` | Corgea instance URL, for single-tenant and regional instances. | | `CORGEA_DEBUG` | Set to `1` to enable debug logs. | | `CORGEA_SCAN_TIMEOUT_SECONDS` | How long to wait for a scan to reach a final state. Defaults to 10 hours. | | `CORGEA_BLOCKING_RULES_TIMEOUT_SECONDS` | How long `--fail` and `--block-on` wait for blocking rules to be evaluated. Defaults to 35 minutes. | | `CORGEA_CONTAINER_ENGINE` | Container CLI used to export `--include-image` images. Defaults to `docker`, then `podman`. | | `CORGEA_ACCEPT_CERT` | Set when an HTTPS proxy terminates TLS with its own certificate and you want the CLI to accept it. | | `CORGEA_DEFAULT_AGENT` | Agent used by `corgea skill install` and `corgea mcp install` when `--agent` is not passed. | | `CORGEA_VULN_API_URL` | Custom vulnerability API endpoint for the install gate and `corgea advisories`. | | `CORGEA_VULN_API_SEND_TOKEN_TO_CUSTOM_URL` | Set to `1` to send your token to a custom vulnerability API endpoint. | | `CORGEA_NPM_REGISTRY` | Custom npm registry used for install-gate version lookups. | | `CORGEA_PYPI_REGISTRY` | Custom PyPI registry used for install-gate version lookups. | | `CORGEA_RECENCY_GATE` | Set to `false` to disable the install gate's recency check. | | `CORGEA_RECENCY_THRESHOLD_DAYS` | Recency window in days. Defaults to 14. | ### Automatic Rate Limit and Gateway Retries In CLI 1.14.1 and later, Corgea API calls made by the CLI automatically retry `429 Too Many Requests` responses for all requests, including uploads (`POST` and `PATCH`). `502 Bad Gateway` responses are retried only for read requests; writes fail without retrying the response to avoid creating duplicate scans. In CLI 1.16.1 and later, `504 Gateway Timeout` and Cloudflare `520`–`524` responses follow the same retry behavior as `502 Bad Gateway`: read requests are retried, while writes fail without retrying the response to avoid duplicate scans. The CLI retries up to three times per request, waiting 10, 30, and 50 seconds before successive retries. Each retry is logged. For a `429` response with a `Retry-After` value in seconds, the CLI extends the wait if needed, up to two minutes per pause, without shortening the scheduled delay. If the error persists, the request fails and the command handles the failure as usual. If a source file upload during `corgea upload` receives a gateway error (`502`, `504`, or `520`–`524`), or still receives `429 Too Many Requests` after all retries, the CLI stops uploading the remaining source files and reports them as unsent. ### 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`. ### Finding Catalog | ID | Status | Severity | Finding | Remediation | | - | - | - | - | - | | `DEP001` | `emitted` | High | Missing lockfile: the manifest has no expected lockfile, so resolution is not reproducible. | Generate and commit the ecosystem lockfile. | | `DEP002` | `emitted` | High | Stale lockfile: a manifest dependency is missing from its lockfile. | Regenerate and commit the lockfile. | | `DEP003` | `emitted` | Medium | A direct dependency uses a bounded version range. | Pin an exact version or explicitly allow the range by policy. | | `DEP004` | `emitted` | High | A direct dependency uses wildcard, `latest`, or another unbounded range. | Pin an exact version. | | `DEP005` | `emitted` | High | A direct dependency uses a mutable Git branch reference. | Pin a commit SHA or immutable release tag. | | `DEP006` | `emitted` | High | A direct URL or tarball dependency has no integrity checksum. | Add an integrity checksum or pin a registry package. | | `DEP008` | `emitted` | Medium | A lockfile entry lacks its integrity hash. | Add the integrity hash to the lockfile entry. | | `DEP010` | `reserved` | Medium | Reserved for vulnerable-package advisory findings; `corgea deps` does not emit it. | Handle this code through advisory checks or the package manager install gate. | | `DEP014` | `emitted` | Low | More than one resolved version of a package is present. | Align or deduplicate the resolved versions. | | `DEP019` | `emitted` | Medium | A detected lockfile format is not supported by the parser. | Use a supported lockfile or wait for parser support. | | `DEP021` | `emitted` | High | A direct artifact version is mutable, such as a Maven SNAPSHOT. | Pin an immutable release version. | ## 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 (Common Weakness Enumeration - a standardized list of software and hardware weakness types) for consistent categorization. > **Grammar & Clarity Issues** > > * **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 > } > ``` > **Code Cleanliness** > > * **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! > ``` > **Code Duplication & Reusability** > > * **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 (Don't Repeat Yourself - a principle aimed at reducing repetition in code) code** - repeated logic that increases maintenance burden > **Performance Issues** > > * **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 > } > ``` > **Design & Architecture** > > * **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 (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion)** > **Code Complexity & Readability** > > * **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 (Keep It Simple, Stupid - a design principle that favors simplicity)** > **Naming & Conventions** > > * **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 & Correctness** > > * **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 > **Incomplete Work** > > * **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. * > [!TIP] > > 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 > [!TIP] > > **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. > [!TIP] > > **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: **Quick Wins** * Removing unused variables and imports * Converting magic numbers to named constants * Fixing typos in variable names and comments **Structural Improvements** * Consolidating duplicate code into shared functions * Simplifying overly complex expressions * Breaking down complex one-liners **Best Practices** * 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 > [!WARNING] > > 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 **High Severity** 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 > [!WARNING] > > **Action**: Fix immediately **Medium Severity** Issues that **impact maintainability or performance**: * Code duplication * Unused code cluttering the codebase * String concatenation in loops * Confusing logic that slows development > [!NOTE] > > **Action**: Address in your next refactoring cycle **Low Severity** **Minor issues that reduce code quality**: * Inconsistent naming * Unnecessary complexity * Minor readability improvements > [!TIP] > > **Action**: Fix when convenient or during related work *** ## Getting Started The Code Quality Scanner integrates seamlessly into your development workflow: **1. Connect Your Repository** Link your code repository to Corgea using [GitHub](/github), [GitLab](/gitlab), [Azure DevOps](/azure_devops), or [Bitbucket](/bitbucket) **2. Automatic Scanning** The scanner analyzes your files automatically **3. Review Findings** Browse identified issues with clear explanations and severity levels in the [project dashboard](/project) **4. Apply Fixes** Use [automated remediation](/fixes) or fix issues manually **5. Track Progress** Monitor improvements in code quality over time *** ## Related Documentation > **[AI-native SAST](/blast)** > > Learn about Corgea's security vulnerability scanning capabilities > **[Automated Fixes](/fixes)** > > Explore how automated remediation works across all scan types > **[False Positive Management](/false_positive)** > > Manage and suppress false positives effectively > **[Issue Management](/project)** > > Track and manage all issues across your projects *** ## Support For assistance, contact us at [support@corgea.com](mailto:support@corgea.com) ## Pull Request Comments PR comments distinguish **Quality** findings from **Security** findings. Code quality comments include a review title and explanation when available, and can be posted even when automatic fixes are unavailable for the file’s language. Security reachability filters do not suppress code quality findings. # 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. **1. Image Discovery** 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. **2. Image Analysis** 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. **3. Vulnerability Matching** The discovered packages are cross-referenced against known vulnerability databases, and any matches are reported alongside your other scan results. ## Scanning a Fully Built Image The discovery flow above scans the base images your project references. To scan a **fully built** image instead — for example an image you just built in CI that has never been pushed to a registry — pass it to the CLI with `--include-image`: ```bash theme={null} corgea scan --include-image myapp:1.2.3 ``` Your local container engine (`docker` or `podman`) exports the image and the CLI uploads it with your project, so the image is scanned exactly as it ships. When you pass `--include-image`, Corgea scans the images you provide instead of discovering base images from your source tree. `--include-image` is supported only by the BLAST scanner. Container scanning must be enabled for your account. See [Scan Container Images](/cli#scan-container-images) in the CLI reference for the full flag behavior. ## Tracking findings across scans Corgea tracks a container finding by its image, package, and vulnerability advisory. Triage decisions persist when package versions change, while different packages affected by the same advisory remain separate findings. ## 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 > [!NOTE] > > Automatic image discovery is enabled when Docker files are detected in your project, and requires no configuration. Scanning a fully built image with `--include-image` requires container scanning to be enabled for your account. ## Limitations These limits apply to the images Corgea discovers and pulls itself: * **Public registries only**: Images hosted on private registries are skipped. To scan a private image, pull or build it on your own runner and pass it with `--include-image`, which uploads the image from your container engine rather than having Corgea fetch it. * **Maximum image size**: Images larger than 1000 MB (1 GB) are skipped. * Only images referenced in `Dockerfile` and Docker Compose files are discovered. Use `--include-image` to scan an image that neither file references. ## Best Practices > [!TIP] > > 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. > [!NOTE] > > 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 ![The Content access page showing which users and teams can reach each project](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/content_access.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=603138a86c4a9567d058882b18b6c198) ## 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: **Team Members** 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). **Dynamic Team Access** 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). **Project Members** 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 **Project Owners** 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 > [!NOTE] > > **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 **1. Enable Project Access Control** > [!TIP] > > **Required Permission**: Company administrator access 1. Go to **Settings → User Management → [Content access](https://www.corgea.app/settings/company/content-access/)** 2. Open the **Settings** tab and find **Project Access Control** 3. Turn on the **Project Access Control** toggle. It applies immediately, with no **Save** to click > [!WARNING] > > Once enabled, users immediately lose access to projects not covered by a direct assignment, team assignment, or team selector. Plan your rollout accordingly. **2. Assign Access to Projects** > [!TIP] > > **Required Permission**: `Change Project` permission or project owner role After enabling Project Access Control, you need to grant users access to projects: 1. Go to **Settings → User Management → [Content access](https://www.corgea.app/settings/company/content-access/)** 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 **Adding Individual Users** 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 **Adding Teams** 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). **Bulk Updates** 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 **3. Verify Access** 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 **4. Ongoing Management** 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 ## GitHub Team Sync If GitHub Team Sync is enabled for your company, Corgea can keep already-linked GitHub teams in sync without re-running a full project-and-member import. * When a user joins your company, Corgea queues a membership-only sync for linked teams. * Membership updates from GitHub are applied to the existing Corgea teams and do not recreate project links. * Company admins can start a membership-only sync from **Content Access → GitHub Team Sync → Sync membership**. Use a full GitHub team sync when you need to import or refresh team-to-project mappings. GitHub members are matched to Corgea users by email. See [GitHub](/github) for app setup and [Teams](/teams) for manual team management. ![Content Access project list while GitHub Team Sync is enabled](https://mintcdn.com/corgea/x3Z_vsbtPnot_ih_/images/settings/content_access_github_sync.png?fit=max\&auto=format\&n=x3Z_vsbtPnot_ih_\&q=85\&s=1a050ab3513397a4d2d2f798f76aa9ac) ## Best Practices > **Plan Before You Enable** > > 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 > **Use Teams for Scalability** > > 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. > **Assign at Least One Owner Per Project** > > Every project should have at least one owner who can: > > * Manage project settings > > * Add/remove other users > > * Handle project-specific configuration > > > [!WARNING] > > > > Without an owner, projects become difficult to manage. > **Distinguish Owners from Members** > > Use ownership strategically: > > * **Owners**: Project leads, managers, senior engineers responsible for the project > > * **Members**: Contributors, reviewers, stakeholders who need visibility > > > [!TIP] > > > > Don't make everyone an owner—it reduces accountability and increases security risk. > **Regular Access Audits** > > 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 > **Use the Search Function** > > 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 > **Export Access Data** > > > [!TIP] > > > > **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. > **Consider Your Workflow** > > 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) > **Communicate Changes** > > 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 > **Start Conservative** > > 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 > **What happens to existing users when I enable Project Access Control?** > > 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. > **Can I enable access control for some projects but not others?** > > No. Project Access Control is a company-wide setting. It's either enabled for all projects or disabled for all projects within your company. > **What's the difference between an owner and a member?** > > 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. > **If someone is both a direct member and part of a team assigned to a project, what happens?** > > They have access through both paths. Removing them from the team doesn't affect their direct member access, and vice versa. > **Can users see which projects exist even if they don't have access?** > > No. When Project Access Control is enabled, users can only see projects they have access to. Projects they cannot access are completely hidden. > **Do integrations respect access control?** > > Yes. API calls and integrations respect the same access control rules as the web interface. > **Can I temporarily disable access control to test something?** > > 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. > **Who can manage project access assignments?** > > Project owners can manage access for their specific projects. Company administrators can manage access for all projects. Regular members cannot manage access. > **What happens when a user is deactivated?** > > 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. > **Does this affect how issues are scanned or fixed?** > > 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. ## Marking a finding as a false positive When marking a finding as a false positive, provide a meaningful explanation of why it is not a real vulnerability, such as unreachable code, sanitized input, or code used only in tests. A label such as “false positive” or filler such as “N/A” is not enough. This applies to individual findings, bulk decisions, and requests made through pull request comments. If your explanation is rejected, add the missing context and try again. ## 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. > [!NOTE] > > 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. > **What's an Abstract Syntax Tree (AST)?** > > 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 > [!TIP] > > AST-based fingerprinting means you get more stable, reliable tracking of security issues throughout your development lifecycle—even as your code evolves. ### Separate Findings at the Same Location SAST findings with different CWEs are tracked separately, even when they occur on the same line and share a fingerprint. Each finding keeps its own triage status, justification, assignee, due date, accepted-risk expiry, and detection history. Marking one finding as a false positive or accepted risk does not suppress a different CWE at that location. First and last detection dates and new-finding counts follow each finding separately. ## Where Is Fingerprinting Used? **Issue Tracking** 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 **Deduplication** 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. **Issue History** 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. **Reporting** 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. > [!WARNING] > > Understanding when fingerprints change is important for accurate issue tracking and security management. ### Situations That Will Generate a New Fingerprint > **File Moves or Renames** > > **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. > > > [!TIP] > > > > If you're doing large-scale file reorganization, coordinate with your security team so they understand the context. > **Significant Code Refactoring** > > **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. > > > [!TIP] > > > > When doing major refactoring, treat these as opportunities to fix the vulnerability rather than just moving it. > **Line Number Shifts Beyond Threshold** > > **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. > > > [!NOTE] > > > > This is rare due to AST intelligence, but if it happens, verify the issue is truly the same before marking it as a duplicate. > **Changes to Vulnerability Classification** > > **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. > > > [!TIP] > > > > Pay attention to classification changes—they often indicate important new information about the security risk. > **Changes to the Vulnerable Code Itself** > > **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. > > > [!TIP] > > > > 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 > [!TIP] > > 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 **1. Check the Issue History** Corgea tracks all historical events by fingerprint, so you can see the timeline of the original issue. **2. Review the Code Changes** Use your version control system to understand what changed between scans. **3. Update Tracking** If you're tracking issues in external systems (JIRA, etc.), you may need to update references. **4. Consider It an Opportunity** A changed fingerprint often means someone modified the vulnerable code—this is a perfect time to ensure the fix is complete and proper. **5. Contact Support** If you believe a fingerprint changed incorrectly or unexpectedly, our team can help investigate. > **Why This Design?** > > 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 **For Security Teams** Get an accurate understanding of your security posture without false inflation from duplicate detections. Understand when code changes affect tracked vulnerabilities. **For Development Teams** Avoid confusion about which issues need attention and which have already been addressed. Continue refactoring and improving code without losing track of security issues. **For Management** 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. > **[Need Help?](mailto:help@corgea.com)** > > 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 > [!NOTE] > > **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. **1. Select an Issue** * 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. ![A scan finding with Auto-Fix set to Fix Available](https://mintcdn.com/corgea/zuI5SAoZJq0woJb1/images/issue_fixes/auto_fix_web_fix_available.png?fit=max\&auto=format\&n=zuI5SAoZJq0woJb1\&q=85\&s=b4ebdb418aa293546327eb7ed9f3848f) ![A scan finding with Auto-Fix set to On Demand](https://mintcdn.com/corgea/4wTUI7zssVC3U7_-/images/issue_fixes/auto_fix_web_on_demand.png?fit=max\&auto=format\&n=4wTUI7zssVC3U7_-\&q=85\&s=ee3d2af3fed8cd64801856814e54f742) ![A scan finding with Auto-Fix set to On Hold](https://mintcdn.com/corgea/4wTUI7zssVC3U7_-/images/issue_fixes/auto_fix_web_on_hold.png?fit=max\&auto=format\&n=4wTUI7zssVC3U7_-\&q=85\&s=d9a0be021074719ebaf8cdd36df653e3) **2. Review the fix** Review the suggested fix in the issue details sidebar before applying it. If the issue is marked `On Demand`, Corgea starts generating the fix in the background when you open the issue. This usually takes a minute or two. The fix appears automatically when it is ready. ![The Suggested Fix tab while Corgea generates a fix](https://mintcdn.com/corgea/zuI5SAoZJq0woJb1/images/issue_fixes/auto_fix_generating.png?fit=max\&auto=format\&n=zuI5SAoZJq0woJb1\&q=85\&s=d2000885ee2cbd44d92a96274293851f) API clients can start the same background generation with `GET /api/v1/issue/{id}?generate_fix=true`. `generate_fix` defaults to `false`, so a request without it returns the issue without starting generation. While generation is pending, `auto_fix_suggestion.status` is `generating` — fetch the issue again until it finishes. Also pass `wait_for_the_fix=true` to wait up to 120 seconds for the result in the same request. See the [API reference](/api-reference/introduction). 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. **3. Apply the fix** 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. \[!TIP] To issue a pull-request from Corgea, you need to setup the appropriate integration with [GitHub](github) or [Azure DevOps](azure_devops). For findings from CLI or IDE scans, pull request creation requires an active source control integration for the repository and the scanned branch to exist on the remote. If Corgea reports that the branch is missing, push it and reload the issue page. ![Issue page warning that the scanned branch is not on GitHub, so a pull request cannot be created until you push the branch and reload](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/issue_fixes/create_pr_branch_missing.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=525a0a8dfa0561ce805abacdee41fbbd) ![](https://mintcdn.com/corgea/1zTIBpc0LYfu4dh5/images/issue_fixes/auto_fix_web_create_pr.png?fit=max\&auto=format\&n=1zTIBpc0LYfu4dh5\&q=85\&s=42b2987e050591aefb24a33c34b1246b) Corgea automatically generates a pull request with issue and fix context. Wait for PR creation to complete, then click `View Pull Request`. ![](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/issue_fixes/auto_fix_web_view_pr.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=0527aaa5148eacaf04714eb29d9c3a23) Alternatively, use `Download Fix` and select one of the available options: * `Download Git Patch` * `Download Fixed File` ![](https://mintcdn.com/corgea/y3xW6TraK0Q97XaD/images/issue_fixes/auto_fix_web_download_fix.png?fit=max\&auto=format\&n=y3xW6TraK0Q97XaD\&q=85\&s=56c00f0787b92cf8a4fa4c1ceb613b3b) * **Option 2**: Corgea IDE Extensions Corgea supports applying fixes locally using our IDE extensions. Corgea supports [Visual Studio Code and Cursor](vsc_extension), [Visual Studio 2022](vs2022_extension), and [JetBrains IDEs](jetbrains_extension). ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/vsc_apply_fix.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=e3d38dac7fec426b3f0f322d61c954c3) 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. **4. Optionally: Vote on the fix** 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. ![](https://mintcdn.com/corgea/y3xW6TraK0Q97XaD/images/issue_fixes/auto_fix_web_give_feedback_button.png?fit=max\&auto=format\&n=y3xW6TraK0Q97XaD\&q=85\&s=521a2856483316fddf485e1ddb79db58) 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`. ![](https://mintcdn.com/corgea/y3xW6TraK0Q97XaD/images/issue_fixes/auto_fix_web_provide_feedback_modal.png?fit=max\&auto=format\&n=y3xW6TraK0Q97XaD\&q=85\&s=252817d34f34f99dbf8912c340a38081) ## Troubleshooting > **No Fix Generated** > > 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`. > > ![The Suggested Fix tab when generation fails, with a Try Again button](https://mintcdn.com/corgea/zuI5SAoZJq0woJb1/images/issue_fixes/auto_fix_unable_to_generate.png?fit=max\&auto=format\&n=zuI5SAoZJq0woJb1\&q=85\&s=cd45349ef1d13360567ee42f6900ff9a) > > 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. > **I don't like the fix generated** > > 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. > > ![](https://mintcdn.com/corgea/y3xW6TraK0Q97XaD/images/issue_fixes/auto_fix_web_provide_feedback_modal.png?fit=max\&auto=format\&n=y3xW6TraK0Q97XaD\&q=85\&s=252817d34f34f99dbf8912c340a38081) # 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/settings/integrations/) page or from an issue as seen in the following steps: **1. Install the Corgea GitHub App** Click on the Install button next to the GitHub logo on the Integrations page. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/github_integrations.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=9c59f1ff613934b1cb2a42567d0afc32) **2. Continue setup in Github** Select the GitHub account or organization you want Corgea to access, and make sure it matches what you 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 After you connect Corgea with GitHub, the GitHub app scans each pull request for vulnerabilities and suggested fixes. You can also open a pull request from Corgea to apply a fix. If GitHub Team Sync is enabled, Corgea can keep membership of already-linked GitHub teams up to date. Use **Sync membership** on the Content Access page when you want to refresh members without re-importing project links. See [GitHub Team Sync](/content-access-management#github-team-sync). ## Scanning PRs Corgea scans each pull request for potential vulnerabilities and suggests actionable fixes. Draft pull requests are not scanned until you mark them as ready for review. Corgea scans non-draft pull requests when they are opened and when you push updates. 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. When a new push starts another scan for the same pull request, Corgea stops the older scan if it is still running. The older scan remains cancelled rather than being reported as failed if it encounters an error while stopping. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/github-scan.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=d52844f9e6894e695ae76aa0c02d7666) ## Issuing PRs from Corgea You can now issue a PR that fixes an issue from any issue page in Corgea. ![](https://mintcdn.com/corgea/iadAV76rx_-M1qX0/images/pull_request.png?fit=max\&auto=format\&n=iadAV76rx_-M1qX0\&q=85\&s=c8286da5954cff2b319a709b40c635ca) 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. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/github-pr-fix.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=a3da809f8f9fe8de0aa58f2036817084) ## GitHub Permissions When you install the Corgea GitHub App, you'll be asked to grant the following permissions: ![](https://mintcdn.com/corgea/o9jrguQxFuAwjqPy/images/github_permission_check.png?fit=max\&auto=format\&n=o9jrguQxFuAwjqPy\&q=85\&s=418de761ef9a68f89fb26ef4f20a7835) ### 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 > **GitHub rate limits** > > GitHub rate limits can delay check updates and PR comments even after a scan has finished. Corgea waits for the rate-limit window to reset before retrying affected check updates and comments that GitHub rejected before posting. > **GitHub app not installed** > > 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. > **Re-issue the Pull Request** > > 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. > **Track Pull Request Status in Corgea** > > This is on the roadmap for development. ## PR Review Context Corgea uses the pull request title, description, and code diff, when available, to give its review context about the change. # 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 **1. Access Integrations** Log in to your Corgea account and go to **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)**. **2. Add GitLab Integration** Click on the "Add Integration" button and select "GitLab" from the list of available integrations. **3. Configure Integration** 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. **4. Save Configuration** 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: **1. Create Access Token** **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 **2. Configure Webhook** 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 * Emoji events (for 👍/👎 fix feedback with Corgea Agent) ![](https://mintcdn.com/corgea/i9tDHy3OJ_n-0ITK/images/gitlab_webhook_config.png?fit=max\&auto=format\&n=i9tDHy3OJ_n-0ITK\&q=85\&s=dac814bde18e43f30a3bde3c607ffd61) 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 **3. Verify Configuration** 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 **1. Access Dropsite** Log in to your Corgea account and navigate to the Dropsite section. **2. Select Connection Method** In the "Add your code" step, select the "Connect Corgea" option. **3. Choose GitLab** Choose the "GitLab" integration from the list of available integrations. **4. Select Repository** Select the repository and branch you want to scan from your GitLab account. **5. Initiate Scan** Click "Confirm" to initiate the scan. Corgea will retrieve the code from the selected repository and branch, and perform a comprehensive security scan. In the Projects list, GitLab repositories are identified by their full namespace path, including nested subgroups (for example, `group/subgroup/project`). Scans started from Dropsite are associated with the repository, including when the selected branch name contains slashes, such as `feature/login`. ## 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 ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/issue_mr.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=4ddc078ba74c7d64b6d0c936c555b346) 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) ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/view_mr.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=3cf196397abd84f1147956d1c83a3951) 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. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/generate_mr.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=6a7399730409534069bc6c90147dfb9e) If creating a merge request fails because the fix branch already exists with its own commits, review it in GitLab and either open a merge request from it manually or delete it before retrying. Corgea can retry using an existing branch that has no changes from the base commit. If the error reports an unexpected non-JSON response, check the integration’s GitLab URL and any proxy in front of GitLab. ## 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. > [!NOTE] > > 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. **1. Open your Harness profile** Sign in to Harness, then click your username at the bottom-left of the navigation bar and choose **Profile Overview**. ![Open Harness profile](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-1.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=5656fa8b423533f3f7b8826ee51d2b25) **2. Create a new API key** 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](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-2.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=9e20ea73c168de45bf4d0d01193bb02d) > [!TIP] > > 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. **3. Name your API key** Give the key a descriptive name such as `corgea-integration`, then click **Save**. ![Name the Harness API key](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-3.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=14ef59176233197644cdc77a0b1dc655) **4. Add a token to the 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](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-4.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=d92ca86787479f058e382f7cc6b4be3d) **5. Generate the token** Give the token a name (for example `corgea-token`) and an expiration date, then click **Generate Token**. > [!WARNING] > > 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](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-5.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=391993f26605b974160c3199e65467c6) **6. Copy the 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](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-6.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=1dd5c28913f965e113d48b4a7064a5bc) **7. Open the Corgea integrations page** Sign in to Corgea at `corgea.app` (or `{your-instance}.corgea.app` for self-hosted deployments) and go to **Settings → Automation → Integrations**. In the **Code Repository Integrations** section, click the **+** button next to **Harness**. ![Open the Corgea integrations page](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-7.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=3867b91d75b7d92b443cfd515aaff1e4) **8. Add the integration** 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](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-8.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=1edf0fb9ebc9e569ab0028c3bc45bd03) **9. Optional settings** 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](https://mintcdn.com/corgea/TPxz-I5TeuxJbvmj/images/harness-9.png?fit=max\&auto=format\&n=TPxz-I5TeuxJbvmj\&q=85\&s=bc6c67574229021dbe609772fd4a54f5) 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. For projects created through the CLI or another URL-based workflow, use the full Harness web or Git clone URL for the repository. Corgea uses the account, organization, project, and repository identifiers in that URL to select the correct integration, which is especially important when you connect multiple Harness accounts. ## 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. | ## Connection status and troubleshooting In **Settings → Automation → Integrations**, the Harness card shows counts of expired tokens and integrations with permission errors. Open the integration list to see each connection's owner, date added, and status; connections that need attention appear first. ![Harness integration list with connections that need attention first, including Token expired and Permission errors](https://mintcdn.com/corgea/qHKsGxwKc7STDQVo/images/harness/harness_connection_status.png?fit=max\&auto=format\&n=qHKsGxwKc7STDQVo\&q=85\&s=1516a19d1e88f571356664ef42a41a0b) * **Token expired** — Harness rejected the token. Edit the integration and replace it with a new PAT or SAT. * **Permission errors** — Expand the errors under that integration to see the affected operation, available organization/project/repository details, required permissions, and when the error last occurred. Grant the missing access in Harness or replace the token with one that has access. * **Connected** — The integration is not marked expired and has no recorded permission errors. Replacing the token clears the recorded errors. An error also clears when the same operation succeeds for the affected scope. # 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 > **Kubernetes** > > **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 > **Docker** > > **File Patterns**: `Dockerfile`, `Containerfile` > > Detects issues like: > > * Running as root user > * Missing health checks > * Exposed secrets in build arguments > * Insecure base images > **Terraform** > > **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 > **CloudFormation** > > **File Patterns**: `*.yml`, `*.yaml`, `*.json` > > Detects issues like: > > * Open security groups > * Unencrypted S3 buckets > * Missing CloudTrail logging > * Insecure AWS resource configurations > **Azure ARM Templates** > > **File Patterns**: `*.json` > > Detects issues like: > > * Public blob containers > * Disabled encryption > * Weak network security rules > * Missing diagnostic settings > **Helm Charts** > > **File Patterns**: `*.yaml`, `*.tpl`, `*.tar.gz` > > Detects issues in Helm templates similar to Kubernetes manifest checks ## Setup Instructions > [!NOTE] > > IaC scanning is not enabled by default. Contact support to enable this feature for your company account. > [!NOTE] > > Project must contain at least one supported IaC file to enable infrastructure scanning. ### Configuration Steps **1. Verify IaC Files** Ensure your project contains supported infrastructure files in any of the formats listed above **2. Configure Scan Scope** Choose whether to include IaC scanning in full or partial scans **3. Set Up Notifications** 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 > [!WARNING] > > **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 > [!TIP] > > 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 > **No issues found but IaC files are present** > > **Solution**: Verify that IaC files are in supported formats and contain valid configuration syntax > > **Check**: Ensure files are not corrupted or contain parsing errors > **Too many low-severity findings** > > **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 > **False positive misconfigurations** > > **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 > **Scan not detecting all IaC files** > > **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 # Corgea Documentation Source: https://docs.corgea.app/introduction Find, triage, and fix security issues in your code with AI. Corgea is an AI-powered application security platform built for developers. It scans your code, dependencies, containers, and infrastructure, filters out the false positives, and generates fixes you can review and merge in a pull request. > **[Quickstart](/quickstart)** > > Add a project and review your first findings in less than 5 minutes. > **[Connect your repositories](/github)** > > Install Corgea in GitHub, GitLab, Azure DevOps, Bitbucket, or Harness. > **[Scan from the CLI](/cli)** > > Run scans, inspect findings, and apply fixes from your terminal or CI. ## Scan your code > **[AI-native SAST](/blast)** > > BLAST finds business logic, authentication, and code vulnerabilities that traditional SAST misses. > **[Dependency Scanning](/sca)** > > Detect vulnerable third-party packages across 25+ languages and ecosystems. > **[Secret Scanning](/secret-scanning)** > > Catch hardcoded credentials, API keys, and tokens before they reach production. > **[Container Scanning](/container-scanning)** > > Scan container images for vulnerable OS and application packages. > **[IaC Scanning](/iac)** > > Find misconfigurations in Terraform, Kubernetes, Docker, CloudFormation, and Helm. > **[Code Quality](/code-quality-scanner)** > > Review maintainability, readability, and performance issues alongside security. ## Triage and fix > **[Vulnerabilities Workbench](/vulnerabilities)** > > Search, filter, and prioritize every finding across your projects in one place. > **[Applying Fixes](/fixes)** > > Review AI-generated fixes and ship them through a pull request, your IDE, or a patch. > **[False Positive Detection](/false_positive)** > > Let Corgea use code and infrastructure context to remove noise automatically. > **[Corgea Agent](/agent)** > > Ask questions about scans and findings in chat or directly in pull request comments. ## Set and enforce policy > **[PolicyIQ](/policies)** > > Teach Corgea your business context and security architecture for sharper results. > **[Blocking Rules](/blocking_rules)** > > Fail builds and block pull requests that introduce unacceptable risk. > **[SLA Management](/sla_management)** > > Set remediation deadlines by severity and track issues that fall behind. ## Work where you build > **[IDE Extensions](/vsc_extension)** > > Fix issues in VS Code, Cursor, Visual Studio 2022, and JetBrains IDEs. > **[Agentic Integrations](/agentic_integrations)** > > Let Cursor, Claude Code, Copilot, and Codex scan and fix on your behalf. > **[Model Context Protocol](/modelcontextprotocol)** > > Connect AI assistants to your scans, issues, and policies over MCP. > **[Issue Tracking](/jira)** > > Sync findings to Jira or Linear and keep status in step with your backlog. > **[Slack Notifications](/slack)** > > Alert the right channel when new issues, fixes, or scans land. > **[API Reference](/api-reference/introduction)** > > Automate scans and pull results with the Corgea API and webhooks. ## Administer your organization > **[User Management](/user_management)** > > Invite teammates and manage roles and teams. > **[SSO](/sso)** > > Set up SAML or OIDC single sign-on with your identity provider. > **[Security & Compliance](/security)** > > Read how Corgea protects your code, data, and infrastructure. ## Get help See what shipped in the [changelog](/changelog), check live availability on the [status page](https://status.corgea.app/), or email [help@corgea.com](mailto:help@corgea.com) and our team will get back to you. # Issue Assignment & Status Management Source: https://docs.corgea.app/issue_assignment Assign and track security issues across your team > [!NOTE] > > 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 > [!TIP] > > * 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 > [!NOTE] > > 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. You can also manage issue triage programmatically through the [Bulk Triage API](/api-reference/triage/bulk-triage-findings). Use `/triage/findings` to apply a status change to multiple SAST or SCA findings, preview an action before applying it, and review the resulting audit record. See the API reference for supported filters, approval workflows, and pagination. ## Setup Instructions > [!NOTE] > > No specific setup is required for this feature. It is enabled by default for all users with the appropriate permissions. ## Usage Guide ### Assigning Issues **1. Navigate to Issue** Go to the issue details page **2. Find Assignment Section** Locate the "Assignment & Status" section **3. Select Assignee** Select the desired assignee from the dropdown menu **4. Notification** The assignee will receive an email notification with the issue details When a rescan detects the same code, dependency, or IaC finding, it retains the current assignee, including an explicit unassignment. Code and dependency findings also retain their due date and SLA status. ### Updating Issue Status **1. Access Actions** On the issue details page, locate the "Actions" section **2. Choose Status** Select the appropriate status for the issue (e.g., "fixed," "false positive," "accepted risk") **3. Add Comment** Provide a comment explaining why you are making this change. The comment is required, and it has to give a reason rather than repeat the decision—see [Triage Justifications](/triage_justifications) **4. Save Changes** 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. **1. Choose Accepted Risk Status** Select "Accepted Risk" from the status dropdown **2. Set Expiry Date (Optional)** 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 **3. Save** Click "Update Status" to apply the changes ![Accepted Risk Expiry Date Input](https://mintcdn.com/corgea/IJNwg2fhuVxK_UAm/images/issue_assignment/accepted_risk.png?fit=max\&auto=format\&n=IJNwg2fhuVxK_UAm\&q=85\&s=443cd2d08a0ad185ff177d22e81eb153) ### Using the User Inbox **1. Access Inbox** Navigate to the user inbox from the main navigation menu **2. View Issues** Review the list of issues assigned to you **3. Filter** Filter issues by SLA status using the dropdown menu (due, overdue, escalated) **4. Take Action** Click on an issue to view its details and take further action ## Examples > [!NOTE] > > 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 explain why in the comment—for example, that the query on the flagged line is parameterized. ### 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 > [!TIP] > > * Regularly review and update issue statuses to ensure accurate tracking > * Write comments that state the reason behind a status change, not just the decision, so the audit record is useful later > * 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 > [!WARNING] > > * 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. On the **SAST**, **Logic & Auth**, **Secret**, and **Code Quality** tabs, CSV exports and the code findings in a SARIF export follow that tab and its current filters, including **New Issues**. With **New Issues** on, those code findings include only findings the scan newly introduced. If there are none, the code portion of the export is empty. A SARIF file still includes the scan's dependency and container findings in a separate run, and that run does not follow the tab or **New Issues**. ## 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 **1. Open a Completed Scan** Go to your project's scan results page, where you can see all detected security issues. **2. Open the Export Menu** 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. **3. Select Export to SARIF** 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](https://mintcdn.com/corgea/6_FZ3tSsReGJqh7D/images/export_to_sarif.png?fit=max\&auto=format\&n=6_FZ3tSsReGJqh7D\&q=85\&s=9046c35ad0cd04d4e0e2702dc0c29e8d) 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](https://mintcdn.com/corgea/6_FZ3tSsReGJqh7D/images/download_button_disabled_scan_in_progress.png?fit=max\&auto=format\&n=6_FZ3tSsReGJqh7D\&q=85\&s=9c799903485aca8719dd9a8a42b5671c) #### 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`. #### SCA Findings in SARIF When you have the **View SCA Issue** permission, the export carries a second SARIF run named `Corgea SCA` alongside the code findings. There is nothing extra to request: the SCA run travels in the same file you download from the **SAST**, **Logic & Auth**, **Secret**, or **Code Quality** tab. The run contains the scan's active dependency and container findings. Fixed findings, false positives, and accepted risks are excluded. Each result records the package, version, ecosystem, CVSS score, fixed version, dependency type, reachability, and licenses as SARIF properties, and is located at the manifest or lockfile that declares the dependency rather than at a line of your own source. Dependency findings carry no code flows — source-to-sink traces apply to code findings only. The SCA run declares its own analysis category, `corgea/sca/`, so platforms such as GitHub code scanning track code and dependency results as independent sets of alerts. The run is included even when a scan has no SCA findings, which lets those platforms resolve alerts that earlier scans reported. Applicable SCA blocking rules are mapped through the same `corgea_pr_policies` taxonomy as code rules, and are included only when you also have permission to view blocking rules. #### 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 * Scan metadata, formatted as semicolon-separated `key=value` pairs #### 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 * **Scan Metadata**: Metadata attached to the scan, formatted as semicolon-separated `key=value` pairs Scan-page CSV exports also include a **Finding Type** column. For these code findings the value is `SAST`, `Logic & Auth`, `Secret`, or `Code Quality`. > [!NOTE] > > On the **Advanced Vulnerability Search** page, results are paginated. The CSV export includes all findings that match the active filters, not only the findings on the current page, along with the **Assignee Email**, **Assignee Name**, and **Scan Metadata** columns. ### 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 **1. Open the Export Menu** 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](https://mintcdn.com/corgea/iDCBd1bh74xnQC9g/images/pdf-export/export_as_pdf_button.png?fit=max\&auto=format\&n=iDCBd1bh74xnQC9g\&q=85\&s=a9c9d0c71fce7d8e8fec8b4a38c992e8) **2. Choose What to Include** 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](https://mintcdn.com/corgea/iDCBd1bh74xnQC9g/images/pdf-export/export_as_pdf_modal.png?fit=max\&auto=format\&n=iDCBd1bh74xnQC9g\&q=85\&s=e01c4817607cd63f5af67d6788198571) **3. Generate the Report** 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`. > [!NOTE] > > 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 * **Scan ID**: The scan identifier * **Scan status**: Whether the scan completed or is incomplete * **Findings scope**: The issue-type and urgency filters applied to the report * **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. If no findings match your filters, you can still generate a report that records the scan and selected scope for audit evidence. Generated reports are available for one hour, after which the download link expires and you'll need to generate the report again. > [!NOTE] > > The scan report API also supports PDF output for completed scans, with optional urgency and classification filters. Other report filters are rejected. Reports with more than 500 findings return `202` and a `poll_url` that includes a `job` parameter; poll the same endpoint with `format=pdf&job=` until the PDF is ready. The CLI doesn't produce PDF output. ### 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. > [!NOTE] > > 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](https://mintcdn.com/corgea/6_FZ3tSsReGJqh7D/images/dependencies_export_to_csv.png?fit=max\&auto=format\&n=6_FZ3tSsReGJqh7D\&q=85\&s=d97d430fbc91e7c007bdcde502e72525) #### 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](https://mintcdn.com/corgea/6_FZ3tSsReGJqh7D/images/project_dependencies_button.png?fit=max\&auto=format\&n=6_FZ3tSsReGJqh7D\&q=85\&s=fccc3c385b6e59ea8a8dd05863bf4d99) Click **Export SBOM** in that modal to download a CycloneDX 1.5 software bill of materials for the scan. If the scan has a completed dependency inventory but no stored SBOM file, Corgea generates the download on demand from that inventory. > ![Export SBOM button in the Project Dependencies modal](https://mintcdn.com/corgea/1zTIBpc0LYfu4dh5/images/dependencies_modal_export_sbom.png?fit=max\&auto=format\&n=1zTIBpc0LYfu4dh5\&q=85\&s=9e548e0240a272632154b714fd493841) #### 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. > [!NOTE] > > For any issues or support, please email [support@corgea.com](mailto:support@corgea.com). ## Features ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_extension.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=352cd2742009aacc865c84a8cd55814f) * **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 ### From the Integrations page Open **Settings → Automation → Integrations** ([open](https://www.corgea.app/settings/integrations/)). In the **IDE Extensions** section, select **Install** on the **IntelliJ IDEA** card. That opens the [JetBrains Marketplace](https://plugins.jetbrains.com/plugin/33252-corgea). After you install the plugin and restart the IDE, continue with login below. ### From the IDE ### Step 1: Open the Plugins Settings ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_plugins_settings.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=9c085dfe964ab131a1c09696d8722336) 1. Open your JetBrains IDE. 2. Go to `Settings` > `Plugins`. ### Step 2: Install the Plugin ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_marketplace.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=51b8744383b36cf5a6ae8aa205f5ef00) 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 ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_plugin_installed.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=aef7cf174948aeba241d87b1f7cca3aa) 1. Click `OK` to close the settings dialog. 2. Restart the IDE when prompted so the plugin loads. ### Step 4: Login ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_login.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=87d541a0c1ef1c0e96376320081da038) 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`. You can find it under **Settings → Automation → [API token](https://www.corgea.app/settings/integrations/api-token/)** in the Corgea dashboard. Your credentials are stored in the IDE's password safe. ## Usage ### Running a Scan ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_scan.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=fe505a3d18ce91ac22546fa1c15cc834) * 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 ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_code_list.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=99f6fe7e723727fa05e4930a48853966) * 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 ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_dependencies.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=2339145ab77bd8ca7b0a64da1d294bf7) * The `Dependencies` tab lists SCA findings grouped by package, with the severity, CVE identifier, and the version that resolves the vulnerability. ![](https://mintcdn.com/corgea/sHe0B2lymm-oxJGU/images/jetbrains_dependency_details.png?fit=max\&auto=format\&n=sHe0B2lymm-oxJGU\&q=85\&s=750907dbc0ad122815e457aeed831a55) * 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 **1. Access Integrations Page** Log in to your Corgea account and go to **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)**. **2. Open JIRA Integrations** Locate the "JIRA" integration and click the "Add" or "Edit" button to open the JIRA integrations page. **3. Configure Integration** ![Create JIRA Integration](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/create-jira-integration.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=9b9ee22cc1005576c9723ff40294e23d) 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 **4. Save Configuration** Click "Save" to complete the integration setup. ## Creating JIRA Issues **1. Navigate to Issues** Navigate to either a code issue or dependency issue in Corgea and open the issue details page. **2. Access Issue Details** On the issue details page, select the ticket icon button (tooltip: "Create Ticket"). ![Create Ticket Button](https://mintcdn.com/corgea/iadAV76rx_-M1qX0/images/pull_request.png?fit=max\&auto=format\&n=iadAV76rx_-M1qX0\&q=85\&s=c8286da5954cff2b319a709b40c635ca) **3. Configure Ticket** 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](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/create-ticket.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=9225ca9d574a1fbf4abe654aa545669d) **4. Create Ticket** Click the "Create JIRA Ticket" button. Corgea will create a new JIRA issue with the relevant details. **5. Confirm Creation** 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 → Automation → [Integrations](https://www.corgea.app/settings/integrations/)** and click **+ Add** in the **JWT Auth** section. > ![Add JWT Auth Configuration form in Corgea](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/jwt_token/corgae_jwt_token_form.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=de26336421fe9566ce0be49c5c410506) 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. | | **Role** | The permission role this configuration uses. Pick an existing role, or create a new one without leaving the form. New configurations have no role until you assign one. | > [!NOTE] > > 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 **1. Register an application in Entra** 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. **2. Expose an API and set the Application ID URI** 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](https://mintcdn.com/corgea/shid6yjMRFa2jrlq/images/jwt_token/entra_expose_an_api.png?fit=max\&auto=format\&n=shid6yjMRFa2jrlq\&q=85\&s=d04b83470b69fca5190511bef80e3129) Copy the Application ID URI (e.g., `api://5d63c8f0-c9a8-4195-90ee-a9e27e4510b8`) — you will enter this as the **Audience** in Corgea. **3. Create a client secret** Go to **Certificates & secrets → New client secret**. Add a description and set an expiry, then click **Add**. > ![Add a client secret in Microsoft Entra](https://mintcdn.com/corgea/shid6yjMRFa2jrlq/images/jwt_token/entra_client_secret.png?fit=max\&auto=format\&n=shid6yjMRFa2jrlq\&q=85\&s=e09e3cdc9aed42edd27ba14d6c294a0d) Copy the secret **Value** immediately — it is only shown once. Store it securely (e.g., in your CI/CD secrets store). **4. Request an access token** 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}" } ``` > [!NOTE] > > Replace `https://www.corgea.app` with `https://your_instance.corgea.app` if you are on a private deployment. **5. Register the configuration in Corgea** 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](https://mintcdn.com/corgea/9RMZY-Ts5g1RCFSA/images/jwt_token/postman_import_curl.png?fit=max\&auto=format\&n=9RMZY-Ts5g1RCFSA\&q=85\&s=d634e6065afdb582aa09a69b9a21ff5f) **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](https://mintcdn.com/corgea/9RMZY-Ts5g1RCFSA/images/jwt_token/postman_request_access.png?fit=max\&auto=format\&n=9RMZY-Ts5g1RCFSA\&q=85\&s=eb94f562884a32bb361dbd23206c03b7) **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](https://mintcdn.com/corgea/9RMZY-Ts5g1RCFSA/images/jwt_token/postman_call_api_with_token.png?fit=max\&auto=format\&n=9RMZY-Ts5g1RCFSA\&q=85\&s=66c68bafb415fa42282f6225d50bcd9f) > [!NOTE] > > 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](https://mintcdn.com/corgea/shid6yjMRFa2jrlq/images/jwt_token/jwt_io.png?fit=max\&auto=format\&n=shid6yjMRFa2jrlq\&q=85\&s=d00c729ec30d74b31bd448b410e67ca0) 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 [Roles](/permission_groups)) > [!NOTE] > > 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. > [!NOTE] > > 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 **1. Access Integrations Page** Log in to your Corgea account, go to **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)**, and find "Linear" under **Ticketing Integrations**. ![Linear listed alongside JIRA under Ticketing Integrations](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/ticketing_integrations.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=e8406565228b260e6adb7083922fea53) **2. Open Linear 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](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/no_linear_integrations.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=fc8927e7b15dd85a69c12e1950f95515) **3. Configure Integration** 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](https://mintcdn.com/corgea/kSEDD3ERVNp3rnFE/images/linear/add_linear_integration_modal.png?fit=max\&auto=format\&n=kSEDD3ERVNp3rnFE\&q=85\&s=8c462b1c7d9a1bcb0fc7d40efa115696) **4. Save Configuration** 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](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/linear_integration_api_key_error.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=d4ad2803c35706aadaeaed72e81bb8c4) ## Creating Linear Issues **1. Navigate to Issues** Navigate to either a code issue or dependency issue in Corgea and open the issue details page. **2. Access Issue Details** 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](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/create_linear_ticket_button.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=7267dee4eb043bab7860ca900917d4c1) **3. Configure Ticket** 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](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/create_linear_ticket_modal.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=836927e5d8afc281211518bc26896cda) **4. Create Ticket** Click the "Create Ticket" button. Corgea will create a new Linear issue with the relevant details. **5. Confirm Creation** 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. > [!NOTE] > > 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](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/hovering_over_edit_button.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=bc6e0067cc9b1fa0d6fe892339870e45) 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](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/edit_linear_integration_modal.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=f9cb2639fea7be6a42464871d8f91026) ### Deleting an integration Select the trash icon on the integration you want to remove. ![The delete button on a Linear integration](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/hovering_over_delete_button.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=0586ae8786924759219b42e9769274cb) 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](https://mintcdn.com/corgea/yUpPYRq94UTabZ2I/images/linear/delete_linear_integration.png?fit=max\&auto=format\&n=yUpPYRq94UTabZ2I\&q=85\&s=9de22d656d06f908e38df0f8e69e061f) 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 > [!WARNING] > > 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 * Export the dependency inventory as CSV * Check blocking rules and policies ## Getting Started Install Corgea MCP with [`corgea mcp install`](/cli#install-mcp-server) (CLI 1.13.0 or later). After `corgea login`, the CLI writes the server URL and token into the agent config. That page covers `npx`, supported agents, `--scope`, `--dir`, and `--set-default`. Restart the agent after installing. Prefer the installer over hand-editing. The rest of this page is the server URL, available tools, and manual client config. ### Prerequisites * A Corgea account. `corgea login` supplies the token the installer writes. * An MCP-compatible client (e.g., Claude Desktop, Cursor, Continue, or any MCP client) * For manual setup only: a Corgea API token from **Settings → Automation → [API token](https://www.corgea.app/settings/integrations/api-token/)** ### 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. > [!NOTE] > > 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} { "status": "ok", "issue": { "id": "6f1c2b9e-3d4a-4c8e-9b7a-1e2f3a4b5c6d", "scan_id": "0b8e7d6c-5a4f-4e3d-8c2b-1a0f9e8d7c6b", "status": "open", "urgency": "HI", "created_at": "2026-09-30T14:12:05Z", "first_detection_date": "2026-08-12T09:41:22Z", "classification": { "id": "CWE-89", "name": "SQL Injection", "description": "The product constructs all or part of an SQL command using externally-influenced input." }, "location": { "file": { "name": "database.py", "language": "python", "path": "src/database.py" }, "project": { "name": "my-project", "branch": "main", "git_sha": "9f2c1a7" }, "line_number": 42, "sink_line_number": 47 }, "auto_fix_suggestion": { "status": "fix_available" } } } ``` *** ### 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": "3c5d7e9f-1a2b-4c3d-8e4f-5a6b7c8d9e0f", "severity": "HIGH", "cvss_score": 7.2, "classification": null, "cve": "CVE-2021-23337", "status": "open", "package": { "name": "lodash", "version": "4.17.15", "ecosystem": "npm", "fix_version": "4.17.21" }, "location": { "path": "package-lock.json" }, "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", "page": 1, "total_pages": 2, "total_issues": 25, "issues": [ { "id": "8a7b6c5d-4e3f-4a2b-9c1d-0e9f8a7b6c5d", "classification": { "id": "CWE-79", "name": "Cross-site Scripting", "description": "The product does not neutralize user-controllable input before it is placed in output that is used as a web page." }, "urgency": "ME", "created_at": "2026-09-30T14:12:05Z", "first_detection_date": "2026-09-02T11:03:40Z", "status": "open", "sla_status": null } ] } ``` *** ### 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`, `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", "page": 1, "total_pages": 1, "total_issues": 12, "issues": [ { "id": "3c5d7e9f-1a2b-4c3d-8e4f-5a6b7c8d9e0f", "severity": "HIGH", "cvss_score": 7.2, "cve": "CVE-2021-23337", "package": { "name": "lodash", "version": "4.17.15", "ecosystem": "npm", "fix_version": "4.17.21" }, "location": { "path": "package-lock.json" } } ] } ``` *** ### 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 } ] } ``` *** ### export\_dependencies\_csv Generate a link for downloading a project's dependency findings as a CSV file. **Parameters:** * `project` (string, required): Project name or ID * `scan_id` (string, optional): Export a specific scan; defaults to the latest scan * `branch` (string, optional): Filter dependencies by branch name * `ecosystem` (string, optional): Filter by ecosystem, such as `pypi`, `npm`, or `maven` * `severity` (string, optional): Filter by severity — `critical`, `high`, `medium`, or `low` * `reachability` (string, optional): Filter by reachability — `reachable`, `unreachable`, `unused`, or `analyzing` * `dependency_type` (string, optional): Filter by dependency relationship — `direct`, `transitive`, `dev`, or `optional` * `search` (string, optional): Filter by package name **Returns:** A `download_url` to hand to the user, not the CSV rows themselves. Use `list_dependencies` when the assistant needs the data to reason over. The link resolves the same export as the download icon on the **Dependencies** tab, so it requires the **View SCA Issue** permission and produces the columns described in [Issue Export](/issue_export#dependency-exports). **Example:** ```json theme={null} { "download_url": "https://www.corgea.app/project/my-project/sca-findings/export/?urgency=critical", "message": "CSV export URL generated for project 'my-project'. Share this link with the user to download the file." } ``` *** ### 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 * `sha` (string, optional): Filter scans by exact commit SHA * `metadata_key` (string, optional): Filter scans that contain this metadata key; combine with `metadata_value` to match an exact key and value * `metadata_value` (string, optional): Match an exact value for `metadata_key`, or search across scan metadata when used alone * `page` (integer, optional): Page number * `page_size` (integer, optional): Number of scans per page **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 Use the sections below only if you prefer to edit an agent's config by hand. For most agents, [`corgea mcp install`](/cli#install-mcp-server) writes the same configuration for you. ### 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" } } } } ``` > [!NOTE] > > Claude Desktop does not substitute variables in this file. `${CORGEA_TOKEN}` is resolved by `mcp-remote`, which reads it from the environment the `env` block gives it, so the token has to be written there. Leave out the space after `CORGEA-TOKEN:` — Claude Desktop on Windows does not escape spaces inside `args`, and the header arrives mangled. 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", "--transport", "http-only", "--header", "CORGEA-TOKEN:${env:CORGEA_TOKEN}" ] } } } ``` > [!NOTE] > > Cursor resolves `${env:NAME}` itself, so the token can live in your environment instead of the file. The spelling is Cursor's own: `${env:CORGEA_TOKEN}` in Claude Desktop resolves to nothing and the header goes out empty. As above, keep the space out after `CORGEA-TOKEN:`. > [!NOTE] > > Cursor reads the variable from its own process environment. `export CORGEA_TOKEN=...` in a terminal reaches only that shell and its children, so a Cursor started from the Dock, Start menu or a desktop entry never sees it and the header goes out empty. Set it where the desktop session will find it, then restart Cursor: > > * **macOS**: `launchctl setenv CORGEA_TOKEN `, which lasts until you reboot. > * **Windows**: `setx CORGEA_TOKEN `, which persists for your user account. > * **Linux**: put `CORGEA_TOKEN=` in `~/.config/environment.d/corgea.conf` and log back in. > > Launching Cursor from a shell that already has the variable exported works anywhere, and is the quickest way to confirm this is the problem. An empty `CORGEA-TOKEN` header and a 401 is the symptom. > [!WARNING] > > The `mcp-remote` bridge is required here, not a convenience. Cursor's built-in `"url"` transport connects and then opens a server-sent events stream, which this server does not support, so the connection fails with `Failed to open SSE stream: Not Acceptable` and no tools appear. **Alternative Configuration (Direct HTTP):** For a client that posts JSON directly and does not open a standalone SSE stream: ```json theme={null} { "mcpServers": { "corgea": { "url": "https://www.corgea.app/mcp", "headers": { "CORGEA-TOKEN": "your_api_token_here" } } } } ``` Not all clients advertising HTTP transport qualify. Cursor is one that does not — use the `mcp-remote` configuration above there instead. A 406 or `Not Acceptable` on connect means the client is trying to open the SSE stream. ### Continue IDE Extension Continue reads standalone MCP block files from `.continue/mcpServers/`, not a `contextProviders` entry in `config.json`. Add Corgea as `~/.continue/mcpServers/corgea.yaml` (user scope) or `.continue/mcpServers/corgea.yaml` in the workspace (project scope): ```yaml theme={null} name: Corgea MCP version: 0.0.1 schema: v1 mcpServers: - name: corgea type: streamable-http url: https://www.corgea.app/mcp requestOptions: headers: CORGEA-TOKEN: your_api_token_here ``` > [!NOTE] > > Continue's config schema drops unknown keys. HTTP headers belong under `requestOptions` — a top-level `headers` map is silently discarded. ## 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 > **Secure Your API Token** > > * Never commit your API token to version control > * Rotate tokens periodically > * Use environment variables or secure secret managers > * Revoke tokens immediately if compromised > **Filter Effectively** > > * Use project, repo, branch, and pull request filters to narrow results > * Start with specific scans when debugging > * Filter by severity when prioritizing work > **Optimize Performance** > > * 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. Go to **Settings → Automation → API token** 3. Generate a new API token 4. Copy the token and add it to your MCP client configuration > [!WARNING] > > Keep your API token secure. Anyone with access to your token can query your security data through the MCP interface. > > Where the client can read the token from your environment, prefer that over writing it into the configuration file, and keep any file holding it out of version control. There is no shared syntax for this: Cursor uses `${env:NAME}`, Claude Code uses `${NAME}`, and Claude Desktop has none of its own. ## 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 > **[API Documentation](/api-reference/introduction)** > > Learn more about the Corgea API > **[Join Our Community](https://corgea-community.slack.com/join/shared_invite/zt-2cjmxat2f-Znvd06nP2gn9RYOSWrZI2A#)** > > Get help from the Corgea community > **[Authentication Guide](/api-reference/authentication)** > > Learn about API authentication > **[MCP Specification](https://modelcontextprotocol.io/)** > > Read the official MCP documentation ## Next Steps 1. **Install Corgea MCP** with [`corgea mcp install`](/cli#install-mcp-server) 2. **Restart the agent** so it loads the new server 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 informed about important security events through **email** notifications and supported **webhook** events, so you don’t have to keep checking the platform. There are two places to configure this: * **Settings → Personal → Notifications** — which emails Corgea sends you. * **Settings → Company → Notification defaults** — the starting point for everyone in the company. Company admins only. ## How It Works Notification preferences 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 emails. If you haven't set a personal preference, you inherit whatever the company admin has configured. Both pages save as you change them, confirming with a brief **Saved** indicator. There are no **Save** buttons. > [!NOTE] > > These settings control **email only**. Webhook delivery is configured separately under **Settings → Automation → Integrations → Webhooks** and is not affected by anything on these pages. See [Webhook Delivery](#webhook-delivery) below. ## Company Defaults **Settings → Company → Notification defaults** This is where company admins decide what's turned on by default for the whole company. ![Company Notification defaults with email toggles and a Recipients column](https://mintcdn.com/corgea/x3Z_vsbtPnot_ih_/images/settings/notification_defaults.png?fit=max\&auto=format\&n=x3Z_vsbtPnot_ih_\&q=85\&s=e9ff6d3cc4ef87490d4816dccce81ea0) | Column | What it controls | | - | - | | **Email** | Whether this notification is on by default for everyone. Members can still override it for themselves | | **Recipients** | Who receives it. Choose **Company admins**, **selected teams**, or **everyone** in the company. SLA and scheduled-scan failure notifications use the same options. | Notifications marked **Admins only** are sent solely to users with the company Admin role. They show **Company admins** in the Recipients column and cannot be limited to teams. Limiting a notification to teams changes who receives the email. It does not change webhook delivery, and the people in scope can still set their own personal preference. ## Your Own Notifications **Settings → Personal → Notifications** Set each notification to **Inherit**, **On**, or **Off**. **Inherit** follows your company's default, which is what every notification starts on. ![Personal notification settings with each notification set to Inherit](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/personal_notifications.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=ddcc3e7a4867f9a8f1fb6f0bacaffd7f) Every user has this page, including users who aren't company admins. ## Webhook Delivery Except for the email-only Auto Learning Recommendations Digest, Triage Review Decision, and Group Permissions Updated notifications, every notification listed below has a matching webhook event. A webhook receives the event whenever it is subscribed to it — there is no per-notification webhook switch, and email preferences have no effect on webhook delivery. Set up a webhook under **Settings → Automation → Integrations → Webhooks**. See [Webhooks](webhooks) for the event list, payload schemas, and delivery history. ## Available Notifications ### Scheduled Scan Report A daily report covers scheduled scans completed in the last 24 hours, including runs with no new findings. It shows new open code findings since each project’s previous scan and open finding totals by category, matching the scan results page. No report is sent when no scheduled scans completed. * **Who receives it:** All users in the company * **Email default:** On * **Recipients:** Company admins can limit delivery to selected teams * **Webhook event:** `scheduled_scan.daily_report` For the 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:** All users in the company * **Email default:** On * **Recipients:** Company admins can limit delivery to selected teams * **Webhook event:** `scheduled_scan.failure` See [Scheduled Scans](scheduled-scans) for help resolving scan failures and running a schedule again. ### Issue 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 * **Email default:** On * **Recipients:** Company admins can limit delivery to selected teams * **Webhook event:** `sla.violation` Per-SLA webhook delivery is configured in [SLA Management](sla_management). ### 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 * **Email default:** On * **Recipients:** Company admins — cannot be limited to teams * **Webhook event:** `issue.accepted_risk_expired` ### AI Pentest Completed Sent when an AI penetration test finishes, with a summary of findings and severity breakdown. * **Who receives it:** Company admins only * **Email default:** On * **Recipients:** Company admins — cannot be limited to teams * **Webhook event:** `pentest.completed` ### Integration Credentials Expired Sent when a GitLab, Azure DevOps, Bitbucket, or Harness access token connected to Corgea is invalid or expired and needs to be renewed. * **Who receives it:** Company admins only * **Email default:** On * **Recipients:** Company admins — cannot be limited to teams * **Webhook event:** `integration.credentials_expired` ### Auto Learning Recommendations Digest A daily email summarizes new auto-learning policy recommendations awaiting admin review. It previews up to 10 recommendations and links to **Policy Center → Learnings** for the full list. Recommendations already included in a digest are not sent again; policies remain unchanged until an admin approves them. * **Who receives it:** Company admins only * **Email default:** On * **Recipients:** Company admins — cannot be limited to teams * **Delivery:** Email only; no matching webhook event Manage delivery under **Settings → Company → Notification defaults** or **Settings → Personal → Notifications**. ### Triage Review Decision Sent to the requester when a false-positive or accepted-risk request is approved or rejected. Bulk reviews summarize results per requester and outcome; withdrawals do not send an email. * **Who receives it:** The requester * **Email default:** On * **Delivery:** Email only; no matching webhook event Manage delivery under **Settings → Company → Notification defaults** or **Settings → Personal → Notifications**. ### Group Permissions Updated Sent when permissions are added to or removed from a role. The email identifies the role and who changed it, summarizes the number of permissions added and removed, and links to the roles page. * **Who receives it:** Company admins and staff, subject to notification preferences and any configured team scope * **Email default:** On * **Delivery:** Email only; no matching webhook event Manage delivery under **Settings → Company → Notification defaults** or **Settings → Personal → Notifications**. # Pentesting Source: https://docs.corgea.app/pentesting Run AI-driven penetration tests against your web applications and get an auditor-ready report Corgea AI Pentest runs autonomous penetration tests against your running web applications. Where SAST reasons about source code, a pentest attacks the deployed application the way an adversary would: enumerating the attack surface, chaining weaknesses together, and proving each finding with a working exploit. Every run produces findings with a reproducible proof of concept and a shareable PDF report you can hand to a customer, an auditor, or your own engineering team. > [!NOTE] > > Pentesting is in beta and is available as an add-on. If you do not see **Pentests** in the sidebar, contact your Corgea administrator or [sales@corgea.com](mailto:sales@corgea.com). > [Corgea AI Pentest walkthrough](https://www.youtube.com/embed/wzvUiEr8I2c) ## How a Pentest Works Each run follows the same three stages. **1. Reconnaissance** Agents map the attack surface of your target — endpoints, authentication flows, parameters, and routes that are not linked from anywhere obvious. **2. Attack** Specialized agents work the target in parallel, each responsible for a domain. They attempt real exploitation rather than pattern matching, and they chain weaknesses across domains to reach higher-impact outcomes. **3. Report** Confirmed findings are written up with a description, business impact, attack chain, exploit script, and remediation guidance, then rolled into a downloadable report. Every run uses these agents: | Agent | Focus areas | | - | - | | Authentication / Authorization | Session management, privilege boundaries, IDOR and BOLA, MFA, JWT, OAuth and OIDC misconfigurations | | Business Logic | Workflow bypass, price and quantity manipulation, race conditions, account-flow abuse, transaction integrity | | Injection | SQL and NoSQL injection, command and template injection, XSS, SSRF, XXE, deserialization, path traversal, mass assignment | A **Deep** run adds an extended red-team agent that explores beyond those domains and builds multi-step attack chains across them. > [!NOTE] > > Corgea only reports findings its agents were able to validate against the running application. A finding in the report has been reproduced, not merely suspected. ## Before You Start > [!WARNING] > > Only run pentests against applications your organization owns or is explicitly authorized to test. A pentest sends real attack traffic and can create, modify, or delete data. Point runs at staging or a dedicated test environment unless you have accepted the risk of testing production. Your target URL must be publicly reachable over `http` or `https`. Corgea rejects targets that: * Use a scheme other than `http` or `https` * Embed credentials directly in the URL, such as `https://user:pass@example.com` * Resolve to `localhost`, a private network range, or a cloud metadata address If your application is not reachable from the internet, expose a test instance or reach out to discuss options. ## Targets A target is a reusable configuration: where to attack, which credentials to use, and any standing instructions. Each run executes against a target, so you configure it once and re-run whenever you ship. ![The Pentesting page showing the Targets tab with a list of configured targets, each with its URL, last run time, and creator, plus remaining Standard and Deep quota in the top right](https://mintcdn.com/corgea/C1ip_1th_wuFGATb/images/pentest/pentest_targets_list.png?fit=max\&auto=format\&n=C1ip_1th_wuFGATb\&q=85\&s=8d8a642788fc9443044e1603da003f23) The header shows how much pentest quota you have left for each scan mode. The **Pentest runs** tab lists every run across all targets, which you can search and filter by status. ![The Pentest runs tab showing a completed Harborline Customer Portal run with finding counts](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_runs_tab.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=070cd475cf99b007789890ce1e4211b2) ### Create a Target **1. Open Pentests** Select **Pentests** from the sidebar, then click **New target**. **2. Name the target and choose a scan mode** Enter a recognizable name, the application root URL, and a default mode: **Balanced** or **Deep**. You can override the mode per run. ![New pentest target wizard with name, URL, and Balanced or Deep scan mode](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_basics.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=1aa518a058ed41c91a625bd07993e72e) **3. Choose how agents sign in** Choose anonymous testing or authenticated testing. For authenticated testing, select password only, an authenticator app (TOTP), or emailed login codes when available on your deployment. ![Pentest wizard login step with authenticated testing or anonymous testing](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_login_method.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=e1afb6ce5226898e011a76e10086e022) If the application asks for a second factor, choose an authenticator app (TOTP) or emailed login codes. Emailed login codes appear only when a shared pentest mailbox is configured for the deployment. ![Pentest wizard two-factor step with authenticator app TOTP selected](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_totp.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=b0cdf09e7da0a164b774e6a3766480a6) ![Pentest wizard two-factor step with emailed login codes selected](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_email_codes.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=a83b671517e5bbf5c99a9677a0ea1dfa) **4. Set up test users** Add a username or email and password for each account. Multiple accounts let agents test access between users. For TOTP, enter the account's TOTP URI or select a QR image; the image is read in your browser and is not uploaded. ![Pentest wizard test user form with username, password, TOTP URI, and QR upload](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_users.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=0d49abdb2e98e84d038f48fa10083b89) **5. Add other credentials and instructions** Use **Other credentials** for API keys, required headers, or tenant IDs. Use **Additional instructions** for rules of engagement, scope exclusions, or endpoints to focus on, then click **Create target**. ![Pentest wizard other credentials step for API keys, headers, or tenant IDs](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_other_credentials.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=b63e7506e84c8e35cb28a52f9e02b2f8) ![Pentest wizard additional instructions step before Create target](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_instructions.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=e3792c1850aabe8d3ee8c3788e159dec) > [!NOTE] > > Credentials are encrypted at rest and are decrypted only while a run against that target is executing. ### Emailed Login Codes When this option is available, Corgea provides an email address for each test user. Enter a short role label using lowercase letters, digits, and hyphens, then click **Provision**. Invite that address into your application, use **Check for mail** to open the invitation and finish registration, then enter the password if your application set one and click **Save user**. Repeat for each user. ![Pentest wizard user setup for emailed login codes, with Provision and Check for mail](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/pentest/pentest_wizard_email_users.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=5d5d7204de685532cd1c560064547bda) Saving a user closes its setup inbox. Agents can read login codes during a run; use **Reopen setup** if you need to access the inbox again for setup. Emailed login codes require a configured pentest mailbox and are unavailable on deployments without one. ### Editing and Archiving Open a target's actions menu to start a run, edit it, or archive it. Edits apply to **future runs only**. Every run captures the target configuration it started with, so historical runs and their findings always reflect the setup that produced them. Changing a URL or rotating credentials never rewrites what a past run reported. Choose **Edit target** to reopen the setup wizard. To remove stored accounts and test anonymously, choose **No, test it anonymously** at the login step. Archiving hides a target from the list while keeping all of its historical runs viewable. ## Starting a Run From a target's actions menu, choose **Start new run**. **Balanced** A faster assessment covering authentication and authorization, business logic, and injection. Use this for routine testing on a regular cadence. **Deep** A more thorough assessment that adds a red-team agent for extended exploration and multi-step attack chaining. Use this before a release, an audit, or a customer security review. **Instruction override** replaces the target's standing instructions for that single run. Leave it blank to use whatever the target already has. This is useful when you want one run to concentrate on a newly shipped feature without permanently narrowing the target. Balanced and Deep runs draw on separate quotas. The scan mode dropdown shows how many of each you have left, and a mode with no remaining quota cannot be selected. To extend your quota, contact [sales@corgea.com](mailto:sales@corgea.com). ## Watching a Run Runs take a few hours depending on scan mode and the size of the application. You do not need to keep the page open — findings are saved as they are confirmed, and admins can be emailed when the run finishes. While a run is active, the run page updates on its own. Findings appear as agents validate them, so you can begin triaging critical issues before the run completes. Click **Logs** to watch the agents work. ![The Corgea Pentest Agents view showing a tree of agents working in parallel, with running totals for tool calls and findings, and a side panel describing the selected agent's current task and latest activity](https://mintcdn.com/corgea/C1ip_1th_wuFGATb/images/pentest/pentest_agent_tree.png?fit=max\&auto=format\&n=C1ip_1th_wuFGATb\&q=85\&s=50de6c57f9648ce06c12b5db0ae0d760) The tree shows each agent, what it is working on, and how many findings it has confirmed. Selecting an agent opens its current task and latest activity. Agents spawn child agents as they go: when one finds something worth pursuing, it delegates a focused follow-up rather than abandoning its own line of attack. ## Reviewing Findings When a run finishes, the run page summarizes what was found. ![A completed pentest run showing 76 total findings broken down into Auth and AuthZ, Business Logic, and Injection category cards with severity counts, above a findings list grouped by CWE](https://mintcdn.com/corgea/C1ip_1th_wuFGATb/images/pentest/pentest_run_completed.png?fit=max\&auto=format\&n=C1ip_1th_wuFGATb\&q=85\&s=7207e0cef8d98087bd8f27e179c5b9ac) The cards across the top break findings into categories by CWE. Click one to filter the list below it. * **All findings** — everything the run confirmed, with counts by severity * **Auth & AuthZ** — broken access control, authentication, and session issues * **Business Logic** — workflow and transaction integrity issues * **Injection** — injection, traversal, and untrusted input issues * **Validated SAST** — coming soon; will cross-reference confirmed SAST findings against runtime exploitability Findings whose CWE does not map to one of these categories still appear under **All findings**. ### Filtering and Grouping The toolbar above the findings list gives you: * **Status pills** — Open, Fixed, Closed, and False Positive, each with a live count. **More** adds Accepted Risk, Duplicate, and All statuses. * **Search** — matches on title, CWE, and endpoint * **Severity** — filter to Critical, High, Medium, Low, or Info * **CWE / Endpoint toggle** — group findings by weakness type, or by the endpoint they affect Grouping by CWE answers "what classes of bug does this application have." Grouping by endpoint answers "which part of the application is worst," which is usually the more useful view when assigning remediation work. ## Finding Details Open any finding to see the full write-up across five tabs. ### Finding Details The description, business impact, affected roles and users, and technical root-cause analysis. The sidebar carries the CWE identifier, severity, CVSS score, target, endpoint, and how many times the finding has been re-detected across runs. ![The Finding Details tab for a critical account takeover finding, showing description, impact, and impacted roles, with a sidebar listing CWE-639, critical severity, a CVSS score of 9.4, and the affected target and endpoint](https://mintcdn.com/corgea/C1ip_1th_wuFGATb/images/pentest/pentest_finding_details.png?fit=max\&auto=format\&n=C1ip_1th_wuFGATb\&q=85\&s=d2e3cc3b5a0bab2c8dd39f70342b35d4) ### Attack Chain The exact sequence the agent used, as numbered steps. Each step names the request it sent and what the application returned, so an engineer can follow the path without guessing. ![The Attack Chain tab showing four sequential steps that reproduce an account takeover, from registering a victim account through verifying full takeover](https://mintcdn.com/corgea/C1ip_1th_wuFGATb/images/pentest/pentest_finding_attack_chain.png?fit=max\&auto=format\&n=C1ip_1th_wuFGATb\&q=85\&s=d3cf2a578456bc584d17d94cd095c2d0) ### Exploit Script A runnable script that reproduces the finding. Run it against your target to confirm the issue yourself, and again after fixing to confirm the fix holds. ![The Exploit Script tab showing a Python script that reproduces the finding against the target application](https://mintcdn.com/corgea/C1ip_1th_wuFGATb/images/pentest/pentest_finding_exploit_script.png?fit=max\&auto=format\&n=C1ip_1th_wuFGATb\&q=85\&s=1797e27a7690716b7ca8fbfc45b3059f) > [!WARNING] > > Exploit scripts perform real attacks. Run them only against systems you are authorized to test, and expect them to create or modify data. ### Remediation Concrete remediation steps for this specific finding, plus references to relevant standards and guidance. ![The Remediation tab showing four sequential remediation steps and a references section linking to OWASP guidance](https://mintcdn.com/corgea/C1ip_1th_wuFGATb/images/pentest/pentest_finding_remediation.png?fit=max\&auto=format\&n=C1ip_1th_wuFGATb\&q=85\&s=d6686e0711feada6029a4b0da61c614b) ### History A timeline for the finding that spans every run: when it was first detected, when it was re-detected, and every status change and comment, with who made each one. Corgea recognizes the same underlying issue across runs. If a finding reappears in a later pentest, it is linked to the original rather than filed as something new, so the history reflects one continuous story. ## Triaging Findings Use **Current Status** on a finding to record a decision. You can set: | Status | Meaning | | - | - | | Open | Unresolved and awaiting work | | Fixed | You believe it is resolved — confirm with a revalidation run | | Accepted Risk | Acknowledged and accepted, optionally with an expiry date | | False Positive | Not a real issue | | Duplicate | Already tracked by another finding | A status change applies to every detection of that same issue, so triaging once updates the whole history rather than just the row you opened. You can also add comments to record context for teammates. > [!NOTE] > > **Closed** appears as a status but cannot be set by hand. Corgea applies it automatically when a revalidation run can no longer reproduce a finding. ## Exporting a Report Once a run completes, **Export report** offers two PDFs. > **Technical report** > > The complete assessment, including technical analysis, proof of concept, exploit code, and remediation guidance for every finding. For your engineering team. > **Executive report** > > The same assessment and findings without the technical deep-dive, proof of concept, or remediation detail. For customers, auditors, and leadership. Both reports contain: * A confidentiality statement and table of contents * An executive summary and findings dashboard * Scope and methodology, including which agents ran and what each covered, plus an explicit out-of-scope statement * Severity definitions and recommended action per tier * A summary table of all findings * Detailed findings grouped by severity Reports can support the penetration-testing evidence used in SOC 2 and ISO 27001 audits, and are designed to be shared as-is with customers and auditors. Whether a report meets a specific requirement depends on your audit scope, your selected controls, and your auditor. ## Revalidating After Fixes Once you have shipped fixes, re-test them without spending a full pentest on the whole application. On a completed run, open the **New run** menu and choose **Revalidate Findings**. A revalidation run re-tests only the findings from the source run and reports: * **Still open** — findings it reproduced again * **Closed by this run** — findings it could no longer reproduce, which are automatically set to Closed **1. Fix the findings** Work through the remediation steps, marking findings **Fixed** as you go. **2. Revalidate** From the completed run, choose **New run** then **Revalidate Findings**. **3. Confirm** Findings that can no longer be reproduced move to Closed. Anything still reproducible stays open with fresh evidence. Revalidation requires a completed run with at least one Open or Fixed finding. A revalidation run cannot itself be revalidated — run another revalidation from the original run instead. > [!TIP] > > Revalidation is the fastest way to prove remediation to an auditor or a customer: it shows the same test that found the issue can no longer reproduce it. ## Notifications Company admins can receive an **AI Pentest Completed** email when a run finishes, with the target, scan mode, total findings, and a severity breakdown. This is a per-admin email preference, so admins who would rather not receive it can turn it off without affecting anyone else. Corgea also fires a webhook on completion, which you can use to post results into Slack, open tickets, or gate a release pipeline. See [Webhooks](/webhooks) for setup and payload details. Revalidation runs do not send completion notifications. ## Frequently Asked Questions > **How long does a pentest take?** > > A few hours, depending on scan mode and the size and complexity of your application. Deep runs take longer than Balanced. You do not need to watch the run — findings save as they are confirmed, and admins can be emailed when it finishes. > **Can I test an application behind authentication?** > > Yes. In the target setup wizard, choose authenticated testing and add one or more test users. You can use a password, an authenticator app (TOTP), or emailed login codes when that option is available. Runs also include unauthenticated testing, so you get both the external-attacker and logged-in-user perspectives. > **Will a pentest damage my application or its data?** > > Agents perform real attacks, which can create, modify, or delete data. Denial-of-service and volumetric load testing are explicitly out of scope, but you should still prefer staging or a dedicated test environment for routine runs. > **Why was my target URL rejected?** > > Targets must use `http` or `https`, must not embed credentials in the URL, and must not resolve to `localhost`, a private network range, or a cloud metadata address. Expose a reachable test instance instead. > **Why does a scan mode appear greyed out?** > > That mode is out of quota. Balanced and Deep are tracked separately, and remaining counts appear in the page header and the scan mode dropdown. Contact [sales@corgea.com](mailto:sales@corgea.com) to extend. > **My run failed. What now?** > > The run's status will say why. The most common causes are a target that became unreachable mid-run and credentials that stopped working. Confirm the target is up and the credentials are current, then start a new run. > **The run finished with no findings. Is that a problem?** > > Not necessarily. It means the agents could not validate any exploitable issues within scope. If you expected findings, check that credentials are correct so authenticated areas were reachable, and consider a Deep run for broader coverage. > **How is this different from SAST?** > > SAST reasons about source code and finds issues before you deploy. A pentest attacks the running application and proves what is actually exploitable in your deployed configuration. They catch different things, and the findings from each are tracked separately in Corgea. ## Related > **[BLAST](/blast)** > > AI-native SAST for finding vulnerabilities in source code before deployment. > **[Webhooks](/webhooks)** > > Receive pentest completion events in your own systems. > **[Reporting](/reporting)** > > Track security posture across your organization over time. > **[Policies](/policies)** > > Define how issues are prioritized and handled. # Roles Source: https://docs.corgea.app/permission_groups This document provides a comprehensive overview of all permissions available for assignment to roles in the Corgea platform. Permissions control what actions users can perform within the system. > [!NOTE] > > Manage roles at **Settings → User Management → [Roles](https://www.corgea.app/settings/company/groups/)**. Viewing this page requires the **Can view Permission Group** permission and a plan that includes role management. ![The Roles page under Settings, listing each role and how many users it has](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/roles.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=41cb2241a9e5ecb814e76386d6b04c6b) ## 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 **roles** that correspond to job functions in your organization (e.g., Admin, Developer, Security Manager). Each role is assigned a specific set of permissions that define what actions those users can perform. Users are then added to one or more roles, inheriting all permissions from those roles. > [!NOTE] > > Permissions are **additive** - if a user belongs to multiple roles, they receive all permissions from all roles 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 > **Admin** > > Full system access - can manage all aspects of the platform including company settings, users, permissions, and all security features. > **Development Manager** > > Can manage development teams, users, projects, and view all security issues. Can initiate scans and manage team assignments but cannot modify security policies. > **Developer** > > 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. > **DevOps** > > 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. > **Security Manager** > > Comprehensive security management including all policy controls, SLAs, blocking rules, and user/team management. Cannot delete roles or modify company settings. > **Security Engineer** > > 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. ### Roles Overview The following are suggested roles to set up. Corgea comes with the Admin role 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 | ✓ | ✓ | ✗ | ✗ | ✗ | ✓ | | **Role Management** | | | | | | | | Create Role | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | | Edit Role | ✓ | ✓ | ✗ | ✗ | ✗ | ✗ | | View Role | ✓ | ✓ | ✗ | ✓ | ✗ | ✗ | | Delete Role | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | **Company Management** | | | | | | | | View Company Settings | ✓ | ✓ | ✗ | ✓ | ✗ | ✓ | | Edit Company Settings | ✓ | ✗ | ✗ | ✗ | ✗ | ✗ | | **Corgea Agent Settings** | | | | | | | | View Corgea Agent | ✓ | ✓ | ✓ | ✗ | ✗ | ✓ | | 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 **Permission Assignment** **1. Identify User Roles** Determine the specific roles and responsibilities within your organization (e.g., Security Analyst, Developer, Manager). **2. Map Permissions to Roles** Assign only the minimum required permissions for each role to follow the principle of least privilege. **3. Create Roles** Create roles that correspond to organizational job functions and assign the appropriate permissions. **4. Assign Users to Roles** Add users to the appropriate roles based on their job function and responsibilities. **Security Considerations** > [!TIP] > > Regularly audit permission assignments to ensure they align with current organizational needs > [!TIP] > > Remove unused permissions and clean up deprecated roles > [!TIP] > > Use integration user permissions only for automated systems, not human users > [!TIP] > > Implement regular reviews of high-privilege permissions like user management and policy changes **Troubleshooting** > [!TIP] > > If a user cannot perform an expected action, check their role assignments and individual permissions > [!TIP] > > Use the view permissions to audit what access a user or role currently has > [!TIP] > > Remember that permissions are additive - users get all permissions from all roles 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 | | **Can approve or reject triage requests** | Review another user's pending false-positive or accepted-risk requests | Approve or reject triage decisions for finding types the reviewer can change | ### 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 | ### Role Management Permissions These permissions appear in the app as **Can add/change/view/delete Permission Group**. They control who can manage roles. | Permission | Description | Use Case | | - | - | - | | **Can add Permission Group** | Create new roles with custom permission sets | Set up role-based access control by creating roles like "Developers", "Security Team", or "Managers" with specific permissions | | **Can change Permission Group** | Modify existing role settings and assigned permissions | Update role permissions, change role names, or adjust access levels as organizational needs evolve | | **Can view Permission Group** | View role configurations and assigned permissions | Review current role settings, audit permissions, or understand the access control structure | | **Can delete Permission Group** | Remove roles from the system | Clean up unused roles 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 Corgea Agent** | Open the Corgea Agent web chat | Ask about scans and findings. This permission does not grant access to agent settings or **Feedback History**. A new company has only the Admin role, and that role includes this permission. On an existing company, every role that could already view agent settings received it too | | **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 > [!NOTE] > > **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. > [YouTube video player](https://www.loom.com/embed/33723430fc3948419ba8d19a83a3b5ac?sid=2228960a-1f89-46c1-8678-68a419d507e5) ## Important Policy Behaviors Before diving into policy structure, there are some key behaviors to understand: 1. **Policy Application**: New policies only take effect on new scans - they won't retroactively affect existing results. 2. **Policy Precedence**: * More specific policies take precedence over general policies for false positive detection and fixes * For example, a SSRF-specific false positive policy would override a general false positive policy * Customer-defined policies always override Corgea's native policies 3. **Policy Grouping**: For scanning policies, it's recommended to group related security concerns together rather than creating individual policies. For example: * Group authentication, authorization, and permission handling together * Combine related data validation checks * Bundle associated security control verifications This approach yields better results as these security concerns often overlap and interact. ## Policy Structure A well-structured policy should include the following components: ![](https://mintcdn.com/corgea/Y5egKzTYPUk7VlOM/images/create-policy.png?fit=max\&auto=format\&n=Y5egKzTYPUk7VlOM\&q=85\&s=470bc5f1d55642955faca203f1a21d96) 1. **Policy Type**: Specify the type of policy you're creating, such as BLAST (detecting vulnerabilities), False Positive (identifying false positives), or Fix (suggesting code fixes). 2. **Business Context**: Provide detailed information about your: * Business domain and requirements * Network architecture and security controls * Environment-specific configurations * Data classification and handling requirements * Compliance requirements (e.g., PCI, HIPAA, GDPR) 3. **Description**: Clear instructions incorporating your context, including: * Specific vulnerability patterns in your environment * Code examples relevant to your architecture * How issues should be handled given your infrastructure 4. **Vulnerability Types (CWEs)**: Choose which types of security vulnerabilities this policy should handle, based on your risk profile. 5. **Projects**: Select which projects to apply this policy to, allowing for environment-specific policies. When Project Access Control is enabled, non-admin users can only create or manage policies for projects they can access and must select at least one accessible project. Company admins can still create policies that apply to all projects. 6. **File Pattern (Glob)**: Optionally limit a policy to matching files (for example, `src/**/*.py`). Leave empty to apply to all files. 7. **Guidance Notes (Optional)**: Add static guidance for developers, such as internal remediation notes, links to internal standards, or implementation tips. This guidance is shown on affected issues, including in issue explanations and suggested fixes. False-positive policies can also supply guidance in those views. ![Issue explanation showing a Policy Guidance block from an applicable policy](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/policies/policy_guidance_in_issue.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=f89f93740ece85ce4722f439b485f993) 8. **Instruction Type**: Choose how your policy instructions interact with Corgea's built-in policies: * **Append to Corgea Default Policy**: Adds your policy instructions to Corgea's built-in policies, preserving both sets of rules. Use this when you want to enhance the default policies with your specific business context, security controls, or environmental details. * **Replace Corgea Default Policy**: Your policy instructions completely override Corgea's default behavior. Use this when you want full control over how specific scenarios are handled. ## Policy Playground Policy Playground is a side-by-side workspace for creating, updating, and testing policies before they affect your scans. You write the policy on the left and test it against real code on the right, so you can iterate quickly without leaving the page. ![](https://mintcdn.com/corgea/flIjeH29bOLJTnXX/images/policy_playground/split_view.png?fit=max\&auto=format\&n=flIjeH29bOLJTnXX\&q=85\&s=dd2348f0f4cf402467f57bda1ba368b4) * The workspace is split into a **policy editor** (left) and a **test panel** (right), with a draggable divider so you can resize the panes to your preference. * Use **Back to Policies** in the top toolbar to return to the Policies table at any time. * Open an existing **BLAST** or **False Positive** policy directly in Policy Playground from the Policies table. * Search the Policies table by **Policy ID**, name, type, or description to quickly find a policy. * Editing and saving in Policy Playground updates the policy by creating a new version. * **Instruction Type** in the editor is shown as two clearly explained options: **Replace Corgea Default Policy** or **Append to Corgea Default Policy**. * Leave **Projects**, **File Pattern (Glob)**, or **CWEs** empty when you want that policy to apply globally. * When Project Access Control is enabled, scoped users can view policies visible to them, but can only edit or delete policies that apply entirely to projects they can access. > [!NOTE] > > Only **BLAST** and **False Positive** policies can be tested in Policy Playground. **Fix** policies can still be created from the Policy Center but are shown as **Fix (coming soon)** in the playground, as testing fixes isn't supported yet. ### Testing a Policy To test a policy, select a **Project** and a **file**, then click **Test**. The button shows a **Testing…** spinner while the scan runs and stays disabled until it completes. If anything required is missing, an inline hint below the button lists exactly what to add (project, file, or policy instructions). By default the file picker only lists files that already have detected issues. To test against a file that doesn't exist yet, enable **New Test File**, select a project, and type a filename. The project provides the language and framework context for the scan, and you can then write your own code in the editor to test the policy against. ![](https://mintcdn.com/corgea/flIjeH29bOLJTnXX/images/policy_playground/new_test_file_checked.png?fit=max\&auto=format\&n=flIjeH29bOLJTnXX\&q=85\&s=0334735a02e8ce36eddda9f2f36e5af7) ### Reviewing Results After a scan completes, findings appear in the results panel below the file preview. Each finding is an expandable row showing its **severity**, **CWE**, and **line number**. Expand a finding to read its explanation, and use **Jump to line** to navigate the file preview to the related line. ![](https://mintcdn.com/corgea/flIjeH29bOLJTnXX/images/policy_playground/jump_to_line.png?fit=max\&auto=format\&n=flIjeH29bOLJTnXX\&q=85\&s=b8942863a8e83c872b043cdee36aa223) If the scan completes without any matches, the panel shows a **No issues found for this policy** state so you can confirm the test ran. ![](https://mintcdn.com/corgea/flIjeH29bOLJTnXX/images/policy_playground/no_issues_found.png?fit=max\&auto=format\&n=flIjeH29bOLJTnXX\&q=85\&s=8691c9e326b1c43f85660dd7572b8230) ## PR Scan & Comment Rules PR Scan & Comment rules control when Corgea scans pull requests and when it posts finding comments back to the pull request. * **Scan Only** runs the pull request scan without posting finding comments. * **Scan & Comment** runs the scan and comments on findings that match the rule. * **Issue Type** selects **All** (the default), **Vulnerabilities**, or **Code Quality** for code findings. It applies to **Scan Only** and **Scan & Comment**: the scan keeps code findings of the selected type, and **Scan & Comment** comments on those findings. **All** and **Vulnerabilities** still comment on dependency findings that match the rule's severity. **Code Quality** ignores CWE filters, comments only on code quality findings, and does not comment on dependency findings. Severity filters apply to security and dependency findings; code quality findings bypass these filters when enabled by the rule. * **Severity** limits security and dependency findings to selected severity levels. Leave it empty to match any severity. Code quality findings are included regardless of urgency by default, unless disabled for the rule. * **Classification to comment** limits comments to selected CWE types. Leave it empty to comment on all matching CWEs. * **Projects** and **Project Tags** define where the rule applies. A rule applies when a project is selected directly or has any selected tag; if both fields are empty, the rule applies to all projects. * **Exclude projects** is available when **Projects** is empty. Excluded projects do not match this rule, even through a project tag. An explicit selection in **Projects** takes precedence over an exclusion on the same rule. * **Integrations** can further limit the rule to pull requests from selected GitHub, GitLab, or Azure DevOps integrations. Leave it empty to use only the project and project tag scope. ![Add Scan Comment Rule with Issue Type set to Code Quality and a project selected. Exclude projects stays hidden.](https://mintcdn.com/corgea/FLSePm4ROSteDzzZ/images/policies/pr_rule_issue_type.png?fit=max\&auto=format\&n=FLSePm4ROSteDzzZ\&q=85\&s=553cf717c405e31be61753a9b7140d5e) ![Add Scan Comment Rule with Projects empty, so Exclude projects is available](https://mintcdn.com/corgea/FLSePm4ROSteDzzZ/images/policies/pr_rule_exclude_projects.png?fit=max\&auto=format\&n=FLSePm4ROSteDzzZ\&q=85\&s=5d04fd7cf36d73485d02f4f15d4cbe12) Use the project tag filter on the PR rules page to find Scan & Comment 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. ## Policy Best Practices When writing policies, follow these best practices to provide effective context: 1. **Be Specific About Your Environment**: Detail your infrastructure, security controls, and compensating controls. 2. **Include Business Logic**: Explain business-specific validation rules, data flows, and security requirements. 3. **Describe Security Architecture**: Document your security layers, trust boundaries, and protection mechanisms. 4. **Define Data Context**: Specify how different types of data should be handled in your environment. 5. **Document Exceptions**: Note any legitimate business cases for apparent security issues. ## Examples When creating policy examples, follow these tips to make them more effective: 1. **Use Multiple Examples**: Include 3-5 diverse examples for each policy type to: * Show different use cases and scenarios * Cover edge cases specific to your environment * Demonstrate varying levels of complexity * Illustrate different security controls and compensating measures 2. **Make Examples Relevant**: Ensure your examples: * Reflect your actual infrastructure and architecture * Include real security controls you use * Reference your specific tools and frameworks * Match your development patterns and practices 3. **Structure Examples Clearly**: Format your examples with: * Clear section headers and labels * Consistent formatting and indentation * Detailed comments explaining key points * Tags to separate different components 4. **Include Context**: Each example should provide: * The specific business scenario * Relevant infrastructure details * Security controls in place * Expected behavior and outcomes Below are example policies demonstrating these principles: ### BLAST Policy Example **Policy Type**: BLAST ``` Business Context: Our application processes healthcare data behind a secure API gateway that handles encryption. Internal services communicate over a private network with mutual TLS. All database access is through our custom ORM that implements row-level encryption. Description: Review code considering our infrastructure. Flag potential PHI exposure but account for our API gateway encryption. Consider our network segregation when evaluating internal service communication. Verify proper use of our custom ORM for database access. Use Cases: - Detecting direct database access bypassing our ORM - Identifying services accidentally exposed outside the API gateway - Finding improper internal service authentication - Detecting logging of pre-encryption PHI - Identifying misuse of our security infrastructure ``` ### False Positive Policy Example **Policy Type**: False Positive ``` Business Context: Our test environments use sanitized data and mock services. All external services are replaced with stubs. The test network is isolated and all traffic is monitored. We use a custom test framework that simulates security controls. Description: Consider our test infrastructure when evaluating security issues. Data that appears sensitive is actually sanitized. External service calls are mocked. Network isolation provides additional security layers. Use Cases: - Validating test data handling - Confirming proper use of service mocks - Verifying test environment isolation - Checking sanitized data usage - Validating test security controls ``` ### Fix Policy Example Here's an example of a Fix policy that uses a custom middleware to protect against XSS vulnerabilities: **Policy Type**: Fix ```` Business Context: We use a custom security middleware called "SecureMiddleware" that provides XSS protection, among other security features. All web applications must use this middleware for request handling. The middleware automatically sanitizes user input and encodes output to prevent XSS attacks. Description: Generate fixes that integrate with our SecureMiddleware for XSS protection. Use the built-in sanitization and encoding functions provided by the middleware. Follow our secure coding guidelines for handling user input and rendering output. Use Cases: - Implementing XSS protection using SecureMiddleware Example: ```javascript // Import the SecureMiddleware import SecureMiddleware from '../middleware/SecureMiddleware'; // Use the middleware for request handling router.get('/profile', SecureMiddleware.sanitizeInput(), (req, res) => { const username = req.query.username; // Username is now sanitized // Render the profile page with encoded output res.render('profile', { username: SecureMiddleware.encodeOutput(username) }); }); `` ` In this example, the `SecureMiddleware.sanitizeInput()` function is used to sanitize the `username` parameter from the query string, preventing XSS attacks through user input. The `SecureMiddleware.encodeOutput()` function is then used to encode the `username` value before rendering it in the template, preventing XSS attacks through output rendering. - Integrating with our centralized security middleware Example or description: [Add an content] - Following secure coding practices for user input handling Example or description: [Add an content] - Implementing context-specific XSS protection measures Example or description: [Add an content] ```` By providing this context, Corgea can generate fixes that properly integrate with your custom security middleware and follow your secure coding guidelines for XSS protection. **Policy Type**: Fix ``` Business Context: We use a custom security framework that provides encryption, authentication, and audit logging. All services must use our security middleware. We have specific requirements for key rotation and cipher selection. Description: Generate fixes that integrate with our security framework. Use our standard middleware components. Follow our encryption standards and key management practices. Ensure proper audit logging through our centralized system. Use Cases: - Implementing framework-compliant security controls Example or description: [Add an content] - Integrating with our authentication services Example or description: [Add an content] - Setting up proper audit logging Example or description: [Add an content] - Configuring encryption using our standards Example or description: [Add an content] - Establishing service-to-service authentication Example or description: [Add an content] - Implementing environment-specific security measures Example or description: [Add an content] ``` Providing rich context about your business environment, security controls, and infrastructure helps Corgea deliver more accurate and relevant security analysis tailored to your specific needs. ## Prework-generated policies When prework is enabled for your company, Corgea can generate policies from your project context before the main scan completes. * Generated policies appear in the **Policies** table with `Source` set to **Generated By Corgea Prework**. * In scan details, the **Policies** tab shows all policies applied to that specific scan, including older archived or inactive versions, and lets you open the policy for more details. * If **Policy Review** is enabled from **Policies > Settings**, generated policies are created as **Inactive** so your team can review and activate them manually. ### Generating a Policy You can manually trigger policy generation directly from the PolicyIQ page at any time. **1. Click Generate Policy** On the **PolicyIQ** page, click the **Generate Policy** button in the top-right area. ![](https://mintcdn.com/corgea/FQs5jEJbhZc1ja12/images/prework/policy_generate_policy_button.png?fit=max\&auto=format\&n=FQs5jEJbhZc1ja12\&q=85\&s=899a590377ad4d38a4283d09ecdfdaf0) **2. Fill Out the Generation Form** In the dialog, select a **Pattern** (e.g., Authentication), choose a **Project**, and select a **Policy Type**. Click **Generate** to start. ![](https://mintcdn.com/corgea/FQs5jEJbhZc1ja12/images/prework/poilcy_generate_policy_form.png?fit=max\&auto=format\&n=FQs5jEJbhZc1ja12\&q=85\&s=54076a68431108fb7f661e736bdeba01) **3. Wait for Prework to Complete** Corgea runs a **Corgea-Prework** scan in the background to analyze your project. You can monitor its progress from the **Scans** page. ![](https://mintcdn.com/corgea/FQs5jEJbhZc1ja12/images/prework/policy_generation_in_progress.png?fit=max\&auto=format\&n=FQs5jEJbhZc1ja12\&q=85\&s=a07e57b9d735d386262144e7a6da72b7) **4. Review the Generated Policy** Once complete, the generated policy appears in the **Policies** table. Click on it to review the policy details, including the description populated with real code patterns found in your project. ![](https://mintcdn.com/corgea/FQs5jEJbhZc1ja12/images/prework/policy_generated_policy.png?fit=max\&auto=format\&n=FQs5jEJbhZc1ja12\&q=85\&s=be961ddb89457c220f5bcc9a063a9bbd) ## Corgea Policy YAML Configuration Support Customers can now define security policies for their projects using a `corgea.yaml` file. This configuration file enables the specification of detailed security policies, such as: * Specific CWE identifiers * Policies tailored to sub-folders * Testing new policies on a separate branch This feature is available with the `Scale` or `Enterprise` plan and requires additional enablement. Please contact us at [https://corgea.com/contact](https://corgea.com/contact) for more information. For reference, you can view an example repository here: [Example Repository](https://github.com/Corgea/mini-juice-shop). You can have - [Main Policies](https://github.com/Corgea/mini-juice-shop/blob/main/corgea.yaml) for general policy. Examples of sub-folder specific policies can be found in sub-folders like: * [Frontend Policies](https://github.com/Corgea/mini-juice-shop/blob/main/frontend/corgea.yaml) * [Backend Policies](https://github.com/Corgea/mini-juice-shop/blob/main/backend/corgea.yaml) These configurations help identify vulnerabilities by considering the context of each folder's responsibilities. This is particularly useful for monorepos, allowing developers to configure the right context. ### Workflow for Updating corgea.yaml **1. Create Branch and Trigger Scan** Create a new branch with the corgea.yaml file and open a pull request. This will automatically trigger a scan on the branch. Alternatively, you can manually trigger a scan from the project page. ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/policy_iq_trigger_scan.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=22a8283587940f18a78c950099c4a4c6) **2. Review Policy File** Go to the PoliciesIQ page, where you will find a section labeled `Policy File in Repos`. ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/policy_iq_policy_files_in_repo.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=62e4ed2bb530d4c943ab0d211e4aba06) **3. Review Policies from Policy File** Click on the section to review the specific policies generated by the corgea.yaml file. ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/policy_iq_corgea_yaml_scan.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=b1a0088efaa518e258ca7dea3d5444da) **4. Click on `Associated Issues`** Click on the `Associated Issues` column to see issues triggered from this policy. ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/policy_iq_corgea_yaml_issues.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=a3c36228075b0d8889f43874016b83fe) **5. Update and Experiment or Merge Your PR** Make further modifications until the results meet your expectations, then merge your pull request to include the corgea.yaml file in the main branch. ### Basic configuration for corgea.yaml Basic configuration of corgea.yaml looks like this : ``` # This is the corgea YAML file used for defining and managing security policies within applications. # For more information, visit: https://docs.corgea.app/policies version: 1 # Specifies the version of the corgea YAML standard being used. Update only if the standard changes. policies: - type: "scan" description: > This section ensures that all directories and files are thoroughly scanned to detect any security vulnerabilities in the backend code. It is essential to identify and address potential issues such as SQL injection, exposure of sensitive data, and unauthorized access. Comprehensive scanning helps maintain the security and integrity of the application. ``` * `type` : type of policy. This can be one of “scan”, “false\_positive”, “fix” * `description` contents of policy. Explain additional context or internal security guidelines to tailor security vulnerabilities findings. ## Advanced configuration for corgea.yaml Optionally, you can add these fields * `instruction_type` : Determines how your policy instructions interact with Corgea's built-in policies. Can be set to `"append"` or `"overwrite"`. When set to `"append"`, your policy instructions are added to Corgea's built-in policies, preserving both sets of rules. When set to `"overwrite"` (default), your policy instructions completely replace Corgea's default behavior. * `guidance_text` : Optional static guidance shown to developers when viewing issues associated with the policy, including in issue explanations and suggested fixes. Use this for team-specific instructions, internal links, or remediation context. ``` policies: - type: "fix" instruction_type: "append" guidance_text: > Use our secure logging utility and do not log raw request payloads. description: > Additionally, ensure all fixes integrate with our custom SecureMiddleware framework and follow our internal security guidelines for key rotation. cwes: - "CWE-79" # XSS ``` * `cwes` : Only applicable to "fix", or "false\_positive". It can apply specific policy to specific cwes. As an example, ``` cwes: - "CWE-20" # CWE-20: Improper Input Validation - "CWE-78" # CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') - "CWE-209" # CWE-209: Information Exposure Through an Error Message - "CWE-362" - "CWE-79" ``` * `excludes` : If you want to exclude some paths for a specific policy scan, you can list those files using a glob expression. ``` excludes: - "config/*" - "migrations/*" ``` * `ignore_paths` : If you want to exclude folders globally from all scans and new issue creation, you can specify them here. (Note: these file paths are ignored globally, not just for a specific policy. Patterns such as `**/vendor/**` match at any directory depth.) ``` ignore_paths: - "test/*" ``` * `path` : Instead of having separate corgea.yaml files under sub-folders, you can manage everything centrally by setting path. As an example of mini-juice-shop, you can have one corgea.yaml like [this](https://github.com/Corgea/mini-juice-shop/blob/central_corgea_yaml/corgea.yaml) ``` # This is the corgea YAML file used for defining and managing security policies within applications. # For more information, visit: https://docs.corgea.app/policies version: 1 # Specifies the version of the corgea YAML standard being used. Update only if the standard changes. policies: - type: "scan" path: 'backend' description: > ... - type: "scan" path: 'frontend' description: > ... - type: "fix" path: 'backend' description: > ... cwes: - "CWE-22" # CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') - type: "false_positive" path: 'backend' description: > .... cwes: - "CWE-20" # CWE-20: Improper Input Validation - type: "false_positive" path: "frontend" description: > ... cwes: - "CWE-79" # CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') ``` Once you trigger a scan on a branch with central yaml, **1. On the PolicyIQ page, you will see five policies generated.** ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/policy_iq_central_yaml.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=9021608defee9bba026ecd441cfff6a7) **2. You can view all the different policies with their respective paths.** ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/policy_iq_scans_policies_paths.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=79a9ca4ccab1ef102a6194ca82fafd42) # Private Package Registries Source: https://docs.corgea.app/private-package-registries Connect Corgea to your private package registry so dependency scanning covers your internal packages and everything they depend on. Supports Maven, PyPI, and NuGet. ## Overview * **What it Does**: Lets Corgea sign in to your private package registry so it can analyze the internal packages your projects depend on, along with every package those internal packages bring in. * **Who it's For**: Teams whose applications depend on internally published packages — shared libraries, platform SDKs, in-house frameworks — that live on a private registry instead of a public one such as Maven Central, PyPI, or nuget.org. ### Why you need it Corgea analyzes each dependency by looking it up in the registry it comes from. Public packages are available to anyone, so they work out of the box. Internal packages are not: without credentials, Corgea cannot open them, and anything hidden behind them stays invisible. Without a connected registry you will typically see: * A **Dependency Analysis** warning on the affected file in the scan's Errors tab. * Internal packages listed with **no sub-dependencies**, because Corgea could not look inside them. * **Missing vulnerabilities**, because anything reachable only through an internal package is never analyzed. Once connected, your internal packages are treated like any other dependency: they appear in the dependency tree with everything they pull in, and vulnerabilities inside them are reported, prioritized, and fixable in the usual way. ## Availability > [!NOTE] > > Private package registries are available to **enterprise customers on a dedicated tenant**. The feature is enabled per organization and is **off by default** — contact [support@corgea.com](mailto:support@corgea.com) to turn it on for your account. Until it is enabled for your organization, the feature is hidden: there is no **Package Registries** entry on the Integrations page and no registries panel in project settings. ## Supported package types | Package type | Language | | - | - | | **Maven** | Java, Kotlin, Scala | | **PyPI** | Python | | **NuGet** | .NET | ### Compatible registries Corgea connects using each package type's standard protocol, so it is not tied to a specific vendor. Any registry that serves packages the way the standard client expects, and accepts a username and token, will work. That includes: * Sonatype Nexus Repository * Azure Artifacts * GitHub Packages * Google Artifact Registry * MyGet * ProGet * Self-hosted registry servers ## Before you start You will need: 1. **A registry that Corgea can reach.** Corgea connects to your registry over the internet. A registry that is only reachable from inside your VPN or private network, or that sits behind an IP allowlist, will not work until you allow access. 2. **A token with read access.** Corgea only downloads packages and reads their dependency information. It never publishes. 3. **A token that does not expire quickly.** Corgea stores the token you provide and reuses it on every scan. > [!WARNING] > > Some registries issue **short-lived** tokens that expire after a few hours. These work for the first scan and then start failing. Use a long-lived token, service account, or API key instead. > [!TIP] > > Create a dedicated read-only service account for Corgea rather than using a personal token. Access stays limited to what Corgea needs, and the connection keeps working when someone leaves the team. ## Setting up a registry ### Step 1 — Get your registry details In your registry, create a token (or service account) with **read** access to the repositories Corgea should use. Note the **username** it belongs to and the **URL** of the repository. **Maven** Use the URL of the repository that serves your internal artifacts, for example: ```text theme={null} https://packages.example.com/repository/maven-releases ``` **PyPI** Use your package index URL, which usually ends in `/simple`: ```text theme={null} https://packages.example.com/repository/pypi/simple ``` **NuGet** Use your feed's index URL, which usually ends in `/index.json`: ```text theme={null} https://packages.example.com/repository/nuget/v3/index.json ``` ### Step 2 — Add the registry in Corgea Go to **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)** → **Package Registries** and click **Manage**. ![Package Registries section on the Integrations page](https://mintcdn.com/corgea/CncYiZxwYXM7eJG5/images/package-registries/integrations_entry.png?fit=max\&auto=format\&n=CncYiZxwYXM7eJG5\&q=85\&s=74452c9a3af2fccdea375a730928d02e) > [!NOTE] > > You need the **Manage Integrations** permission to add, edit, or delete a registry. See [Permissions](#permissions). Click **Add Registry**. ![Package Registries list showing configured registries](https://mintcdn.com/corgea/CncYiZxwYXM7eJG5/images/package-registries/registries_list.png?fit=max\&auto=format\&n=CncYiZxwYXM7eJG5\&q=85\&s=7d246e52ce7f5d1a177dc2305ace9408) Fill in the form: ![Add Package Registry form in Structured form mode](https://mintcdn.com/corgea/CncYiZxwYXM7eJG5/images/package-registries/add_registry_structured.png?fit=max\&auto=format\&n=CncYiZxwYXM7eJG5\&q=85\&s=4ab913a69898a6ef939e4c984ac04d0a) | Field | Required | Notes | | - | - | - | | **Name** | Yes | A label to recognize this registry by. Shown in the list and in project settings. | | **Ecosystem** | Yes | `Maven`, `PyPI`, or `NuGet`. Choose the package type this registry serves. | | **Setup method** | Yes | **Structured form** (default) or **Paste config file**. See [Setup methods](#setup-methods). | | **Repository URL** | Yes | The URL from Step 1. | | **Additional repositories** | No | Other repositories on the same registry, one per line as `name=url`. Leave blank to use only the URL above. | | **Username** | Yes | The user or service account the token belongs to. | | **Access token** | Yes | Your token or password. Stored encrypted and never shown again after saving. | | **Apply to all projects** | No | On by default. See [Choosing which projects use a registry](#choosing-which-projects-use-a-registry). | | **Enabled** | No | On by default. Turn off to stop using the registry without deleting it. | > [!WARNING] > > Each registry entry covers **one package type**. If your registry hosts Maven, PyPI, and NuGet repositories, add three entries — one per package type — each with its matching URL. ### Step 3 — Choose which projects use it Leave **Apply to all projects** on so every project in your organization can use this registry, or turn it off and select specific projects. See [Choosing which projects use a registry](#choosing-which-projects-use-a-registry). ### Step 4 — Re-scan and check the results Run a new scan on a project that depends on an internal package, then confirm: * The **Dependency Analysis** warning for that file is gone from the scan's Errors tab. * Your internal package now shows **sub-dependencies** and can be expanded in the [dependency tree](/sca#dependency-tree-view). * Vulnerabilities that only exist inside internal packages now appear. > [!NOTE] > > Connecting a registry does not change results from earlier scans. Run a **new scan** to pick up the improved coverage. > [!NOTE] > > If Corgea cannot reach your registry during a scan, the scan still finishes using public packages and shows a warning on the affected file. A registry problem never fails your scan or blocks your pipeline — but the results will be missing your internal packages until it is resolved. ## Setup methods ### Structured form (recommended) Enter your URL, username, and token, and Corgea handles the rest. Use this unless you have a specific reason not to. ### Paste config file (advanced) If you already maintain a package manager configuration file for your registry, you can paste it instead. Choose this when your registry needs settings the form does not cover — such as mirrors, proxies, or rules about which packages come from which source. ![Add Package Registry form in Paste config file mode](https://mintcdn.com/corgea/CncYiZxwYXM7eJG5/images/package-registries/add_registry_raw.png?fit=max\&auto=format\&n=CncYiZxwYXM7eJG5\&q=85\&s=709a6d791cbe9c998d3fd8584a78ca71) Paste the configuration file your package manager already uses for this registry: a Maven `settings.xml`, a pip configuration file, or a `NuGet.Config`. > [!WARNING] > > The file must contain **working credentials**. If your file uses an encrypted or placeholder password, replace it with a real token before pasting — Corgea cannot decrypt your registry's own password format. > [!NOTE] > > If you switch an existing registry from one setup method to the other, enter the credentials again for the new method. Corgea keeps only the credentials for the method you are using. ## Choosing which projects use a registry Registries are set up once for your organization, then applied to projects in one of two ways: * **Apply to all projects** (default): every project in your organization can use the registry. Best for a single company-wide registry. * **Specific projects**: only the projects you select. Useful when a registry belongs to one team, or when you want to roll the feature out gradually. ### Checking a single project Open a project and go to **Settings → Package Registries** to see which registries apply to it: * Registries set to apply everywhere show an **All projects** badge. Change these from **Integrations → Package Registries**. * Other registries show a **toggle** you can switch on or off for this project. * A registry that has been turned off completely shows a **Disabled** badge. > [!NOTE] > > Changing a project's registries requires the **Change Project** permission. If [Project Access Control](/content-access-management) is enabled, you also need access to that project. ## Using more than one registry You can add as many registries as you need, and a project can use several at once: * **Several registries for the same package type**: packages are looked up across all of them. * **Different package types**: each is handled independently. * **Several repositories on one registry**: list them under **Additional repositories** instead of creating separate entries. > [!NOTE] > > For a single package type, use the same setup method across all of its registries. If some use **Structured form** and others use **Paste config file**, the pasted files are skipped. ## Permissions | Action | Permission required | | - | - | | View the Package Registries list | **View Integrations** | | Add, edit, or delete a registry | **Manage Integrations** | | View a project's Package Registries panel | **View SAST Scan** | | Change which registries a project uses | **Change Project** | See [Roles](/permission_groups) for how to assign these. ## Security Your registry credentials are treated as secrets: * **Encrypted storage.** Credentials are encrypted and are never displayed again after you save them. When you edit a registry, the token field is blank; leaving it blank keeps your existing token. * **Used only during scans.** Credentials are used to authenticate to your registry while a scan runs, and for nothing else. * **Isolated.** Credentials and any packages downloaded with them are never shared with another scan or another organization. * **Kept out of your repository.** Corgea does not write your credentials into any file it produces. * **Hidden in logs and messages.** Credentials are removed from error messages and diagnostics shown in Corgea. * **Read-only access.** Corgea only downloads packages and reads their dependency information. ## Registries on restricted networks If your network blocks public registries and requires all packages to come through your own registry, point Corgea at a repository that serves both your internal packages **and** proxies the public ones. Corgea then has everything it needs from a single source. If your registry only serves internal packages and public registries are unreachable, dependency analysis cannot complete. ## Troubleshooting > **Dependency Analysis could not fully process this file** > > **What it means**: Corgea found a package it could not look up — usually an internal package on a registry it cannot sign in to. > > **What to do**: Add a registry for that package type, make sure it applies to the project, and re-scan. If a registry is already connected, check the URL and that the token is still valid. > **Private package registry auth was enabled but no registry credentials could be loaded** > > **What it means**: The project is set up to use a private registry, but no usable registry was available when the scan started. Usually the registry has been turned off, no longer applies to the project, or was deleted. > > **What to do**: Go to **Integrations → Package Registries** and check that a registry for that package type exists, is **Enabled**, and either applies to all projects or includes this one. > **Private registry dependency resolution failed** > > **What it means**: Corgea signed in but could not retrieve the packages. Common causes are an expired or revoked token, a URL pointing at the wrong repository, or a package that is not actually on the registry. > > **What to do**: Confirm the credentials work from outside your network: > > ```bash theme={null} > curl -u "USERNAME:TOKEN" -I "YOUR_REGISTRY_URL" > ``` > > A `401` or `403` means the credentials are wrong. A `404` means the URL is wrong. > **Private registry dependency resolution timed out** > > **What it means**: Retrieving your dependencies took too long, usually a very large project or a slow registry. > > **What to do**: Commit lock files where you can, so there is less to resolve during the scan, and check your registry's response times. Then re-scan. > **Some modules in a large repository were not covered** > > **What it means**: The repository contains more independent modules than Corgea resolves in a single scan. > > **What to do**: If the uncovered modules matter, split them into separate Corgea projects, or commit lock files for them. > **Private registry CVE scan failed or timed out** > > **What it means**: Your internal packages were retrieved, but the vulnerability check over them did not finish. > > **What to do**: Re-scan. Results for public packages are unaffected; only vulnerabilities specific to internal packages may be missing. > **Dependency analysis fails when public registries are blocked** > > **What it means**: Corgea needs some publicly available components to analyze your project, and neither your registry nor the public internet is providing them. > > **What to do**: Point the registry at a repository that also proxies public packages. See [Registries on restricted networks](#registries-on-restricted-networks). > **Will this interfere with my own package manager configuration?** > > **What it means**: Nothing to fix — Corgea adds its registry access alongside any configuration committed to your repository rather than replacing it, so your existing sources and rules continue to apply. > > **What to do**: If sources still appear to be missing, check that any configuration file committed to your repository is valid. Corgea leaves a file it cannot read untouched rather than risk breaking your build. > **My registry uses http instead of https** > > **What it means**: This works, but your token is sent unencrypted. > > **What to do**: Use `https` for anything beyond local testing. > **I cannot find the feature in Corgea** > > **What it means**: The feature is off by default, and while it is off it is hidden rather than shown as locked — so there is nothing to click. > > **What to do**: Private package registries are available to enterprise customers on a dedicated tenant. Contact [support@corgea.com](mailto:support@corgea.com) to enable it for your organization, then reload the Integrations page. ## Best practices > [!TIP] > > Start with one registry on a single project, confirm the dependency tree looks right, then apply it to all projects. * **Use a dedicated read-only service account** rather than a personal token. * **Use long-lived tokens** and track their expiry dates so scans do not quietly lose coverage. * **Add one entry per package type**, each with its matching URL. * **Prefer a repository that also proxies public packages** — it works whether or not your network is restricted. * **Prefer the structured form**, and use a pasted configuration file only when you need settings it does not cover. * **Commit lock files** where practical. Scans are faster and results more consistent. * **Rotate tokens** on your normal schedule and update the registry in Corgea. Leave the token field blank when editing if you are not changing it. ## Related * [Dependency Scanning (SCA)](/sca) — how dependency scanning, the dependency tree, and reachability work * [Roles](/permission_groups) — granting View and Manage Integrations * [Content Access Management](/content-access-management) — controlling who can change a project # Project Management Source: https://docs.corgea.app/project Configure scanning behavior for your project including CWE filters, file ignore rules, and file include rules ## Overview Corgea’s project management live inside each project’s dashboard. Use this page to tailor scanning behavior so it aligns with your codebase, compliance needs, and team workflows. You can block noisy files, force-scan folders Corgea would otherwise skip, ignore irrelevant CWEs, document policies, and see the operational views you need to keep your application secure. Every change you make here applies to future scans for the selected branch. If you’re new to these controls, start with the Default Settings and gradually refine the filters after reviewing a few scan reports. > [!NOTE] > > Changing scan settings requires the **Can edit project** permission. The **Settings** dialog is only available to users with project edit access. ## File Ignore Rules File ignore rules help you keep findings focused on the code that matters. Matching files are skipped for future scans and ignored when new issues are added to the project. We already exclude common build artifacts, dependency folders, and generated files, so you typically only need to add rules that are unique to your project structure. ### Default exclusions * **Test files**: `*_test.*`, `test_*.*`, `*.test.*`, `*.spec.*`, `*__tests__/*`, `*test/*`, `*tests/*` * **Dependencies**: `*node_modules/*`, `*python*/site-packages/*` * **Generated code**: `*generated.*`, `*.gen.go`, `*.pb.*`, `*.designer.cs`, `*.d.ts` * **Build artifacts**: `*build/*`, `*dist/*`, `*coverage/*` * **Configuration**: `tsconfig.json`, `webpack.config.js`, `pnpm-lock.yaml`, `*compose*.yml` * **Other common folders**: directory names `migrate`, `migration`, `migrations`, `changelog`; also `*mock/*`, `*mocks/*`, `*fixtures*`, `*tmp/*`, `*log/*`, `*logs/*` ### How to add custom ignores **1. Open the Settings dialog** From the project dashboard, click **Settings** to open the settings dialog, then expand the **File Ignore Rules** section. ![Scan Settings](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/scan_settings.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=ad2984792039ddf70376dc2c9ff573c9) **2. Add a pattern** In **Glob Pattern of files to ignore**, enter a single glob pattern for the paths (`src/tools/`), directories (`**/legacy/**`), or nested files (`src/assets/languages/**`) you want to skip. Patterns that start with `**/` can match the folder at any depth, including the repository root. Optionally add a **Comment (optional)** explaining why the rule exists (up to 200 characters), then click **Add Ignore Rule**. Each new rule appears in the table below with its **Pattern**, **Type**, **Status**, and **Comment**. > ![File Ignore Rules Configuration](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/file_ignore_rules.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=533ce6820a321722f4627e1c9cfc4c7b) **3. Update a rule's comment** To edit a rule's comment, re-enter its exact pattern. The button changes to **Update Ignore Rule**, and submitting updates the comment on the existing rule instead of creating a duplicate. Submitting a blank comment leaves the existing comment unchanged. > ![Updating an existing file ignore rule](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/same_file_update_ignore_rule.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=6b60a869ad8acd214eec83af8eec57dc) **4. Enable, disable, or delete rules** Use the **Actions** column to **Disable** a rule (it stays in the list but is skipped during scans), **Enable** it again, or **Delete** it entirely. The **Status** column shows whether each rule is currently active. > ![A disabled file ignore rule](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/disabled_rule.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=f1a54fa2b15701e318c8bb63397f6c20) **5. Monitor** Run a test scan to make sure the behavior matches your expectations. Revisit this list whenever you add new generated outputs or temporary directories. ### When to add rules * **Internal tooling**: Scripts or utilities that should never be scanned (e.g., internal deploy scripts or CLI helpers). * **Legacy or deprecated code**: Modules you’re no longer shipping but still keep for reference. * **Vendor or third-party artifacts**: Files provided by hardware vendors or partners that don’t change and you don’t control. * **Documentation or content**: Rule out large doc folders when only code matters. * **Custom output**: Non-standard build directories created during CI or local experimentation. Always explain why a rule exists so teammates know why a folder is skipped during future reviews. ## File Include Rules Corgea skips common folders such as `migrations`, `vendor`, and `node_modules`. Include rules scan matching files anyway. Use them when that code is yours — for example a `migrations` folder, or a fork under `vendor/`. A File Ignore Rule still wins if both match. Patterns that match the whole repository (`**`, `**/*`) are rejected. Include rules do not scan files Corgea still treats as tests, minified, or generated from their contents. **1. Open File Include Rules** From the project dashboard, click **Settings**, then expand **File Include Rules**. **2. Add a pattern** In **Glob Pattern of files to always scan**, enter a glob such as `**/migrations/**` or `vendor/our-fork/**`. Patterns that start with `**/` can match the folder at any depth, including the repository root. Optionally add a **Comment (optional)** explaining why the files should be scanned (up to 200 characters), then click **Add Include Rule**. > ![File Include Rules configuration](https://mintcdn.com/corgea/E0aS_BVQT-LrnioT/images/project-settings/file_include_rules.png?fit=max\&auto=format\&n=E0aS_BVQT-LrnioT\&q=85\&s=19bb5b516ad789af81921220b7cccc9d) **3. Enable, disable, or delete rules** Use the **Actions** column the same way as File Ignore Rules. You can also set `include_paths` in `corgea.yaml`. If a file was skipped on an earlier scan, run one full scan after adding the rule (`corgea scan --disable-incremental`, or **Full Scan** in the app) so it is analyzed. ## CWE Filters CWEs let you align Corgea’s findings with your project’s threat model. Think of this section as your security policy in code: you can disable specific vulnerability families that you’re already protecting through other controls or that don’t apply to your stack. ### How to configure filters **1. Open CWE Filters** In the **Settings** dialog, expand the **CWE Filters** section. By default, all CWEs are tracked. **2. Pick the CWEs you want to ignore** Enter a CWE ID (for example, `CWE-79`) and optionally include a **Glob Pattern** to scope the rule to specific files or folders (for example, `**/tests/**`). Leave the glob pattern empty to apply the rule across all files in the project. Add an optional **Comment** explaining why the filter exists, then click **Add CWE Filter**. > ![CWE Filters Configuration](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/cwe_filters.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=01ddd34a639d39b44bfc2fbd1be024e5) **3. Update, disable, or delete filters** Re-enter an existing CWE and glob pattern combination to edit its comment—the button changes to **Update CWE Filter** and the existing entry is updated instead of duplicated. Submitting a blank comment leaves the existing comment unchanged. Use the **Actions** column to disable, enable, or delete a filter at any time. ### Common scenarios * **Focus on critical paths**: Temporarily mute low-impact CWEs until you finish triaging high-severity findings. * **Framework-level protection**: Skip CWEs covered by built-in framework hardening (e.g., managed auth providers). * **Compliance tailoring**: Disallow CWEs that violate organizational policies while keeping scans manageable. * **Early-stage development**: Move fast by hiding noise but re-enable the filters later before shipping. > Tip: Periodically re-run scans with the full CWE list enabled so you don’t miss regressions when filters change. ## Project Views and Controls ### Search the Projects List Use the search box on the **Projects** page to match project names, repository URLs, and tags. A one-character search filters projects already added to Corgea; enter at least two characters to also include matching repositories discovered from your connected source code providers. Recently added or renamed repositories may appear after the provider inventory refreshes; administrators can use the page’s refresh action to request an updated inventory. Click the filter icon beside the search box to show the project filters. Choose a tag, an **Integration** (GitHub, GitLab, Azure DevOps, Bitbucket, Harness, or **Zip Upload**), or a **Team**. Where available, use **Projects I Own** or **Projects I'm Member Of** to filter by your role; selecting a role clears the team selection, and selecting a team clears the role selection. Search and the other filters apply together. Hiding the filter panel keeps filters active, and the icon shows the number set. Click **Clear** to reset the filters while keeping your search text. When content access control is enabled, the **Teams** column on the **Projects** page lists both directly linked teams and teams whose project tags or repository URL patterns match the project. Each team appears only once. ### Trigger a Scan for a Specific Branch Select the branch you care about from the branch picker at the top of the dashboard before starting a scan. Corgea locks the scan to that branch's latest commit and stores branch metadata so you can compare results across lines of development. > ![Branch picker in project dashboard](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/branch_picker.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=e4bf347673f33e4e90ebff9ea9f88d51) Start the scan from the button in the page header. It reads **New Scan** on a project that has been scanned before, and **Start Scan** on one that hasn't. > ![New Scan button in the page header](https://mintcdn.com/corgea/6_FZ3tSsReGJqh7D/images/new_scan_button.png?fit=max\&auto=format\&n=6_FZ3tSsReGJqh7D\&q=85\&s=e108244878bac8a2962ff5950e23465a) The button opens a menu with two options: * **Full Scan** runs every scanner enabled for the project against the selected branch. * **Custom Scan** opens a dialog where you choose which scanners to run and, for scanners driven by policies, which policies to include. Confirm with **Start Custom Scan**. Scanners your plan doesn't include are shown but marked **Plan Restricted**. > ![Full Scan and Custom Scan options in the New Scan menu](https://mintcdn.com/corgea/6_FZ3tSsReGJqh7D/images/new_scan_list_expanded.png?fit=max\&auto=format\&n=6_FZ3tSsReGJqh7D\&q=85\&s=9468779954641e9f3c4aec7447ba72bf) > [!NOTE] > > When scanning isn't available for a project, the button is greyed out with a lock icon. Hover it to see the reason. ### Scan Log The **Scan Log** tracks every run you kick off. It records status, duration, branch, and who triggered each scan. Use this page to rerun scans, compare results side by side, and jump into the findings that caused failures. In the Scan Log filters, search for a tag in the **Tag** dropdown, choose a scanner from **All Scanners**, or choose **Manual Full Scan**, **Scheduled Full Scan**, or **PR Scan** from **All Scan Triggers**. Selections update the list immediately; use **Clear** to reset the filters. The scan list updates the status of running scans in place. When more scans match your filters, a button appears with that count, for example **3 scans to show**. Click it to load the first page with your current filters. ![Scan list with a 3 scans to show button for scans that match the current filters](https://mintcdn.com/corgea/qHKsGxwKc7STDQVo/images/project-settings/scans_to_show.png?fit=max\&auto=format\&n=qHKsGxwKc7STDQVo\&q=85\&s=ae02e6e9aa1a93c64045c61cbe6cf958) In the scan details header, a scan type badge shows how the run was triggered: * **Full Scan** — covers the selected branch or uploaded project * **CLI Scan** — triggered from the CLI * **PR #N** — triggered from a pull request (links to the PR when available) > ![Scan details header showing a Full Scan badge](https://mintcdn.com/corgea/JSgsrtfQPXk7jTWK/images/project-settings/scan_type_badge_full_scan.png?fit=max\&auto=format\&n=JSgsrtfQPXk7jTWK\&q=85\&s=0df00af55c9fb6a1a8ae6b9df49ac2bb) > ![Scan details header showing a CLI Scan badge](https://mintcdn.com/corgea/JSgsrtfQPXk7jTWK/images/project-settings/scan_type_badge_cli_scan.png?fit=max\&auto=format\&n=JSgsrtfQPXk7jTWK\&q=85\&s=22a8fd213b4e72255216b17b5f9983c3) > ![Scan details header showing a PR #12 badge](https://mintcdn.com/corgea/JSgsrtfQPXk7jTWK/images/project-settings/scan_type_badge_pr_scan.png?fit=max\&auto=format\&n=JSgsrtfQPXk7jTWK\&q=85\&s=bf528102c422343cadd056e37c49cef2) When a scan records errors, warnings, or informational entries, Corgea displays the count in the Scan Log and highlights the **Logs** button based on the highest severity present. > ![Scan log view listing scan runs](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/scan_log.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=89c8ac01cc4311a763e2826b70cd6d84) ### Endpoint Findings Filters Use the **Reachable** toggle to limit scan results to findings with at least one static call path from a discovered endpoint. The toggle state is preserved in the URL so you can share or bookmark the filtered view. Switch to the **Endpoint** view to group findings by HTTP method and route. Each group shows its issue count and severity distribution. Where reachability data is available, the group also shows the maximum call depth and number of call graphs. Expand an endpoint to review its associated findings. > [!WARNING] > > A reachable finding is not necessarily exploitable, and a finding without reachability data is not necessarily unreachable. See [Endpoint Reachability Analysis](/blast#endpoint-reachability-analysis) for the analysis workflow and limitations. ### Advanced Vulnerability Search Click the **Advanced** button on the project page to open the Advanced Vulnerability Search page and zero in on findings across every scan run. The view surfaces totals plus severity counts at the top, and you can expand any project to reveal its files, CWE badges, urgency levels, detection times, and other context without leaving the list. When content access control is enabled, the project and tag filters offer only projects you can access and tags from those projects. * **Filters**: Narrow results by Vulnerability Category, Urgency, Status, Fix Status, Scan Type, Project, Branch, policies, or other metadata. A Date Range (preset or custom) is required so the system knows which span of time to examine. * **Date reminder**: The interface highlights what’s missing if you try to run a search without selecting a date range, and keeps the controls disabled until you pick a preset or custom window. * **Results exploration**: Click any row to load more context in the side panel while keeping your active filters in place. This lets you review evidence, remediation guidance, and related scan details without disrupting the list. * **SCA and container findings**: Open inline package details, history, and reachability when available. Use **Open Full View** for the full finding page. * **IaC findings**: Change assignment and status from the search results, including on smaller screens. > ![Advanced search location](https://mintcdn.com/corgea/tZ_QwjgMonKKSEeb/images/project-settings/advanced_search_location.png?fit=max\&auto=format\&n=tZ_QwjgMonKKSEeb\&q=85\&s=d35724acf445d60e5b7779327072886c) > ![Advanced vulnerability search screen](https://mintcdn.com/corgea/1An8Zd0QcAI60XdO/images/project-settings/advanced_search.png?fit=max\&auto=format\&n=1An8Zd0QcAI60XdO\&q=85\&s=a4d6ba9206ee943d70f88ac2fe5579e4) # Quickstart Source: https://docs.corgea.app/quickstart Setup Corgea in less than 5 mins. ## 1. Register with Corgea Go to [corgea.app](https://www.corgea.app/) and register for a free account with Corgea. You will be onboarded through our setup flow that'll help you set up everything you need. ## 2. Add Your Project The first step is to add your project to Corgea. You can do this using the Corgea Dropsite, a web interface that allows you to easily upload your code and security reports. 1. Navigate to the Dropsite page by clicking the "Add Project" button in the Corgea dashboard. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/empty_projects.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=73bc2e03ae852e1b7dbb3eea90a9cd3a) 2. On the Dropsite page, you can choose from several options to add your project: * **Connect Your Repository (Recommended)**: Connect a configured source control integration, such as [GitHub](github), [GitLab](gitlab), [Azure DevOps](azure_devops), [Bitbucket](bitbucket), or [Harness](harness), directly to Corgea. * **Web Upload**: Upload a ZIP file containing your project's code. * **Add a Public Repository**: If your repository is publicly accessible, provide the URL. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/dropsite_add_project.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=9485d69a1856ecf518b80b3e0514e4c9) > [!TIP] > > Corgea is dedicated to maintaining the highest standards in privacy and security. > For more information about our security practices, please visit our [security documentation](security). > > If you'd like to test Corgea using opensource projects first, here are some great example vulnerable apps: > > * [JuiceShop](https://github.com/Corgea/juice-shop): Javascript & Typescript > * [NodeGOAT](https://github.com/OWASP/NodeGoat): Node.js > * [PyGoat](https://github.com/adeyosemanputra/pygoat): Python/Django > * [GoVWA](https://github.com/0c34/govwa): Go > * [RailGoat](https://github.com/smDahlgren/railgoat): Ruby on Rails > * [WebGoat.NET](https://github.com/Nova-8/Damm-Vulnerable-dotNet-Application): .Net ## 3. Scan Once your project is added, you have two options for processing a scan: * **Option 1**: BLAST Enabled If you have [**BLAST**](blast) enabled—Corgea’s AI-powered security scanner—you can initiate a scan directly within Corgea. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/blast-start-scan.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=8006abc227b4ea6355b7d54f52786c26) * **Option 2**: Upload 3rd-party Report If you are using another security tool, you can upload a scan report from that tool. Just select the report file (typically a JSON file) from your local machine and drop it into the upload box. ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/upload_report.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=ac858a4bdf28e8cc2e46552db583208a) After uploading, Corgea will process your project and report, and you’ll be redirected to the dashboard to view the analysis results. ## 4. Review Findings and Fixes 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 relevant coding patterns or best practices. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/false_positive.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=8163d9351fc1e80845f8c5459bf87550) For valid vulnerabilities, Corgea provides a proposed fix, along with an explanation of the issue and the reasoning behind the fix. ## 5. Apply Fixes You can apply the proposed fixes in several ways: * **Pull Request Integration**: Corgea can automatically create a pull request with the proposed fixes for your repository. * **IDE Integration**: Use the Corgea extension for VS Code, Cursor, Visual Studio 2022, or JetBrains IDEs to apply fixes directly within your integrated development environment (IDE). * **Manual Application**: Download the proposed fixes as a Git diff or a full file and apply them manually to your codebase. By following this workflow, you can seamlessly integrate Corgea into your development process, benefiting from AI-powered vulnerability detection, false positive reduction, and automated fix generation. # Reporting Source: https://docs.corgea.app/reporting Track scan activity, vulnerabilities, and developer insights across your organization. Reporting brings together scan activity and security outcomes so you can track trends, progress, and ownership. **Where to find reporting** * In the app sidebar, open `Reporting` to access: * `General` for security and developer insights * `Scans` for scan operations and PR policy status * `Aging` for vulnerability aging and overdue trend analysis (available when policies are enabled) **General reporting tabs** * `Code Vulnerabilities` shows unique vulnerability counts, category coverage, false positives, remediation progress, MTTR, and burn-down trends. In `Code Vulnerabilities`, `Fixed Issues Over Time` tracks unique findings by their first fix date, and `Open Findings by Classification` breaks down open findings by classification and severity. Reporting counts each finding once across repeated scans, using its latest detection in the selected scope. Use the status checkboxes in `Vulnerability Status Flow` to show or hide statuses; false positives are hidden by default. ![Code Vulnerabilities Reporting](https://mintcdn.com/corgea/zRpcJEEU2aJtqdsj/images/reporting/code_vulnerabilities_reporting.png?fit=max\&auto=format\&n=zRpcJEEU2aJtqdsj\&q=85\&s=e80b6c77a695e7628daa01be323eb750) * `Code Quality` highlights open vs fixed issues, severity distribution, categories, languages, and top projects. ![Code Quality Reporting](https://mintcdn.com/corgea/ckpc6Pjkusw8p4Ov/images/reporting/code_quality_reporting.png?fit=max\&auto=format\&n=ckpc6Pjkusw8p4Ov\&q=85\&s=c43cb45627b8f84b0c4df28570da71ed) * `SCA` summarizes dependency vulnerabilities by severity, ecosystem, package, and direct vs transitive impact. ![SCA Reporting](https://mintcdn.com/corgea/ckpc6Pjkusw8p4Ov/images/reporting/sca_reporting.png?fit=max\&auto=format\&n=ckpc6Pjkusw8p4Ov\&q=85\&s=9aaa9264af21ec07a54d4ae64fdf1541) * `IaC` breaks down infrastructure findings by severity, provider, service, rule, and IaC type. ![IaC Reporting](https://mintcdn.com/corgea/ckpc6Pjkusw8p4Ov/images/reporting/iac_reporting.png?fit=max\&auto=format\&n=ckpc6Pjkusw8p4Ov\&q=85\&s=3c44259ac84e51571699d99026d08778) * `Developer Insights` combines developer feedback and Corgea Agent usage trends, decisions, and active users. ![Developer Insights](https://mintcdn.com/corgea/ckpc6Pjkusw8p4Ov/images/reporting/developer_insights.png?fit=max\&auto=format\&n=ckpc6Pjkusw8p4Ov\&q=85\&s=03ab6f4050b6eb75083d868added466c) **Filters and time controls** * In `General`, use the searchable project, team, tag, and branch dropdowns to select multiple values. Click `Apply` in each dropdown to update the charts, or `Clear` to reset all filters. Select projects first to choose their scanned branches. * Values within one filter match any selected value; different filters apply together. Results include only projects you can access. Team membership includes directly linked projects and projects matching the team’s tags or repository URL patterns. * For time-series charts, choose a date range and group by day, week, or month. * Severity filters on supported charts let you focus on critical, high, medium, or low issues. **Scans reporting** * `Scans` focuses on operational visibility, including PR policy status, repositories covered, full scans, PR scans, and scan performance over time. ![Scans Reporting](https://mintcdn.com/corgea/ckpc6Pjkusw8p4Ov/images/reporting/scans_reporting.png?fit=max\&auto=format\&n=ckpc6Pjkusw8p4Ov\&q=85\&s=b7a4e627ae8e1da2dcf293886862a090) **Aging report** * The aging report highlights overdue **code and dependency** issues, average age, and where risk is accumulating by project and assignee. * Assign issues from the issue details pages so overdue breakdowns and SLA emails reach the right owner. * Configure SLAs in [SLA Management](sla_management). # Dependency Scanning (SCA) Source: https://docs.corgea.app/sca Dependency Scanning, also known as Software Composition Analysis (SCA), automatically identifies known security vulnerabilities in your project's third-party dependencies and libraries. It scans dependency manifest files (like `package.json`, `requirements.txt`, `pom.xml`) and provides detailed vulnerability information including CVE identifiers, CVSS scores, and remediation guidance. ## Overview * **What it Does**: Dependency Scanning, also known as Software Composition Analysis (SCA), automatically identifies known security vulnerabilities in your project's third-party dependencies and libraries. It scans dependency manifest files (like `package.json`, `requirements.txt`, `pom.xml`) and provides detailed vulnerability information including CVE identifiers, CVSS scores, and remediation guidance. * **Who it's For**: This feature is designed for security teams, developers, DevOps engineers, and anyone responsible for maintaining secure software applications. It's particularly valuable for teams managing projects with numerous third-party dependencies who need to stay informed about security vulnerabilities that could impact their applications. ## Key Features and Benefits * **Comprehensive Ecosystem Coverage**: Scans dependencies across 25+ programming languages and ecosystems including Python, JavaScript/Node.js, Java, Go, Ruby, PHP, C#, Swift, and many more > **View All Vulnerability Data Sources** > > * **Authoritative Data Sources**: Leverages multiple trusted vulnerability databases including: > * GitHub Advisory Database (CC-BY 4.0) > * PyPI Advisory Database (CC-BY 4.0) > * Go Vulnerability Database (CC-BY 4.0) > * Rust Advisory Database (CC0 1.0) > * Global Security Database (CC0 1.0) > * OSS-Fuzz (CC-BY 4.0) > * Rocky Linux (BSD) > * AlmaLinux (MIT) > * Haskell Security Advisories (CC0 1.0) > * RConsortium Advisory Database (Apache 2.0) > * OpenSSF Malicious Packages (Apache 2.0) > * Python Software Foundation Database (CC-BY 4.0) > * Bitnami Vulnerability Database (Apache 2.0) > * Ubuntu (GPL v3) > * And many more authoritative sources * **Rich Vulnerability Intelligence**: Provides detailed vulnerability information including: * CVE identifiers and alternative vulnerability IDs * CVSS scores and severity ratings (Critical, High, Medium, Low) * Affected package versions and available fixes * Detailed vulnerability descriptions and references * Advisory links from sources such as GitHub Advisory Database, NVD, and vendor security advisories when available * Publication dates and external links * **Smart Scanning Logic**: Automatically detects when dependency files are present and optimizes scanning performance ## Setup Instructions > [!NOTE] > > Project must contain at least one supported dependency file and appropriate permissions to run security scans. ### Configuration Steps **1. Verify Dependency Files** Ensure your project contains supported dependency files: **Python** ```text theme={null} requirements.txt Pipfile Pipfile.lock pyproject.toml poetry.lock ``` **JavaScript/Node.js** ```text theme={null} package.json package-lock.json yarn.lock pnpm-lock.yaml ``` **Java** ```text theme={null} pom.xml build.gradle build.gradle.kts gradle.lockfile ``` **Go** ```text theme={null} go.mod go.sum ``` **Ruby** ```text theme={null} Gemfile Gemfile.lock ``` **PHP** ```text theme={null} composer.json composer.lock ``` **C#** ```text theme={null} *.csproj packages.config ``` **Swift** ```text theme={null} Package.swift Package.resolved ``` **2. Configure Scan Scope** Choose whether to include dependency scanning in full or partial scans **3. Set Up Notifications** Configure how you want to be notified of new vulnerabilities ## Usage Guide > [!NOTE] > > Viewing scan dependencies, downloading SBOM files, and exporting dependency CSVs require the **View SCA Issue** permission. If Project Access Control is enabled, you must also have access to the project. ### Key Workflows 1. **Automatic Detection**: The system automatically identifies dependency files in your project directory 2. **Comprehensive Scanning**: Analyzes all supported dependency files and cross-references against vulnerability databases 3. **Vulnerability Processing**: Processes scan results and enriches with additional security intelligence 4. **Issue Creation**: Creates trackable security issues for each vulnerability found 5. **Reporting**: Generates comprehensive vulnerability reports with actionable remediation guidance ### Dependencies View Filters ![Dependencies View](https://mintcdn.com/corgea/Ol14XvOQ0I7r7nLK/images/dependencies/dependencies_view.png?fit=max\&auto=format\&n=Ol14XvOQ0I7r7nLK\&q=85\&s=407616b72ca6c9419a9d4c7ae9ff35e3) Use filters on the Dependencies view to narrow SCA results: * **Search**: Find issues by CVE, package name, or summary * **Severity**: Focus on Critical, High, Medium, or Low findings * **SLA Status**: Focus on dependency issues that are overdue or escalated when an SCA SLA applies * **Ecosystem**: Limit results to a specific package ecosystem * **Project**: Filter to a specific project by name (shows only projects you can access) * **License**: Filter by dependency license * **Dependency Type**: Show direct, transitive, dev, or optional dependencies * **Reachability**: Show issues that are reachable, unreachable, unused, or still being analyzed (see [Reachability Analysis](#reachability-analysis)) * **Fix Available**: Show only issues with a known fix **Scans Affected** counts the distinct scans in which a vulnerability was detected, even when the same scan finds it in multiple packages or manifests. ### Export Dependencies to CSV Click **Export CSV** on the Dependencies view to download the results that match your current search and filters. The export includes package and vulnerability details, dependency type and reachability, project and branch, and the affected manifest path. When Project Access Control is enabled, the export includes only projects you can access. ### Transitive Dependencies Most vulnerabilities in modern projects live in **transitive** dependencies — packages you never added directly, but that were pulled in by the packages you did add. Corgea resolves the full dependency graph so you can see exactly what your application depends on and why. #### Dependency Types In scan results, package groups include badges that show where a vulnerable dependency comes from: * **Direct**: The vulnerable package is a direct dependency declared in your manifest (for example, `package.json` or `pom.xml`). * **Transitive**: The vulnerable package is pulled in indirectly through another dependency. * **Dev**: The vulnerable package is used as a development dependency (build, test, or tooling) rather than at runtime. * **Optional**: The vulnerable package is marked as an optional dependency. On the SCA issue details page, the dependency type is shown alongside issue details. A **Sub-dependencies** badge is shown when the selected package has nested dependencies. #### How the Dependency Graph Is Built Corgea builds the dependency tree by combining the packages you declare with the packages your build actually resolves: 1. **Direct dependencies** are read from your manifest files (`package.json`, `pom.xml`, `requirements.txt`, `go.mod`, `Gemfile`, and others). 2. **Transitive dependencies** are resolved from lock files (such as `package-lock.json`, `yarn.lock`, `poetry.lock`, `go.sum`) and a generated Software Bill of Materials (SBOM), which capture the exact resolved versions and their parent-child relationships. 3. When a lock file is missing, Corgea attempts to **generate one automatically** for supported ecosystems (for example, resolving Python or .NET dependencies) so transitive packages can still be analyzed. Each dependency records the **parent** that introduced it and the **root direct dependency** it traces back to, which lets Corgea show the complete path from your manifest to the vulnerable package. #### Dependency Tree View The Dependencies view can render your dependencies as a collapsible **tree**, so you can expand a direct dependency to see everything it pulls in: ```text theme={null} express@4.17.1 (direct) ├── lodash@4.17.15 (transitive) └── qs@6.7.0 (transitive) └── side-channel@1.0.4 (transitive) ``` Searching in the tree view highlights matching packages and keeps their ancestors visible, so you can always see *why* a vulnerable package is present. For very large projects (more than \~10,000 dependencies), the tree view is not rendered for performance reasons; use the list and search views instead. In a scan's **Dependencies** dialog, direct dependencies appear before transitive dependencies. License badges identify each dependency's detected licenses, and the license dropdown can be combined with search, dependency-type filters, and either the list or tree view. ### Supported Ecosystems > **View All 25+ Supported Ecosystems** > > The dependency scanning feature supports the following ecosystems: > > * **AlmaLinux** - Enterprise Linux packages > * **Alpine** - Alpine Linux packages > * **Android** - Android app dependencies > * **Bitnami** - Bitnami application packages > * **crates.io** - Rust packages > * **Curl** - cURL library vulnerabilities > * **Debian GNU/Linux** - Debian packages > * **Git** - Git repositories (including C/C++) > * **GitHub Actions** - GitHub Action workflows > * **Go** - Go modules and packages > * **Haskell** - Haskell packages > * **Hex** - Elixir packages > * **Linux kernel** - Linux kernel vulnerabilities > * **Maven** - Java Maven dependencies > * **npm** - Node.js packages > * **NuGet** - .NET packages > * **OSS-Fuzz** - Google's continuous fuzzing service > * **Packagist** - PHP packages > * **Pub** - Dart packages > * **PyPI** - Python packages > * **Python** - Python language vulnerabilities > * **R** - R packages (CRAN and Bioconductor) > * **Rocky Linux** - Rocky Linux packages > * **RubyGems** - Ruby packages > * **SwiftURL** - Swift packages > * **Ubuntu OS** - Ubuntu packages ### Multi-Ecosystem Project Example ```text Enterprise Application Structure theme={null} Enterprise Application: ├── backend/ │ ├── requirements.txt ✓ Python dependencies │ ├── pom.xml ✓ Java dependencies │ └── go.mod ✓ Go dependencies ├── frontend/ │ ├── package.json ✓ Node.js dependencies │ └── package-lock.json ✓ Lock file ├── mobile/ │ └── Gemfile ✓ Ruby dependencies └── infrastructure/ └── docker-compose.yml ✓ Container dependencies ``` ### Vulnerability Severity Breakdown > [!WARNING] > > **Critical**: Immediate action required, potential for complete system compromise * **High**: Should be addressed promptly, significant security impact * **Medium**: Should be addressed in regular maintenance cycles * **Low**: Minor issues that can be addressed when convenient ## Reachability Analysis A vulnerable package in your dependency tree does not always mean your application is actually exposed. Reachability analysis helps you prioritize by determining whether a vulnerability can actually be triggered by your code. For each vulnerable **direct** dependency, Corgea answers two questions: 1. **Is the package used?** Corgea looks for imports and usages of the package in your code. A package that is declared but never imported carries much lower risk. 2. **Is the vulnerable function reachable?** For packages that are used, Corgea analyzes whether your code actually calls the specific functions affected by the vulnerability. Corgea treats utility libraries and frameworks differently. For **utility libraries**, it can look for direct calls to the vulnerable functions. For **frameworks** — where the vulnerable code runs deep inside the framework's own internals rather than through a function you call directly — reachability is reported as *unsure*, because a definitive answer isn't possible from your code alone. > [!NOTE] > > Reachability analysis runs on direct dependencies. Vulnerabilities in transitive dependencies are reported and can be fixed (see [Fix Recommendations](#fix-recommendations)) but are not individually reachability-analyzed. ### Reachability States Each analyzed issue resolves to one of the following states, which you can also use as filters on the Dependencies view: * **Reachable**: Your code calls the vulnerable functionality. These are the highest priority — especially for direct dependencies. * **Unreachable**: The package is used, but the vulnerable functions are not called. * **Unused**: The package is declared but not used in your code. * **Analyzing**: Reachability analysis for the issue is still in progress. ### Reachability Visualization For reachable issues, Corgea can render the path from your application's entry points to the vulnerable code — showing how execution flows from **endpoints** through intermediate **functions** to the **vulnerable** function. This makes it easy to understand and validate exactly why an issue is reachable. ## Fix Recommendations When a fix is available, Corgea recommends the **nearest fixed version** — the lowest version that resolves the vulnerability — shown alongside the version you currently have installed. Recommending the nearest safe version keeps the upgrade as small as possible and reduces the chance of breaking changes. For **direct** dependencies, you can apply the fix by updating the version in your manifest. For **transitive** dependencies, you often cannot bump the version directly because it is controlled by a parent package. In these cases, Corgea surfaces the **dependency path** and the **parent dependency** you need to upgrade so the fixed transitive version is pulled in. See [Transitive Dependencies](#transitive-dependencies) for how the dependency path is built. > [!NOTE] > > Fix recommendations for dependencies are guidance for how to remediate. Review upgrades for compatibility before applying them. ### Tracking issues across upgrades Corgea keeps triage decisions attached to the same package and advisory in a manifest when the installed or recommended fixed version changes between scans. This prevents routine dependency upgrades from resetting an issue's status. For example, accepted-risk and false-positive decisions carry forward to the next scan; an expired accepted-risk decision does not. If an issue marked as fixed is detected again, it reopens. ## License Scanning During dependency scanning, Corgea captures the **software license** associated with each dependency, giving you visibility into the licenses present across your project. Licenses are surfaced in two ways: * **License filter**: On the Dependencies view, filter issues by a specific license (see [Dependencies View Filters](#dependencies-view-filters)). * **CSV export**: License information is included when you [export dependencies to CSV](#export-dependencies-to-csv). > [!NOTE] > > License scanning provides a license inventory for visibility and reporting. To enforce denied licenses or license families in pull requests or CI, create a [License Compliance blocking rule](blocking_rules#rule-types). ## Container Image Scanning Corgea also scans the container images your project depends on, identifying vulnerabilities in base operating system packages and other software installed within image layers. Images are automatically discovered from `Dockerfile` and Docker Compose files — no configuration required. For details on discovery, supported registries, and limits, see [Container Image Scanning](/container-scanning). ## Malicious Package Detection As part of dependency scanning, Corgea flags known **malicious and compromised packages** — such as typosquats, hijacked releases, and backdoored versions — using the OpenSSF Malicious Packages database and related advisory feeds. For details, see [Malicious Package Detection](/malware-scanning). ## Private Package Registries If your projects depend on **internal packages** published to a private feed, Corgea can authenticate to that registry during a scan and resolve those packages along with everything they pull in. Without it, internal packages cannot be opened, so their transitive dependencies — and any vulnerabilities inside them — are not analyzed. Supports Maven, PyPI, and NuGet. For details, see [Private Package Registries](/private-package-registries). ## Best Practices > [!TIP] > > Enable automatic scanning to catch new vulnerabilities as they are disclosed in real-time. * **Regular Scanning**: Enable automatic scanning to catch new vulnerabilities as they are disclosed * **Dependency Updates**: Promptly update dependencies when fixes are available for identified vulnerabilities * **Severity Prioritization**: Focus on addressing Critical and High severity vulnerabilities first * **Risk Assessment**: Evaluate whether vulnerabilities actually affect your application's attack surface * **Dependency Hygiene**: Regularly review and remove unused dependencies to reduce attack surface * **Version Pinning**: Use specific version numbers in dependency files for consistent scanning results * **Monitoring**: Set up alerts for new vulnerabilities discovered in your dependencies * **Documentation**: Maintain records of accepted risks and remediation decisions ## Troubleshooting > **No vulnerabilities found but dependencies are present** > > **Solution**: Verify that dependency files are in supported formats and contain valid package information > > **Check**: Ensure dependency files are not corrupted or contain syntax errors > **Scan results seem incomplete** > > **Solution**: Check that all dependency files are included in the scan scope > > **Check**: Verify that dependency files are properly formatted and accessible > **False positive vulnerabilities reported** > > **Solution**: Review vulnerability details to determine if they actually affect your application > > **Check**: Consider the specific usage patterns and attack vectors in your application > **Scan performance is slow** > > **Solution**: This is normal for large projects with many dependencies > > **Check**: Consider using incremental scanning for changed files only # Scheduled Scans Source: https://docs.corgea.app/scheduled-scans Automatically run security scans on a recurring schedule > [!NOTE] > > **Prerequisite** You have a connected repository (GitHub, GitLab, Azure DevOps, or Harness) and Scheduled Scans enabled on your plan. See [Corgea pricing](https://corgea.com/pricing/) to enable this feature. Scheduled Scans let you automatically trigger security scans across your projects on a recurring cadence — without manual intervention. You can scope scans to specific projects, tags, or teams, choose which scan types to run, and control the frequency from daily to yearly. ## Viewing Scheduled Scans Open **Policies → Scheduled Scans** in the sidebar. The **Security Scan Schedules** page lists all configured schedules for your organization, along with their status, frequency, scope, and last-run outcome. ![Security Scan Schedules page listing schedules with Name, Scope, Scan Types, Frequency, Status, and Last run columns, plus a banner reporting projects that appear in more than one active schedule](https://mintcdn.com/corgea/ykitTppWs5yMvech/images/scheduled_scans/scheduled_scans_list_page.png?fit=max\&auto=format\&n=ykitTppWs5yMvech\&q=85\&s=f5928e9af893c49f7653d0571a44033c) Each row shows: * **Name** — a label for the schedule (plus an overlap link when the same project appears on another active schedule) * **Scope** — how many projects are targeted, plus the project names when three or fewer are selected, the tag names for a tag-scoped schedule, or the team names for a team-scoped schedule * **Scan Types** — which scanners will run (e.g., BLAST, Secrets, PII) * **Frequency** — how often the scan runs * **Status** — whether the schedule is active or paused * **Last run** — the outcome of the most recent attempt, shown in the schedule's timezone | Last run | Meaning | | - | - | | **Never run** | The schedule has not completed a run yet | | ✓ timestamp | The last run succeeded | | **Running…** | A run is in progress (the list updates as it finishes) | | **Failed** | One or more projects failed — select the badge for per-project reasons | | **Retry** | The run was skipped to avoid a duplicate scan — select the badge for details, then try **Run Now** again | From the list you can **edit**, **pause/resume**, **run immediately**, or **delete** any schedule. ## Overlapping coverage When the same project is included in more than one **active**, project-scoped schedule, Corgea surfaces that overlap so you can see where scans may run more often than expected. * A banner at the top of the list shows how many projects appear in more than one active schedule * Affected schedules show an **overlap** link under the name — select it to see which projects are shared and which other schedules include them ![Overlapping coverage modal for a schedule, listing each shared project alongside the other active schedule that also includes it](https://mintcdn.com/corgea/ykitTppWs5yMvech/images/scheduled_scans/scheduled_scan_overlapping_coverage_modal.png?fit=max\&auto=format\&n=ykitTppWs5yMvech\&q=85\&s=6703487db8bdf114ebdac484900f3a9b) > [!NOTE] > > Overlap detection currently applies to **project-scoped** schedules only. Tag- and team-scoped coverage is not included in overlap warnings yet. When you create or edit a project-scoped schedule, Corgea also warns inline if a selected project already belongs to another active schedule: ![Edit Schedule page with an inline Overlapping coverage warning under Select Projects, noting that a selected project is also included in another active schedule](https://mintcdn.com/corgea/ykitTppWs5yMvech/images/scheduled_scans/edit_scheduled_scan_page.png?fit=max\&auto=format\&n=ykitTppWs5yMvech\&q=85\&s=6b4589140b30c5ae5ac8a62ffd5616c9) ## Creating a Scheduled Scan Click **Create Schedule** to open the schedule creation form. **1. Name the schedule** Give your schedule a descriptive name. If left blank, Corgea will auto-generate one based on the scope and frequency. **2. Select the scope** Choose how to target projects: * **Projects** — pick one or more specific repositories from your connected integrations * **Tags** — target all projects that share one or more labels (useful for scanning a service tier, team, or environment) * **Teams** — target projects that are assigned to one or more selected teams > [!TIP] > > Using tags makes it easy to automatically include new projects in a schedule as your organization grows — no need to update the schedule manually. **3. Choose scan types** Select which scanners to run. Multiple scan types can be combined in a single schedule. | Scan Type | What it detects | | - | - | | **BLAST** | Security vulnerabilities in application code | | **Policy** | Violations of your custom PolicyIQ rules | | **PII** | Personally identifiable information exposure | | **Dependencies** | Vulnerable third-party packages (SCA) | | **Secrets** | Hardcoded credentials and API keys | | **Malicious** | Malicious code patterns | **Dependencies** schedules report reachability status for each finding when reachability analysis is enabled on your plan. This applies to every dependency scan, not just scheduled ones. **4. Set the frequency** Select how often the scan should run: | Frequency | Description | | - | - | | **Daily** | Runs every day | | **Weekly** | Runs on a specific day of the week | | **Monthly** | Runs on a specific day of the month (or the last day) | | **Quarterly** | Runs on a specific day each quarter (January, April, July, October) | | **2×/Year** | Runs twice a year on two months you specify | | **Yearly** | Runs once a year on a specific month and day | > [!NOTE] > > **Daily** is only offered if daily scheduled scans are enabled on your plan. If you do not see it, the other frequencies are still available. Last-run timestamps use the schedule's timezone so they line up with the Frequency column, not your [account timezone](/user_management#timezone-settings). A weekly Tuesday schedule still shows Tuesday even when those timezones disagree. **5. Save and activate** Click **Create**. The schedule is immediately set to **active** and Corgea will calculate the next run time based on your chosen frequency. When editing an existing schedule, the same button is labeled **Save**. ## Running a Scan Immediately You can trigger any schedule to run right away by selecting **Run Now** from the schedule's actions menu. The **Last run** column shows **Running…** while the run is in progress, then updates to a success timestamp, **Failed**, or **Retry**. Corgea enforces a 24-hour cooldown after a **successful** run or while a run is already active. Failed attempts and retryable skips can be retried immediately with **Run Now**. If a run does not finish (for example, an interrupted attempt), the schedule stays retryable instead of remaining blocked for a full 24 hours — select **Run Now** again. ## Last run failures When **Last run** shows **Failed**, select the badge to open **Last run failures**. The modal lists each affected project and the reason it failed: ![Last run failures modal listing each failed project with its reason, such as a branch not found or repository access denied](https://mintcdn.com/corgea/ykitTppWs5yMvech/images/scheduled_scans/last_run_failures_modal.png?fit=max\&auto=format\&n=ykitTppWs5yMvech\&q=85\&s=3078e957e27d7edd0ce4edeb8d5ae9d5) When **Last run** shows **Retry**, the same modal explains that the run was skipped because a scan for that commit was already in progress or being registered: ![Last run failures modal for a Retry outcome, explaining that a scan for the commit was already in progress so the scheduled run was skipped to avoid a duplicate](https://mintcdn.com/corgea/ykitTppWs5yMvech/images/scheduled_scans/retry_run_last_run_failures_modal.png?fit=max\&auto=format\&n=ykitTppWs5yMvech\&q=85\&s=475e7e7ef6fd004573e628b40a79d264) ## Managing Schedules ### Pausing and Resuming Toggle a schedule between **active** and **paused** from the list view. Paused schedules will not run automatically until reactivated, and they are excluded from overlap warnings. ### Editing Click **Edit** on any schedule to modify its name, scope, scan types, or frequency. Changes take effect on the next scheduled run. Overlap warnings update as you change the project selection. ### Deleting Click **Delete** to permanently remove a schedule. This does not affect scans that have already been executed. ## How Scans Are Executed When a scheduled scan runs, Corgea: 1. Resolves the target projects (directly selected, or matched via tags or teams) 2. Downloads the latest code from the configured branch (defaults to the project's default branch) 3. Runs the selected scan types against the code 4. Creates a scan record linked to the schedule run The scan stays on the project the schedule selected. When several projects share the same repository URL, the run does not attach to a different project that uses that URL. Corgea also avoids starting a duplicate scan for the same project and commit when another run is already covering that commit. In that case the schedule shows **Retry** instead of reporting a successful run. You can view results from scheduled scans the same way as any other scan — through the [Fixes](fixes) and project dashboards. Each scheduled scan result is labeled with the schedule name for easy identification. ## Daily Report A daily report covers scheduled scans completed in the last 24 hours, including runs with no new findings. It shows new open code findings since each project’s previous scan and open finding totals by category, matching the scan results page. No report is sent when no scheduled scans completed. The **Scheduled Scan Report** email is on by default. Company admins can change the default or limit recipients to selected teams, and users can override their email preference. Subscribed webhooks receive the report independently of email preferences. See [Notifications](/notifications#daily-scheduled-scan-report). ## Troubleshooting > **Scheduled Scans is not visible** > > Scheduled Scans requires a compatible plan and must be enabled for your organization. Contact your Corgea account team to enable it. > **No projects found for schedule** > > If a schedule has scope type **Projects** but no projects are selected, scope type **Tags** but no projects match the configured tags, or scope type **Teams** but no projects are assigned to the selected teams, the scan will be skipped. Edit the schedule to verify the scope configuration. > **Scan failed for a project** > > The schedule list shows **Failed** if one or more project scans fail. Select the badge to view the failure reason for each affected project. Common causes: > > * The repository is not accessible (check your integration credentials) > * The configured branch does not exist > * The project has no connected integration > > Check the reported reason, correct the project or integration configuration, and select **Run Now** to retry. Failed attempts do not need to wait for the 24-hour cooldown. > **A project is no longer included in scheduled runs** > > When the same project fails the same schedule three times in a row for a persistent reason, such as a missing branch or expired credentials, Corgea emails the project owners and company admins and stops including that project in the schedule's automatic runs. Other projects on the schedule continue to run as normal. > > Fix the underlying problem, then use **Run Now** to retry — **Run Now** always attempts every project in scope, including skipped ones. The project is included in automatic runs again once a scan succeeds for it. See [Notifications](notifications#scheduled-scan-consecutive-failures) for the email and its delivery settings. > **Last run shows Retry** > > Corgea prevents duplicate scans for the same project and commit. If another run is already in progress or still registering the scan, the schedule shows **Retry** instead of reporting a successful run. Select the badge for the skip reason, wait briefly, then select **Run Now** again. > **Run Now is blocked** > > If the schedule completed successfully within the last 24 hours or is still running, **Run Now** remains blocked. Check the **Last run** column before retrying. > > Failed runs and **Retry** outcomes are retryable immediately. > **Projects appear in more than one schedule** > > The list banner and per-schedule **overlap** links highlight projects that are selected on multiple active, project-scoped schedules. Review the overlapping coverage modal, then edit one of the schedules if you want to reduce duplicate coverage. Overlap is a warning only — schedules still run as configured. # Secret Scanning Source: https://docs.corgea.app/secret-scanning Detect and secure hardcoded secrets in your codebase ## Overview Secret scanning is a critical security capability within Corgea's AI-native SAST that identifies hardcoded credentials, API keys, tokens, and other sensitive information in your codebase. By detecting secrets before they reach production, you can prevent unauthorized access, data breaches, and compliance violations. Unlike traditional secret scanners that rely solely on pattern matching, Corgea's secret scanning uses a combination of pattern matching, entropy analysis, and AI-powered contextual understanding to minimize false positives while ensuring comprehensive coverage. ## How It Works Corgea's secret scanner analyzes your entire codebase to identify potential secrets through multiple techniques: **1. Pattern Matching** Identifies known secret formats using an extensive library of patterns for popular services and platforms. **2. Entropy Analysis** Detects high-entropy strings that may indicate randomly generated keys, tokens, or passwords. **3. Contextual Understanding** Uses AI to understand the context around potential secrets, reducing false positives from test data, examples, or placeholders. ## Supported File Types Corgea's secret scanner supports a comprehensive range of file types across different languages and frameworks: | Language/Framework | Extensions | File Types | | - | - | - | | **Python** | `.py` | Python source files | | | `.toml`, `.ini`, `.txt`, `.cfg` | Configuration files (pyproject.toml, setup.cfg, etc.) | | **Ruby** | `.rb` | Ruby source files | | | `.yml`, `.yaml` | Configuration files (config files, Rails configs) | | **JavaScript/Node.js** | `.js`, `.jsx`, `.mjs` | JavaScript source files | | | `.json`, `.env`, `.config` | Package.json, environment files, configs | | **TypeScript** | `.ts`, `.tsx` | TypeScript source files | | | `.json`, `.config` | tsconfig.json, configuration files | | **C#/.NET** | `.cs`, `.cshtml` | C# source and Razor files | | | `.xml`, `.config`, `.json` | App.config, web.config, appsettings.json | | **Go** | `.go` | Go source files | | | `.toml`, `.yaml`, `.yml`, `.env` | Configuration files | | **Java** | `.java`, `.jsp`, `.jspf`, `.tag` | Java source and JSP files | | | `.properties`, `.xml`, `.gradle`, `.yaml`, `.yml` | application.properties, pom.xml, build.gradle, configs | | **PHP** | `.php` | PHP source files | | | `.ini`, `.xml`, `.yaml`, `.yml`, `.env`, `.json` | php.ini, configs, environment files | | **C/C++** | `.c`, `.cpp`, `.cc`, `.cxx`, `.c++` | C/C++ source files | | | `.conf`, `.config`, `.cfg`, `.ini` | Configuration files | | **Kotlin** | `.kt`, `.kts` | Kotlin source files | | | `.gradle`, `.properties`, `.xml`, `.json` | Build files and configs | | **Swift** | `.swift` | Swift source files | | | `.json`, `.yaml`, `.yml`, `.toml` | Package.swift configs | | **Rust** | `.rs` | Rust source files | | | `.toml`, `.env` | Cargo.toml, environment files | | **Universal Config Files** | `.txt`, `.conf`, `.config`, `.cfg`, `.ini` | Generic configuration files | | | `.env` | Environment variables (all languages) | | | `.json`, `.yaml`, `.yml`, `.xml`, `.toml` | Common configuration formats | ## Detected Secret Types Corgea's secret scanner can detect a wide range of secret types across different platforms and services: > **Cloud Provider Credentials** > > * AWS Access Keys and Secret Keys > * Google Cloud API Keys > * Azure Storage Account Keys > * Azure Service Principal Credentials > * DigitalOcean Access Tokens > * Alibaba Cloud Access Keys > **API Keys and Tokens** > > * API keys and tokens > * Authentication credentials > * Personal access tokens > * OAuth tokens > * Bearer tokens > * Service account tokens > **Database and Storage** > > * Database connection strings > * MongoDB URIs > * PostgreSQL connection strings > * MySQL credentials > * Redis passwords > * Storage access keys > **Cryptographic Material** > > * Private keys (RSA, SSH, PGP) > * SSL/TLS certificates > * Encryption keys > * JWT secrets > * Signing keys > **Payment and Financial** > > * Payment gateway credentials > * Stripe API keys > * PayPal credentials > * Square access tokens > **Communication Services** > > * Slack tokens and webhooks > * Twilio API keys > * SendGrid API keys > * Mailgun credentials > **Development Tools** > > * GitHub tokens > * GitLab tokens > * NPM tokens > * Docker registry credentials > * CI/CD secrets > **Other Sensitive Data** > > * Internal endpoints > * Private URLs > * Environment variables with secrets > * Hardcoded passwords > * Authentication cookies ## Detection Results When secrets are detected, Corgea provides comprehensive information to help you understand and remediate the issue: > **Secret Type** > > Classification of the detected secret (e.g., AWS Access Key, API Token) > **Location** > > Exact file path and line number where the secret was found > **Security Impact** > > Assessment of the potential risk and impact of the exposed secret > **Remediation Guidance** > > Actionable steps to secure the secret properly ### Prevention Strategies **1. Pre-commit Hooks** Implement [pre-commit](cli#integrating-with-git-hooks) hooks to scan for secrets before code is committed to your repository. **2. Developer Training** Educate your team about the risks of hardcoded secrets and secure alternatives. **3. Code Reviews** Include secret scanning checks as part of your code review process. **4. Automated Scanning** Enable automated secret scanning in your CI/CD pipeline to catch secrets early. ## Integration with Development Workflow Secret scanning integrates seamlessly into your development workflow: > **Pull Request Scanning** > > Automatically scan pull requests for secrets before merging > **CI/CD Integration** > > Run secret scans as part of your continuous integration pipeline > **IDE Extensions** > > Get real-time feedback while coding with IDE integrations > **Scheduled Scans** > > Regular repository scans to detect secrets in existing code > **[Learn More](/blast)** > > Explore AI-native SAST for comprehensive vulnerability detection beyond secrets # Security Source: https://docs.corgea.app/security Corgea's Security and Privacy Standards ## Our Promise At Corgea, security and privacy is at the heart of everything we do. It is our belief that great software delivers value while maintaining the privacy and security of it’s users data. Our commitment to these principles is unwavering, and it's evident in every facet of our operations. We have designed Corgea with a foundational emphasis on safeguarding user data and ensuring the highest levels of reliability. The team behind Corgea brings a wealth of experience from previous roles where they built and managed highly scalable applications compliant with stringent regulations such as FedRamp, ITAR, HIPAA, PCI, and various data privacy standards. This collective expertise ensures that Corgea not only meets but often exceeds industry standards. In conclusion, Corgea is more than just a service; it's a testament to our unwavering commitment to security and privacy. Our users can rest easy knowing that their data is in capable and caring hands. Best Regards, Ahmad Sadeddin CEO of Corgea ## Security FAQ > **What happens to our code within Corgea’s system?** > > Protecting your intellectual property is our top priority. Corgea operates by storing only the code differences (diffs) necessary to facilitate fixes, handling them with industry-leading encryption standards during both storage and transmission. You own your data, and can always request deleting your data at anytime. > **What model does Corgea use to fix my code?** > > Corgea uses OpenAI selectively to fix insecure code combined with static code analysis techniques. > **Does Corgea or OpenAI utilize our proprietary data to enhance its AI models?** > > Your trust is paramount. Corgea is designed to respect your data’s confidentiality. We ensure that your data is not used to train or refine our models. > **Which 3rd parties do you share data with?** > > To provide adequate service, Corgea limits the number of 3rd parties that receive data and shares with the following 3rd parties only: > > * Amazon Web Services: used to host corgea instances, and databases. > * OpenAI or AzureOpenAI: used in aiding Corgea in fixing insecure code, and in part of the fix QA process. We maintain a ZDR (Zero Data Retention) with both. > * Sentry: for application performance monitoring and error tracking. > * Google Analytics: to track and report on website traffic and events. > * PostHog: product analytics and client error tracking. > **Does Corgea auto-merge the proposed fixes into our codebase?** > > Corgea empowers your team with full control. While we automate the creation of Pull-Requests (PRs), the choice to merge rests with your engineers, ensuring that every change aligns with your project’s objectives. For those who prefer manual integration, diffs are available for direct application within your preferred IDE. > **What measures does Corgea take to prevent prompt poisoning?** > > Corgea does not allow user inputs into our fixing prompts, and we leverage AI-security checks before any fix is issued. Coupled with mandatory human reviews during the PR process, we provide a balanced defense against prompt poisoning. > **How does Corgea ensure system security?** > > We are advocates for security, adhering to and often surpassing SOC 2 compliance benchmarks. Our systems are currently undergoing SOC 2 auditing to further validate our steadfast commitment to security. > **Is Corgea deployed as a Single-tenant or Multi-tenant application?** > > Corgea.app is a multi-tentant environment. We do offer enterprise customers single-tenant environment. Each customer gets a dedicated environment with separate compute and storage resources. These environments are siloed, ensuring no cross-communication or data leakage between customers. ## Security Controls ### Authentication and Session #### Password Policy Corgea's password policy is designed to prevent the use of weak passwords, which are a common vulnerability point in security systems. The policy includes several requirements: * Personal Information Dissimilarity: Passwords must not be too similar to the user's personal information. This prevents easy guessing of passwords based on known user data. * Minimum Length: Each password must contain at least 8 characters. Longer passwords generally equate to stronger security. * Common Password Restriction: Passwords that are commonly used or easy to guess are prohibited. This includes passwords like "123456", "password", or "qwerty". * Password Reuse Restriction: A new password cannot match any of the five most recently used passwords. * Numeric Restriction: Passwords that are entirely numeric are not allowed, as numeric-only passwords are often easier to crack. * Password Reset: Email's are required to verify a password change request. * Corgea uses uses the PBKDF2 algorithm with a SHA256 hash, a password stretching mechanism recommended by NIST. #### Account Policy Corgea's account policy is designed to prevent abuse and increase security: * Email accounts can only be used once. * User accounts are activated through email. * Corgea reserves the right to terminate a user's account and a company's account #### Rate Limiting Corgea implements a limit on the number of requests a user can make within a certain timeframe. This is crucial in mitigating distributed denial-of-service (DDoS) attacks and ensuring the system's availability for all users. #### Authentication Brute-Force Prevention This control is essential in safeguarding against attackers who attempt to gain unauthorized access by guessing passwords. After a certain number of failed login attempts, the account may be locked for a period of time, or the response time is deliberately slowed down. #### Malicious Requests Corgea uses a Web Application Firewall (WAF) that detects and mitigates malicious requests across all traffic. If any traffic is detected as suspicious, the WAF will intiatiate a Javascript challenge that the user must pass to access Corgea. #### Session Expiration Session expiration is a key aspect of session security in Corgea: * Inactivity Timeout: User sessions are automatically terminated after a period of inactivity. This time period is carefully chosen to balance security with user convenience. * Prevention of Unauthorized Access: This mechanism helps in preventing unauthorized access to a user's session, especially in scenarios where a user might forget to log out from a shared or public computer. * Re-authentication Requirement: After session expiration, users are required to re-authenticate to ensure that the session is resumed securely. ### Web Security #### Cross Site Scripting (XSS) Protection Measures to prevent attackers from injecting malicious scripts into web pages. Corgea escapes specific characters to prevent malicious input. #### Cross Site Request Forgery (CSRF) Protection Ensuring that requests made to a web application are from the authenticated user. CSRF protection works by checking for a secret in each POST request. This ensures that a malicious user cannot “replay” a form POST to your website and have another logged in user unwittingly submit that form. The malicious user would have to know the secret, which is user specific (using a cookie). #### SQL Injection Protection Safeguards against unauthorized database manipulations through SQL code injection. Queries in Corgea are protected from SQL injection since their queries are constructed using query parameterization. A query’s SQL code is defined separately from the query’s parameters. Since parameters may be user-provided and therefore unsafe, they are escaped by the underlying database driver. #### Clickjacking Protection Preventing attackers from tricking users into clicking on something different than what the user perceives. Corgea has clickjacking protection in the form of the X-Frame-Options middleware which in a supporting browser can prevent a site from being rendered inside a frame. #### Host Header Validation Host header validation is crucial to ensure that HTTP requests are directed to the intended domain. ### Data Security #### Data Collection Corgea's approach to data collection focuses on gathering essential information while maintaining user privacy and security. The types of data collected include: * Email Addresses: Used for account creation, communication, and notifications. * First and Last Names: Collected to personalize user experience and for identification purposes in account management. * IP Addresses: Gathered for security purposes, such as tracking login attempts and identifying potentially malicious activities. * Vulnerability Information from SAST/SCA Tools: Includes details of vulnerabilities identified in the code during Static Application Security Testing (SAST) and Software Composition Analysis (SCA). * Code: Source code from users necessary for the operation of Corgea's services, such as code reviews and vulnerability scans. * GitHub Access Tokens: Used to securely access repositories for code scanning and integration purposes. #### Data Encryption In-Transit & At-Rest Corgea ensures that all data, whether in transit or at rest, is securely encrypted: In-Transit Encryption: * Corgea redirects traffic from HTTP protocol (port 80) to HTTPS (port 443) * Utilizes AWS Certificate Manager (ACM) to manage and deploy SSL/TLS certificates. * Employs TLS 1.3, the latest and most secure version of the TLS protocol, ensuring that data transmitted over the internet is encrypted and secure from interception or tampering. At-Rest Encryption: * Implements Advanced Encryption Standard (AES) with a 256-bit key length for encrypting data at rest. * AES-256 is a robust encryption standard, widely recognized for its strength and effectiveness in protecting data from unauthorized access. * For licensed self-hosted deployments, Corgea encrypts issue data, fix data, IaC issue data, PDF exports, and fusion reports in configured file storage at rest. #### Data Backups To prevent data loss and ensure data availability, Corgea implements a comprehensive backup strategy: * Daily Backups: Automated daily backups to capture and store the latest data, ensuring minimal data loss in case of system failures or data corruption. * 30-Day Archive: Maintains a rolling 30-day archive of backups, providing a window for data recovery in case of delayed detection of data loss or corruption. * AWS S3 / RDS Backups: Utilizes Amazon S3 for secure and scalable storage of backup data. Employs Amazon RDS Backups for database backup and recovery, taking advantage of its automated backup capabilities and point-in-time recovery features. #### Non-Production environments Non-production environments do not contain production data ### SDLC Controls #### Security in SDLC Corgea has integrated security into every stage of the Software Development Life Cycle (SDLC) to ensure that security is not an afterthought but a fundamental aspect of development: * Threat Modeling during Design: In the design phase, threat modeling is conducted to identify potential security issues and create design strategies to mitigate these risks. * Secure Coding Practices: Developers are trained and encouraged to follow secure coding practices to minimize vulnerabilities in the code. * Regular Security Audits: Throughout the development process, regular security audits are performed to identify and rectify any security lapses. * Security Testing before Deployment: Prior to deployment, comprehensive security testing, including penetration testing and vulnerability assessments, is conducted to ensure the application is secure against known threats. #### Code-Reviews Corgea has instituted a rigorous code review process: * Mandatory Peer Reviews: All code changes undergo mandatory peer reviews. This process involves thorough examination by fellow developers to identify any code issues, including potential security vulnerabilities. * Checklists and Standards: Reviewers follow a checklist and adhere to established coding standards to ensure that nothing is overlooked during the review process. * Feedback and Iteration: Feedback from code reviews is used for immediate improvements and as a learning tool for future development. #### Supply-Chain Vulnerability Scanning during Code Merge Corgea takes supply chain security seriously, particularly during the integration of new code from external sources: * Automated Vulnerability Scanning: When new code is merged, automated tools scan for vulnerabilities that could be introduced from external libraries or dependencies. * Continuous Monitoring: Continuous monitoring and scanning of the code base to identify any vulnerabilities that might arise over time due to changes in the external code or libraries used. #### Secrets Scanning To protect sensitive data, Corgea employs automated secrets scanning: * Automated Detection: Tools are used to automatically scan the code repositories for unintended inclusion of secrets like passwords, API keys, and tokens. * Immediate Alerts: When secrets are detected, immediate alerts are generated for rapid response to secure the exposed data. #### SAST/SCA Code Scanning & Corgea for Security Fixes Corgea's approach to code scanning and security fixes includes: * Static Application Security Testing (SAST): This involves scanning the source code for potential security vulnerabilities that could be exploited. * Software Composition Analysis (SCA): SCA tools are used to analyze third-party components and open-source libraries for known vulnerabilities. * Automated Security Fixes: Corgea integrates tools that not only identify vulnerabilities but also suggest or implement security fixes automatically, reducing the time to remediation. ### Infrastructure #### Cloud Infrastructure Corgea leverages the power and flexibility of Amazon Web Services (AWS) for its cloud infrastructure needs. This choice provides a robust, scalable, and secure environment for hosting services and applications. #### Cloud Infrastructure Security Practices Corgea uses AWS security best practices, including VPCs, Security Groups, IAM roles, and will be conducting regular security assessments. #### Shared responsibility model of cloud security Corgea adheres to the AWS shared responsibility model, which delineates the security responsibilities between AWS and Corgea: * Security "Of" the Cloud: AWS is responsible for protecting the infrastructure that runs all the services offered in the AWS Cloud. * Security "In" the Cloud: Corgea's responsibility involves securing the content, platform, applications, systems, and networks they use on AWS. #### Network segmentation and isolation Corgea's approach to network segmentation and isolation is designed to enhance security and control: * Virtual Private Clouds (VPCs) and Subnets: By using VPCs and subnets, Corgea effectively segments its network, isolating different parts of its infrastructure for specific purposes. * Security Groups and Network ACLs: These are used to provide stateful and stateless filtering of traffic to and from resources. * Service Communication Controls: Ensuring that services within Corgea's infrastructure communicate only with authorized counterparts, thus reducing the risk of internal threats and external breaches. ### Access controls #### Access to Data Corgea enforces strict access controls to ensure that staff access to data is limited and monitored: * Restricted Data Access: Access to sensitive data is tightly controlled and is only permitted in specific circumstances, such as addressing production issues. This minimizes the risk of unauthorized data access or leaks. * Infrastructure Access Control: Access to Corgea’s infrastructure is managed through a corporate Virtual Private Network (VPN). Our VPN provides a secure and encrypted connection, ensuring that access to internal resources is restricted to authorized personnel only. * Role-Based Access Control (RBAC): Implementation of RBAC to ensure that employees only have access to the information and resources necessary for their job functions. #### Access Logs Corgea maintains comprehensive access logs to track and audit access to its servers: * WAF Logging: All server access is logged within our WAF. This includes information about who accessed the server, when the access occurred, and what actions were performed. * Audit and Review: Regular audits of access logs are conducted to identify any unusual or unauthorized access patterns. This helps in quickly identifying and responding to potential security incidents. * Transparency and Accountability: Keeping detailed access logs ensures transparency in access management and holds staff accountable for their actions within the infrastructure. # Security Design Reviews Source: https://docs.corgea.app/security-review Review design documents, PRDs, and specifications for security recommendations before implementation > [!NOTE] > > Security Design Reviews are currently in beta and must be enabled for your company. If you do not see Security Review in the sidebar, contact your Corgea administrator or Corgea contact. Security Design Reviews help teams assess PRDs, specifications, and design documents before implementation. Corgea analyzes the design against the selected project's code and context, then returns security recommendations that your team can accept, reject, or keep pending. Use a Security Design Review when you want to catch design-level security risks early, such as missing authentication or authorization requirements, unsafe data handling, weak cryptography or session management, risky third-party dependencies, API security gaps, or infrastructure concerns. ## Start a Review **1. Open Security Review** In Corgea, select **Security Review** from the sidebar. **2. Create a review** Click **New Review**. If this is your first review, the empty state may show **Start a review** instead. **3. Add design details** Enter a title and paste the design document, PRD, or technical specification into the **Design Document** field. The current beta supports the **Custom** document source. Confluence, Google Docs, and Notion sources are planned for a future release. **4. Add context** Use **Additional Context** for constraints, business requirements, architecture notes, or security expectations that are not already in the design document. **5. Select projects** Select one or more projects when the design maps to existing repositories. Project selection gives Corgea more context for the review. **6. Submit the review** Click **Start Review**. The review is created with a pending status and moves through processing until recommendations are available. ## Review Results The review detail page shows the original design document, additional context, selected projects, status, and security recommendations. Security recommendations include a category, criticality, status, title, and description. Recommendations are ordered by criticality so the highest-impact items appear first. Each recommendation is classified into one of the following categories: * **Authentication**: Sign-in flows, credential handling, and identity verification * **Authorization**: Access control and permission enforcement * **Input Validation**: Data validation and injection prevention * **Data Exposure**: Sensitive data handling and information disclosure * **Cryptography**: Encryption and key management * **Session Management**: Session tokens and lifecycle * **API Security**: API endpoints, rate limiting, and CORS * **Third-Party Risk**: External dependencies and integrations * **Infrastructure**: Deployment, networking, and infrastructure concerns Recommendation statuses: * **Pending**: The recommendation has not been triaged yet. * **Accepted**: The recommendation is relevant and should be addressed. * **Rejected**: The recommendation is not applicable for this design. Users with permission to update Security Review recommendations can accept, reject, or reset each recommendation from the review detail page. ## Review Statuses * **Pending**: The review has been submitted and is waiting to be processed. * **Processing**: Corgea is analyzing the design and selected project context. * **Completed**: Recommendations are available. * **Failed**: The review could not be completed. Review the error shown on the detail page or contact your Corgea administrator. ## Access Security Review access is controlled by your company's plan and user permissions. Users may need permission to view security reviews, create new reviews, or update recommendation status. # Settings Source: https://docs.corgea.app/settings Find and change every account, company, and automation setting from one place ## Overview Every setting in Corgea lives under **Settings**, organized into four categories: **Company**, **User Management**, **Automation**, and **Personal**. Each category groups the pages that belong together, so you no longer have to hunt through the sidebar to find where something is configured. ## Opening Settings Click **Settings** near the bottom of the sidebar. This always opens **Personal → Profile**, and from there you pick any section from the rail on the left. ![The Corgea sidebar expanded and collapsed, with Settings pinned at the bottom of both](https://mintcdn.com/corgea/L-24If3t2LOPrEXE/images/settings/sidebar_views.png?fit=max\&auto=format\&n=L-24If3t2LOPrEXE\&q=85\&s=6d1bfff89582f19bc51b0b096ed6c176) The sidebar groups collapse, but Settings stays pinned at the bottom. A company on a pilot plan also shows the remaining trial time. Two shortcuts are worth knowing: * **Search settings** at the top of the page (or ⌘K) jumps straight to a section by name. Searching "content" takes you to Content access, for example. * The theme toggle in the top-right corner switches between light and dark. On a narrow screen the rail collapses into a drawer you open from the header. ![The Settings page showing all four categories in the left rail](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/settings_overview.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=85f85ba581170914efa1d2521e4dd206) ## What You Can See The rail only lists sections you have access to. Which sections appear depends on your [role](/permission_groups) and your plan, so two people in the same company can see different rails. A user with no administrative permissions sees only the **Personal** category: ![Settings for a user without administrative permissions, showing only the Personal category](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/settings_non_admin.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=d12729e079b86fe278eaecf210fa73f7) ## Changes Save Automatically Settings pages save as you go. Toggle a switch or pick an option and Corgea persists it in the background, confirming with a brief **Saved** indicator. There are no **Save** buttons to click. There are three exceptions. The analytics consent controls on **Preferences** require an explicit **Save cookie preferences** click because they govern tracking consent. The token expiry on **API token** is applied with **Update Expiration**. The company-wide **Default Timezone** on **Users** is applied with **Save**. ## Personal Settings that apply to your own account only. ### Profile **Settings → Personal → Profile** ([open](https://www.corgea.app/settings/user/)) Your name, the email address you sign in with, your company, and your role. **Change password** sends a password reset link to your email. If you're a company admin, the **Company** field is editable here and renaming the company applies for everyone. Other users see the company name as read-only text. **Role** is always read-only and is set by your administrator. The **Release** card shows the Corgea version you're running, with a link to the [changelog](/changelog). ![The Profile page showing your details, editable company name, and read-only role](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/profile.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=7da6a19b2155b0f25a6ca721b3f70449) ### Preferences **Settings → Personal → Preferences** ([open](https://www.corgea.app/settings/user/preferences/)) ![The Preferences page with appearance, regional, and privacy controls](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/preferences.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=407fcb353e21caf911c6ba314b7a1467) | Setting | What it does | | - | - | | **Diff view** | Whether fixes open **Line by line** or **Side by side** by default | | **Fun mode** | Occasional celebratory flourishes in the interface | | **Timezone** | Overrides your company's default timezone for your account only. Leave it on **Company default** to follow whatever admins have set | | **Google Analytics** / **PostHog Analytics** | Analytics consent. Click **Save cookie preferences** to apply | Preferences apply to your account on every device you sign in from. ### Notifications **Settings → Personal → Notifications** ([open](https://www.corgea.app/settings/notifications/)) Which emails Corgea sends you. Each notification is set to **Inherit**, **On**, or **Off** — **Inherit** follows your company's default. See [Notifications](/notifications) for what each notification covers. ## Company ### Triage rules **Settings → Company → Triage rules** ([open](https://www.corgea.app/settings/company/triage-approvals/)) Company admins can require a second reviewer before a finding is marked **False positive** or **Accepted risk**. When enabled, the finding stays unchanged until a different reviewer approves the request. Use the approvals queue to review pending requests; reviewers need **Can approve or reject triage requests** plus change permission for every finding type in the request. ![The Triage rules page with False positive and Accepted risk on, and two auto triage rules](https://mintcdn.com/corgea/gXE6s3uSV4XQ0K2H/images/settings/triage_rules.png?fit=max\&auto=format\&n=gXE6s3uSV4XQ0K2H\&q=85\&s=aecf2cd18443c22cf898ed8a77c33603) Auto triage rules are available only when enabled for your company. Company admins manage them on this page, in **Auto triage rules**. Each rule matches a project name or repository URL with a case-insensitive glob (`*` matches anything, `?` matches one character). Rules run in list order. The first match that has not expired applies. When a scan detects an open SAST or SCA finding with no triage comment, that rule sets the status and comment. An **Accepted risk** rule also sets the expiry date, which must be in the future. This includes findings from earlier scans when detected again and, for SAST, untriaged findings carried forward by an incremental scan. Findings already in the rule’s status take its current comment and expiry on their next scan, even if a person set that status. Editing a rule therefore updates these findings on their next scan. Findings reopened because their accepted risk expired count as untriaged unless someone has triaged them since; other triage decisions are preserved. The rule applies directly without creating a triage approval request. ![Add auto triage rule dialog with Issue creation selected, an empty pattern, and an empty default status](https://mintcdn.com/corgea/K88fBiyu9iuG0Rzy/images/settings/auto_triage_rule_modal.png?fit=max\&auto=format\&n=K88fBiyu9iuG0Rzy\&q=85\&s=11050552c5520b3f4f4c125ca29ad4bf) ### Notification defaults **Settings → Company → Notification defaults** ([open](https://www.corgea.app/settings/company/notifications/)) The starting point for everyone in the company: which emails are on by default, and who receives them. Company admins only. See [Notifications](/notifications). ### Billing **Settings → Company → Billing** ([open](https://www.corgea.app/settings/company/billing/)) Your plan, usage, and invoices. Requires permission to view company details. ![The Billing page showing the current plan, seat usage, and plan comparison](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/billing.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=86c1aea36b9cdb1edbb8962c5944eec3) ## User Management ### Users **Settings → User Management → Users** ([open](https://www.corgea.app/settings/company/members/)) Invite, deactivate, and reactivate people, and assign their roles. Company admins also set the **Company name** and the company-wide **Default Timezone** on the **Company Settings** tab of this page. See [User Management](/user_management). ![The Users page listing everyone in the company with their roles and teams](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/users.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=c50f0b4fa8acd00f808f8d7316e9f21d) ### Roles **Settings → User Management → Roles** ([open](https://www.corgea.app/settings/company/groups/)) Roles and the permissions each one grants. Requires a plan that includes role management. See [Roles](/permission_groups). ![The Roles page listing each role and how many users it has](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/roles.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=41cb2241a9e5ecb814e76386d6b04c6b) ### Teams **Settings → User Management → Teams** ([open](https://www.corgea.app/settings/company/teams/)) Group people together and grant the whole team access to projects. Requires a plan that includes teams. See [Teams](/teams). ![The Teams page listing each team with its members and projects](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/teams.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=b9978dd974d7ebba5543ece05ce8530d) ### Content access **Settings → User Management → Content access** ([open](https://www.corgea.app/settings/company/content-access/)) Control which projects each person and team can see. Requires a plan that includes teams. See [Content Access Management](/content-access-management). ![The Content access page showing which users and teams can reach each project](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/content_access.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=603138a86c4a9567d058882b18b6c198) ## Automation ### Corgea Agent **Settings → Automation → Corgea Agent** ([open](https://www.corgea.app/settings/company/corgea-agent/)) Turn the agent on or off and configure how it triages and fixes issues. See [Corgea Agent](/agent). ![The Corgea Agent page with the Enable Corgea Agent toggle](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/corgea_agent.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=2c6c0cdf130b472c83f7866f545dfb3f) ### Integrations **Settings → Automation → Integrations** ([open](https://www.corgea.app/settings/integrations/)) Source control, ticketing, scanners, webhooks, package registries, and SAML SSO. Every integration guide in these docs starts here. ![The Integrations page with integrations grouped by category](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/integrations.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=c254c3028e4589521967e7dbf90037ff) ### API token **Settings → Automation → API token** ([open](https://www.corgea.app/settings/integrations/api-token/)) Your personal token for the [CLI](/cli), the IDE extensions, the [MCP server](/modelcontextprotocol), and the [public API](/api-reference/introduction). You can show, copy, and rotate the token, and set an expiration date for it. > [!WARNING] > > Rotating your token immediately invalidates the old one. Update it anywhere you've stored it — CI pipelines, IDE extensions, and local CLI configuration. ![The API token page with the masked token, show, copy, and rotate controls, and the expiration field](https://mintcdn.com/corgea/5JASlqJeHwNT0QGq/images/settings/api_token.png?fit=max\&auto=format\&n=5JASlqJeHwNT0QGq\&q=85\&s=f9b3837060499861aa5ab5f97bc6aa03) ## Where Things Moved If you have an old link or bookmark, it still works — Corgea redirects it to the new location. | Previously | Now | | - | - | | User Settings | **Personal → Profile** and **Personal → Preferences** | | Notifications, with a Company Defaults section at the top | **Personal → Notifications** and **Company → Notification defaults** | | `/billing/` | **Company → Billing** | | `/users` | **User Management → Users** | | Permission Groups | **User Management → Roles** | | `/teams` | **User Management → Teams** | | `/content-access` | **User Management → Content access** | | Agent Settings | **Automation → Corgea Agent** | | `/integrations/` | **Automation → Integrations** | | The API token section on the Integrations page | **Automation → API token** | # SLA Management Source: https://docs.corgea.app/sla_management Configure and manage Service Level Agreements (SLAs) for security issues > [!NOTE] > > SLA Management lets you define remediation and escalation timeframes by urgency for **SAST (code)** and **SCA (dependency)** findings. When deadlines are missed, Corgea can notify your team by **email** and/or **webhook** (`sla.violation` events). ## Who it's For Project managers, security teams, and developers who need predictable response times for open findings. ## Key Features > [!TIP] > > * Separate SLAs for **Code Vulnerability (SAST)** and **Dependency Vulnerability (SCA)** > * Configurable remediation and escalation timeframes per urgency (Critical, High, Medium, Low) > * **Email** summaries when deadlines are missed (recipients depend on issue type and deadline stage) > * **Webhook** notifications via Corgea webhooks (`sla.violation` event) — use an existing integration webhook or create one from the SLA form > * Daily automated checks for breached deadlines (`overdue` / `escalated`) > * SLA breach status on issues and in **Issue Aging** reporting for code and dependency findings ## How to Access > [!NOTE] > > Go to **Policies → SLA Management**. Requires the appropriate plan and `Issue SLA` permissions. ## Setup Instructions **1. Open SLA Management** Navigate to **Policies** and open **SLA Management**. ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/sla_management_nav.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=97d0df34a7913973b46cea1e2e2b06e1) **2. Create Issue SLA** Click **Create Issue SLA**. ![](https://mintcdn.com/corgea/cejZdXchGy8_rGGY/images/sla/create-issue-sla.png?fit=max\&auto=format\&n=cejZdXchGy8_rGGY\&q=85\&s=ade084c99eff3ed6e05d748f448711f6) **3. Choose issue type** Select **Code Vulnerability (SAST)** or **Dependency Vulnerability (SCA)**. Each SLA applies only to the selected type. **4. Set urgency and timeframes** Choose urgency levels and set **Remediation** and **Escalation** timeframes (days). **5. Configure notifications** * **Email** — optional; sends a daily summary to the right people when a deadline is missed (see below). * **Webhook** — optional; pick an existing webhook from the dropdown or enter a new HTTPS URL (creates a webhook subscribed to `sla.violation`). See [Webhooks](webhooks). **6. Save** Click **Save SLA**. ## How Notifications Work Corgea checks open issues **once per day**. Alerts are sent only after a deadline is missed—not while an issue is still within its SLA window. ### Email notifications Turn on **Email** when creating or editing an SLA. You’ll receive a **daily summary** listing overdue issues by project and severity (one email per person, not one email per issue). There are two kinds of deadlines: * **Remediation** — the first alert that an issue is overdue and should be addressed. * **Escalation** — a later alert, typically for project leads when the issue remains open. **Who receives the email?** That depends on the issue type and which deadline was missed: **Code vulnerabilities (SAST)** | Deadline missed | Who is notified | | - | - | | Remediation | The person **assigned** to the issue. If no one is assigned, **project owners**. If the project has no owners, **company administrators**. | | Escalation | **Project owners**, or **company administrators** if the project has no owners. | **Dependency vulnerabilities (SCA)** | Deadline missed | Who is notified | | - | - | | Remediation | The person **assigned** to the issue. If no one is assigned, **project owners**. If the project has no owners, **company administrators**. | | Escalation | **Project owners**, or **company administrators** if the project has no owners. | Assign dependency issues from the issue details page (**Assignee** dropdown), the same way as code issues. > [!TIP] > > Add **project owners** under **Project settings** so SLA emails reach the right team. Without owners, notifications go to company administrators. ### Webhook notifications When a webhook is configured on an SLA, Corgea fires a **`sla.violation`** event to that webhook with a structured JSON payload (see [Webhooks](webhooks)). You can: * Select an **existing** webhook (Corgea automatically subscribes it to `sla.violation` if needed), or * Enter a **new URL** to create a dedicated webhook for SLA alerts (HTTPS required). Webhooks use the same delivery pipeline as other Corgea webhooks (retries, signing, delivery history). For `sla.violation`, **project filters** match if any project in the payload overlaps your filter (useful when one notification spans multiple projects). > [!NOTE] > > SLAs created before this release may still list **Slack** as a notification method. New and edited SLAs use **webhook** instead; subscribe a Slack incoming webhook under **Integrations → Webhooks** and select it on the SLA form. ## Editing and Managing SLAs * Use **Edit** on an existing SLA. The form pre-fills issue type, urgency, timeframes, email checkbox, and the selected webhook (if any). * The SLA table shows **Type** (SAST or SCA), timeframes, and configured notification methods. ## Reporting and Issue Status * **Reporting → Aging** includes overdue **code** and **dependency** issues (summary counts, urgency breakdown, projects, ecosystems, and trends). * **Code and dependency issues** show SLA status and appear in assignee breakdowns on the aging report when assigned. * Filter dependency SLA status on scan dependency views when an SCA SLA applies. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/aging_report.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=81b1012a84bf21c2501192bbce30c945) ## Examples ### SLA for critical code findings **1. Create SLA** Create an SLA with type **Code Vulnerability (SAST)** and **Critical** urgency. **2. Set timeframes** Set remediation to 2 days and escalation to 3 days. **3. Notify** Enable **Email** and select a Slack or Teams webhook subscribed to `sla.violation`. ### SLA for high-severity dependencies **1. Create SLA** Create an SLA with type **Dependency Vulnerability (SCA)** and **High** (and **Critical**, if desired) urgency. **2. Set timeframes** Set remediation and escalation windows appropriate for your patch cadence. **3. Notify** Use **Email** to project owners and/or a webhook for your security channel. ## Best Practices > [!TIP] > > * Use short remediation windows in non-production environments to validate email and webhook delivery. > * Assign project owners on all active projects that have SLAs. > * Prefer integration webhooks (Slack, Zapier, custom) subscribed to `sla.violation` for team channels instead of one-off URLs when possible. > * Define separate SAST and SCA SLAs when remediation timelines differ between code fixes and dependency upgrades. ## Troubleshooting > [!WARNING] > > * **No emails** — Confirm **Email** is enabled on the SLA, issues have actually missed a deadline, and the expected recipients (assignee, project owners, or admins) have valid email addresses on their Corgea accounts. > * **No webhooks** — Confirm the SLA has a webhook selected or created, the webhook is **active**, and issues have actually breached the SLA. Check **Integrations → Webhooks → History**. > * **Empty recipient list** — Add project owners or company Admin users with valid email addresses. > * **SCA issues not matching** — Ensure the issue’s project is linked via the scan and urgency matches the SLA rule. # Slack Source: https://docs.corgea.app/slack Setting up Slack notifications with Corgea webhooks Send Corgea alerts to Slack by connecting a Slack Workflow Builder webhook under **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)** → **Webhooks**. > [!WARNING] > > The standalone **Slack** row under Automation Integrations is deprecated. Create new Slack notifications with **Webhooks**. Existing Slack integrations keep working — use **View All** to test or delete them. ![Automation Integrations with Slack marked Deprecated](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/webhooks_integrations.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=e84b9d7d75569f68d644ada376ea16bf) ## Prerequisites * Admin access in Corgea * Permission to create workflows in your Slack workspace ## Setting Up Slack Workflow Builder Use Slack Workflow Builder so you can map Corgea **top-level** payload fields into a channel message. > [!WARNING] > > Slack Workflow Builder only supports **top-level JSON keys**. Nested paths like `data.message` or `data.summary.total_issues` are **not supported** and commonly produce HTTP 400 `invalid_workflow_input`. > > For `Type = Slack` + a Workflow Builder URL (`hooks.slack.com/triggers/...`), Corgea flattens **only** `scan.started`, `scan.completed`, `scan.failed`, and `webhook.test` into a top-level payload. Map `message`, `pull_request_id`, `scan_url`, and `true_positive_count` — not nested `data.*`. > > Other subscribed events on the same Slack webhook (for example `issue.status_changed` or `sla.violation`) still receive the nested envelope. Prefer scan lifecycle subscriptions for Workflow Builder, or use a Custom Body / non-Slack destination for those events. **1. Create a Workflow** 1. In Slack, open your workspace menu 2. Go to **Tools → Workflow Builder** 3. Click **Create** 4. Choose **Webhook** as the trigger 5. Name the workflow and continue **2. Configure Workflow Steps** 1. Copy the Workflow Builder webhook URL (`hooks.slack.com/triggers/...`) 2. On the **Webhook** trigger step, **add variables** whose names match Corgea’s top-level keys (Slack does not auto-discover payload fields). Add at least: `message`, `pull_request_id`, `scan_url`, `true_positive_count`, `scan_id`, `event_type`, `project_name`, `status`, `branch`, `company` 3. Add a **Send a message** step (required — Corgea does not post to Slack by itself) 4. Use **Insert a variable** to insert those webhook variables into the message (typed `{message}` text will not work) Example flat `scan.completed` body Corgea sends to Workflow Builder (nested `project`, `summary`, and `scheduled_scan_ids` are **not** included): ```json theme={null} { "event_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901", "event_type": "scan.completed", "timestamp": "2025-01-15T15:45:00.000Z", "message": "Scan completed for My Project (PR #42): 5 true-positive findings. View: https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890", "scan_id": "scan-uuid-7890", "scan_url": "https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890", "scan_type": "full", "pull_request_id": "42", "true_positive_count": 5, "status": "completed", "branch": "feature/auth", "project_name": "My Project", "company": "comp-uuid-1234", "run_id": "run-abc", "engine": "corgea" } ``` On `scan.failed`, the flat body also includes top-level `error` when present. Start with `message` for a ready-to-send summary, then add `pull_request_id`, `scan_url`, and `true_positive_count` for PR triage. Completed-scan `message` wording uses **true-positive** counts (not total issues):\ `Scan completed for {project} (PR #N): X true-positive finding(s) [(Y with fixes)]. View: {scan_url}`\ `Y with fixes` counts fixes only among those true-positive findings. 5. Finish and publish the workflow **3. Configure in Corgea** 1. Go to **Integrations → Webhooks** 2. Create a new webhook 3. Set **Type** to `Slack` 4. Enter a name and paste the Workflow Builder URL 5. Subscribe to `scan.completed` and/or `scan.failed` (optionally `scan.started`) 6. Under **Scan Event Filters** (optional): * **Only pull request / merge request scans** — skip non-PR scans * **Only completed scans with true-positive findings** — skip `scan.completed` when `true_positive_count` is 0 (`scan.failed` is unaffected) 7. Click **Create Webhook** and save the one-time secret key 8. Click **Test** to confirm delivery ## Test Webhook expectations When you click **Test Webhook** on a Slack Workflow Builder destination, Corgea sends a flat sample like: ```json theme={null} { "event_id": "...", "event_type": "webhook.test", "timestamp": "2025-01-15T15:45:00.000Z", "message": "This is a test webhook from Corgea", "test": true, "webhook_name": "My Slack Hook", "company": "comp-uuid-1234", "company_id": "comp-uuid-1234", "scan_id": "00000000-0000-0000-0000-000000000000", "scan_url": "https://app.corgea.app/project/example/?scan_id=00000000-0000-0000-0000-000000000000", "scan_type": "full", "pull_request_id": "123", "true_positive_count": 2, "status": "completed", "branch": "main", "project_name": "Example Project", "run_id": "test-run", "engine": "corgea" } ``` `company` matches live scan events. `company_id` is the same value for older Test consumers. Non-Slack destinations receive the same fields nested under `data` in the usual envelope. Expect: * HTTP 2xx from Slack (not 400 `invalid_workflow_input`) * A non-empty Slack message when you map the top-level `message` variable * Variable names that match production scan events (so you can map PR # / scan link / TP count during Test) ## Notification Content For Slack Workflow Builder (`Type = Slack` + `hooks.slack.com/triggers/...`), map these **top-level** fields: | Field | Description | | - | - | | `message` | Ready-to-send summary (PR #, TP count, scan URL when available) | | `event_type` | e.g. `scan.completed`, `scan.failed`, `webhook.test` | | `event_id` | Delivery event UUID | | `timestamp` | ISO 8601 timestamp | | `scan_id` | Scan UUID | | `scan_url` | Deep link to the scan in Corgea | | `scan_type` | Scan type string | | `pull_request_id` | PR/MR number when this is a pull request scan (empty when not a PR) | | `true_positive_count` | Non-deleted security findings excluding false positives and code-quality | | `status` | `started`, `completed`, or `failed` | | `branch` | Git branch | | `project_name` | Project name | | `company` | Company ID (same key as live scan payloads) | | `company_id` | Same value as `company` (`webhook.test` only; not on live `scan.*`) | | `run_id` | Scan run ID | | `engine` | Scanner engine | | `error` | Failure reason (`scan.failed` only, when present) | | `test` | `true` on `webhook.test` only | | `webhook_name` | Webhook display name (`webhook.test` only) | `true_positive_count` matches the scan UI security count: excludes `status=false_positive`, `hold_reason=false_positive`, and `detected_by=code-quality`. Nested fields such as `summary`, `project`, `scheduled_scan_ids`, `scan_errors`, `created_at`, and `processed_at` remain available under `data` for Zapier/Other (and in delivery history), but are not flattened for Slack Workflow Builder. ## Compatibility notes * **Zapier / Other:** still receive the nested envelope (`event_id`, `event_type`, `timestamp`, `data`), including `data.message`, `data.summary`, and the new triage fields under `data`. * **Existing Slack Workflow Builder configs** that mapped nested `data.*` will not work — remap to top-level keys (`message`, not `data.message`). * **Delivery history** in Corgea stores the nested envelope even when Slack receives a flat HTTP body. * **Non-scan events** on a Slack WF webhook are not flattened; keep those on Zapier/Other or a Custom Body if you need usable Slack variables. ## Incoming Webhooks vs Workflow Builder * **Recommended:** Workflow Builder URLs (`hooks.slack.com/triggers/...`) with a **Send a message** step. Corgea flattens `scan.*` and `webhook.test` for `Type = Slack`. * **Incoming Webhooks** (`hooks.slack.com/services/...`): rejected on save unless you add a [custom body](/webhooks) whose rendered JSON has a top-level non-empty string `text` field (Slack fallback text; optional `blocks` are allowed alongside it). `{"text": "{{message}}"}` works only when the webhook is limited to `scan.started` / `scan.completed` / `scan.failed` / `scheduled_scan.daily_report` (`{{message}}` is empty for other events). Without a valid body, deliveries fail and the webhook can auto-pause. ## Managing Existing Slack Integrations If you still have integrations on the deprecated Slack row, open **View All** to test or delete them: ![View All Slack Integrations modal for managing existing integrations](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/slack_view_all_modal.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=82712d185c56db9be7b35b1e8eff1931) ## Customization Options With Workflow Builder, you can: * Route messages to different channels by severity or project * Add reminders or follow-up steps * Build conditional logic around scan results (for example, only notify when `true_positive_count` is greater than 0) * Reuse the same payload variables across multiple actions Prefer Corgea **Scan Event Filters** (PR-only + completed with findings) when you want to avoid noise from scheduled/full scans without a third-party flattener like Zapier. ## Additional Resources * [Slack Workflow Builder Guide](https://slack.com/help/articles/360035692513-Guide-to-Workflow-Builder) * [Flatten JSON for Workflow Builder](https://slack.dev/flatten-json-for-workflow-builder/) * [Corgea Webhooks](/webhooks) # SSO Source: https://docs.corgea.app/sso Enable seamless and secure access to multiple applications with Single Sign-On (SSO) using the SAML protocol, enhancing user experience and security. ## Overview ### Functionality The SSO by SAML feature allows users to authenticate and access multiple applications using a single set of credentials via the Security Assertion Markup Language (SAML) protocol. This feature streamlines the login process, enhances security, and reduces the need for multiple passwords. Users signing in through a configured SAML connection are provisioned automatically on their first successful login, even when self-service registration is disabled. ### Target Audience This feature is designed for organizations looking to implement Single Sign-On (SSO) for their users, providing a seamless and secure authentication experience across various applications. ## Key Features and Benefits * **Centralized Authentication**: Log in once to access multiple applications without re-entering credentials. * **Enhanced Security**: Reduces the risk of password fatigue and phishing attacks by minimizing the number of passwords users need to remember. * **Improved User Experience**: Simplifies the login process, reducing the time and effort required to access different services. ## Access Instructions To access the SSO by SAML feature, you must provide either a SAML metadata link or specific configuration details to the Corgea support team. ## SAML Configuration Instructions ### Setting Up SSO SAML in Your SSO Provider 1. Access your SSO provider account and set up the SAML application using these parameters: * **Single Sign-On URL**: [https://www.corgea.app/saml/acs/](https://www.corgea.app/saml/acs/) * **Audience URI (SP Entity ID)**: [https://www.corgea.app/saml/metadata/](https://www.corgea.app/saml/metadata/) * **Default RelayState**: [https://www.corgea.app/projects/](https://www.corgea.app/projects/) * **Name ID Format**: EmailAddress * **Application Username**: Email * **Update Application Username On**: Create and update Note: Replace `https://www.corgea.app` with `https://your_instance.corgea.app` if you are on private deployment. 2. For the "Attribute Statement" section, use the following mappings: **Required field:** * email (user.profile.email) **Optional fields:** * firstName (user.profile.firstName) * lastName (user.profile.lastName) > ![Okta Config](https://mintcdn.com/corgea/Rx20dJ1L_HPdycuu/images/okta_sso_groups_attributes.png?fit=max\&auto=format\&n=Rx20dJ1L_HPdycuu\&q=85\&s=3eb8afd297d759b024268a89266a88e5) **Optional: Group Export Configuration** To export user groups into Corgea, configure the groups attribute as: ``` user.getGroups({'group.type': {'BUILT_IN','OKTA_GROUP','APP_GROUP'}}).[profile.name] ``` This exports the group profile name for each group. ### Map IdP groups to Corgea roles After your SAML integration is connected, edit it and expand **IdP Group Mapping**. Each mapping assigns members of an IdP group to an existing Corgea role and controls their project access: * **No project access** assigns the role without granting access to projects. * **All projects** grants the role access to every project. * **Projects matching this group** grants access based on a value in the IdP group name. Select **Application**, **Line of business (LOB)**, or **Repository**, then include the corresponding placeholder in the group pattern. For example, an IdP group pattern of `DOE.Developer.{APPLICATION}` matches groups such as `DOE.Developer.Payments`. If **Application** is selected, `Payments` is used to grant access to projects with the same application value. Use the **Project naming pattern** to describe how your Corgea project names are structured. For example: * `{LOB}_{APPLICATION}_{REPOSITORY}` matches a project named `Finance_Payments_checkout-api`. * `{LOB}-{APPLICATION}` matches a project named `Finance-Payments`. The available placeholders are `{APPLICATION}`, `{LOB}`, and `{REPOSITORY}`. The placeholder selected for project matching must appear once in both the IdP group pattern and the project naming pattern. Use a unique IdP group pattern for each Corgea role. **Legacy Configuration Format** If you're using the legacy configuration format, the mapping looks like this: * **Name** -> **Value** * email -> user.email * firstName -> user.firstName * lastName -> user.lastName > ![Okta Config](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/sso_okta_config.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=88b0d574b953e06ae0d8e9e041adc88a) After completing the SSO configuration, ensure users are assigned to the SAML application in your SSO provider and have the appropriate role permissions set in Corgea. > ![Okta Config](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_okta_assign_app.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=ab2adbaa1fcb528da24b65071a3347b9) Upon completing the setup, a new SAML metadata link will be provided. ### Integrating SAML with Corgea **1. Navigate to Integrations** Log into your Corgea account and go to **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)**. **2. Initiate SAML SSO** Select the "Add" option within the "SAML SSO" area. **3. SAML Configuration** > ![SSO Modal](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_fetch_and_populate.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=cb1e16a43ef7c33f604ce329730a272b) * Input the SAML metadata URL in the **"Metadata URL"** field. * Press the **"Fetch and Populate"** button to auto-fill fields such as Entity ID, SSO URL, and X.509 Certificate using the metadata. * **Configuration Name**: Assign a name to your SAML configuration. * **Email Domain**: Define the email domain for SSO setup. Domain matching is case-insensitive, and new or edited domains are saved in lowercase. **Manual Entry (if necessary)**: * Should manual input be needed, ensure you have the following details: * **Entity ID**: The SAML entity's unique identifier. * **X509 Certificate**: The certificate for signing SAML assertions. * **Single Sign-On Service Location**: The URL for SAML IdP authentication responses. **4. Finalize Configuration** * Check the accuracy of the auto-filled fields. * Hit the "Connect" button to finalize and save your SAML configuration. **Fetch and Populate** accepts a metadata URL that uses HTTPS on port 443, does not include a username or password, and resolves to a public address. If the host is not accepted, contact your Corgea account team. ### Login by SSO. * Once SAML configuration is properly configured, you should be now able to login through your SSO service. * **User Login**: Authenticate through the SAML IdP and get redirected back to the application with a SAML assertion. After entering your email address on the initial login page, the "Login by SAML" option will appear on the step 2 page if the setup is correct. This option is triggered by the email domain. **1. Initial Login Page** > ![Initial Login Page](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/sso_initial_login.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=04cfa70bc1f613d03c580508e624e178) > [!NOTE] > > Enter your email address on the initial login page. If your email domain is configured for SSO, the "Login by SAML" option will appear on the next page. **2. Login by SAML Option** > ![Login by SAML Option](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/sso_login_by_saml.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=9a3c03b6b80dbf6b4cbe0a065a0b8826) > [!NOTE] > > Click on the "Login by SAML" button to proceed with authentication through your SAML Identity Provider (IdP). **3. SAML Authentication** > ![SAML Authentication](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/sso_saml_authentication.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=38c21cc3c92ee7a317c28946dc082c50) > [!NOTE] > > You will be redirected to your SAML IdP for authentication. Enter your credentials as required by your IdP. **4. Redirect to Application** > ![Redirect to Application](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/sso_redirect_to_app.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=f534ee96379f62486e78f1ed98affd50) > [!NOTE] > > After successful authentication, you will be redirected back to the application with a SAML assertion, granting you access. ### Sign in with a one-time password during an IdP outage Organizations can ask Corgea support to enable a passwordless email fallback for times when their SAML identity provider is unavailable. When enabled, **Sign in with a one-time password** appears alongside the SAML option for the organization's configured email domain. This option is available only to active Corgea users who are eligible for the organization's SAML configuration. If you do not receive a code, verify the email address or contact your Corgea administrator; the confirmation screen is the same whether or not an account is eligible. **1. Choose the one-time password option** > ![SSO login page with Sign in with a one-time password](https://mintcdn.com/corgea/wXzytKO57N5Fqd4_/images/sso_otp_login.png?fit=max\&auto=format\&n=wXzytKO57N5Fqd4_\&q=85\&s=ae35e22e2c6d868c3b22f89cad86d364) > [!NOTE] > > Select **Sign in with a one-time password** on the SSO login page. **2. Request a code** > ![Sign in with a one-time password email form](https://mintcdn.com/corgea/wXzytKO57N5Fqd4_/images/sso_otp_request.png?fit=max\&auto=format\&n=wXzytKO57N5Fqd4_\&q=85\&s=3ac36a24dbc3d178f4cf47b66b069ec2) > [!NOTE] > > Enter your work email and select **Send code**. **3. Open the email** > ![One-time sign-in code email](https://mintcdn.com/corgea/wXzytKO57N5Fqd4_/images/otp_email.png?fit=max\&auto=format\&n=wXzytKO57N5Fqd4_\&q=85\&s=536ffd4571bedc9080f4a7ffbdb12c93) > [!NOTE] > > Use the 6-digit code from the email. The code expires in 10 minutes. **4. Enter the code** > ![Enter your sign-in code confirmation page](https://mintcdn.com/corgea/wXzytKO57N5Fqd4_/images/sso_otp_verify.png?fit=max\&auto=format\&n=wXzytKO57N5Fqd4_\&q=85\&s=75d1c34f4e18514f49e55b1c47e7c725) > [!NOTE] > > Enter the code on **Enter your sign-in code** and select **Verify and continue**. If you select **Resend code**, only the newest code is valid. ### Step-by-Step Guide to Configuring SSO SAML for Microsoft Entra **1. Access Azure Active Directory** Begin by logging into your Azure portal. Once logged in, navigate to the "Azure Active Directory" section. **2. Create a New Application** > ![Azure Create App](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_azure_create_app.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=5ebe069925e4ad9e47d722f5b588771a) * Go to "Enterprise applications" and select "New application". * Opt for "Create your own application" and provide a name for your new application. **3. Configure SAML-based Sign-On** > ![Azure SAML Config](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_azure_choose_sampl_app.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=2d93c7136a62e18f30b58fb00e3564fa) * Within the application settings, choose "Single sign-on" and select "SAML". **4. Copy SAML Metadata URL** > ![Copy SAML Fields](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_azure_copy_metadata.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=4ca9aaa711232eb7d10d40a5c608e4dc) * Copy the Federation Metadata XML URL for later use. **5. Populate SAML Configuration in Corgea** > ![Populate Azure on Corgea](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_populate_azure_on_corgea.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=468e5b591f753f38545f5042fd3f7d05) * Log into your Corgea account and go to **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)**. * Click on "+ Add" button in SAML SSO section. * Enter the copied SAML metadata URL into the "Metadata URL" field and click "Fetch and Populate". * Check the auto-filled fields for accuracy. **6. Finalize and Test Configuration** * Click the "Connect" button to save your SAML configuration. **7. Copy Updated Corgea SSO URLs** > ![SSO fields](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_copy_updated_fields.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=6585c88a8b6eca85fb7fc1bfbddd6c0a) * After saving the SAML integration, view the updated identifier and ACS URL by clicking "View All" in the SAML SSO section. **8. Fill in SSO SAML Config on Entra** > ![SSO fields](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/sso_azure_fill_in_basic_saml_config.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=8e4844350232a3bc4295231bca6a222f) * Enter the copied SSO fields into the corresponding fields on your SAML Basic configuration page in Entra. * Double-check all entries for accuracy to ensure a successful SSO connection, then click the "Save" button at the top. **9. Test login by SSO** Now you should be able to login with configured domain through login page. [Login by SSO](/sso#login-by-sso) ### Prerequisites or Dependencies * A configured SAML Identity Provider (IdP). ## Best Practices * **Regularly Update Certificates**: Ensure that your x509 certificates are up-to-date to maintain secure connections. * **Test Configurations**: Before rolling out SSO to all users, test the configuration with a small group to ensure everything works as expected. ## Troubleshooting * **Missing Referer Header**: If you receive a "Missing Referer header" error, check that the HTTP\_ORIGIN is correctly configured in the request headers. * **No SAML Configuration Found**: If the configuration is missing, ensure that the correct referer URL or email domain is being utilized. * **Sign-in stopped with a generic error**: More than one SAML configuration may claim the same email domain with different capitalization. Contact Corgea support to resolve the conflicting configurations before users try again. * **Permission Update**: If a user cannot access the SAML application, verify that their permissions are correctly configured and updated. ## Domain Ownership Conflicts If you see a message that another workspace has already verified ownership of your domain, Corgea is preventing two different workspaces from claiming the same company domain at the same time. This most commonly happens when: * your team already has an existing Corgea workspace tied to the same email domain * another admin in your organization enabled domain-based user join first * SSO or domain-based workspace join was configured in a different workspace before the current one We enforce this because a verified company domain is used to route users into the correct workspace and to protect against users being automatically sent to the wrong place. ### What to do next 1. Confirm whether your organization already has an existing Corgea workspace for this domain. 2. If the existing workspace is the correct one, continue managing users and SSO there instead of creating a second workspace for the same domain. 3. If the domain needs to move to a different workspace, contact Corgea support ([support@corgea.com](mailto:support@corgea.com)) so we can help verify the correct ownership and update the configuration safely. ## Additional Resources * [SAML Protocol Overview](https://en.wikipedia.org/wiki/SAML_2.0) * [Troubleshooting SAML Issues](https://www.samltool.com/troubleshoot.php) * [Add an Okta SAML application](https://help.okta.com/oag/en-us/content/topics/access-gateway/add-app-saml-pass-thru-add-okta.htm) # SCIM as an Optional Feature ## Overview ### Functionality SCIM (System for Cross-domain Identity Management) is an open standard designed to manage user identities in cloud-based applications and services. It automates the exchange of user identity information between identity domains or IT systems, making it easier to manage user accounts across multiple platforms. ### Target Audience This feature is ideal for organizations that need to manage user identities across various applications efficiently. ## Key Features and Benefits * **Automated User Provisioning**: Automatically create, update, and deactivate user accounts in connected applications, reducing manual effort and errors. * **Consistent User Data**: Ensures that user information is consistent across all integrated applications, improving data accuracy and compliance. * **Scalability**: Easily manage a large number of users across multiple platforms, making it suitable for growing organizations. * **Security**: Enhances security by ensuring that user access is promptly updated or revoked as needed. ## Why Customers Want SCIM * **Efficiency**: Automates repetitive tasks, freeing up IT resources for more strategic initiatives. * **Accuracy**: Reduces the risk of human error in user management, ensuring that user data is always up-to-date. * **Compliance**: Helps maintain compliance with data protection regulations by ensuring that user data is consistently managed and protected. * **Integration**: Seamlessly integrates with existing SSO solutions, providing a comprehensive identity management system. ## SSO SCIM Provider Configuration To enable SCIM functionality, you need to configure the SCIM application in your SSO provider with the following settings: * Ensure SCIM is enabled. * Set up the Application SCIM Integration with: * SCIM connector base URL: [https://www.corgea.app/scim/v2/](https://www.corgea.app/scim/v2/) * Unique user identifier field: email * Supported provisioning actions: * Push New Users * Push Profile Updates * Authentication Mode: HTTP Header The SCIM token can be found in the SSO Configuration modal: > ![SCIM Token in SSO Modal](https://mintcdn.com/corgea/Se2Ve0BHwtjo4g31/images/scim_token_sso_modal.png?fit=max\&auto=format\&n=Se2Ve0BHwtjo4g31\&q=85\&s=c3d2535285f2b70df741004f0950cfc3) By enabling SCIM, organizations can significantly enhance their identity management processes, leading to improved operational efficiency and security. # Teams Source: https://docs.corgea.app/teams Organize users into teams and manage project access at scale with team-based permissions ## Overview Teams in Corgea provide a powerful way to manage project access at scale. Instead of assigning users individually to each project, you can organize your users into teams and grant entire teams access to projects. This streamlines permission management, especially for organizations with multiple projects and numerous team members. > [!NOTE] > > Teams and team management are available on plans that include Team Management. If your company uses GitHub organization teams, you can keep linked Corgea teams in sync from Content Access. See [GitHub Team Sync](/content-access-management#github-team-sync). ## What Are Teams? A **Team** is a named group of users within your organization. Teams act as a bridge between your organizational structure and your projects, allowing you to mirror real-world teams (like "Security Team," "Frontend Engineers," or "DevOps") directly in Corgea. ### Key Characteristics * **Company-Scoped**: Teams are specific to your organization and cannot be shared across different companies * **Flexible Membership**: Add or remove users from teams at any time * **Reusable**: A single team can be assigned to multiple projects * **Dynamic Access**: When you add someone to a team, they automatically gain access to all projects assigned to that team ## Implementing Teams in Your Organization **1. Go to the Teams page** Go to **Settings → User Management → [Teams](https://www.corgea.app/settings/company/teams/)**. \[!NOTE] You will need View Teams permission to see this. **2. Create Your Teams** ![Create Team](https://mintcdn.com/corgea/pddtADaDnD3yjwzX/images/teams/create-team.png?fit=max\&auto=format\&n=pddtADaDnD3yjwzX\&q=85\&s=7f49d81cce7f06860c89d3da8ba48138) 2. Click "Create Team" 3. Provide a descriptive name (e.g., "Backend Engineers," "Security Reviewers") 4. Select initial members from your organization 5. Save the team **3. Manage Team Membership** As your organization evolves: * **Add new members**: Click on a team and add users * **Remove members**: Remove users * **Edit team details**: Rename teams or adjust membership as needed **4. Assign Teams to Projects** 1. Navigate to the Content Access management page (see [Content Access Management Guide](content-access-management)) 2. Select the project you want to manage 3. Add your newly created team to the project 4. All team members now have access ## Dynamic Project Access In addition to assigning individual projects, you can edit a team and grant member-level access dynamically: * **Project tags**: The team receives access to every project carrying any selected tag. The picker shows how many projects currently use each tag. * **Repository URL fragments**: The team receives access when a project's repository URL contains any configured fragment, case-insensitively. Explicit assignments, tag selectors, and repository URL selectors are combined with OR logic. New or re-tagged projects begin matching automatically. These grants take effect only while Project Access Control is enabled. > [!TIP] > > Use project tags for stable, auditable access groups. Use repository URL fragments when repository naming conventions make automatic matching more practical. ## Manage Teams with the API Team APIs require API access and the `user_management.change_content_access` permission. Authenticate with a `CORGEA-TOKEN` header or Bearer token. See the [Teams API Reference](/api-reference/teams/list-teams) for interactive endpoint documentation and response schemas. Create a team with explicit and dynamic project access: ```bash theme={null} curl --request POST \ --url 'https://www.corgea.app/api/v1/teams' \ --header 'CORGEA-TOKEN: YOUR_API_TOKEN' \ --header 'Content-Type: application/json' \ --data '{ "name": "Payments Team", "member_ids": [12, 34], "project_ids": [101], "project_tags": ["payments", "backend"], "repo_url_patterns": ["github.com/acme/payments-"] }' ``` Update selected fields: ```bash theme={null} curl --request PATCH \ --url 'https://www.corgea.app/api/v1/teams/42' \ --header 'CORGEA-TOKEN: YOUR_API_TOKEN' \ --header 'Content-Type: application/json' \ --data '{ "project_tags": ["payments", "critical"], "repo_url_patterns": ["github.com/acme/payments-"] }' ``` Preview every resolved project and its matching access sources: ```bash theme={null} curl --request GET \ --url 'https://www.corgea.app/api/v1/teams/42/projects' \ --header 'CORGEA-TOKEN: YOUR_API_TOKEN' ``` `PATCH` replaces each selector list included in the request. Omit a field to leave it unchanged, or send an empty array to clear it. ## Common Use Cases > **Department-Based Access** > > Create department teams (e.g., "Security Team") and assign them to relevant projects. New hires automatically inherit access when added to the team. > **Project-Based Collaboration** > > Build cross-functional teams (e.g., "Mobile App Team") and grant access to related repositories for streamlined collaboration. > **Temporary Access Management** > > Create teams for contractors or temporary staff, assign to specific projects, then remove everyone at once when the engagement ends. > **Hierarchical Permissions** > > Combine team assignments with direct ownership. For example, assign a team as members while making senior engineers owners for elevated permissions. > **Scaling Access Management** > > Instead of managing thousands of individual assignments, create a few teams and assign them to projects—maintenance becomes exponentially easier. ## Best Practices **Mirror Your Organizational Structure**: Create teams that reflect how your organization actually works. This makes it intuitive for everyone to understand who has access to what. **Use Descriptive Names**: Name teams clearly: "QA Team" is better than "Team 3." Future administrators will thank you. **Regular Audits**: Periodically review team memberships and project assignments to ensure they're still accurate. People change roles, and access should reflect that. **Start with Broader Teams**: Begin with larger teams (like "Engineering") and create more specific ones (like "iOS Team") as needed. It's easier to refine than to consolidate. **Combine with Direct Assignments**: Don't feel limited to only using teams. For unique situations, direct user assignments work perfectly alongside team assignments. **Document Your Team Structure**: Maintain documentation about what each team represents and which projects they should access. This helps with onboarding and audits. **Learn more:** * [Content Access Management Guide](content-access-management) - Understand how project access control works in Corgea * [User Management](user_management) - Learn about managing users in your organization # Triage Justifications Source: https://docs.corgea.app/triage_justifications Require a reason when a finding is closed ## Overview Closing a finding is a permanent audit record. A comment like "false positive" or "accept risk" only repeats the decision that was already recorded in the status, so anyone reading the finding months later — a teammate, a new owner, an auditor — learns nothing from it. Corgea reviews the comment you write when you change a finding's status and asks again when it does not explain the decision. The bar is low: one specific sentence that a reader could go and check is enough. > [!NOTE] > > The justification requirement applies to the comment on a status change. It does not change who is allowed to change a status, which remains controlled by the `change_issue_status` permission. See [Roles](/permission_groups). ## Where it applies The review runs everywhere a status change is recorded: * The **Change Decision** modal on the finding details page * The details drawer in the [Vulnerabilities Workbench](/vulnerabilities) * The bulk triage action bar, including SAST, SCA, and IaC findings * Dismissals requested from a pull request through the [Corgea Agent](/agent) ![The finding details page showing the explanation, code, and Overview information](https://mintcdn.com/corgea/4wTUI7zssVC3U7_-/images/scans/issue_details_overview.png?fit=max\&auto=format\&n=4wTUI7zssVC3U7_-\&q=85\&s=75a92584f8f950d1f46b13dc932d1723) Reopening a finding is exempt. Reopening does not dismiss anything, so it carries no justification bar. ## What makes a good justification A justification is accepted when it names at least one concrete thing a reader could verify. Any one of these is enough: > [!TIP] > > * **The control that makes the code safe** — input validation, output escaping, a parameterized query, an authorization check, or a framework guarantee > * **Why the input is trusted or the path is unreachable** in this deployment > * **A compensating control or business reason** for carrying the risk, ideally with an owner, a deadline, or a scope > * **Where the fix landed**, or which finding this one duplicates — a commit, pull request, ticket, or finding ID > * **What the scanner misread** about the code Examples that are accepted: ```plaintext theme={null} The query on line 44 is parameterized; the user value is bound, never concatenated. This input is the signed JWT claim, validated in the auth middleware before it reaches this handler. Internal-only endpoint behind the VPN. Accepting until the 2.0 upgrade next quarter, owned by the platform team. Fixed in PR #1421, which landed after this scan ran. Duplicate of finding 8c31; same sink, same commit. ``` ## What gets rejected A comment is sent back when it adds nothing to the decision itself: | Pattern | Examples | | - | - | | Restates or labels the decision | `false positive`, `accept risk`, `won't fix`, `fixed`, `duplicate` | | Asserts a conclusion with no reason | `not exploitable`, `this is safe`, `not a real issue`, `low priority` | | Filler, placeholder, or gibberish | `n/a`, `test`, `asdf`, `...`, `per policy`, `as discussed` | | Names an approver or a process, but no reason | `approved by security`, `reviewed`, `ticket created` | When a comment is rejected, Corgea explains what is missing and keeps what you typed so you can add to it. The status is not changed until the comment is accepted. ![The Change Decision modal rejecting a comment that only says false positive](https://mintcdn.com/corgea/L-24If3t2LOPrEXE/images/triage/change_decision_rejected.png?fit=max\&auto=format\&n=L-24If3t2LOPrEXE\&q=85\&s=0ffa8fd249286665a7fff1257cf85e34) > [!TIP] > > The same phrase followed by an actual reason is fine. "False positive — the value is escaped by the template engine before it is rendered" is accepted; "false positive" on its own is not. ## What Corgea never rejects for The review looks for whether a reason is given at all, not for how well it is written. > [!NOTE] > > A justification is never rejected because of its length, spelling, grammar, informal tone, or the language it is written in. Justifications written in any language are reviewed on equal terms. Corgea also does not judge whether your reasoning is technically correct — that judgment stays with your team — and accepts the comment when it is unsure. If the review is unavailable, the comment is accepted and the status change goes through. Triage is never blocked by the review being down. ## Closing a finding from a pull request The [Corgea Agent](/agent) writes the same audit record when it acts on a pull request comment, so it asks for the same reason. A comment that asks to dismiss a finding without saying why — `@Corgea false positive`, `accept risk`, `not an issue`, `wontfix` — gets a reply asking for the reason instead of a status change. Include the reason in the comment and the agent records it: ```plaintext theme={null} @Corgea false positive, the query is parameterized on line 44 @Corgea accept risk until the 2.0 upgrade next quarter, this endpoint is internal-only ``` A reason you already gave earlier in the same thread counts. This applies to dismissals — false positive and accepted risk — because those close a live finding. Marking a finding fixed or duplicate from a pull request is unchanged. ## Requiring a second reviewer A justification explains a decision, but on its own nothing checks it. Company admins can also require that a second person approves a dismissal before it takes effect. Turn this on under **Settings → Company → Triage rules** ([open](https://www.corgea.app/settings/company/triage-approvals/)). The page has two independent toggles, both off by default: * **False positive** — dismissing a finding as a false positive waits for approval. * **Accepted risk** — suppressing a finding as accepted risk, with or without an expiry, waits for approval. ![The Triage rules page with False positive and Accepted risk on, and two auto triage rules](https://mintcdn.com/corgea/gXE6s3uSV4XQ0K2H/images/settings/triage_rules.png?fit=max\&auto=format\&n=gXE6s3uSV4XQ0K2H\&q=85\&s=aecf2cd18443c22cf898ed8a77c33603) With a decision switched on, making it from the finding details page, the workbench drawer, or the bulk triage bar creates a request instead of changing the status. **Containers** and **IaC** findings change immediately; approval does not apply to them. Every other finding keeps the status it has and shows as **Pending approval** until someone reviews it. Your justification travels with the request — it is what the reviewer reads. ![A finding that stays Open while a false-positive request waits for approval](https://mintcdn.com/corgea/L-24If3t2LOPrEXE/images/triage/pending_approval_finding.png?fit=max\&auto=format\&n=L-24If3t2LOPrEXE\&q=85\&s=cf0f3b8c7652075f1eb565fc02e521dd) ### Reviewing requests Reviewers work from the approvals queue at [/approvals/](https://www.corgea.app/approvals/), which has **Pending**, **Approved**, **Rejected**, and **Withdrawn** tabs. Filter by decision, project, requester, severity, and recommendation, narrow to **Everyone**, **Waiting on me**, or **Mine**, and search across CWE, CVE, path, project, justification, reviewer note, and requester. Filters live in the query string, so a filtered view can be shared as a link. The recommendation filter includes **Has recommendation**, **Approve**, **Reject**, and **No recommendation**. On **Pending**, a false-positive request is hidden when every finding on it is a code finding and the project's latest completed full scan already marks each of those findings as a false positive. A request that includes a dependency finding stays visible. Turn on **Closed by rescan** to show the hidden requests. They remain pending and still need a review decision. ![The approvals queue on Pending, filtered to Waiting on me, with Severity, Recommendation, and Closed by rescan](https://mintcdn.com/corgea/K88fBiyu9iuG0Rzy/images/triage/approvals_queue.png?fit=max\&auto=format\&n=K88fBiyu9iuG0Rzy\&q=85\&s=e84d58968fb355ff681d3dad01a6acf2) A reviewer has to be someone other than the requester, in the same company, holding permission to approve triage requests and to change every finding type in the request. Approving or rejecting can carry an optional note, and requesters can withdraw their own requests. > [!NOTE] > > People who can approve requests are exempt from their own gate: queueing their decision would only ask them to approve themselves, so it applies immediately. Company admins see every request in the queue; everyone else sees only the requests they submitted. Every step — the request, the approval or rejection, any reviewer note, and a withdrawal — is recorded in the finding's history timeline. ### Reviewing requests in bulk On **Pending**, select individual requests, all reviewable requests on the current page, or all requests matching the filters. Your own requests are excluded from review selections. Choose **Approve** or **Reject**, review the confirmation dialog, and confirm the decision. You can send the same note for all requests or customize notes per request; per-request notes require an explicit selection rather than all matching requests. Pending requests submitted by an agent can also be approved by an authorized human reviewer. The confirmation dialog identifies agent-submitted requests before you apply the decision. ### Optional triage suggestions Triage suggestions are available only when enabled for your company. Corgea can draft a justification for a false-positive or accepted-risk selection in the workbench; review and edit it before submitting. For reviewers, a pending card can show **Corgea recommends** with **Approve** or **Reject**, a confidence indicator, and reasoning that will be sent to the requester. **Submit recommendation** applies that suggestion. **Override** changes the decision or the note. Select several requests to use **Apply suggestions**, which applies each selected request's recommendation after confirmation. Requests without a recommendation still need a manual decision. Suggestions never approve or reject a request on their own. ![Approvals queue on Pending, with Corgea recommendations to approve an accepted risk and reject a false positive](https://mintcdn.com/corgea/K88fBiyu9iuG0Rzy/images/triage/approvals_suggestions.png?fit=max\&auto=format\&n=K88fBiyu9iuG0Rzy\&q=85\&s=6fad34ff9a6234719d02f9df38493722) New requests submitted by a person start review-suggestion generation after submission. Requests submitted by an agent do not. An older pending request that still has no suggestion starts generation when you open the **Pending** page that lists it, or when you open that finding. Opening one page of the queue does not generate suggestions for requests on another page. Requesters receive approval and rejection emails according to their [notification preferences](/notifications#triage-review-decision). Bulk reviews group results into a summary per requester and outcome. # Uploading Scans Source: https://docs.corgea.app/upload-report Start generating fixes for your repository Users have a choice between two options: the Corgea Dropsite and the Corgea CLI. > [!NOTE] > > **Prerequisite** You registered in Corgea > > **SAST Scanner** You have a SAST scanner like Checkmarx, CodeQL, Semgrep, Fortify, Coverity, or Snyk. Corgea currently supports these scanners, with Veracode and Sonarqube support on the roadmap. ## Corgea Dropsite The Corgea Dropsite is a web interface that allows you to easily add your project to Corgea for analysis. It provides several options to upload your code and reports from various security scanners. The Dropsite has a file size limit of 200MB. For larger projects, please use the Corgea CLI. ### Adding a Project To add a project to Corgea, follow these steps: Navigate to the Dropsite page by clicking on the "Add Project" button in the Corgea Projects page or the Scans page. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/add_project.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=a5c3236d7c3b96e8dd8098a04db3d612) On the Dropsite page, you will see several options to add your project: ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/dropsite_add_project.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=9485d69a1856ecf518b80b3e0514e4c9) #### Connect Your Repository (Recommended) This option allows you to connect your code repository directly to Corgea using a configured source control integration, including GitHub, GitLab, Azure DevOps, Bitbucket, or Harness. Click the appropriate source control integration to authorize Corgea to access your repositories. Select the repository you want to add to Corgea. #### Add a Public Repository If your repository is publicly accessible, you can provide the URL to add it to Corgea. Click on the "Add a public repository" accordion. 2\. Enter the URL of your public repository in the input field. Click the "Add" button. #### Web Upload This option allows you to upload a ZIP file containing your project's code. Click on the "Web upload" accordion. Click the "Upload" button and select the ZIP file containing your project's code. > [!TIP] > > To reduce file size and improve processing speed, exclude third-party libraries and build artifacts (e.g., node\_modules, vendor, dist) when uploading your project. This can be done by downloading a zip from your repository directly. > [!WARNING] > > Remember that the web upload has a 200MB file size limit. For larger projects, use the Corgea CLI. After adding your project, you can proceed to the next step to upload a report from a supported security scanner. #### Uploading a Report ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/upload_report.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=ac858a4bdf28e8cc2e46552db583208a) **1. Upload the report** Select the report file (typically a JSON file) from your local machine, and drop it into the upload box. \[!NOTE] Corgea supports Checkmarx (JSON), CodeQL (JSON), Snyk (SARIF), Semgrep (JSON), Fortify (FPR), and Coverity (XML) scans. **2. Processing** Once the report is uploaded successfully, Corgea will process your project and report. **3. View results** You will be redirected to the Corgea dashboard, where you can view the analysis results for your project. By following these steps, you can easily add your project and upload security reports to Corgea for analysis and remediation. ### Corgea CLI The Corgea CLI (Command-Line Interface) provides advanced features for integrating Corgea with your CI/CD pipeline, performing custom scans, and uploading large projects (>200MB). Click on the "Corgea CLI" accordion to learn more about installing and using the [CLI](install_cli). You can install the Corgea CLI using pip: ```bash theme={null} pip install corgea-cli ``` [More on the CLI here](install_cli) #### Upload with the CLI **1. Go to repository** Go to the repository you want to scan: ```bash Bash theme={null} cd <> ``` **2. Run the scan** ```bash Semgrep theme={null} corgea scan semgrep ``` ```bash Snyk theme={null} corgea scan snyk ``` ```bash Custom project name theme={null} corgea upload report.json --project-name my-service ``` ```bash Checkmarx theme={null} # Create a scan with a JSON output for example: cx scan create --project-name juice-shop -s . --branch master --scan-types sast --report-format json --output-name report #Upload the vulnerability report to Corgea corgea upload report.json ``` ```bash CodeQL theme={null} corgea upload ``` ```bash Fortify theme={null} corgea upload ``` ```bash Coverity theme={null} corgea upload ``` Run these commands from the repository root. In CLI 1.14.0 and later, `corgea upload` automatically includes `corgea.yaml` and `corgea.yml` policy files from the current directory and its subdirectories, even if the report does not reference them. In CLI 1.14.2 and later, the CLI can also locate source files when the report records a different base directory, such as a build agent's path. See [CLI](/cli). **3. See Results** Once a scan is completed a scan report will be generated in the repository folder and a copy will be sent to Corgea for processing. ![](https://mintcdn.com/corgea/uxLuQR4653lM43Tj/images/completed-scan.png?fit=max\&auto=format\&n=uxLuQR4653lM43Tj\&q=85\&s=5e7ee36166bd94cddeb3f918c2bc53bc) **4. Issue Fixes** 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 [fixes](fixes) to learn more. ## Troubleshooting > **Command Not Found** > > This error happens because you haven't installed the Corega CLI or its not available in your PATH. > > ``` > bash: corgea: command not found > ``` > > Follow the instructions in the [install CLI section](/cli) to install the CLI. > **Invalid token provided.** > > Double check you have logged into the CLI with the correct token from **Settings → Automation → [API token](https://www.corgea.app/settings/integrations/api-token/)** > **Not Logged In** > > You might receive an error that you're not logged into your SAST/SCA tool. > > Some tools require you to login to use the tool. For example, you can login to Semgrep with the following command: > > ``` > semgrep login > ``` > **Git Show Failed to Run** > > You might receive an error that you're not logged into your SAST/SCA tool. > > Some tools require you to login to use the tool. For example, you can login to Semgrep with the following command: > > ``` > Command failed with output: > fatal: not a git repository (or any of the parent directories): .git > > > Failed to run 'git show -s --format=%B'. Possible reasons: > > - the git binary is not available > - the current working directory is not a git repository > - the current working directory is not marked as safe > (fix with `git config --global --add safe.directory $(pwd)`) > > Try running the command yourself to debug the issue. > Could not start scan Command failed with exit code: 128 > ``` # User Management Source: https://docs.corgea.app/user_management Manage your users in Corgea ## Overview The User Management section of Corgea is designed to help administrators effectively manage user accounts. This includes the ability to add new users, as well as deactivate and reactivate existing users. This guide provides a comprehensive overview of these processes. > [!NOTE] > > User creation is limited by the number of licensed seats in your current plan. ## Billing and seats Go to **Settings → Company → [Billing](https://www.corgea.app/settings/company/billing/)** to: * Upgrade your plan * Adjust seat quantity during checkout * Open the billing portal to view invoices and manage payment methods > [!NOTE] > > Viewing Billing requires the **Can view company** permission. Upgrading your plan, changing seat quantity, and opening the billing portal require the **Can change company** permission. If you reach your licensed user limit, upgrade your plan or increase seats from Billing before adding more users. ## Company name Company admins can rename the company from **Settings → Personal → [Profile](https://www.corgea.app/settings/user/)**, or from the **Company Settings** tab of **Settings → User Management → [Users](https://www.corgea.app/settings/company/members/)**. The name is visible to everyone in your workspace. Everyone else sees it as read-only. ## Timezone settings Corgea displays dates and times, including scan dates, in your effective timezone. Company admins set the default for everyone under **Default Timezone** on the **Company Settings** tab of **Settings → User Management → [Users](https://www.corgea.app/settings/company/members/)** by selecting a timezone and clicking **Save**. The company default is UTC until an admin changes it. To use a different timezone for your account, open **Settings → Personal → [Preferences](https://www.corgea.app/settings/user/preferences/)** and select a timezone under **Regional**. The change saves automatically. This personal setting overrides the company default; select **Company default** to follow the company setting again. ## Email verification for password authentication If email verification is enabled for your company, Corgea sends a one-time verification code after you sign in with a password or set a password from a magic link. Enter the code from the email on the **Enter your sign-in code** page and select **Verify and continue**. The code expires in 10 minutes. If you select **Resend code**, only the newest code is valid. > ![One-time sign-in code email](https://mintcdn.com/corgea/wXzytKO57N5Fqd4_/images/otp_email.png?fit=max\&auto=format\&n=wXzytKO57N5Fqd4_\&q=85\&s=536ffd4571bedc9080f4a7ffbdb12c93) > ![Enter your sign-in code with a verification code filled in](https://mintcdn.com/corgea/wXzytKO57N5Fqd4_/images/otp_verify_code.png?fit=max\&auto=format\&n=wXzytKO57N5Fqd4_\&q=85\&s=c8b3392d55ac492a9b0f0b32e1d72a34) This extra verification step does not apply to SAML SSO or service accounts. ## Add a user To enhance the security and functionality of Corgea, users can be added with specific roles and permissions. **1. Go to Users** Go to **Settings → User Management → [Users](https://www.corgea.app/settings/company/members/)** in the Corgea dashboard. **2. Create User** A modal will appear for you to enter the user's details. * Email Address: Must be unique for each user. This will be used for all communications and as their login identifier. * First Name: The user's given name. * Last Name: The user's family name or surname. Submit User Information: After entering the details, click the 'Add User' button to create the new user account. **3. Email Confirmation** The user will receive an automated email with instructions to register and set their password. ## Deactivate an existing user In situations where it is necessary to restrict access, Corgea allows for the deactivation of user accounts. Users that have been deactivated cannot login into the system or reset their password. **1. Go to Users** Go to **Settings → User Management → [Users](https://www.corgea.app/settings/company/members/)** in the Corgea dashboard. **2. Deactivate User** Find the user in the table and click the **Deactivate** link. #### Implications * Access Revoked: Deactivated users will lose access to their accounts immediately and cannot log in or reset their password. * Data Preservation: The user's data and settings are preserved for future reactivation. ## Activate an existing user Reactivating a user restores their access to Corgea, allowing them to log in and reset their password if necessary. **1. Go to Users** Go to **Settings → User Management → [Users](https://www.corgea.app/settings/company/members/)** in the Corgea dashboard. **2. Activate User** Find the deactivated user in the table and click the **Activate** link. #### Implications * Password Reset: Users may need to reset their password upon reactivation, depending on the duration of deactivation and security policies in place. * Role Review: It's advisable to review and adjust the user's roles and permissions if necessary. # Visual Studio 2022 Source: https://docs.corgea.app/vs2022_extension Bring Corgea to your Visual Studio Code Corgea is a Visual Studio extension that helps developers triage false positive SAST (Static Application Security Testing) findings and automatically fix insecure code. It integrates with the Corgea cloud service to provide a seamless experience within Visual Studio. > [!NOTE] > > For any issues or support, please email [support@corgea.com](mailto:support@corgea.com). ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/vs2022.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=613cb835a7ab4c8cd906cf6d16f328eb) ## Installation 1. [Install](https://marketplace.visualstudio.com/items?itemName=Corgea.corgea) the extension from the Visual Studio Marketplace. OR 1. Open Visual Studio 2022. 2. Go to `Tools` > `Extensions and Updates`. 3. Search for "Corgea" in the Online section. 4. Click `Download` and follow the prompts to install the extension. ## Setup 1. After installing the extension, restart Visual Studio. 2. Go to `Tools` > `Corgea` > `Login`. 3. Enter your Corgea URL (default:[https://corgea.app](https://corgea.app)) and your API Key to authenticate. ## Usage ### Fetch Vulnerabilities 1. Open your solution in Visual Studio. 2. Go to `Tools` > `Corgea` > `Fetch Vulnerabilities`. 3. The Vulnerability Tool Window will open, displaying a list of vulnerabilities found in your project. ### View Vulnerability Details 1. In the Vulnerability Tool Window, double-click on a vulnerability to open the Vulnerability Details Tool Window. 2. This window provides detailed information about the vulnerability, including: * Classification (e.g., SQL Injection, Cross-Site Scripting) * Urgency level * Status (e.g., fix available, false positive) * Code diff showing the proposed fix * Issue description * Explanation of the fix ### Apply Fix If a fix is available for the vulnerability, you can apply it directly from the Vulnerability Details Tool Window: 1. Review the code diff and the explanation of the fix. 2. Click the "Apply Fix" button. 3. The modified code will be applied to your project. ### Mark as False Positive If you determine that a vulnerability is a false positive, you can mark it as such: 1. In the Vulnerability Details Tool Window, click the "See in Corgea" button. 2. This will open the vulnerability details in the Corgea web application. 3. Follow the instructions in the Corgea web app to mark the vulnerability as a false positive and provide reasoning. ## Additional Features * The extension integrates with Visual Studio's secure storage to securely store your Corgea account credentials. * It automatically detects the active project in your solution and fetches vulnerabilities for that project. * The Vulnerability Details Tool Window provides a convenient way to view and navigate to the vulnerable code in your project. # Visual Studio Code and Cursor Source: https://docs.corgea.app/vsc_extension Bring Corgea to Visual Studio Code and Cursor ## Introduction Corgea is a powerful extension for Visual Studio Code and Cursor designed to enhance security practices by automatically fixing vulnerabilities in code. It integrates artificial intelligence to provide real-time security insights, making secure coding more accessible and effective. The same extension runs in both editors. It is published on the [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=Corgea.corgea) for Visual Studio Code and on [Open VSX](https://open-vsx.org/extension/Corgea/corgea) for Cursor. > [!NOTE] > > For any issues or support, please email [support@corgea.com](mailto:support@corgea.com). ## Features ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/vsc_extension.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=aedfe3983e6fe0dfa3876dc8c9df034a) * **AI-Generated Fixes**: Offers intelligent, context-aware fixes for detected vulnerabilities. * **Vulnerability Management Panel**: A dedicated sidebar that lists detected vulnerabilities, allowing for easy management and review. * **Diff Application**: Enables direct application of suggested patches through an interactive interface. * **Detailed Vulnerability Insights**: Displays comprehensive details about each vulnerability in a separate webview panel. * **Secure API Integration**: Manage your API key and Corgea service endpoint securely within your editor. * **User Authentication Management**: Provides functionalities for securely logging in and out, and managing API keys. ## Prerequisites Before installing the Corgea extension, ensure you have the following: * **Corgea account**: have an active Corgea account. * **One of the following editors**: * **Visual Studio Code (Version 1.50+)**: Download and install from [Visual Studio Code website](https://code.visualstudio.com/). * **Cursor**: Download and install from [Cursor website](https://cursor.com/). ## Installation Guide ### Step 1: Install the Extension **Visual Studio Code** 1. [Install](https://marketplace.visualstudio.com/items?itemName=Corgea.corgea) the extension from the Visual Studio Marketplace. Alternatively, open the Extensions view (`Ctrl+Shift+X`, or `Cmd+Shift+X` on macOS), search for **Corgea**, and click **Install**. **Cursor** 1. Open the Extensions view (`Ctrl+Shift+X`, or `Cmd+Shift+X` on macOS). 2. Search for **Corgea**. 3. Select the extension published by Corgea and click **Install**. Cursor installs the extension from [Open VSX](https://open-vsx.org/extension/Corgea/corgea). ### Step 2: Login ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/vsc_login.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=0e2d8c5c73a6f4be0d4911c6ff6895e3) 1. After installation, open the Command Palette by pressing `Ctrl+Shift+P` (`Cmd+Shift+P` on macOS). 2. Type `Corgea: Login` and press Enter. 3. Follow the prompts to input your Corgea URL. If you are using the default URL (corgea.app), it will be prefilled. 4. Enter your API key when prompted. You can find it under **Settings → Automation → [API token](https://www.corgea.app/settings/integrations/api-token/)** in the Corgea dashboard. ## Usage ### Viewing Vulnerabilities ![](https://mintcdn.com/corgea/mpJUc1GyXtnVYEyT/images/vsc_list.png?fit=max\&auto=format\&n=mpJUc1GyXtnVYEyT\&q=85\&s=c94d870845d43d543ff7a07d0f742c5e) * To view the list of detected vulnerabilities, click on the "Vulnerabilities" icon in the sidebar. This panel will display all the current issues along with their severity and location in your code. ### Applying Fixes ![](https://mintcdn.com/corgea/y3xW6TraK0Q97XaD/images/issue_fixes/auto_fix_vscode_apply_fix.png?fit=max\&auto=format\&n=y3xW6TraK0Q97XaD\&q=85\&s=7b7632abb9a962f662feefb9107a6a7b) * Click on a vulnerability in the sidebar to open its details in a new webview panel. * The details panel shows the vulnerability context and suggested fix so you can review it before applying changes. * Corgea generates fixes with AI and runs quality checks before surfacing them, but you should still validate the change in your codebase. * To apply a fix, click the `Apply Fix` button in the details panel. Corgea updates the related files automatically. * Save the updated files. ### Logging Out * To login into another user or log out, use the Command Palette (`Ctrl+Shift+P`, or `Cmd+Shift+P` on macOS) and select the respective commands (`Corgea: Login` or `Corgea: Logout`). ## Release Notes Full release notes are found on the extension's [change log page](https://marketplace.visualstudio.com/items/Corgea.corgea/changelog). You can also see the latest version published for Cursor on [Open VSX](https://open-vsx.org/extension/Corgea/corgea). # Vulnerabilities Workbench Source: https://docs.corgea.app/vulnerabilities Review and triage findings across your organization ## Overview The **Vulnerabilities** page provides an organization-wide view of open security findings. Use it to review findings across projects, investigate details, export results, and apply triage decisions without opening each scan separately. > [!NOTE] > > The Vulnerabilities Workbench is available to organizations where it has been enabled by Corgea. Contact your Corgea representative to request access. Users also need permission to view at least one finding type. ![Vulnerabilities Workbench with finding-type tabs, status controls, search, a filter icon, and grouped findings](https://mintcdn.com/corgea/K88fBiyu9iuG0Rzy/images/vulnerabilities/vulnerabilities_workbench.png?fit=max\&auto=format\&n=K88fBiyu9iuG0Rzy\&q=85\&s=a772395a079cec010b245688c218e7f2) Findings are separated into these tabs: * **Secrets** * **SAST** * **Logic & Auth** * **SCA Packages** * **Containers** * **IaC** Each tab is available only when you have permission to view that finding type. The badge on a tab shows its unfiltered open-finding count. Counts of 1,000 or more are shortened (for example, 1.8K). ## Find and review findings Select a tab, then expand its groups and projects to reach individual findings. Grouping is tailored to each finding type—for example, SCA findings begin with packages, container findings with images, and IaC findings with rules. Counts of 1,000 or more are shortened (for example, 24.6K). Point at a shortened count to see the exact number. Use **Previous**, **Next**, and page numbers, when they appear, to move through grouped results. Each list shows the current row range and a total when Corgea has one. Use the status controls to switch between **Open**, **Fixed**, **False Positive**, and the other statuses available for that finding type. Click the filter icon to show severity, project, team, and tag filters. A count on the icon shows how many of those filters are set while the row is hidden. Hiding the row leaves them active. Selecting multiple tags shows findings from projects that have any selected tag. Tag matching is case-sensitive and must match the stored project tag exactly. SCA Packages adds a reachability filter on the main toolbar. Use the **Team** filter on any tab to show findings from projects owned by the selected team that you have permission to view. Combined with a project filter, it shows only projects that match both filters. The team filter also applies when expanding groups, exporting filtered results, and selecting all findings matching the current filters. ![Vulnerabilities Workbench with the filter row open and the Team menu showing a team search](https://mintcdn.com/corgea/K88fBiyu9iuG0Rzy/images/vulnerabilities/vulnerabilities_team_filter.png?fit=max\&auto=format\&n=K88fBiyu9iuG0Rzy\&q=85\&s=a2bbade0476706a7325eaa2c60458fbc) Select a finding to open the same details panel used on scan pages. From the panel, you can review evidence, assign the finding, and change its status with **Current Status**. Use **Open Full View** when it is shown to open the full finding page. The address bar keeps the selected finding, so opening that link again restores the panel when the finding is still in the current results. A comment is required when changing a disposition, and it has to explain the decision rather than repeat it—see [Triage Justifications](/triage_justifications). When you mark a supported finding as accepted risk, you can also choose when that expires. SAST findings carried forward from a previous scan during an incremental scan retain their triage status, justification, assignee, due date, and accepted-risk expiry date. Carrying a finding forward does not reset or remove its due date or expiry date. When Corgea recognizes a finding at a corrected location, it can carry over an existing triage decision without replacing a decision already made on the new finding. In incremental branch scans, a matching finding in an unchanged file can also inherit the earlier decision; findings in files changed by that scan remain open for review. The finding history records **Decision carried over from the finding's previous location**, with the previous location and original decision date when available. SCA and container findings show package details and history in that panel, plus reachability when it is available. If your company requires triage approval for **False positive** or **Accepted risk**, changing a **Secrets**, **SAST**, **Logic & Auth**, or **SCA Packages** finding to that disposition creates a request and leaves the finding unchanged. **Containers** and **IaC** change immediately. A different authorized reviewer can approve or reject a request from the approvals queue or the finding details. Requesters can withdraw their own pending requests. ## Export findings Click **Export** to download a CSV containing the findings that match the active tab, status, search, and filters. The export includes the latest occurrence of each finding and is limited to 25,000 rows. To export only particular findings, select them and click **Export selection** in the action bar. ## Triage findings in bulk Select individual findings or an expanded group. You can also choose **Select all findings matching the current filters** after making an initial selection. The bulk action bar lets you: * Assign findings to a team member * Change the selection to another status the active tab supports, including reopening a finding or accepting risk * Export the selection ![Bulk action bar with the selected finding, project, and team counts, and Assign, Change status, Export selection, and Clear](https://mintcdn.com/corgea/K88fBiyu9iuG0Rzy/images/vulnerabilities/bulk_action_bar.png?fit=max\&auto=format\&n=K88fBiyu9iuG0Rzy\&q=85\&s=a91706f961b620bd2cfd2fefaced9e9b) Click **Change status**, choose a **Decision**, and add a comment that explains the change. The menu lists that tab's statuses except the one you are already viewing. For **Accepted Risk**, set **Expiry Date (Optional)** to a future time, or leave it empty so the acceptance does not expire. After that time, the finding returns to **Open** and Corgea sends a notification. IaC findings have no expiry date. When your company requires approval, a bulk change to **False positive** or **Accepted Risk** on **Secrets**, **SAST**, **Logic & Auth**, or **SCA Packages** is submitted for approval, and those findings keep their current status until it is approved. **Containers** and **IaC** change immediately. Someone who can approve triage requests applies the change immediately on every tab. ![Change Status dialog with a Decision menu and a required comment. Expiry Date appears after Accepted Risk is selected.](https://mintcdn.com/corgea/K88fBiyu9iuG0Rzy/images/vulnerabilities/bulk_change_status.png?fit=max\&auto=format\&n=K88fBiyu9iuG0Rzy\&q=85\&s=c8467f8f97b15544aa78f07e50908291) Bulk status changes require a comment, and the same [justification requirement](/triage_justifications) applies: a comment that only repeats the decision is rejected and no status is changed. The action bar summarizes the number of selected findings, projects, and teams, and reports any findings that were skipped. A bulk selection can contain up to 1,000 findings. > [!NOTE] > > Assignment and disposition controls appear only when you have permission to change that finding type. Export remains available with view permission. # Vulnerability Disclosure Policy Source: https://docs.corgea.app/vulnerability-disclosure Guidelines for security researchers to responsibly report vulnerabilities in Corgea products and services At Corgea, we take the security of our products and services seriously. We appreciate the security research community's efforts in helping us maintain the highest security standards. This Vulnerability Disclosure Policy outlines how security researchers can responsibly disclose security vulnerabilities to us. ## Our Commitment We are committed to: * Working with security researchers to understand and resolve security vulnerabilities quickly and responsibly * Acknowledging your contribution to improving our security * Keeping you informed about the progress of resolving reported vulnerabilities * Treating security researchers fairly and with respect ## Scope This policy applies to vulnerabilities discovered in any of Corgea's products, services, and infrastructure, including but not limited to: ### In Scope * **Web Application**: corgea.app and all related subdomains * **API**: All Corgea API endpoints and services * **Command Line Interface (CLI)**: Corgea CLI tool * **IDE Extensions**: * Visual Studio Code extension * Visual Studio 2022 extension * **Integrations**: GitHub, GitLab, Azure DevOps, Bitbucket, Jira, Slack, and other official integrations * **Infrastructure**: Servers, databases, and systems directly controlled by Corgea ### Out of Scope The following are explicitly **excluded** from this policy: * **Third-party dependencies**: Vulnerabilities in third-party libraries, frameworks, or services (please report these directly to the respective maintainers) * **Physical security**: Physical access to Corgea offices or infrastructure * **Social engineering**: Phishing, vishing, or other social engineering attacks against Corgea employees or users * **Denial of Service (DoS)**: DoS or DDoS attacks * **Spam**: Email or comment spam * **Issues already known**: Vulnerabilities that have already been reported or are publicly known If you're unsure whether a vulnerability is in scope, please contact us at [security@corgea.com](mailto:security@corgea.com) before testing. ## Guidelines for Security Research When conducting security research on Corgea products and services, we ask that you: ### Do * ✅ Comply with all applicable laws and regulations * ✅ Only test against accounts you own or have explicit permission to test * ✅ Respect user privacy - do not access, modify, or delete user data * ✅ Use test accounts and test data whenever possible * ✅ Report vulnerabilities as soon as possible after discovery * ✅ Provide detailed information to help us reproduce and fix the issue * ✅ Give us reasonable time to fix vulnerabilities before any public disclosure * ✅ Keep vulnerability details confidential until we've resolved the issue ### Don't * ❌ Access, modify, or delete data belonging to other users * ❌ Execute attacks that could harm the availability of our services (DoS/DDoS) * ❌ Conduct attacks on our physical facilities or social engineering attacks * ❌ Use automated scanners in a way that negatively impacts our services * ❌ Publicly disclose vulnerability details before we've had a chance to fix them * ❌ Demand compensation or threaten to publish vulnerabilities * ❌ Violate any laws or breach any agreements in your research ## How to Report a Vulnerability If you believe you've discovered a security vulnerability in any Corgea product or service, please report it to us by emailing: **[security@corgea.com](mailto:security@corgea.com)** ### What to Include in Your Report To help us understand and address the issue quickly, please include: 1. **Description**: A clear description of the vulnerability 2. **Impact**: The potential impact and severity of the vulnerability 3. **Steps to Reproduce**: Detailed steps to reproduce the vulnerability 4. **Proof of Concept**: Code, screenshots, or videos demonstrating the vulnerability (if applicable) 5. **Affected Components**: Which products, services, or endpoints are affected 6. **Your Information**: Your name or handle (if you'd like recognition) and contact information ### Encrypted Communication For highly sensitive vulnerability reports, we encourage you to encrypt your communication. Please contact us at [security@corgea.com](mailto:security@corgea.com) to request our PGP public key. ## Our Response Process When you report a vulnerability, here's what you can expect from us: ### 1. Acknowledgment * We will acknowledge receipt of your vulnerability report within **72 hours** (3 business days) * You'll receive a confirmation email with a tracking reference ### 2. Assessment * Our security team will assess the vulnerability to determine its validity and severity * We may reach out for additional information or clarification ### 3. Status Updates * We will keep you informed about the progress of addressing the vulnerability * You can expect regular updates on the status of your report ### 4. Resolution * We will work diligently to resolve confirmed vulnerabilities based on their severity * **Critical vulnerabilities**: 30 days * **High severity**: 60 days * **Medium severity**: 90 days * **Low severity**: 120 days These are target timelines and may vary depending on the complexity of the fix. ### 5. Recognition * Once the vulnerability is resolved, we will publicly acknowledge your contribution (if you wish) * Researchers who submit valid vulnerabilities may receive Corgea swag as a token of our appreciation ## Responsible Disclosure We believe in coordinated disclosure of security vulnerabilities. We ask that you: * **Do not disclose the vulnerability publicly** until we have had a reasonable opportunity to investigate and address it * **Notify us immediately** if you become aware that vulnerability details have been disclosed to others * Work with us on a reasonable timeline for public disclosure We commit to working with you on a disclosure timeline that gives us adequate time to fix the issue while respecting the security community's interest in timely disclosure. ## Safe Harbor Corgea is committed to protecting security researchers who act in good faith. We will not pursue legal action against researchers who: * Follow the guidelines outlined in this policy * Act in good faith and make a reasonable effort to avoid privacy violations, destruction of data, and interruption or degradation of our services * Do not exploit a security vulnerability beyond what is necessary to demonstrate the issue * Report vulnerabilities promptly and work with us to resolve them We consider security research conducted under this policy to be: * **Authorized** under the Computer Fraud and Abuse Act (CFAA) and similar laws * **Exempt** from restrictions under the Digital Millennium Copyright Act (DMCA) * **Protected** from legal action by Corgea If you follow this policy in good faith, we will not bring any legal action against you, and we will work with third parties to ensure they take a similar approach. ## Recognition and Hall of Fame We value the contributions of security researchers who help us improve our security posture. Researchers who report valid vulnerabilities may be recognized in the following ways: * **Public acknowledgment** on our Security Hall of Fame (with your permission) * **Corgea swag** including t-shirts, stickers, and other merchandise * **Private thank you** if you prefer to remain anonymous To be recognized, you must: * Report a valid, in-scope vulnerability * Follow the guidelines in this policy * Allow us to verify and fix the vulnerability before public disclosure ## Questions or Concerns If you have any questions about this Vulnerability Disclosure Policy or need clarification on what is in scope, please contact us at: **[security@corgea.com](mailto:security@corgea.com)** We're here to help and appreciate your efforts in keeping Corgea secure. ## Policy Updates This policy may be updated from time to time. The latest version will always be available on this page. We encourage you to review this policy periodically. *** **Last Updated**: January 2025 Thank you for helping us keep Corgea and our users secure! 🛡️ # Webhooks Source: https://docs.corgea.app/webhooks Automate HTTP callbacks from Corgea to any external system ## What are Webhooks? Webhooks are automated HTTP callbacks that allow Corgea to send real-time notifications to your external systems when specific events occur. Instead of continuously polling our API to check for updates, webhooks push event data directly to your specified endpoint the moment something happens. ### Key Benefits * **Real-time notifications** - Receive instant updates when security issues are found, status changes occur, or scans complete * **Automation** - Trigger workflows in external tools like Slack, Zapier, or custom applications * **Efficiency** - No need to poll APIs - we push data to you when events happen * **Flexibility** - Subscribe only to the events you care about and filter by project, status, or scheduled scan * **Reliability** - Built-in retry logic and delivery tracking ensure your notifications get through ### Supported Event Types Corgea supports webhooks for the following events: **Issue Events:** * `issue.status_changed` - Triggered when an issue's status is updated (e.g., open → fixed) * `issue.assigned` - Triggered when an issue is assigned to a team member These events cover SAST, SCA, container, and IaC findings. For SCA, container, and IaC findings detected in multiple scans, the event identifies the most recent occurrence and links to its finding page. **SLA Events:** * `sla.violation` - Triggered when the daily SLA job finds one or more SAST or SCA issues past their remediation or escalation deadline (configured per SLA in [SLA Management](sla_management)) **Scan Events:** * `scan.started` - Triggered when a security scan begins * `scan.completed` - Triggered when a scan finishes successfully * `scan.failed` - Triggered when a scan encounters an error * `scheduled_scan.daily_report` - Sent daily for scheduled scans completed in the last 24 hours, including runs with no new findings. Reports new open code findings and open finding totals. See [Notifications](/notifications#daily-scheduled-scan-report). > [!NOTE] > > Scan lifecycle events (`scan.started`, `scan.completed`, `scan.failed`) include `data.message` — a short plain-text summary you can drop into Slack, Zapier, or other chat tools. They also include triage fields: `pull_request_id`, `scan_url`, `true_positive_count`, `project_name`, and `status`. > > For Slack Workflow Builder (`Type = Slack` + `hooks.slack.com/triggers/...`), Corgea flattens **only** `scan.started` / `scan.completed` / `scan.failed` and `webhook.test` into top-level keys. Do not map nested `data.*` in Slack — that causes HTTP 400. Other event types on the same Slack webhook keep the nested envelope. See [Slack](slack). **User Auth Events:** * `user.login` - Triggered when a user successfully logs in * `user.login_failed` - Triggered when a user login attempt fails *** ## How Webhooks Work ### The Webhook Lifecycle **1. Event Occurs** Something happens in Corgea (e.g., a scan completes, an issue status changes) **2. Webhook Triggered** The system identifies all webhooks subscribed to that event type **3. Filtering Applied** Project, status, scheduled scan, PR-only, and completed-with-findings filters determine if the webhook should fire **4. Payload Built** By default, a standardized JSON envelope is constructed with event details (or your custom body template is used, if configured). For Slack Workflow Builder (`Type = Slack` + `triggers/` URL), Corgea flattens the HTTP body for `scan.*` and `webhook.test` only; other events stay nested. **5. HTTP POST Request** The payload is sent to your webhook URL with security headers **6. Retry Logic** If the request fails, automatic retries occur with exponential backoff **7. Delivery Logged** All attempts are tracked in the delivery history for troubleshooting ### Payload Structure By default, webhook payloads follow a standardized nested envelope (Zapier / Other). Scan lifecycle events include `data.message` plus triage fields: ```json webhook-payload.json theme={null} { "event_id": "550e8400-e29b-41d4-a716-446655440000", "event_type": "scan.completed", "timestamp": "2025-01-15T14:30:00.000Z", "data": { "company": "company-uuid", "scan_id": "scan-uuid", "run_id": "run-12345", "project": { "id": "project-uuid", "name": "My Application" }, "project_name": "My Application", "branch": "feature/auth", "engine": "corgea-blast", "scan_type": "full", "status": "completed", "pull_request_id": "42", "scan_url": "https://app.corgea.app/project/project-uuid/?scan_id=scan-uuid", "true_positive_count": 5, "summary": { "total_issues": 12, "issues_with_fixes": 7, "issues_without_fixes": 5, "true_positive_count": 5, "true_positive_issues_with_fixes": 3 }, "message": "Scan completed for My Application (PR #42): 5 true-positive findings (3 with fixes). View: https://app.corgea.app/project/project-uuid/?scan_id=scan-uuid", "scheduled_scan_ids": ["scheduled-scan-uuid"], "processed_at": "2025-01-15T14:30:00.000Z", "created_at": "2025-01-15T14:00:00.000Z" } } ``` `summary.total_issues` counts all non-deleted issues (including false positives and code-quality). `true_positive_count` is the triage count used in `message` and Scan Event Filters. | Event | Example `data.message` | | - | - | | `scan.started` | `Scan started for My Application (PR #42).` | | `scan.completed` | `Scan completed for My Application (PR #42): 5 true-positive findings. View: ...` | | `scan.failed` | `Scan failed for My Application (PR #42): Scanner timed out. View: ...` | `true_positive_count` counts non-deleted security findings that are not false positives (same logic as the scan UI: excludes `status=false_positive`, `hold_reason=false_positive`, and `detected_by=code-quality`). The optional `(N with fixes)` suffix in `scan.completed` messages counts fixes only among those true-positive findings (not all issues on the scan). > [!TIP] > > **Slack Workflow Builder:** when `Type = Slack` and the URL is `hooks.slack.com/triggers/...`, Corgea POSTs a **flat** body for `scan.*` and `webhook.test` (top-level `message`, `pull_request_id`, `scan_url`, `true_positive_count`, `company`, etc.). Nested `data.*` mapping is unsupported in Slack and causes HTTP 400. Non-scan events on that webhook are **not** flattened. See [Slack](slack). **Example `sla.violation` payload** (from SLA Management daily job): ```json sla-violation-payload.json theme={null} { "event_id": "550e8400-e29b-41d4-a716-446655440001", "event_type": "sla.violation", "timestamp": "2025-01-15T14:30:00.000Z", "data": { "company": "1", "sla": { "id": 3, "rule_type": "code", "urgency": ["CR", "HI"], "remediation_days": 7, "escalation_days": 3 }, "notification_type": "remediation", "issue_kind": "SAST", "issue_count": 5, "summary_message": "Plain-text summary (same style as email body)...", "projects": [ { "id": "project-uuid", "name": "My Application", "url": "https://app.corgea.com/project/project-uuid", "issue_count": 5, "urgency_counts": { "Critical": 2, "High": 3 } } ] } } ``` | Field | Description | | - | - | | `notification_type` | `remediation` or `escalation` | | `issue_kind` | `SAST` or `SCA` | | `sla.rule_type` | `code` (SAST) or `sca` (dependency) | | `projects` | One entry per affected project; used for webhook **project filters** | Subscribe to `sla.violation` under **Integrations → Webhooks**, or attach a webhook from the [SLA Management](sla_management) form (existing webhooks are auto-subscribed). **Example `scheduled_scan.daily_report` payload**: ```json scheduled-scan-daily-report-payload.json theme={null} { "event_id": "550e8400-e29b-41d4-a716-446655440002", "event_type": "scheduled_scan.daily_report", "timestamp": "2025-01-15T14:30:00.000Z", "data": { "title": "Corgea Scheduled Scan Report", "company": "1", "company_name": "Acme Security", "total_new_issues": 4, "message": "4 new findings in Payments API for Acme Security.", "scan_runs": [ { "scheduled_scan_name": "Weekly Production Scan", "project": "Payments API", "new_issue_count": 4, "open_issue_count": 12, "scan_url": "https://www.corgea.app/scans/scan-uuid" } ] } } ``` This event is sent to every webhook subscribed to it. There is no separate on/off switch for webhook delivery, and notification email preferences do not affect it. If you configure **Custom Body** during webhook setup, Corgea sends your rendered JSON object instead of the default payload structure. > [!NOTE] > > The `scheduled_scan.daily_report` event uses the same envelope but has its own `data` schema. See [Payload Examples](#payload-examples) for the full reference. ### Security Features > **HMAC Signature Verification** > > * Corgea automatically generates a secret key when you create a webhook > * Each request includes an `X-Corgea-Signature` header with an HMAC-SHA256 hash of the payload > * Verify the signature with your secret key to ensure the webhook came from Corgea > **Custom Headers** > > * Include headers required by your endpoint (e.g., authentication tokens) > * Configure custom headers during webhook setup > **HTTPS Required** > > * All webhook URLs must use HTTPS (ports 443 or 80 only) > * URLs must not embed credentials in the URL > * Destinations that resolve to private, loopback, link-local, reserved, or multicast addresses are rejected (SSRF protection) > * Operators can optionally restrict hosts with the `WEBHOOK_ALLOWED_HOSTS` setting ### Automatic Retry Logic > [!NOTE] > > If webhook delivery fails, Corgea automatically retries with the following strategy: * **Initial attempt** + **2 retries** = 3 total attempts * **Exponential backoff**: 2 seconds, 4 seconds between retries * **Timeout**: 10 seconds per request * **Auto-pause**: After 10 consecutive failures, the webhook is automatically paused ### Headers Sent with Each Webhook ```text webhook-headers.txt theme={null} Content-Type: application/json X-Corgea-Event: issue.status_changed X-Corgea-Delivery: X-Corgea-Timestamp: X-Corgea-Signature: User-Agent: Corgea-Webhooks/1.0 ``` *** ## Setting Up a Webhook ![Webhooks management interface showing list of configured webhooks](https://mintcdn.com/corgea/JgeRsjW5cn2yU52a/images/webhooks/webhooks_table.png?fit=max\&auto=format\&n=JgeRsjW5cn2yU52a\&q=85\&s=23c5fe597820ac3bdb57560ef29c3b9d) ### Prerequisites > [!TIP] > > Admin or integration management permissions in your Corgea account > [!TIP] > > A webhook endpoint URL that accepts POST requests > [!TIP] > > HTTPS endpoint (required for security) ### Step-by-Step Setup **1. Navigate to Integrations** * Open **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)** in Corgea * Under **Automation Integrations**, open **Webhooks** ![Automation Integrations showing Webhooks active, with Slack and Zapier marked Deprecated](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/webhooks_integrations.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=e84b9d7d75569f68d644ada376ea16bf) > [!WARNING] > > The standalone **Slack** and **Zapier** rows are deprecated. Use **Webhooks** for new setups. Existing Slack/Zapier integrations keep working — open **View All** to test or delete them. **2. Configure Basic Settings** ![Create webhook form showing Name, Webhook URL, and Type fields](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/create_webhook_basic.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=64b04b74bc95600f1c4e58c9a8b94398) * **Name**: A clear label (for example, "Slack Notifications" or "Production Scan Alerts") * **Webhook URL**: Your HTTPS endpoint * **Type**: * `Slack` — Slack Workflow Builder or Incoming Webhook destinations * `Zapier` — Zapier Catch Hooks * `Other` — custom endpoints > [!TIP] > > For Slack, prefer a Workflow Builder URL (`hooks.slack.com/triggers/...`). Corgea flattens `scan.*` and `webhook.test` for those destinations — map top-level `message`, not nested `data.*`. Non-scan events stay nested. Incoming Webhooks (`hooks.slack.com/services/...`) are rejected unless you set a Custom Body whose rendered JSON has a top-level non-empty string `text` field. `{"text": "{{message}}"}` is allowed only for scan lifecycle events and `scheduled_scan.daily_report`. See [Slack](slack). **3. Subscribe to Events** ![Event Subscriptions form with toggles for issue, SLA, scan, user, and scheduled scan events](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/create_webhook_events.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=dffd5f8c779ea28405555be193aae289) Toggle on the events you care about. You can select more than one: * Issue Status Changed * Issue Assigned * SLA Violation (`sla.violation`) * Scan Started / Completed / Failed * User Login / User Login Failed * Scheduled Scan Daily Report (`scheduled_scan.daily_report`) **4. Configure Filters (Optional)** ![Project Scope, Scheduled Scan Scope, Custom Headers, and Custom Body sections](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/create_webhook_scopes.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=b77a4be9aeb754e6b411ca55714f84f6) **Scan Event Filters** (for `scan.*` events) * **Only pull request / merge request scans** — skip scans without a `pull_request_id` * **Only completed scans with true-positive findings** — skip `scan.completed` when `true_positive_count` is 0 (`scan.failed` / `scan.started` are unaffected) **Project Scope** * Leave disabled to receive events from all projects * Enable filtering to limit the webhook to selected projects * For `sla.violation`, the webhook fires if **any** project in the payload matches **Status Change Filter** (for `issue.status_changed`) * Leave empty for all status changes * Or limit to statuses like `fixed` or `false_positive` **Scheduled Scan Scope** (for `scan.*` events) * Leave disabled to receive all scans (manual and scheduled) * Enable it to only fire for selected scheduled scans **5. Add Custom Headers and Body (Optional)** **Custom Headers** Add headers required by your webhook destination. Each service has different requirements: > **Jira Automation** > > **Required Header:** > > ```text theme={null} > X-Automation-Webhook-Token: > ``` > > **How to get your token:** > > 1. In Jira, create an automation rule with an "Incoming webhook" trigger > 2. Copy the secret token provided by Jira > 3. Add it as the header value in Corgea > > [Jira Webhook Documentation](https://support.atlassian.com/cloud-automation/docs/configure-the-incoming-webhook-trigger-in-atlassian-automation/) > **Slack** > > **No custom headers needed** — auth is in the Slack URL. > > Prefer a Workflow Builder URL (`https://hooks.slack.com/triggers/...`). With `Type = Slack`, Corgea flattens `scan.*` and `webhook.test` — map `message`, `pull_request_id`, `scan_url`, `true_positive_count`, `company`. Do **not** map nested `data.*` (Slack returns HTTP 400). Other event types are not flattened. See [Slack](slack). > > Incoming Webhooks (`https://hooks.slack.com/services/...`) need a Custom Body whose rendered JSON has a top-level non-empty string `text` field. Use `{"text": "{{message}}"}` only with scan lifecycle events and `scheduled_scan.daily_report`. > **Microsoft Teams** > > **No custom headers needed** - Teams webhook URLs include authentication in the URL itself. > > Just paste your Teams webhook URL (format: `https://xxx.webhook.office.com/webhookb2/xxx/IncomingWebhook/xxx`) > > > [!NOTE] > > > > Teams incoming webhooks do not validate custom headers. Security is provided by keeping the webhook URL secret. > > [Teams Webhook Documentation](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) > **Custom API with Bearer Token** > > **Header:** > > ```text theme={null} > Authorization: Bearer > ``` > > Common for REST APIs that use JWT or OAuth tokens. > **Splunk HEC** > > **Header:** > > ```text theme={null} > Authorization: Splunk > ``` > > Use this when sending webhook events to a Splunk HTTP Event Collector (HEC) endpoint. > **Custom API with API Key** > > **Headers (choose one):** > > ```text theme={null} > X-API-Key: > ``` > > or > > ```text theme={null} > Authorization: ApiKey > ``` > > Common for simple API key authentication. > **PagerDuty** > > **No custom headers needed** - PagerDuty Events API v2 uses the `routing_key` in the JSON payload for authentication. > > Use the PagerDuty Events API endpoint: `https://events.pagerduty.com/v2/enqueue` > > > [!NOTE] > > > > PagerDuty does not validate custom headers. Authentication is handled via the routing\_key in the request body. > > [PagerDuty Webhook Documentation](https://developer.pagerduty.com/docs/ZG9jOjExMDI5NTgw-events-api-v2-overview) > **Zapier** > > **No custom headers needed** - Zapier webhook URLs include authentication in the URL itself. > > Create a "Webhooks by Zapier" trigger and use the provided URL. > > > [!NOTE] > > > > Zapier Catch Hook does not validate custom headers by default. Security is provided by keeping the webhook URL secret. You can add header validation logic within your Zap if needed. > > [Zapier Webhook Documentation](https://zapier.com/help/create/code-webhooks/trigger-zaps-from-webhooks) > [!TIP] > > If your service isn't listed here, check the service's webhook or incoming webhook documentation for required headers. > [!WARNING] > > **Important:** While Corgea will send any custom headers you configure, not all webhook destinations validate them. Services like Slack, Teams, and Zapier rely on secret URLs rather than header validation. Only add custom headers if your destination service actually requires or validates them (like Jira, custom APIs, etc.). **Custom Body** * Optionally provide a JSON object template for the webhook request body * Leave blank to use Corgea's default payload structure * Supported placeholders: * `{{payload}}` (full default payload object) * `{{time}}` (Unix seconds) * `{{timestamp}}` (ISO 8601 timestamp) * `{{event_type}}` * `{{event_id}}` * `{{message}}` (from `data.message` when present — scan lifecycle and daily report) * If the rendered template is invalid JSON, delivery fails and the error appears in webhook history **6. Save and Activate** * Click **Create Webhook** * Copy the secret key from the popup — Corgea shows it only once ![Webhook Secret Key popup shown once after creating a webhook](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/webhook_secret_key.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=e219c00690cd7873f987954a632fec23) > [!WARNING] > > Save the secret key before closing the dialog. You cannot view it again afterward. Contact support if you need to rotate it. * Click **I've saved the Secret Key** * The webhook is active and will start receiving events **7. Test Your Webhook** * Open the webhook and click **Test Webhook** * Confirm your endpoint returns a 2xx response * For Slack Workflow Builder: expect a flat body with a non-empty top-level `message` and sample triage keys (`pull_request_id`, `scan_url`, `true_positive_count`, etc.) so you can map variables during Test. Nested-only Workflow Builder configs are unsupported. ### Verifying Webhook Signatures > [!NOTE] > > Use the secret key shown at creation time to verify the `X-Corgea-Signature` header on each request. **Python** ```python verify-signature.py theme={null} import hmac import hashlib def verify_webhook_signature(payload, signature, secret): """Verify Corgea webhook signature""" expected_signature = hmac.new( secret.encode('utf-8'), payload.encode('utf-8'), hashlib.sha256 ).hexdigest() return hmac.compare_digest(expected_signature, signature) # In your webhook handler: if not verify_webhook_signature(request.body, request.headers['X-Corgea-Signature'], SECRET_KEY): return HttpResponse(status=403) # Reject invalid signatures ``` **Node.js** ```javascript verify-signature.js theme={null} const crypto = require('crypto'); function verifyWebhookSignature(payload, signature, secret) { const expectedSignature = crypto .createHmac('sha256', secret) .update(payload) .digest('hex'); return crypto.timingSafeEqual( Buffer.from(expectedSignature), Buffer.from(signature) ); } ``` *** ## Use Cases ### 1. Real-time Slack Notifications **Scenario**: Notify your security team in Slack when high-severity issues are found **Setup**: * Create a Slack incoming webhook URL in your Slack workspace * In Corgea, create a webhook with: * Type: `Slack` * URL: Your Slack webhook URL * Events: `scan.completed` * Project Filter: Critical production projects **Result**: Your #security channel gets instant notifications when scans complete *** ### 2. Automated Ticketing for Critical Issues **Scenario**: Automatically create tickets in Jira/Linear when critical issues are detected **Setup**: * Create a Zapier zap or custom endpoint that creates tickets * In Corgea, create a webhook with: * Events: `scan.completed`, `issue.status_changed` * Status Filter: Only `open` status (to avoid duplicate tickets) * Project Filter: Production projects **Result**: High/critical issues automatically become tickets in your project management tool *** ### 3. Risk Acceptance Workflow Integration **Scenario**: Automatically document accepted risks in Jira or Linear when security issues are marked as "Accepted Risk" **Setup**: * Create an endpoint or Zapier integration that creates documentation tickets * In Corgea, create a webhook with: * Events: `issue.status_changed` * Status Filter: Only `accepted_risk` status * Project Filter: All projects or specific high-compliance projects * Configure the integration to: * Create a ticket documenting the risk acceptance * Include issue details (classification, file path, urgency) * Tag with "risk-acceptance" label * Assign to security lead for review **Result**: Every accepted risk is automatically logged in your project management system with full context, creating an audit trail for compliance and risk management reviews *** ### 4. Custom Dashboard Integration **Scenario**: Display real-time security metrics on your internal dashboard **Setup**: * Build an endpoint that receives webhook data and updates your dashboard * In Corgea, create a webhook with: * Events: All scan and issue events * No filters (receive everything) **Result**: Your dashboard shows live security scan results and issue trends *** ### 5. Multi-team Routing **Scenario**: Route different project notifications to different teams **Setup**: * Create separate webhooks for each team: * **Backend Team Webhook**: Project filter = backend projects, Slack channel #backend-security * **Frontend Team Webhook**: Project filter = frontend projects, Slack channel #frontend-security * **DevOps Team Webhook**: Project filter = infrastructure projects, Slack channel #devops-security **Result**: Each team only sees security issues relevant to their projects *** ### 6. Compliance Reporting **Scenario**: Automatically log all security findings to a compliance system **Setup**: * Create an endpoint that writes to your compliance database * In Corgea, create a webhook with: * Events: `scan.completed` * All projects * Store webhook delivery history for audit trail **Result**: Complete audit trail of all security scans for compliance purposes *** ## Troubleshooting ### Viewing Webhook Delivery History **1. Navigate to Webhook History** Navigate to **Integrations** → **Webhooks** ![Webhook delivery history showing recent webhook attempts](https://mintcdn.com/corgea/JgeRsjW5cn2yU52a/images/webhooks/webhook_history.png?fit=max\&auto=format\&n=JgeRsjW5cn2yU52a\&q=85\&s=e0c209104347995d1bde95b867a6bb7d) **2. Access Delivery Log** Click on **History** or **Delivery Log** **3. Review Delivery Details** ![Detailed webhook delivery information including request and response](https://mintcdn.com/corgea/JgeRsjW5cn2yU52a/images/webhooks/webhook_history_details.png?fit=max\&auto=format\&n=JgeRsjW5cn2yU52a\&q=85\&s=14c49d0e334a55ee79a2bdb7f8b5126b) View all webhook delivery attempts with: * Event type and timestamp * HTTP status code * Request/response details * Error messages (if any) * Retry attempts ### Common Issues and Solutions > **Webhook Not Receiving Events** > > **Possible Causes:** > > * Webhook is paused or inactive > * Event subscriptions not configured > * Project, status, or scheduled scan filters excluding events > * Endpoint not returning 2xx status codes > > **Solutions:** > > 1. Check webhook status - ensure it's active (not paused) > 2. Verify event subscriptions are selected > 3. Review filters - temporarily remove project, status, or scheduled scan filters to test > 4. Check your endpoint logs for incoming requests > 5. Test the webhook using the "Test Webhook" button > **Webhook Automatically Paused** > > **Cause:** 10 consecutive delivery failures > > **Solutions:** > > 1. Check the delivery history for error details > 2. Verify your endpoint URL is correct and accessible > 3. Ensure your endpoint returns 2xx status codes > 4. Check for firewall/security rules blocking Corgea's requests > 5. Fix the underlying issue, then **manually re-activate** the webhook > 6. Use "Test Webhook" to verify it's working before re-enabling > **Receiving Too Many Webhook Calls** > > **Solutions:** > > 1. **Use Status Filters**: For `issue.status_changed`, filter to only statuses you care about (e.g., only `fixed` and `false_positive`) > 2. **Use Project Filters**: Only subscribe to specific critical projects > 3. **Use Scheduled Scan Filters**: For scan events, select the scheduled scans that should trigger the webhook > 4. **Reduce Event Subscriptions**: Unsubscribe from events you don't need > 5. **Implement Rate Limiting**: On your endpoint, implement rate limiting or queuing > **Signature Verification Failing** > > **Possible Causes:** > > * Wrong secret key > * Incorrect signature verification logic > * Character encoding issues > > **Solutions:** > > 1. Verify you're using the exact secret key from Corgea > > 2. Ensure you're using HMAC-SHA256 algorithm > > 3. Use the raw request body (not parsed JSON) for verification > > 4. Check for UTF-8 encoding on both sides > > 5. Use `hmac.compare_digest()` (Python) or `crypto.timingSafeEqual()` (Node.js) for timing-safe comparison > > > [!TIP] > > > > Log both the received signature and your computed signature to compare > **Endpoint Timing Out** > > **Cause:** Your endpoint takes longer than 10 seconds to respond > > **Solutions:** > > 1. **Acknowledge Immediately**: Return 200 OK immediately, then process asynchronously > 2. **Use a Queue**: Add webhook payloads to a queue for background processing > 3. **Optimize Processing**: Speed up your webhook handler logic > 4. **Increase Resources**: Scale up your endpoint infrastructure > > **Best Practice Pattern:** > > ```python webhook-handler.py theme={null} > @app.route('/webhook', methods=['POST']) > def handle_webhook(): > payload = request.json > > # Immediately acknowledge receipt > queue.add(process_webhook, payload) > > # Return quickly > return '', 200 > > def process_webhook(payload): > # Do time-consuming work here > ... > ``` > **Duplicate Events** > > **Possible Causes:** > > * Multiple webhooks subscribed to same event > * Retry logic triggering after delayed success > > **Solutions:** > > 1. Check for duplicate webhook configurations > 2. Use `event_id` field for idempotency - store processed event IDs and skip duplicates > 3. Implement idempotency keys in your endpoint > > **Idempotency Pattern:** > > ```python idempotency.py theme={null} > processed_events = set() # Or use Redis/database > > @app.route('/webhook', methods=['POST']) > def handle_webhook(): > event_id = request.json['event_id'] > > if event_id in processed_events: > return '', 200 # Already processed > > # Process event... > processed_events.add(event_id) > return '', 200 > ``` > **Missing Data in Payload** > > **Solutions:** > > 1. Check the webhook delivery history for the full payload > 2. Some fields may be `null` if data doesn't exist (e.g., unassigned issues) > 3. Implement null checks in your handler code > 4. Reference the event-specific payload structure in the delivery history ### Getting Webhook Statistics View performance metrics for your webhooks: 1. Navigate to **Integrations** → **Webhooks** 2. View each webhook's statistics: * **Total Deliveries**: Total number of webhook calls * **Successful Deliveries**: Calls that returned 2xx * **Failed Deliveries**: Calls that failed or timed out * **Success Rate**: Percentage of successful deliveries * **Consecutive Failures**: Current failure streak * **Last Triggered**: When the webhook last fired *** ### Manual Retry If a webhook delivery failed, you can manually retry it: 1. Go to **Integrations** → **Webhooks** → **History** 2. Find the failed delivery 3. Click **Retry** 4. A new delivery attempt will be created and sent immediately *** ### Exporting Delivery History For compliance or debugging, export webhook delivery history: 1. Navigate to **Integrations** → **Webhooks** → **History** 2. Apply filters (date range, event type, status, webhook) 3. Click **Export** to download CSV 4. Use the export for: * Compliance audits * Performance analysis * Debugging patterns * Issue resolution tracking *** ### Testing Tips > **Before Going Live** > > 1. Use [webhook.site](https://webhook.site) or [RequestBin](https://requestbin.com) to inspect payloads > 2. Test with low-volume projects first > 3. Monitor delivery success rate for the first few days > 4. Set up alerting for webhook failures in your own system > **Debug Checklist** > > * Webhook URL is correct and accessible > * Endpoint returns 2xx status code within 10 seconds > * Firewall allows Corgea's requests > * Event subscriptions are selected > * Filters are configured correctly (or removed for testing) > * Signature verification works (if using secret) > * Webhook is active (not paused) *** ## Payload Examples **Issue Status Changed** ```json issue-status-changed.json theme={null} { "event_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "event_type": "issue.status_changed", "timestamp": "2025-01-15T14:30:00.000Z", "data": { "company": "comp-uuid-1234", "issue_id": "issue-uuid-5678", "classification": "SQL Injection", "urgency": "HI", "status": "fixed", "previous_status": "open", "changed_by": { "id": "user-uuid-1111", "email": "jane.doe@company.com", "name": "Jane Doe" }, "file_path": "src/controllers/user.py", "line_num": 45, "project": { "id": "proj-uuid-9012", "name": "Production API" }, "scan_id": "scan-uuid-3456", "url": "https://security.example.com/issue/issue-uuid-5678/" } } ``` `changed_by` identifies the user who made the status change and is `null` for system-initiated changes. `url` uses your deployment's configured public domain. **Scan Started** ```json scan-started.json theme={null} { "event_id": "a0b1c2d3-e4f5-6789-abcd-ef0123456789", "event_type": "scan.started", "timestamp": "2025-01-15T15:40:00.000Z", "data": { "company": "comp-uuid-1234", "scan_id": "scan-uuid-7890", "run_id": "run-12345", "project": { "id": "proj-uuid-9012", "name": "Production API" }, "project_name": "Production API", "branch": "main", "engine": "corgea-blast", "scan_type": "full", "status": "started", "pull_request_id": "42", "scan_url": "https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890", "true_positive_count": 0, "message": "Scan started for Production API (PR #42).", "scheduled_scan_ids": ["scheduled-scan-uuid"], "created_at": "2025-01-15T15:40:00.000Z" } } ``` **Scan Completed** ```json scan-completed.json theme={null} { "event_id": "b2c3d4e5-f6a7-8901-bcde-f12345678901", "event_type": "scan.completed", "timestamp": "2025-01-15T15:45:00.000Z", "data": { "company": "comp-uuid-1234", "scan_id": "scan-uuid-7890", "run_id": "run-12345", "project": { "id": "proj-uuid-9012", "name": "Production API" }, "project_name": "Production API", "branch": "main", "engine": "corgea-blast", "scan_type": "full", "status": "completed", "pull_request_id": "42", "scan_url": "https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890", "true_positive_count": 5, "summary": { "total_issues": 8, "issues_with_fixes": 5, "issues_without_fixes": 3, "severity_breakdown": { "HI": { "name": "High", "count": 2 }, "ME": { "name": "Medium", "count": 6 } }, "classification_breakdown": [ { "classification": "SQL Injection", "count": 2 }, { "classification": "Cross-Site Scripting (XSS)", "count": 1 } ] }, "message": "Scan completed for Production API (PR #42): 5 true-positive findings (5 with fixes). View: https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890", "scheduled_scan_ids": ["scheduled-scan-uuid"], "processed_at": "2025-01-15T15:45:00.000Z", "created_at": "2025-01-15T15:40:00.000Z" } } ``` Nested envelope shown above is what Zapier / Other receive (and what Corgea stores in delivery history). Slack Workflow Builder gets triage fields as **top-level** keys on the HTTP request body for `scan.*` / `webhook.test` only (`message`, `scan_id`, `scan_url`, `pull_request_id`, `true_positive_count`, `status`, `branch`, `project_name`, `company`, `run_id`, `engine`, `scan_type`, plus `error` on `scan.failed` when present, and `company_id` / `test` / `webhook_name` on `webhook.test` — not nested `summary` / `project` / `scheduled_scan_ids` / `scan_errors` / `created_at` / `processed_at`). `data.message` / top-level `message` is a plain-text summary; the "(N with fixes)" suffix counts fixes among true-positive findings only (not all issues on the scan). **Scan Failed** ```json scan-failed.json theme={null} { "event_id": "c1d2e3f4-a5b6-7890-cdef-1234567890ab", "event_type": "scan.failed", "timestamp": "2025-01-15T15:42:00.000Z", "data": { "company": "comp-uuid-1234", "scan_id": "scan-uuid-7890", "run_id": "run-12345", "project": { "id": "proj-uuid-9012", "name": "Production API" }, "project_name": "Production API", "branch": "main", "engine": "corgea-blast", "scan_type": "full", "status": "failed", "pull_request_id": "42", "scan_url": "https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890", "true_positive_count": 0, "error": "Scanner timed out", "scan_errors": null, "message": "Scan failed for Production API (PR #42): Scanner timed out. View: https://app.corgea.app/project/proj-uuid-9012/?scan_id=scan-uuid-7890", "scheduled_scan_ids": ["scheduled-scan-uuid"], "created_at": "2025-01-15T15:40:00.000Z" } } ``` `data.message` includes the failure reason (truncated when longer than 200 characters) and the scan URL when available. Use `data.error` / `data.scan_errors` for the raw failure details. On Slack Workflow Builder, `error` is also available as a top-level flat field. **Issue Assigned** ```json issue-assigned.json theme={null} { "event_id": "c3d4e5f6-a7b8-9012-cdef-123456789012", "event_type": "issue.assigned", "timestamp": "2025-01-15T16:00:00.000Z", "data": { "company": "comp-uuid-1234", "issue_id": "issue-uuid-5678", "classification": "Cross-Site Scripting (XSS)", "urgency": "ME", "status": "open", "assigned_to": { "id": "user-uuid-1111", "email": "jane.doe@company.com", "name": "Jane Doe" }, "previously_assigned_to": { "id": "user-uuid-2222", "email": "john.smith@company.com", "name": "John Smith" }, "project": { "id": "proj-uuid-9012", "name": "Production API" }, "url": "https://app.corgea.com/issue/issue-uuid-5678/" } } ``` **SLA Violation** ```json sla-violation.json theme={null} { "event_id": "f6a7b8c9-d0e1-2345-f012-345678901234", "event_type": "sla.violation", "timestamp": "2025-01-15T16:20:00.000Z", "data": { "company": "comp-uuid-1234", "sla": { "id": 3, "rule_type": "sca", "urgency": ["CR", "HI"], "remediation_days": 14, "escalation_days": 7 }, "notification_type": "escalation", "issue_kind": "SCA", "issue_count": 12, "summary_message": "Plain-text summary of breached issues...", "projects": [ { "id": "proj-uuid-9012", "name": "Production API", "url": "https://app.corgea.com/project/proj-uuid-9012", "issue_count": 12, "urgency_counts": { "Critical": 4, "High": 8 } } ] } } ``` **User Login** ```json user-login.json theme={null} { "event_id": "d4e5f6a7-b8c9-0123-def0-123456789012", "event_type": "user.login", "timestamp": "2025-01-15T16:10:00.000Z", "data": { "company": "comp-uuid-1234", "user_id": 123, "username": "jane.doe", "email": "jane.doe@company.com", "first_name": "Jane", "last_name": "Doe", "user_agent": "Mozilla/5.0", "path": "/login/" } } ``` **User Login Failed** ```json user-login-failed.json theme={null} { "event_id": "e5f6a7b8-c9d0-1234-ef01-234567890123", "event_type": "user.login_failed", "timestamp": "2025-01-15T16:12:00.000Z", "data": { "company": "comp-uuid-1234", "username": "jane.doe", "user_agent": "Mozilla/5.0", "path": "/login/" } } ``` **Scheduled Scan Daily Report** ```json scheduled-scan-daily-report.json theme={null} { "event_id": "3282dbbb-7392-476b-8ce2-19fc1070342c", "event_type": "scheduled_scan.daily_report", "timestamp": "2026-05-13T12:29:53.083616+00:00", "data": { "title": "🐕 Corgea Scheduled Scan Report", "company": "123", "company_name": "Acme Corp", "total_new_issues": 7, "message": "7 new findings across 2 scheduled scans for Acme Corp.", "scan_runs": [ { "scheduled_scan_name": "Nightly API Scan", "project": "api-service", "new_issue_count": 5, "open_issue_count": 13, "scan_url": "https://app.corgea.com/scans/abc123" }, { "scheduled_scan_name": "Nightly Frontend Scan", "project": "frontend", "new_issue_count": 2, "open_issue_count": 10, "scan_url": "https://app.corgea.com/scans/def456" } ] } } ``` The outer envelope (`event_id`, `event_type`, `timestamp`, `data`) follows the [standard payload structure](#payload-structure). The `data` object contains: | Field | Type | Description | | - | - | - | | `title` | string | Display title for the report | | `company` | string | Company ID | | `company_name` | string | Display name of the company | | `total_new_issues` | integer | Sum of new issues across all scan runs in the payload | | `message` | string | Human-readable summary suitable for plain-text notifications (e.g. Slack) | | `scan_runs` | array | One entry per scheduled scan completed in the last 24 hours, including runs with no new findings | | `scan_runs[].scheduled_scan_name` | string | Name of the scheduled scan configuration | | `scan_runs[].project` | string \| null | Project name, or `null` if no project is linked | | `scan_runs[].new_issue_count` | integer | Number of new issues found in this run | | `scan_runs[].open_issue_count` | integer | Open findings across all categories, matching the scan results page | | `scan_runs[].scan_url` | string \| null | Deep link to the scan results in Corgea, or `null` if unavailable | *** ## FAQ > **Can I use the same webhook URL for multiple event types?** > > Yes! Your endpoint will receive an `X-Corgea-Event` header and `event_type` field to identify the event. > **How many webhooks can I create?** > > There's no hard limit, but we recommend organizing by purpose (e.g., one per team or tool). > **What happens if my endpoint is down?** > > Corgea will retry 3 times with exponential backoff. After 10 consecutive failures, the webhook auto-pauses. > **Can I test webhooks without triggering real events?** > > Yes! Use the "Test Webhook" button to send a sample payload without waiting for real events. For Slack Workflow Builder, the sample is flat and includes a non-empty `message` plus triage keys (`pull_request_id`, `scan_url`, `true_positive_count`, `company`). `company_id` is also included (same value) for older Test consumers. > **Can I notify only on PR scan failures / completed PR scans with findings?** > > Yes. Under **Scan Event Filters**, enable **Only pull request / merge request scans** and **Only completed scans with true-positive findings**. Subscribe to `scan.failed` and `scan.completed`. The findings filter does not apply to `scan.failed`. > **Do webhooks support authentication?** > > Yes! Corgea auto-generates a secret key for HMAC signature verification (`X-Corgea-Signature`). You can also add custom headers for destination-specific auth tokens. > **Can I filter webhooks to specific branches?** > > Not directly, but you can filter by project. You can also filter on the received payload in your endpoint. > **Are webhook payloads encrypted?** > > Payloads are sent over HTTPS (TLS), providing encryption in transit. Use HMAC signatures for verification. > **How long are webhook delivery logs kept?** > > Delivery logs are retained for compliance and debugging. Check with your plan for specific retention periods. > **Can I retry a webhook manually?** > > Yes! Go to the webhook delivery history and click "Retry" on any failed delivery. > **What IP addresses does Corgea send webhooks from?** > > Contact support for the current list of IP addresses to whitelist in your firewall. *** **Questions or issues?** Contact [Corgea Support](mailto:support@corgea.com) # Zapier Source: https://docs.corgea.app/zapier Setting up Zapier with Corgea webhooks Connect Corgea to Zapier by registering a Catch Hook URL under **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)** → **Webhooks**. > [!WARNING] > > The standalone **Zapier** row under Automation Integrations is deprecated. Create new Zapier workflows with **Webhooks**. Existing Zapier integrations keep working — use **View All** (when shown) to test or delete them. ![Automation Integrations with Zapier marked Deprecated](https://mintcdn.com/corgea/bUShOerLaxHbdmO7/images/webhooks/webhooks_integrations.png?fit=max\&auto=format\&n=bUShOerLaxHbdmO7\&q=85\&s=e84b9d7d75569f68d644ada376ea16bf) ## Prerequisites * A Zapier account * Admin access in Corgea ## Setting up the Integration **1. Create a Catch Hook in Zapier** 1. Sign in at [Zapier](https://zapier.com/) 2. Create a Zap with **Webhooks by Zapier** as the trigger 3. Choose **Catch Hook** and copy the URL Zapier provides **2. Register the webhook in Corgea** 1. Open **Settings → Automation → [Integrations](https://www.corgea.app/settings/integrations/)** 2. Under **Automation Integrations**, open **Webhooks** (not the deprecated Zapier row) 3. Create a webhook with: * **Type**: `Zapier` * **Webhook URL**: your Catch Hook URL * The events you want to automate 4. Save the one-time secret key, then click **Test** **3. Finish the Zap** 1. In Zapier, map fields from the Corgea payload — for scan events, `data.message` is a ready-to-use summary 2. Configure your action app 3. Test the Zap and turn it on ## Example Use Cases 1. **Slack notifications**: Send channel alerts when scans complete. You can also do this directly with [Slack](slack) + [Webhooks](/webhooks). 2. **Issue tracking**: Create or update tickets in Trello, Jira, Asana, and similar tools. Jira and Linear also have native integrations ([Jira](jira), [Linear](linear)). 3. **Email alerts**: Notify teammates when critical findings appear. 4. **Custom workflows**: Kick off CI/CD steps or update docs from scan results. ## Additional Resources * [Corgea Webhooks](/webhooks) # Create a Harness integration Source: https://docs.corgea.app/api-reference/harness-integrations/create-a-harness-integration /api-reference/openapi.json post /integrations/harness Creates a Harness Code SCM integration after verifying its PAT or Service Account Token. Requires the `integrations.manage_integration` permission. An account can have multiple integrations when each uses a different organization allowlist. # Delete a Harness integration Source: https://docs.corgea.app/api-reference/harness-integrations/delete-a-harness-integration /api-reference/openapi.json delete /integrations/harness/{integration_uuid} Deletes a Harness Code SCM integration and attempts to remove its registered webhooks. Requires the `integrations.manage_integration` permission. # Get a Harness integration Source: https://docs.corgea.app/api-reference/harness-integrations/get-a-harness-integration /api-reference/openapi.json get /integrations/harness/{integration_uuid} Retrieves a Harness Code SCM integration for your company. Requires the `integrations.view_integration` permission. # List Harness integrations Source: https://docs.corgea.app/api-reference/harness-integrations/list-harness-integrations /api-reference/openapi.json get /integrations/harness Lists Harness Code SCM integrations for your company. Requires the `integrations.view_integration` permission. # Update a Harness integration Source: https://docs.corgea.app/api-reference/harness-integrations/update-a-harness-integration /api-reference/openapi.json patch /integrations/harness/{integration_uuid} Updates selected fields. Changing the token, base URL, or gateway prefix re-verifies the credentials. A replacement token must belong to the existing Harness account. Requires the `integrations.manage_integration` permission. # 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. # Add team members Source: https://docs.corgea.app/api-reference/teams/add-team-members /api-reference/openapi.json post /teams/{team_id}/members # Create a team Source: https://docs.corgea.app/api-reference/teams/create-a-team /api-reference/openapi.json post /teams Creates a team and optionally assigns members, explicit projects, project-tag selectors, and repository URL fragment selectors. Requires the `user_management.change_content_access` permission. # Delete a team Source: https://docs.corgea.app/api-reference/teams/delete-a-team /api-reference/openapi.json delete /teams/{team_id} Permanently deletes a team. Requires the `user_management.change_content_access` permission. # Get a team Source: https://docs.corgea.app/api-reference/teams/get-a-team /api-reference/openapi.json get /teams/{team_id} Retrieves an active team for the authenticated user's company. # List projects accessible to a team Source: https://docs.corgea.app/api-reference/teams/list-projects-accessible-to-a-team /api-reference/openapi.json get /teams/{team_id}/projects Resolves projects granted through explicit assignment, project tags, or repository URL fragments. Use `sources` to see every matching access path. # List teams Source: https://docs.corgea.app/api-reference/teams/list-teams /api-reference/openapi.json get /teams Lists active teams for the authenticated user's company. Requires the `user_management.change_content_access` permission. # Remove team members Source: https://docs.corgea.app/api-reference/teams/remove-team-members /api-reference/openapi.json delete /teams/{team_id}/members Removes the supplied users from the team. Company administrators cannot be removed. # Update a team Source: https://docs.corgea.app/api-reference/teams/update-a-team /api-reference/openapi.json patch /teams/{team_id} Updates any supplied team fields. Selector lists replace their current values; omit a field to leave it unchanged. Requires the `user_management.change_content_access` permission. # Create user Source: https://docs.corgea.app/api-reference/users/create-user /api-reference/openapi.json post /users Creates an active company user and sends a welcome sign-in email. Requires `auth.add_user` and an available user seat. Optionally supply either role_id or role_name, never both. Role assignment requires a plan supporting roles; Admin cannot be assigned, and the caller must hold every permission in the selected role. Duplicate email or user limits return 409. # Deactivate user Source: https://docs.corgea.app/api-reference/users/deactivate-user /api-reference/openapi.json delete /users/{user_id} Deactivates a company user without deleting the account, revokes active API tokens, and clears project access. Requires `auth.delete_user`. Company admins, staff, and service principals cannot be deactivated through this endpoint. Repeating the request for an inactive user succeeds. # List roles Source: https://docs.corgea.app/api-reference/users/list-roles /api-reference/openapi.json get /roles Lists company roles with active user counts. Requires `user_management.view_permissiongroup` and a plan supporting roles. The SAML-managed role is excluded. # List users Source: https://docs.corgea.app/api-reference/users/list-users /api-reference/openapi.json get /users Lists company users, including inactive users. Requires `auth.view_user`. The default list and search exclude company admins, staff, and service principals. Exact, case-insensitive email lookup also includes company admins.