Feat/upgrade from upstream

[toindev]

No description provided.

[aikido-pr-checks]

Possible command injection via shell script - high severity
Your code spawns a subprocess via a shell script. User input could be abused to inject extra commands.

Remediation: This issue can be mitigated or ignored if you verified or sanitized the user input used in the shell command.
^{View details in Aikido Security}

[aikido-pr-checks]

Possible command injection via shell script - high severity
Your code spawns a subprocess via a shell script. User input could be abused to inject extra commands.

Remediation: This issue can be mitigated or ignored if you verified or sanitized the user input used in the shell command.
^{View details in Aikido Security}

[aikido-pr-checks]

Potential file inclusion attack via reading file - high severity
If an attacker can control the input leading into the ReadFile function, they might be able to read sensitive files and launch further attacks with that information.

Remediation: Ignore this issue only after you've verified or sanitized the input going into this function.
^{View details in Aikido Security}

[aikido-pr-checks]

Potential file inclusion attack via reading file - high severity
If an attacker can control the input leading into the ReadFile function, they might be able to read sensitive files and launch further attacks with that information.

Show Remediation

Remediation - medium confidence
This patch mitigates potential file inclusion attacks by implementing input validation for the ReadFile function.

Suggested change

	outputFile, err := os.Open(params.outputPath)
	if strings.Contains(params.outputPath, "../") || strings.Contains(params.outputPath, "..\\") {
	err := fmt.Errorf("Invalid file path")
	params.ctx.Log().Error(fmt.Sprintf("open output file: %s", err))
	params.handleError(err)
	return
	}
	outputFile, err := os.Open(params.outputPath)

^{View details in Aikido Security}

[wiz-poc-connector]

Wiz Scan Summary

Scanner	Findings
Vulnerabilities	-
Sensitive Data	-
Secrets	-
IaC Misconfigurations	1  2  2  3
SAST Findings	16
Software Supply Chain Findings	-
Total	1  18  2  3

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try using Wiz Code VS Code Extension.

[wiz-poc-connector]

 SAST Finding

Overly permissive directory permissions in Go (CWE-732)

More Details

This rule detects cases where Go applications create directories with overly permissive permissions, potentially allowing unauthorized access or modification of files within those directories. Assigning excessively open permissions to directories can lead to security vulnerabilities, as it may enable malicious actors or other processes to read, write, or execute files they should not have access to.

Consequences of this issue can include data leaks, data tampering, or even remote code execution, depending on the contents and purpose of the affected directories. To mitigate this risk, it is crucial to assign the least permissive access rights necessary for the application's intended functionality.

Attribute	Value
Impact
Likelihood

Remediation

When creating directories in Go, ensure that the permissions are set to the minimum required level for the application's needs. A common recommendation is to use 0700 (read/write/execute for the owner, no access for group or others) if the directory will only be accessed by the application itself.

If the directory needs to be readable by other users or processes in the same group, consider using 0750 (read/write for owner, read-only for group members, no access for others).

Example:

err := os.Mkdir("directory", 0700)
if err != nil {
  log.Fatal(err)
}

Rule ID: WS-I011-GO-00011

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

OS Command Injection (CWE-78)

More Details

OS command injection is a critical vulnerability that allows an attacker to execute arbitrary commands on the system. This can lead to a full system compromise, as the attacker can potentially gain complete control over the application and the underlying system.

The vulnerability arises when user input is used to construct commands or command arguments that are then executed by the application. This can occur when user-supplied data is passed directly to functions that execute OS commands, such as exec.Command, exec.CommandContext, syscall.ForkExec, or syscall.StartProcess.

If an attacker can inject malicious code into these commands, they can potentially execute any command on the system, including installing malware, stealing data, or causing a denial of service. This vulnerability can have severe consequences, including data breaches, system compromise, and unauthorized access to sensitive information.

To avoid this vulnerability, user input should never be used directly in constructing commands or command arguments. Instead, the application should use a hardcoded set of arguments and validate any user input to ensure it does not contain malicious code.

Attribute	Value
Impact
Likelihood

Remediation

To remediate this vulnerability, follow these recommendations:

• Never use user-supplied input directly in constructing commands or command arguments.
• Validate and sanitize all user input before using it in any context.
• Use a hardcoded set of arguments for executing OS commands.
• If filenames are required, use a hash or unique identifier instead of the actual filename.
• Consider using a native library that implements the required functionality instead of executing OS commands.

Example of safely executing an OS command:

userData := []byte("user data")
// Create a temporary file in the application-specific directory
f, err := ioutil.TempFile("/var/app/restricted", "temp-*.dat")
if err != nil {
  log.Fatal(err)
}

if _, err := f.Write(userData); err != nil {
  log.Fatal(err)
}

if err := f.Close(); err != nil {
  log.Fatal(err)
}

// Pass the full path to the binary and the name of the temporary file
out, err := exec.Command("/bin/cat", f.Name()).Output()
if err != nil {
  log.Fatal(err)
}

Rule ID: WS-I011-GO-00026

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

Unsafe Command Execution in Go (CWE-94)

More Details

This rule detects instances where user-supplied input is used to construct a command for execution using the exec.Command or exec.CommandContext functions in Go. This can lead to a code injection vulnerability, allowing an attacker to execute arbitrary commands on the system.

Attribute	Value
Impact
Likelihood

Remediation

The vulnerability arises from the use of non-static commands in the exec.Command or exec.CommandContext functions. This can lead to code injection vulnerabilities, where an attacker can inject malicious code into the command and execute arbitrary code on the system. This poses a severe security risk, as it can potentially compromise the entire system.

To fix this issue, it is crucial to validate and sanitize all user input before passing it to the exec.Command or exec.CommandContext functions. One secure approach is to use a whitelist of allowed commands and arguments, and reject any input that does not match the whitelist.

Code examples:

// VULNERABLE CODE - User input is directly passed to exec.Command
userInput := getUntrustedInput()
cmd := exec.Command(userInput)
// This is vulnerable to code injection

// SECURE CODE - Use a whitelist of allowed commands and arguments
allowedCommands := []string{"ls", "grep", "awk"}
userInput := getUntrustedInput()
if !isAllowedCommand(userInput, allowedCommands) {
    // Reject the input if it's not in the whitelist
    return
}
cmd := exec.Command(userInput)
// This is secure because only whitelisted commands are allowed

Additional recommendations:

• Follow the principle of least privilege: only grant the minimum required permissions to the executed commands.
• Consider using a dedicated sandbox or container to execute untrusted commands, limiting the potential damage in case of a successful code injection attack.
• Implement input validation and sanitization consistently throughout the codebase.
• Adhere to the OWASP Injection Prevention Cheat Sheet and the CWE-94: Improper Control of Generation of Code guidelines.
• Consider using static analysis tools like Semgrep to detect potential code injection vulnerabilities during development.

Rule ID: WS-I013-GO-00024

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

Unsafe Command Execution in Go (CWE-94)

More Details

This rule detects instances where user-supplied input is used to construct a command for execution using the exec.Command or exec.CommandContext functions in Go. This can lead to a code injection vulnerability, allowing an attacker to execute arbitrary commands on the system.

Attribute	Value
Impact
Likelihood

Remediation

The vulnerability arises from the use of non-static commands in the exec.Command or exec.CommandContext functions. This can lead to code injection vulnerabilities, where an attacker can inject malicious code into the command and execute arbitrary code on the system. This poses a severe security risk, as it can potentially compromise the entire system.

To fix this issue, it is crucial to validate and sanitize all user input before passing it to the exec.Command or exec.CommandContext functions. One secure approach is to use a whitelist of allowed commands and arguments, and reject any input that does not match the whitelist.

Code examples:

// VULNERABLE CODE - User input is directly passed to exec.Command
userInput := getUntrustedInput()
cmd := exec.Command(userInput)
// This is vulnerable to code injection

