Skip to content

feat(kona-sp1): add native super-range acceptance parity#21857

Draft
Inphi wants to merge 1 commit into
developfrom
inphi/test/sp1-super-range-acceptance-parity
Draft

feat(kona-sp1): add native super-range acceptance parity#21857
Inphi wants to merge 1 commit into
developfrom
inphi/test/sp1-super-range-acceptance-parity

Conversation

@Inphi

@Inphi Inphi commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

Summary

Run SP1 super-range acceptance checks natively alongside the existing FPVM scenarios. The native executor collects real witnesses, replays them through the shared range and consolidation cores, and verifies canonical and replacement outcomes across the required interop scenarios.

CircleCI builds and runs the native executor in both acceptance variants. Full program ELF execution remains limited to one opt-in cross-chain smoke test and is never enabled in CI. This will be done in a later PR.

Meta

Part of #21624

Replay collected witnesses through the shared range and consolidation cores
so interop acceptance scenarios can validate SP1 checkpoints without running
the expensive guest ELF. Reuse the same scenarios for FPVM, native SP1, and
the single opt-in full-ELF smoke, and wire the native executor into CI.
@wiz-0f98cca50a

Copy link
Copy Markdown

Wiz Scan Summary

Scanner Findings
Vulnerability Finding Vulnerabilities 3 High 2 Medium 3 Low
Data Finding Sensitive Data -
Secret Finding Secrets -
IaC Misconfiguration IaC Misconfigurations -
SAST Finding SAST Findings 1 Medium
Software Management Finding Software Management Findings -
Total 3 High 3 Medium 3 Low

View scan details in Wiz

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

if !ok {
return false
}
cmd := exec.CommandContext(contextualT.Ctx(), exePath, args[1:]...)

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Medium 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 Medium
Likelihood Medium

Remediation

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.

To fix this issue, 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. Additionally, it is recommended to use language-specific facilities for executing commands, which provide better input validation and sanitization.

Code examples

// VULNERABLE CODE - User input is directly used in constructing the command
userInput := getInput() // Assume this comes from user input
cmd := exec.Command("/bin/sh", "-c", userInput)
err := cmd.Run()
// SECURE CODE - Command and arguments are hardcoded, and user input is validated
userInput := getInput() // Assume this comes from user input
if !isValidInput(userInput) {
    // Handle invalid input
    return
}
cmd := exec.Command("/bin/sh", "-c", "echo", userInput)
err := cmd.Run()

Additional recommendations

  • Follow the principle of least privilege and run the application with the minimum required permissions.
  • Use input validation and sanitization techniques to ensure that user input does not contain malicious code.
  • Implement secure coding practices and follow security standards such as OWASP Top 10 and CWE.
  • Consider using language-specific facilities for executing commands, such as os/exec in Go, which provide better input validation and sanitization.
  • Regularly update and patch the application and its dependencies to address known vulnerabilities.
  • Implement logging and monitoring mechanisms to detect and respond to potential security incidents.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant