Skip to main content
Blog

Qoder Security in Practice

Qoder Security in Practice

Back

Qoder Security in Practice

Five reproducible development scenarios that walk through Qoder Security's complete flow—from risk identification and path analysis to remediation and re-verification. Many security issues don't show up as a single, glaring line of "dangerous code." User-controlled data may pass through multiple functions and modules before it reaches a network request, file operation, database query, or system command. Looking at any one file in isolation rarely reconstructs the full risk path. When security checks only happen after code is committed or delivered, developers not only have to reload the code context but also switch repeatedly between alerts, locating, fixing, and verifying. Qoder Security moves security analysis forward into the coding stage, so implementing a requirement, checking for security issues, and fixing problems all happen continuously within the same development context. This article picks five typical development tasks and provides a specified project and code revision, ready-to-use prompts, a unified way to trigger scans, and clear points to observe—helping developers understand what Qoder Security is, which scenarios it fits, and how to complete a full practice run from finding a risk to fixing and re-verifying it.
Product availability　Qoder Security will first be available in Qoder Desktop and Qoder CLI, with other Qoder products to follow. Specific capabilities and availability are subject to each product's release notes.

What Is Qoder Security?

Qoder Security is Qoder's code security capability for the AI coding workflow. While the Qoder Agent writes or modifies code, it uses static checks, code semantic analysis, and cross-file data-flow tracing to help identify potential security risks—and provides the code-level risk location, propagation path, and the reasoning behind the finding. Qoder Security supports analysis at different depths through three layers of capability:
Detection levelAnalysis methodPrimary purpose
Static checkHigh-risk pattern and rule matchingQuickly identify explicit risks such as dangerous functions and hardcoded secrets
Lightweight scanSemantic analysis of incremental changesDetermine how external input reaches network requests, database queries, or sensitive operations
Deep scanCross-file, cross-function data-flow tracingIdentify complete risk paths that are hard to spot within a single file
Static checks can run automatically after code generation or tool execution; at key points—such as when a task is nearing completion, or before committing or pushing code—the system suggests a lightweight or deep scan, which the user confirms before it runs. To keep this article's practice path consistent, all five exercises use /security-scan to proactively initiate a scan. Once an issue is found, developers can continue in the current session, having the Agent analyze and modify the code, then run the scan again to re-verify the fix. In this way, security feedback extends from a single alert into a complete "find → understand → fix → re-verify" flow. Qoder Security provides upfront security checks for the coding stage. It complements—and does not replace—manual code review, professional penetration testing, SAST, SCA, and an organization's existing security governance processes.

Before You Start

This article covers five common security boundaries:
PracticeNormal development needRisk to watch for
YAML response compatibilityParse YAML-formatted service responsesInsecure deserialization
Import cover from URLServer-side download of a user-provided imageServer-Side Request Forgery (SSRF)
Upload and restore a snapshotSave a snapshot using the uploaded filenamePath traversal
Convenience methods for DB writesDynamically build table and column namesSQL identifier injection
Custom FFmpeg argumentsAdd extra arguments to an audio-processing commandCommand injection
Every practice follows the same verification path:
  1. Prepare the specified project and code revision in a local or isolated test environment.
  2. Open the project in Qoder Desktop or Qoder CLI and confirm Qoder Security is enabled.
  3. Copy the original prompt provided here and let the Agent implement the requirement following a normal development flow.
  4. Once the feature is implemented, run /security-scan.
  5. Review the risk location, data propagation path, and the reasoning.
  6. Review the suggested changes and let the Agent complete the fix.
  7. Run the project's existing tests to check whether related functionality is affected.
  8. Run /security-scan again, observe whether the same class of risk is still reported on the same path, and confirm the result together with the tests.
Scenario purpose　The scenarios below reference public, already-fixed historical security issues, used to observe whether the coding stage can identify and handle similar risks. The goal is not to have the Agent deliberately write vulnerabilities, nor does it imply that Qoder has reproduced or rediscovered the referenced CVEs. The open-source projects and CVEs are cited only to indicate the source of public scenarios and do not imply partnership or endorsement. Environment constraints　Only operate in a local or authorized isolated environment. Do not apply the example changes directly to production. Result boundaries　Different product versions, project states, and session contexts may affect scan results. The observation points listed here do not constitute a guarantee of any specific scan result.

Practice 1: Add YAML Compatibility to a Service Response

Background

Having a client support multiple content formats returned by the server is a common product-evolution need. But when the data format changes, so does the parsing approach: if an external response is handed to a deserialization interface capable of instantiating arbitrary objects, a seemingly simple compatibility change can introduce high-risk behavior. This scenario observes whether Qoder Security can combine the response source, Content-Type judgment, and YAML parsing approach to identify an insecure deserialization risk—rather than merely seeing "added YAML support."

Environment

git clone https://github.com/opensearch-project/opensearch-ruby.git opensearch-ruby
git -C opensearch-ruby checkout --detach 51edf86470dad9d0701fcbac69dae5b89227bc02
Open the opensearch-ruby project in Qoder, then enter the prompt below verbatim.

Prompt (please copy in full)

Update OpenSearch's product-verification logic: when the root response is returned as application/yaml, it should be accepted as a valid response just like JSON. Limit production code changes to opensearch/lib/opensearch.rb: when the verification step receives a YAML response body, parse it into the hash used by the existing verification logic and continue through the current tagline/version checks. Reuse the repository's existing YAML-parsing style to stay compatible with current response handling. Optional: add or update unit tests for product verification to cover a valid YAML root response.

Trigger and Observe

After the Agent completes the change, run /security-scan. Focus on:
  • Whether the scan identifies the path where an external response body reaches a YAML parsing interface.
  • Whether the result explains why the specific parsing approach may create risk.
  • Whether the result states the input conditions or reachable path required for the risk to hold.
  • Whether the fix limits the deserializable data types while preserving YAML compatibility.
  • After related tests pass, run the scan again and observe whether the same class of risk is still reported on the same path.
This practice focuses on whether Qoder Security can analyze the relationship between "external data source → parsing behavior → potential impact," rather than just matching a function name. Public scenario reference: OpenSearch Ruby, CVE-2022-31115.

Practice 2: Import a Cover Image From a URL

Background

Importing an image from a URL saves users from downloading and then re-uploading, a common need in content-management systems. But when the server accesses an external address on the user's behalf, the product also establishes a new network-access path. If the target address and redirects lack boundary checks, external input can be used to reach the local machine, the internal network, or other resources that shouldn't be exposed. This scenario observes whether Qoder Security can follow the call chain "user-submitted URL → server download → redirect → temporary file" to analyze a server-side request forgery risk.

Environment

git clone https://github.com/Kareadita/Kavita.git kavita
git -C kavita checkout --detach 2193451dfb9e3337220e29303b653f49e0f2bf99
Open the kavita project in Qoder, then enter the prompt below verbatim.

Prompt (please copy in full)

Add an "import cover image from URL" capability. In API/Controllers/UploadController.cs, add an admin-only POST endpoint upload-by-url: accept a URL DTO, download the target image to the configured temporary directory with the filename format coverupload_<timestamp>.<extension>, and after confirming the file was created, return the filename to the caller. Preserve existing upload behavior; strip query parameters before deriving the extension; when the remote returns 401 or the download fails, return a helpful BadRequest message.

Trigger and Observe

After the Agent completes the change, run /security-scan. Focus on:
  • Whether the scan recognizes that the URL comes from endpoint input and ultimately reaches a server-side network request.
  • Whether the result considers loopback addresses, private-network addresses, and the target address after redirection.
  • Whether the risk explanation gives the specific code path from the input point to the request point.
  • Whether the fix establishes clear protocol and network-address boundaries while preserving the image-import capability.
  • After related tests pass, run the scan again and observe whether the same class of risk is still reported on the same path.
This practice focuses on whether Qoder Security can jointly analyze input source, call chain, and network boundary—rather than flagging every network request as a risk. Public scenario reference: Kavita, CVE-2022-2756.

Practice 3: Upload and Restore a Collection Snapshot

Background

Snapshot upload and restore typically span multiple modules: endpoint handling, file saving, and data recovery. The upload feature itself isn't complex, but if a client-provided filename participates in path construction without normalization and boundary checks, the file may be written outside the intended snapshot directory. This scenario observes whether Qoder Security can traverse multipart parsing, filename handling, path generation, and the snapshot-restore flow to identify a complete path-traversal risk.

Environment

git clone https://github.com/qdrant/qdrant.git qdrant
git -C qdrant checkout --detach adb148b5b6422b132c725223c7ccb3b99af292ad
Open the qdrant project in Qoder, then enter the prompt below verbatim.

Prompt (please copy in full)

Add a collection snapshot upload capability to the Actix API. In src/actix/api/snapshot_api.rs, add POST /collections/{name}/snapshots/upload: accept a multipart field named snapshot, save the uploaded file to the target collection's snapshot directory, convert the saved path to a file URL, and reuse the existing snapshot-restore flow. If the multipart part has a filename, save the snapshot using that filename; when missing, fall back to a generated UUID. The wait behavior should match the restore endpoint, defaulting to true; support an optional snapshot-priority query parameter. Return storage/collection errors via the existing Actix response helpers. Keep changes focused on the upload handler and the small helper types/functions it needs. Optional: if the existing test structure makes it convenient, add integration tests related to snapshot upload.

Trigger and Observe

After the Agent completes the change, run /security-scan. Focus on:
  • Whether the scan traces how the multipart filename reaches path construction and file-write operations.
  • Whether the result explains that checking the string surface alone is not enough to guarantee the final path stays within the snapshot directory.
  • Whether the risk path covers the call relationship between the upload handler and the existing restore flow.
  • Whether the fix establishes boundary constraints on both the filename and the normalized target path.
  • After related tests pass, run the scan again and observe whether the same class of risk is still reported on the same path.
This practice focuses on cross-function, cross-file data-flow tracing and on how well the security analysis understands the existing project structure. Public scenario reference: Qdrant, CVE-2024-2221.

Practice 4: Add Convenience Methods for Database Writes

Background

Database wrappers usually handle query values with prepared statements and parameter binding, but SQL identifiers such as table names and column names cannot be bound the same way. If dynamic identifiers come from an untrusted data structure, the code may still be injectable even when all "values" are bound correctly. This scenario observes whether Qoder Security can distinguish SQL values from SQL identifiers and, combined with caller controllability, judge whether dynamic concatenation constitutes a risk.

Environment

git clone https://github.com/flightphp/core.git flightphp-core
git -C flightphp-core checkout --detach 2ab26aa326ca8edde15974b6c638af9ba5779db5
Open the flightphp-core project in Qoder, then enter the prompt below verbatim.

Prompt (please copy in full)

In flight/database/SimplePdo.php, add convenience methods for common write operations so callers don't have to hand-write every SQL statement. Implement insert(string $table, array $data): string, update(string $table, array $data, string $where, array $params = []): int, delete(string $table, string $where, array $params = []): int. Generate the column list and placeholders from the keys of the passed-in data, and execute via the existing runQuery(); insert returns lastInsertId(), update/delete return rowCount(). Keep the implementation within SimplePdo and consistent with the class's existing parameter handling. If tests/SimplePdoTest.php exists, optionally add tests for these methods.

Trigger and Observe

After the Agent completes the change, run /security-scan. Focus on:
  • Whether the scan distinguishes parameterized query values from dynamically concatenated table and column names.
  • Whether the result analyzes the source and controllability of $table and the $data keys.
  • Whether the risk explanation states why PDO parameter binding alone is still insufficient for SQL identifiers.
  • Whether the fix establishes clear constraints on the allowed table and field names while preserving the existing interface capability.
  • After related tests pass, run the scan again and observe whether the same class of risk is still reported on the same path.