// SECURE CODE - Use a whitelist of allowed commands and arguments
allowedCommands := []string{"ls", "grep", "awk"}
userInput := getUntrustedInput()
if !isAllowedCommand(userInput, allowedCommands) {
    // Reject the input if it's not in the whitelist
    return
}
cmd := exec.Command(userInput)
// This is secure because only whitelisted commands are allowed

Additional recommendations:

• Follow the principle of least privilege: only grant the minimum required permissions to the executed commands.
• Consider using a dedicated sandbox or container to execute untrusted commands, limiting the potential damage in case of a successful code injection attack.
• Implement input validation and sanitization consistently throughout the codebase.
• Adhere to the OWASP Injection Prevention Cheat Sheet and the CWE-94: Improper Control of Generation of Code guidelines.
• Consider using static analysis tools like Semgrep to detect potential code injection vulnerabilities during development.

Rule ID: WS-I013-GO-00024

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 IaC Finding

Apt Get Install Pin Version Not Defined
on resource FROM debian:13-slim AS custom-jre-stage.RUN apt-get update -qq && apt-get upgrade -yqq && DEBIAN_FRONTEND=noninteractive apt-get install -y -qq --no-install-recommends default-jdk-headless binutils

More Details

When installing a package, its pin version should be defined

Expected

Package 'default-jdk-headless' has version defined

Found

Package 'default-jdk-headless' does not have version defined

Rule ID: f6b640f4-3ee0-4b6c-812d-81086a08e3f8

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

Unsafe Command Execution in Go (CWE-94)

More Details

This rule detects instances where user-supplied input is used to construct a command for execution using the exec.Command or exec.CommandContext functions in Go. This can lead to a code injection vulnerability, allowing an attacker to execute arbitrary commands on the system.

Attribute	Value
Impact
Likelihood

Remediation

The vulnerability arises from the use of non-static commands in the exec.Command or exec.CommandContext functions. This can lead to code injection vulnerabilities, where an attacker can inject malicious code into the command and execute arbitrary code on the system. This poses a severe security risk, as it can potentially compromise the entire system.

To fix this issue, it is crucial to validate and sanitize all user input before passing it to the exec.Command or exec.CommandContext functions. One secure approach is to use a whitelist of allowed commands and arguments, and reject any input that does not match the whitelist.

Code examples:

// VULNERABLE CODE - User input is directly passed to exec.Command
userInput := getUntrustedInput()
cmd := exec.Command(userInput)
// This is vulnerable to code injection

// SECURE CODE - Use a whitelist of allowed commands and arguments
allowedCommands := []string{"ls", "grep", "awk"}
userInput := getUntrustedInput()
if !isAllowedCommand(userInput, allowedCommands) {
    // Reject the input if it's not in the whitelist
    return
}
cmd := exec.Command(userInput)
// This is secure because only whitelisted commands are allowed

Additional recommendations:

• Follow the principle of least privilege: only grant the minimum required permissions to the executed commands.
• Consider using a dedicated sandbox or container to execute untrusted commands, limiting the potential damage in case of a successful code injection attack.
• Implement input validation and sanitization consistently throughout the codebase.
• Adhere to the OWASP Injection Prevention Cheat Sheet and the CWE-94: Improper Control of Generation of Code guidelines.
• Consider using static analysis tools like Semgrep to detect potential code injection vulnerabilities during development.

Rule ID: WS-I013-GO-00024

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

OS Command Injection (CWE-78)

More Details

OS command injection is a critical vulnerability that allows an attacker to execute arbitrary commands on the system. This can lead to a full system compromise, as the attacker can potentially gain complete control over the application and the underlying system.

The vulnerability arises when user input is used to construct commands or command arguments that are then executed by the application. This can occur when user-supplied data is passed directly to functions that execute OS commands, such as exec.Command, exec.CommandContext, syscall.ForkExec, or syscall.StartProcess.

If an attacker can inject malicious code into these commands, they can potentially execute any command on the system, including installing malware, stealing data, or causing a denial of service. This vulnerability can have severe consequences, including data breaches, system compromise, and unauthorized access to sensitive information.

To avoid this vulnerability, user input should never be used directly in constructing commands or command arguments. Instead, the application should use a hardcoded set of arguments and validate any user input to ensure it does not contain malicious code.

Attribute	Value
Impact
Likelihood

Remediation

To remediate this vulnerability, follow these recommendations:

• Never use user-supplied input directly in constructing commands or command arguments.
• Validate and sanitize all user input before using it in any context.
• Use a hardcoded set of arguments for executing OS commands.
• If filenames are required, use a hash or unique identifier instead of the actual filename.
• Consider using a native library that implements the required functionality instead of executing OS commands.

Example of safely executing an OS command:

userData := []byte("user data")
// Create a temporary file in the application-specific directory
f, err := ioutil.TempFile("/var/app/restricted", "temp-*.dat")
if err != nil {
  log.Fatal(err)
}

if _, err := f.Write(userData); err != nil {
  log.Fatal(err)
}

if err := f.Close(); err != nil {
  log.Fatal(err)
}

// Pass the full path to the binary and the name of the temporary file
out, err := exec.Command("/bin/cat", f.Name()).Output()
if err != nil {
  log.Fatal(err)
}

Rule ID: WS-I011-GO-00026

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

Unsafe Command Execution in Go (CWE-94)

More Details

This rule detects instances where user-supplied input is used to construct a command for execution using the exec.Command or exec.CommandContext functions in Go. This can lead to a code injection vulnerability, allowing an attacker to execute arbitrary commands on the system.

Attribute	Value
Impact
Likelihood

Remediation

The vulnerability arises from the use of non-static commands in the exec.Command or exec.CommandContext functions. This can lead to code injection vulnerabilities, where an attacker can inject malicious code into the command and execute arbitrary code on the system. This poses a severe security risk, as it can potentially compromise the entire system.

To fix this issue, it is crucial to validate and sanitize all user input before passing it to the exec.Command or exec.CommandContext functions. One secure approach is to use a whitelist of allowed commands and arguments, and reject any input that does not match the whitelist.

Code examples:

// VULNERABLE CODE - User input is directly passed to exec.Command
userInput := getUntrustedInput()
cmd := exec.Command(userInput)
// This is vulnerable to code injection

// SECURE CODE - Use a whitelist of allowed commands and arguments
allowedCommands := []string{"ls", "grep", "awk"}
userInput := getUntrustedInput()
if !isAllowedCommand(userInput, allowedCommands) {
    // Reject the input if it's not in the whitelist
    return
}
cmd := exec.Command(userInput)
// This is secure because only whitelisted commands are allowed

Additional recommendations:

• Follow the principle of least privilege: only grant the minimum required permissions to the executed commands.
• Consider using a dedicated sandbox or container to execute untrusted commands, limiting the potential damage in case of a successful code injection attack.
• Implement input validation and sanitization consistently throughout the codebase.
• Adhere to the OWASP Injection Prevention Cheat Sheet and the CWE-94: Improper Control of Generation of Code guidelines.
• Consider using static analysis tools like Semgrep to detect potential code injection vulnerabilities during development.

Rule ID: WS-I013-GO-00024

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

OS Command Injection (CWE-78)

More Details

OS command injection is a critical vulnerability that allows an attacker to execute arbitrary commands on the system. This can lead to a full system compromise, as the attacker can potentially gain complete control over the application and the underlying system.

The vulnerability arises when user input is used to construct commands or command arguments that are then executed by the application. This can occur when user-supplied data is passed directly to functions that execute OS commands, such as exec.Command, exec.CommandContext, syscall.ForkExec, or syscall.StartProcess.

If an attacker can inject malicious code into these commands, they can potentially execute any command on the system, including installing malware, stealing data, or causing a denial of service. This vulnerability can have severe consequences, including data breaches, system compromise, and unauthorized access to sensitive information.