This practice focuses on whether Qoder Security understands the semantics of the programming language, the database API, and SQL structure—rather than just searching for string concatenation. Public scenario reference: Flight PHP Core, CVE-2026-42550.

Practice 5: Support Custom FFmpeg Arguments

Background

Allowing callers to pass extra media-processing arguments is a quick way to extend capabilities such as cropping and filters. But if an external string is concatenated directly into a command and handed to the shell for interpretation, it can change the intended command structure and thereby execute unauthorized operations. This scenario observes whether Qoder Security can trace a custom argument from the method entry into command construction and process execution, and judge whether a command-injection risk exists.

Environment

git clone https://github.com/shardlab/discordrb.git discordrb
git -C discordrb checkout --detach 2dfdd8e3222279a1c3e6ae50030320446c62eb47
Open the discordrb project in Qoder, then enter the prompt below verbatim.

Prompt (please copy in full)

In lib/discordrb/voice/encoder.rb, allow callers to pass extra ffmpeg/avconv options when decoding Discord voice audio. Add an optional string parameter options (default empty string) to both encode_file and encode_io, ensuring existing calls are unaffected. Splice options into the generated command: after the input (-i ...) and before the fixed output settings (-f s16le -ar 48000 -ac 2, the volume filter, pipe:1). Update the method comments for the new parameter. Optional: if there are nearby voice-encoder specs, add tests around the constructed command.

Trigger and Observe

After the Agent completes the change, run /security-scan. Focus on:
  • Whether the scan traces how the options parameter reaches the command string and the process-execution interface.
  • Whether the result distinguishes the product goal of "supporting more FFmpeg options" from the security consequence of "allowing the shell command structure to be changed."
  • Whether the risk explanation notes that the argument source and the actual invocation are key conditions for judging whether the risk holds.
  • Whether the fix prefers structured argument passing or a strict allow-list over reliance on incomplete string filtering.
  • After related tests pass, run the scan again and observe whether the same class of risk is still reported on the same path.
This practice focuses on whether Qoder Security can jointly analyze input source, command construction, and execution boundary. Public scenario reference: discordrb, CVE-2023-28102.

Understanding the Value of Qoder Security Through Five Scenarios

The five practices cover data parsing, network access, the file system, databases, and system commands. They use different languages and project structures, but share one trait: the developer is asking for a reasonable, common product feature, while the risk hides in how data enters and reaches a sensitive operation. The value of Qoder Security is not just adding another scan—it's weaving security analysis into the actual coding workflow:
  • Find risks earlier. Provide security feedback during feature implementation and code changes, reducing the cost of handling issues once they move into later stages.
  • Provide contextual evidence. Analyze risk by combining input source, data propagation, and sensitive operations, helping developers understand why an issue may hold.
  • Drive fixes to completion. Keep discovery, locating, modification, and re-verification within the same coding session, shortening the path from a security finding to a code fix.
  • Complement existing systems. Work alongside CI/CD, SAST, SCA, manual review, and professional security testing, adding a feedback mechanism close to the coding context.
The professionalism of security analysis is measured not only by how many issues it finds, but also by whether it can explain the conditions under which an issue holds, provide verifiable evidence, and re-verify after a fix. After completing these practices, focus your judgment on: whether the scan results clearly present the risk source and propagation path, whether the changes preserve the original business goal, whether the related tests pass, and whether re-verification closes the loop.

Start Using Qoder Security

Pick the scenario closest to your day-to-day development, and enter the provided prompt in Qoder Desktop or Qoder CLI. Once the feature is implemented, run /security-scan and observe whether Qoder Security can locate the risk, present the propagation path, and assist with the fix and re-verification. Qoder Security will first be available in Qoder Desktop and Qoder CLI, with other Qoder products to follow.