To avoid this vulnerability, user input should never be used directly in constructing commands or command arguments. Instead, the application should use a hardcoded set of arguments and validate any user input to ensure it does not contain malicious code.

Attribute	Value
Impact
Likelihood

Remediation

To remediate this vulnerability, follow these recommendations:

• Never use user-supplied input directly in constructing commands or command arguments.
• Validate and sanitize all user input before using it in any context.
• Use a hardcoded set of arguments for executing OS commands.
• If filenames are required, use a hash or unique identifier instead of the actual filename.
• Consider using a native library that implements the required functionality instead of executing OS commands.

Example of safely executing an OS command:

userData := []byte("user data")
// Create a temporary file in the application-specific directory
f, err := ioutil.TempFile("/var/app/restricted", "temp-*.dat")
if err != nil {
  log.Fatal(err)
}

if _, err := f.Write(userData); err != nil {
  log.Fatal(err)
}

if err := f.Close(); err != nil {
  log.Fatal(err)
}

// Pass the full path to the binary and the name of the temporary file
out, err := exec.Command("/bin/cat", f.Name()).Output()
if err != nil {
  log.Fatal(err)
}

Rule ID: WS-I011-GO-00026

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[wiz-poc-connector]

 SAST Finding

SQL Injection in Go via String Concatenation (CWE-89)

More Details

SQL Injection is a critical vulnerability that allows an attacker to execute arbitrary SQL commands on the database. This can lead to unauthorized data access, data manipulation, or even complete system compromise. SQL Injection occurs when user input is directly concatenated into SQL queries without proper sanitization or validation.

Dynamically constructing SQL queries by concatenating user input is highly risky and should be avoided. Instead, use parameterized queries or prepared statements, which separate the query structure from user input data. This prevents user input from being interpreted as part of the SQL command.

Attribute	Value
Impact
Likelihood

Remediation

To mitigate SQL Injection vulnerabilities, use parameterized queries or prepared statements instead of dynamically constructing SQL queries through string concatenation. This ensures that user input is treated as data and not as part of the SQL command.

Recommendation:

• Use the database/sql package in Go and its methods like Query, QueryRow, or Exec with parameter placeholders (?).
• Bind user input to the parameter placeholders using the appropriate methods.

Example:

// Safe usage of parameterized query
query := "SELECT * FROM users WHERE username = ?"
rows, err := db.Query(query, userInput)
if err != nil {
    // Handle error
}
defer rows.Close()

Rule ID: WS-I011-GO-00025

To ignore this finding as an exception, reply to this conversation with #wiz_ignore reason

If you'd like to ignore this finding in all future scans, add an exception in the .wiz file (learn more) or create an Ignore Rule (learn more).

To get more details on how to remediate this issue using AI, reply to this conversation with #wiz remediate

[Copilot]

Pull request overview

This PR upgrades the codebase from upstream changes, introducing significant new functionality for PDF manipulation, logging improvements, and various bug fixes.

Changes:

• Added support for PDF splitting, flattening, encryption, file embedding, and bookmark importing operations
• Enhanced logging with GCP field support and access/application log separation
• Fixed multiple typos and improved code documentation throughout the codebase

Reviewed changes

Copilot reviewed 97 out of 269 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
pkg/modules/pdfengines/pdfengines.go	Added new PDF engine capabilities (split, flatten, encrypt, embed, import bookmarks) with corresponding field names and route configurations
pkg/modules/pdfengines/multi_test.go	Added comprehensive test coverage for new PDF engine methods (Encrypt, Split, Flatten)
pkg/modules/pdfengines/multi.go	Implemented multi-engine support for new PDF operations with proper error handling
pkg/modules/pdfcpu/sort_test.go	Added tests for digit suffix sorting functionality
pkg/modules/pdfcpu/sort.go	Implemented custom sorting logic for PDF files with numeric suffixes
pkg/modules/pdfcpu/pdfcpu.go	Added split, flatten, encrypt, embed, and import bookmarks methods to pdfcpu engine
pkg/modules/pdfcpu/doc.go	Updated documentation to reflect new capabilities
pkg/modules/logging/logging.go	Added GCP fields support and deprecated log-enable-gcp-severity flag
pkg/modules/logging/gcp.go	Implemented GCP severity mapping and encoding functions
pkg/modules/logging/color.go	Added color support for terminal output
pkg/modules/libreoffice/routes.go	Integrated new PDF operations (split, flatten, encrypt, embed) into LibreOffice conversion routes
pkg/modules/libreoffice/pdfengine/pdfengine.go	Added stub implementations for unsupported PDF operations
pkg/modules/libreoffice/libreoffice.go	Fixed comment grammar
pkg/modules/libreoffice/api/libreoffice.go	Added Debug method, improved comments, and file system initialization
pkg/modules/libreoffice/api/api.go	Added Debug method, updated documentation, and GCP field descriptions
pkg/modules/exiftool/exiftool.go	Added Debug method and stub implementations for new PDF operations
pkg/modules/chromium/tasks.go	Added support for tagged PDF generation and fixed background handling
pkg/modules/chromium/routes.go	Integrated split, encrypt, and embed functionality with improved markdown rendering
pkg/modules/chromium/chromium.go	Added bookmarks support, Debug method, and various configuration improvements
pkg/modules/chromium/browser.go	Improved browser lifecycle management and health checks
pkg/modules/api/middlewares.go	Added output filename middleware and enhanced error handling
pkg/gotenberg/shutdown.go	Added graceful shutdown error handling
pkg/gotenberg/modules.go	Introduced Debuggable interface for modules

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The variable name 'unsafe' is misleading as the content is subsequently sanitized. Consider renaming to 'unsanitized' or 'raw' to better reflect the actual state of the content.

Suggested change

	unsafe := markdown.ToHTML(b, nil, nil)
	sanitized := bluemonday.UGCPolicy().SanitizeBytes(unsafe)
	rawHTML := markdown.ToHTML(b, nil, nil)
	sanitized := bluemonday.UGCPolicy().SanitizeBytes(rawHTML)

[Copilot]

The variable 'strs' should be renamed to 'strings' for clarity, or alternatively to 'stringValues' to avoid potential confusion with the strings package.

[aikido-pr-checks]

The script uses eval("$cmd") to execute a dynamically constructed command string, which can hide the actual operations. Avoid eval; run commands directly or use arrays to execute without shell evaluation.

Details

✨ AI Reasoning
​The code builds command strings dynamically (including interpolated arrays and variables) and executes them via eval in a helper that runs build commands. Dynamically constructed and evaluated shell commands can hide actual executed operations and make review or static analysis miss side effects. This harms transparency and increases risk that injected values or unexpected expansions change runtime behavior.

🔧 How do I fix it?
Ensure code is transparent and not intentionally obfuscated. Avoid hiding functionality from code review. Focus on intent and deception, not specific patterns.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}

[aikido-pr-checks]

The test runner uses eval("$cmd") to execute a dynamically built command string, which can obscure the real commands executed. Prefer executing commands directly or using bash arrays to avoid eval.

Details

✨ AI Reasoning
​A helper in the integration test script also accepts a constructed command string and executes it via eval. This makes it difficult to audit what will run, and expanded variables or untrusted inputs may alter behavior unexpectedly. Using eval for running build/test commands reduces transparency and can mask harmful or unintended actions.

🔧 How do I fix it?
Ensure code is transparent and not intentionally obfuscated. Avoid hiding functionality from code review. Focus on intent and deception, not specific patterns.

_{Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info}

[Copilot]

Pull request overview

Copilot reviewed 99 out of 274 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The variable name 'fs' is ambiguous in this context. Consider renaming to 'fileSystem' for better clarity.

[Copilot]

Corrected 'return' to 'returns' to match function documentation convention.

Suggested change

	// Modules return the list of modules which satisfies the requested interface.
	// Modules returns the list of modules which satisfies the requested interface.