Conversation
Wiz Scan Summary
|
| Scanner | Findings |
|---|---|
 |
- |
 |
- |
 |
- |
 |
- |
 |
29   |
 |
- |
| Total | 29 |
To detect these findings earlier in the dev lifecycle, try the Wiz Code extension for VS Code, JetBrains, or Visual Studio.
![wiz-0f98cca50a[bot]](https://avatars.githubusercontent.com/u/58791460?s=60&v=4){kind=small}
| raise ValueError("Empty integration test discovery") | ||
| actual = {} | ||
| flaky = [] | ||
| for case in ET.parse(directory / "junit.xml").iter("testcase"): |
There was a problem hiding this comment.
Unsafe XML Parsing Using xml.etree (CWE-611)
More Details
The application is using the built-in xml.etree package for parsing XML data. This package is known to be vulnerable to various XML parsing vulnerabilities, including Billion Laughs/Exponential Entity Expansion and Quadratic Blowup Entity Expansion attacks. These vulnerabilities can potentially lead to Denial of Service (DoS) attacks, where an attacker can craft a malicious XML payload that causes excessive resource consumption, crashing or freezing the application.
Additionally, depending on the Python version, more critical vulnerabilities like XML External Entity (XXE) injection may be exploitable. XXE vulnerabilities can allow an attacker to access sensitive data, execute remote code, or perform other malicious actions by leveraging the XML parser's ability to retrieve external resources.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
The use of the built-in xml.etree package in Python for parsing XML data can expose the application to various XML parsing vulnerabilities, including Billion Laughs/Exponential Entity Expansion, Quadratic Blowup Entity Expansion, and potentially XML External Entity (XXE) injection attacks. These vulnerabilities can lead to Denial of Service (DoS) attacks, where an attacker can craft a malicious XML payload that causes excessive resource consumption, crashing or freezing the application. Additionally, XXE vulnerabilities can allow an attacker to access sensitive data, execute remote code, or perform other malicious actions by leveraging the XML parser's ability to retrieve external resources.
To mitigate these vulnerabilities, it is recommended to use a secure XML parsing library that provides protection against these attacks. One such library is defusedxml, which is a Python library that provides a secure way to parse XML data by disabling external entity resolution and limiting the maximum depth of nested entities.
Code examples
# VULNERABLE CODE - The built-in `xml.etree` package is used for parsing XML data
import xml.etree.ElementTree as ET
xml_data = """<root>...</root>"""
tree = ET.fromstring(xml_data)# SECURE CODE - Using the `defusedxml` library to parse XML data securely
from defusedxml import ElementTree as ET
xml_data = """<root>...</root>"""
tree = ET.fromstring(xml_data)Additional recommendations
- Follow the principle of least privilege and only grant the minimum required permissions to the XML parser.
- Validate and sanitize all user input before parsing XML data to prevent injection attacks.
- Keep the XML parsing library and its dependencies up-to-date with the latest security patches.
- Implement input validation, output encoding, and other security best practices recommended by the OWASP XML External Entity (XXE) Prevention Cheat Sheet.
- Adhere to relevant security standards, such as the OWASP Application Security Verification Standard (ASVS) and the OWASP Top 10 Web Application Security Risks.
- Consider using a Web Application Firewall (WAF) or an XML Gateway to provide an additional layer of protection against XML-based attacks.
Rule ID: WS-I011-PYTHON-00055
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
| inputs={name:'https://secret-fixture.example/rpc' for name in RPC.NAMES} | ||
| for payload, succeeds in [({'id':1,'result':'0x0'},True), ({'id':1,'error':{'message':'secret-fixture'}},False), ({'id':2,'result':'0x0'},False)]: | ||
| def answer(request, timeout): | ||
| body=json.loads(request.data) |
There was a problem hiding this comment.
Improper handling of malformed JSON input (CWE-703)
More Details
This rule detects instances where JSON data is parsed without proper error handling. Parsing malformed or malicious JSON input without proper validation can lead to application crashes, denial of service, or even remote code execution vulnerabilities. When an application receives JSON data from an untrusted source, such as user input or external APIs, it is crucial to validate and sanitize the input before parsing it. Failure to do so can result in unexpected behavior, data corruption, or security vulnerabilities. To mitigate this risk, developers should implement proper error handling and input validation mechanisms when working with JSON data. This includes wrapping JSON parsing operations in try-except blocks and validating the input against expected formats or schemas.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
The vulnerability arises from the lack of proper error handling when parsing JSON data using the json.load() or json.loads() functions in Python. If the input JSON data is malformed or corrupted, these functions will raise a ValueError exception, which can cause the application to crash or become unresponsive if not handled correctly. This can lead to denial of service (DoS) attacks or other security issues.
To fix this issue, you should wrap the json.load() or json.loads() calls in a try-except block and handle the ValueError exception appropriately. This could involve logging the error, returning an error response, or taking other appropriate actions based on your application's requirements.
Code examples
# VULNERABLE CODE - No error handling for malformed JSON data
import json
def parse_json(json_data):
data = json.loads(json_data)
# Process data...# SECURE CODE - Proper error handling for malformed JSON data
import json
def parse_json(json_data):
try:
data = json.loads(json_data)
except ValueError as e:
# Handle the error, e.g., log, return error response, etc.
print(f"Error parsing JSON: {e}")
return None
# Process data...Additional recommendations
- Follow the principle of "failing securely" by handling exceptions gracefully and avoiding exposing sensitive information in error messages.
- Implement input validation and sanitization to prevent malformed or malicious JSON data from reaching the parsing stage.
- Consider using a JSON parser library that provides more robust error handling and security features, such as the
demjsonlibrary. - Adhere to the OWASP Input Validation Cheat Sheet and other relevant security standards for handling user input securely.
- As an alternative approach, you could use a JSON schema validation library to validate the structure and format of the JSON data before parsing it.
Rule ID: WS-PYTHON-00359
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
| inventory=git_inventory((raw/'tracked-stage.bin').read_bytes()) | ||
| for name,path in [('mise.toml','mise.toml'),('contracts.justfile','packages/contracts-bedrock/justfile'), | ||
| ('foundry.toml','packages/contracts-bedrock/foundry.toml')]: | ||
| data=(raw/name).read_bytes();blob=hashlib.sha1(b'blob '+str(len(data)).encode()+b'\0'+data).hexdigest() |
There was a problem hiding this comment.
Usage of weak hash algorithm (MD5 or SHA-1) in Python hashlib (CWE-328)
More Details
This rule detects the use of cryptographically weak hash algorithms MD5 and SHA-1 through Python's hashlib module without explicitly marking them as non-security-critical. Both MD5 and SHA-1 have known collision vulnerabilities, meaning an attacker can craft two different inputs that produce the same hash output. This makes them unsuitable for any security-sensitive purpose.
Using these algorithms for password hashing, digital signatures, certificate generation, or data integrity verification exposes applications to forgery, impersonation, and data tampering attacks. Attackers can exploit collision weaknesses to bypass authentication or integrity checks. To mitigate this risk, replace MD5 and SHA-1 with SHA-256, SHA-3, or other modern algorithms. If you genuinely need MD5 or SHA-1 for non-security purposes such as non-critical checksums or legacy compatibility, pass the argument usedforsecurity=False to suppress this warning and document the intent clearly.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
The use of MD5 or SHA-1 hashing algorithms via Python's hashlib module introduces a critical cryptographic weakness. Both algorithms are considered cryptographically broken: MD5 is vulnerable to collision attacks and SHA-1 has been practically broken since 2017 (demonstrated by the SHAttered attack). Using these algorithms for password hashing, digital signatures, or data integrity verification can allow attackers to forge hashes, bypass authentication, or tamper with data undetected.
To fix this issue, replace hashlib.md5() or hashlib.sha1() calls with a stronger algorithm such as hashlib.sha256(), hashlib.sha3_256(), or hashlib.sha512(). If the hash is genuinely used for a non-security purpose (e.g., a cache key or non-cryptographic checksum), you may suppress the warning by explicitly passing usedforsecurity=False to signal intent and maintain compatibility with FIPS-compliant environments.
Code examples
# VULNERABLE CODE - MD5 and SHA-1 are cryptographically broken and unsafe for security use
import hashlib
def hash_password(password: str) -> str:
return hashlib.md5(password.encode()).hexdigest()
def verify_file_integrity(data: bytes) -> str:
return hashlib.sha1(data).hexdigest()# SECURE CODE - SHA-256 is cryptographically strong and suitable for security-sensitive operations
import hashlib
def hash_password(password: str) -> str:
return hashlib.sha256(password.encode()).hexdigest()
def verify_file_integrity(data: bytes) -> str:
return hashlib.sha256(data).hexdigest()
# Non-security use: explicitly mark with usedforsecurity=False
cache_key = hashlib.md5(data, usedforsecurity=False).hexdigest()Additional recommendations
- For password hashing specifically, never use raw SHA-256 either — use dedicated password hashing functions like
hashlib.scrypt(),bcrypt, orargon2-cffiwhich include salting and work factors. - Prefer
hashlib.sha3_256()orhashlib.sha3_512()(SHA-3 family) for new implementations, as they are structurally distinct from SHA-2 and provide defense-in-depth. - When migrating legacy systems, audit all uses of MD5/SHA-1 to determine whether they are security-sensitive before applying
usedforsecurity=Falseas a workaround. - Follow NIST SP 800-131A and OWASP Cryptographic Storage Cheat Sheet guidelines, which formally deprecate MD5 and SHA-1 for all security applications.
- Ensure that hash algorithm choices are centralized in a utility module to make future algorithm migrations easier and consistent across the codebase.
- If interoperability with legacy systems requires MD5/SHA-1, document the risk explicitly and implement compensating controls such as additional HMAC layers.
Rule ID: WS-PYTHON-00367
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
| // removed; a failed generator must never label the historical snapshot as a | ||
| // successfully regenerated bundle. | ||
| func retainSource(root, worktree, report string, fork forks.Name, entry nuts.ForkLockEntry) error { | ||
| if err := os.MkdirAll(report, 0755); err != nil { |
There was a problem hiding this comment.
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
The vulnerability arises from assigning overly permissive permissions to directories created by the application. This can potentially allow unauthorized access or modification of files within those directories, leading to security risks such as data leaks, data tampering, or even remote code execution, depending on the contents and purpose of the affected directories.
To fix this issue securely, you should assign the least permissive access rights necessary for the application's intended functionality. Specifically, you should use the os.Mkdir or os.MkdirAll functions with a permission mask that restricts access to only the necessary users or processes.
Code examples
// VULNERABLE CODE - Assigns overly permissive permissions (0777) to the created directory
err := os.Mkdir("/path/to/dir", 0777)// SECURE CODE - Assigns more restrictive permissions (0750) to the created directory
err := os.Mkdir("/path/to/dir", 0750)Additional recommendations
- Follow the principle of least privilege and assign the minimum required permissions for the application's functionality.
- Consider using a more restrictive permission mask, such as 0700 (read, write, execute for the owner only), if the directory does not need to be accessed by other users or processes.
- Regularly review and audit directory permissions to ensure they remain appropriate for the application's security requirements.
- Adhere to relevant security standards and best practices, such as the OWASP Top 10 and CWE guidelines, which emphasize the importance of proper access control and resource protection.
- If the application requires more granular access control, consider implementing additional security measures, such as file system access control lists (ACLs) or mandatory access control (MAC) systems.
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
| if err != nil { | ||
| return err | ||
| } | ||
| if err := os.WriteFile(filepath.Join(report, "source.json"), append(metadata, '\n'), 0644); err != nil { |
There was a problem hiding this comment.
Overly Permissive File Permissions in Go (CWE-732)
More Details
The application is setting file permissions to overly permissive values, allowing unauthorized access to sensitive files. This vulnerability can lead to data breaches, unauthorized modifications, or execution of malicious code. Attackers who gain access to the system could exploit these excessive permissions to read, modify, or execute files they should not have access to.
To mitigate this risk, applications should assign the least permissive file permissions required for their intended functionality. Permissions should be carefully reviewed and restricted to only allow necessary operations for the application user or group.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Setting overly permissive file permissions (greater than 0o640) exposes sensitive files to unauthorized users on the system. This violates the principle of least privilege and can lead to data breaches, unauthorized file modifications, or execution of malicious code by unintended users or groups. In multi-user environments, world-readable or world-writable files are especially dangerous.
To fix this issue, review all calls to os.Chmod, os.OpenFile, and os.WriteFile and restrict permissions to the minimum required. For most application files, 0o600 (owner read/write only) or 0o640 (owner read/write, group read) is sufficient. Avoid using permissions like 0o777, 0o755, or 0o666 unless there is a specific, documented requirement.
Code examples
// VULNERABLE CODE - World-readable and world-writable permissions expose the file to all users
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o777)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o666)
}// SECURE CODE - Restricts access to owner only, preventing unauthorized reads or writes
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o600)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o640)
}Additional recommendations
- Use
0o600for sensitive files (private keys, credentials, config files) to restrict access to the owner only. - Use
0o640when group read access is explicitly required by the application design. - Never use world-writable permissions (
0o777,0o666,0o646) on files containing sensitive data. - Apply
os.Chmodafter file creation to enforce permissions even if the processumaskis permissive. - Set a restrictive
umask(e.g.,0o027or0o077) at application startup as a defense-in-depth measure. - This issue maps to CWE-732 and OWASP A01:2021 – Broken Access Control; follow your organization's security policy for file permission standards.
Rule ID: WS-I011-GO-00010
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
| "foundry.toml": filepath.Join(worktree, "packages/contracts-bedrock/foundry.toml"), | ||
| "locked-bundle.json": filepath.Join(root, entry.Bundle), | ||
| } { | ||
| data, err := os.ReadFile(source) |
There was a problem hiding this comment.
Improper Path Validation in File Operations (CWE-22)
More Details
This vulnerability arises when an application fails to properly validate file paths or filenames before performing operations on them. If user input is used to construct file paths or filenames without proper sanitization, an attacker could exploit this vulnerability to access unauthorized files or directories on the system.
The consequences of this vulnerability can be severe, as it may allow an attacker to read sensitive data, overwrite critical system files, or even gain elevated privileges on the system. Path traversal attacks, where an attacker attempts to access files outside the intended directory, are a common exploitation technique for this vulnerability.
To mitigate this risk, it is crucial to validate and sanitize all user input used in file operations. This includes properly handling directory separators, removing any path traversal sequences, and restricting access to only the intended directories. Additionally, it is recommended to use a whitelist approach, where only a predefined set of safe paths or filenames are allowed.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
This vulnerability arises when an application fails to properly validate and sanitize user-supplied file paths or filenames before performing file operations. If an attacker can control the file path or filename, they may be able to access unauthorized files or directories on the system, potentially leading to data breaches, system compromise, or privilege escalation.
To mitigate this vulnerability, it is crucial to validate and sanitize all user input used in file operations. This includes properly handling directory separators, removing any path traversal sequences, and restricting access to only the intended directories. It is recommended to use a whitelist approach, where only a predefined set of safe paths or filenames are allowed.
Code examples
// VULNERABLE CODE - User input is used directly in file operations without validation
func handleRequest(r *http.Request) {
filename := r.URL.Query().Get("file")
data, err := os.ReadFile(filename)
// ...
}// SECURE CODE - User input is validated and sanitized before file operations
import (
"path/filepath"
"strings"
)
func handleRequest(r *http.Request) {
filename := r.URL.Query().Get("file")
cleanPath := filepath.Clean(filename)
if !strings.HasPrefix(cleanPath, "/safe/directory/") {
// Reject the request if the path is not within the allowed directory
http.Error(w, "Invalid file path", http.StatusBadRequest)
return
}
data, err := os.ReadFile(cleanPath)
// ...
}Additional recommendations
- Use a whitelist approach to restrict file operations to a predefined set of safe paths or filenames.
- Implement strict input validation and sanitization for all user-supplied data used in file operations.
- Follow the principle of least privilege and restrict file access permissions as much as possible.
- Regularly update and patch your software to address known vulnerabilities.
- Adhere to security best practices and standards, such as the OWASP Top 10 and CWE-22 (Improper Limitation of a Pathname to a Restricted Directory).
- Consider using secure coding libraries or frameworks that provide built-in protection against path traversal vulnerabilities.
Rule ID: WS-I011-GO-00013
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
| if err != nil { | ||
| return err | ||
| } | ||
| if err := os.WriteFile(filepath.Join(report, name), data, 0644); err != nil { |
There was a problem hiding this comment.
Overly Permissive File Permissions in Go (CWE-732)
More Details
The application is setting file permissions to overly permissive values, allowing unauthorized access to sensitive files. This vulnerability can lead to data breaches, unauthorized modifications, or execution of malicious code. Attackers who gain access to the system could exploit these excessive permissions to read, modify, or execute files they should not have access to.
To mitigate this risk, applications should assign the least permissive file permissions required for their intended functionality. Permissions should be carefully reviewed and restricted to only allow necessary operations for the application user or group.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Setting overly permissive file permissions (greater than 0o640) exposes sensitive files to unauthorized users on the system. This violates the principle of least privilege and can lead to data breaches, unauthorized file modifications, or execution of malicious code by unintended users or groups. In multi-user environments, world-readable or world-writable files are especially dangerous.
To fix this issue, review all calls to os.Chmod, os.OpenFile, and os.WriteFile and restrict permissions to the minimum required. For most application files, 0o600 (owner read/write only) or 0o640 (owner read/write, group read) is sufficient. Avoid using permissions like 0o777, 0o755, or 0o666 unless there is a specific, documented requirement.
Code examples
// VULNERABLE CODE - World-readable and world-writable permissions expose the file to all users
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o777)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o666)
}// SECURE CODE - Restricts access to owner only, preventing unauthorized reads or writes
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o600)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o640)
}Additional recommendations
- Use
0o600for sensitive files (private keys, credentials, config files) to restrict access to the owner only. - Use
0o640when group read access is explicitly required by the application design. - Never use world-writable permissions (
0o777,0o666,0o646) on files containing sensitive data. - Apply
os.Chmodafter file creation to enforce permissions even if the processumaskis permissive. - Set a restrictive
umask(e.g.,0o027or0o077) at application startup as a defense-in-depth measure. - This issue maps to CWE-732 and OWASP A01:2021 – Broken Access Control; follow your organization's security policy for file permission standards.
Rule ID: WS-I011-GO-00010
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
| if err != nil { | ||
| return err | ||
| } | ||
| return os.WriteFile(filepath.Join(report, "tracked-stage.bin"), data, 0644) |
There was a problem hiding this comment.
Overly Permissive File Permissions in Go (CWE-732)
More Details
The application is setting file permissions to overly permissive values, allowing unauthorized access to sensitive files. This vulnerability can lead to data breaches, unauthorized modifications, or execution of malicious code. Attackers who gain access to the system could exploit these excessive permissions to read, modify, or execute files they should not have access to.
To mitigate this risk, applications should assign the least permissive file permissions required for their intended functionality. Permissions should be carefully reviewed and restricted to only allow necessary operations for the application user or group.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Setting overly permissive file permissions (greater than 0o640) exposes sensitive files to unauthorized users on the system. This violates the principle of least privilege and can lead to data breaches, unauthorized file modifications, or execution of malicious code by unintended users or groups. In multi-user environments, world-readable or world-writable files are especially dangerous.
To fix this issue, review all calls to os.Chmod, os.OpenFile, and os.WriteFile and restrict permissions to the minimum required. For most application files, 0o600 (owner read/write only) or 0o640 (owner read/write, group read) is sufficient. Avoid using permissions like 0o777, 0o755, or 0o666 unless there is a specific, documented requirement.
Code examples
// VULNERABLE CODE - World-readable and world-writable permissions expose the file to all users
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o777)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o666)
}// SECURE CODE - Restricts access to owner only, preventing unauthorized reads or writes
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o600)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o640)
}Additional recommendations
- Use
0o600for sensitive files (private keys, credentials, config files) to restrict access to the owner only. - Use
0o640when group read access is explicitly required by the application design. - Never use world-writable permissions (
0o777,0o666,0o646) on files containing sensitive data. - Apply
os.Chmodafter file creation to enforce permissions even if the processumaskis permissive. - Set a restrictive
umask(e.g.,0o027or0o077) at application startup as a defense-in-depth measure. - This issue maps to CWE-732 and OWASP A01:2021 – Broken Access Control; follow your organization's security policy for file permission standards.
Rule ID: WS-I011-GO-00010
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
| if err != nil { | ||
| return err | ||
| } | ||
| if err := os.WriteFile(filepath.Join(report, name), data, 0644); err != nil { |
There was a problem hiding this comment.
Overly Permissive File Permissions in Go (CWE-732)
More Details
The application is setting file permissions to overly permissive values, allowing unauthorized access to sensitive files. This vulnerability can lead to data breaches, unauthorized modifications, or execution of malicious code. Attackers who gain access to the system could exploit these excessive permissions to read, modify, or execute files they should not have access to.
To mitigate this risk, applications should assign the least permissive file permissions required for their intended functionality. Permissions should be carefully reviewed and restricted to only allow necessary operations for the application user or group.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Setting overly permissive file permissions (greater than 0o640) exposes sensitive files to unauthorized users on the system. This violates the principle of least privilege and can lead to data breaches, unauthorized file modifications, or execution of malicious code by unintended users or groups. In multi-user environments, world-readable or world-writable files are especially dangerous.
To fix this issue, review all calls to os.Chmod, os.OpenFile, and os.WriteFile and restrict permissions to the minimum required. For most application files, 0o600 (owner read/write only) or 0o640 (owner read/write, group read) is sufficient. Avoid using permissions like 0o777, 0o755, or 0o666 unless there is a specific, documented requirement.
Code examples
// VULNERABLE CODE - World-readable and world-writable permissions expose the file to all users
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o777)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o666)
}// SECURE CODE - Restricts access to owner only, preventing unauthorized reads or writes
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o600)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o640)
}Additional recommendations
- Use
0o600for sensitive files (private keys, credentials, config files) to restrict access to the owner only. - Use
0o640when group read access is explicitly required by the application design. - Never use world-writable permissions (
0o777,0o666,0o646) on files containing sensitive data. - Apply
os.Chmodafter file creation to enforce permissions even if the processumaskis permissive. - Set a restrictive
umask(e.g.,0o027or0o077) at application startup as a defense-in-depth measure. - This issue maps to CWE-732 and OWASP A01:2021 – Broken Access Control; follow your organization's security policy for file permission standards.
Rule ID: WS-I011-GO-00010
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
| if err != nil { | ||
| return err | ||
| } | ||
| if err := os.WriteFile(filepath.Join(report, "submodule-inventories.json"), append(data, '\n'), 0644); err != nil { |
There was a problem hiding this comment.
Overly Permissive File Permissions in Go (CWE-732)
More Details
The application is setting file permissions to overly permissive values, allowing unauthorized access to sensitive files. This vulnerability can lead to data breaches, unauthorized modifications, or execution of malicious code. Attackers who gain access to the system could exploit these excessive permissions to read, modify, or execute files they should not have access to.
To mitigate this risk, applications should assign the least permissive file permissions required for their intended functionality. Permissions should be carefully reviewed and restricted to only allow necessary operations for the application user or group.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Setting overly permissive file permissions (greater than 0o640) exposes sensitive files to unauthorized users on the system. This violates the principle of least privilege and can lead to data breaches, unauthorized file modifications, or execution of malicious code by unintended users or groups. In multi-user environments, world-readable or world-writable files are especially dangerous.
To fix this issue, review all calls to os.Chmod, os.OpenFile, and os.WriteFile and restrict permissions to the minimum required. For most application files, 0o600 (owner read/write only) or 0o640 (owner read/write, group read) is sufficient. Avoid using permissions like 0o777, 0o755, or 0o666 unless there is a specific, documented requirement.
Code examples
// VULNERABLE CODE - World-readable and world-writable permissions expose the file to all users
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o777)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o666)
}// SECURE CODE - Restricts access to owner only, preventing unauthorized reads or writes
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o600)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o640)
}Additional recommendations
- Use
0o600for sensitive files (private keys, credentials, config files) to restrict access to the owner only. - Use
0o640when group read access is explicitly required by the application design. - Never use world-writable permissions (
0o777,0o666,0o646) on files containing sensitive data. - Apply
os.Chmodafter file creation to enforce permissions even if the processumaskis permissive. - Set a restrictive
umask(e.g.,0o027or0o077) at application startup as a defense-in-depth measure. - This issue maps to CWE-732 and OWASP A01:2021 – Broken Access Control; follow your organization's security policy for file permission standards.
Rule ID: WS-I011-GO-00010
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
| return err | ||
| } | ||
| if generated { | ||
| data, err := os.ReadFile(filepath.Join(worktree, "packages/contracts-bedrock/snapshots/upgrades/current-upgrade-bundle.json")) |
There was a problem hiding this comment.
Improper Path Validation in File Operations (CWE-22)
More Details
This vulnerability arises when an application fails to properly validate file paths or filenames before performing operations on them. If user input is used to construct file paths or filenames without proper sanitization, an attacker could exploit this vulnerability to access unauthorized files or directories on the system.
The consequences of this vulnerability can be severe, as it may allow an attacker to read sensitive data, overwrite critical system files, or even gain elevated privileges on the system. Path traversal attacks, where an attacker attempts to access files outside the intended directory, are a common exploitation technique for this vulnerability.
To mitigate this risk, it is crucial to validate and sanitize all user input used in file operations. This includes properly handling directory separators, removing any path traversal sequences, and restricting access to only the intended directories. Additionally, it is recommended to use a whitelist approach, where only a predefined set of safe paths or filenames are allowed.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
This vulnerability arises when an application fails to properly validate and sanitize user-supplied file paths or filenames before performing file operations. If an attacker can control the file path or filename, they may be able to access unauthorized files or directories on the system, potentially leading to data breaches, system compromise, or privilege escalation.
To mitigate this vulnerability, it is crucial to validate and sanitize all user input used in file operations. This includes properly handling directory separators, removing any path traversal sequences, and restricting access to only the intended directories. It is recommended to use a whitelist approach, where only a predefined set of safe paths or filenames are allowed.
Code examples
// VULNERABLE CODE - User input is used directly in file operations without validation
func handleRequest(r *http.Request) {
filename := r.URL.Query().Get("file")
data, err := os.ReadFile(filename)
// ...
}// SECURE CODE - User input is validated and sanitized before file operations
import (
"path/filepath"
"strings"
)
func handleRequest(r *http.Request) {
filename := r.URL.Query().Get("file")
cleanPath := filepath.Clean(filename)
if !strings.HasPrefix(cleanPath, "/safe/directory/") {
// Reject the request if the path is not within the allowed directory
http.Error(w, "Invalid file path", http.StatusBadRequest)
return
}
data, err := os.ReadFile(cleanPath)
// ...
}Additional recommendations
- Use a whitelist approach to restrict file operations to a predefined set of safe paths or filenames.
- Implement strict input validation and sanitization for all user-supplied data used in file operations.
- Follow the principle of least privilege and restrict file access permissions as much as possible.
- Regularly update and patch your software to address known vulnerabilities.
- Adhere to security best practices and standards, such as the OWASP Top 10 and CWE-22 (Improper Limitation of a Pathname to a Restricted Directory).
- Consider using secure coding libraries or frameworks that provide built-in protection against path traversal vulnerabilities.
Rule ID: WS-I011-GO-00013
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
| if err != nil { | ||
| return err | ||
| } | ||
| return os.WriteFile(filepath.Join(report, "regenerated-bundle.json"), data, 0644) |
There was a problem hiding this comment.
Overly Permissive File Permissions in Go (CWE-732)
More Details
The application is setting file permissions to overly permissive values, allowing unauthorized access to sensitive files. This vulnerability can lead to data breaches, unauthorized modifications, or execution of malicious code. Attackers who gain access to the system could exploit these excessive permissions to read, modify, or execute files they should not have access to.
To mitigate this risk, applications should assign the least permissive file permissions required for their intended functionality. Permissions should be carefully reviewed and restricted to only allow necessary operations for the application user or group.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
Setting overly permissive file permissions (greater than 0o640) exposes sensitive files to unauthorized users on the system. This violates the principle of least privilege and can lead to data breaches, unauthorized file modifications, or execution of malicious code by unintended users or groups. In multi-user environments, world-readable or world-writable files are especially dangerous.
To fix this issue, review all calls to os.Chmod, os.OpenFile, and os.WriteFile and restrict permissions to the minimum required. For most application files, 0o600 (owner read/write only) or 0o640 (owner read/write, group read) is sufficient. Avoid using permissions like 0o777, 0o755, or 0o666 unless there is a specific, documented requirement.
Code examples
// VULNERABLE CODE - World-readable and world-writable permissions expose the file to all users
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o777)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o666)
}// SECURE CODE - Restricts access to owner only, preventing unauthorized reads or writes
func writeConfig(filename string, data []byte) error {
return os.WriteFile(filename, data, 0o600)
}
func openLog(filename string) (*os.File, error) {
return os.OpenFile(filename, os.O_CREATE|os.O_WRONLY, 0o640)
}Additional recommendations
- Use
0o600for sensitive files (private keys, credentials, config files) to restrict access to the owner only. - Use
0o640when group read access is explicitly required by the application design. - Never use world-writable permissions (
0o777,0o666,0o646) on files containing sensitive data. - Apply
os.Chmodafter file creation to enforce permissions even if the processumaskis permissive. - Set a restrictive
umask(e.g.,0o027or0o077) at application startup as a defense-in-depth measure. - This issue maps to CWE-732 and OWASP A01:2021 – Broken Access Control; follow your organization's security policy for file permission standards.
Rule ID: WS-I011-GO-00010
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
| check(bool(path.stat().st_mode & 0o111) == (mode == b'100755'), | ||
| 'Changed committed source executable mode: ' + name) | ||
| data = path.read_bytes() | ||
| check(hashlib.sha1(b'blob ' + str(len(data)).encode() + b'\0' + data).hexdigest() == oid.decode(), |
There was a problem hiding this comment.
Usage of weak hash algorithm (MD5 or SHA-1) in Python hashlib (CWE-328)
More Details
This rule detects the use of cryptographically weak hash algorithms MD5 and SHA-1 through Python's hashlib module without explicitly marking them as non-security-critical. Both MD5 and SHA-1 have known collision vulnerabilities, meaning an attacker can craft two different inputs that produce the same hash output. This makes them unsuitable for any security-sensitive purpose.
Using these algorithms for password hashing, digital signatures, certificate generation, or data integrity verification exposes applications to forgery, impersonation, and data tampering attacks. Attackers can exploit collision weaknesses to bypass authentication or integrity checks. To mitigate this risk, replace MD5 and SHA-1 with SHA-256, SHA-3, or other modern algorithms. If you genuinely need MD5 or SHA-1 for non-security purposes such as non-critical checksums or legacy compatibility, pass the argument usedforsecurity=False to suppress this warning and document the intent clearly.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
The use of MD5 or SHA-1 hashing algorithms via Python's hashlib module introduces a critical cryptographic weakness. Both algorithms are considered cryptographically broken: MD5 is vulnerable to collision attacks and SHA-1 has been practically broken since 2017 (demonstrated by the SHAttered attack). Using these algorithms for password hashing, digital signatures, or data integrity verification can allow attackers to forge hashes, bypass authentication, or tamper with data undetected.
To fix this issue, replace hashlib.md5() or hashlib.sha1() calls with a stronger algorithm such as hashlib.sha256(), hashlib.sha3_256(), or hashlib.sha512(). If the hash is genuinely used for a non-security purpose (e.g., a cache key or non-cryptographic checksum), you may suppress the warning by explicitly passing usedforsecurity=False to signal intent and maintain compatibility with FIPS-compliant environments.
Code examples
# VULNERABLE CODE - MD5 and SHA-1 are cryptographically broken and unsafe for security use
import hashlib
def hash_password(password: str) -> str:
return hashlib.md5(password.encode()).hexdigest()
def verify_file_integrity(data: bytes) -> str:
return hashlib.sha1(data).hexdigest()# SECURE CODE - SHA-256 is cryptographically strong and suitable for security-sensitive operations
import hashlib
def hash_password(password: str) -> str:
return hashlib.sha256(password.encode()).hexdigest()
def verify_file_integrity(data: bytes) -> str:
return hashlib.sha256(data).hexdigest()
# Non-security use: explicitly mark with usedforsecurity=False
cache_key = hashlib.md5(data, usedforsecurity=False).hexdigest()Additional recommendations
- For password hashing specifically, never use raw SHA-256 either — use dedicated password hashing functions like
hashlib.scrypt(),bcrypt, orargon2-cffiwhich include salting and work factors. - Prefer
hashlib.sha3_256()orhashlib.sha3_512()(SHA-3 family) for new implementations, as they are structurally distinct from SHA-2 and provide defense-in-depth. - When migrating legacy systems, audit all uses of MD5/SHA-1 to determine whether they are security-sensitive before applying
usedforsecurity=Falseas a workaround. - Follow NIST SP 800-131A and OWASP Cryptographic Storage Cheat Sheet guidelines, which formally deprecate MD5 and SHA-1 for all security applications.
- Ensure that hash algorithm choices are centralized in a utility module to make future algorithm migrations easier and consistent across the codebase.
- If interoperability with legacy systems requires MD5/SHA-1, document the risk explicitly and implement compensating controls such as additional HMAC layers.
Rule ID: WS-PYTHON-00367
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
| status, errors, signals = 1, [], [] | ||
| started = time.time() | ||
| with (directory / 'stdout.log').open('wb') as stdout, (directory / 'stderr.log').open('wb') as stderr: | ||
| process = subprocess.Popen(argv, cwd=ROOT, stdout=stdout, stderr=stderr, start_new_session=True) |
There was a problem hiding this comment.
Command Injection via Subprocess (CWE-78)
More Details
This rule detects instances where user-controlled data is passed to the subprocess module without proper sanitization, leading to command injection vulnerabilities.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
The vulnerability arises from the use of user-controlled data in subprocess function calls, which can lead to command injection attacks. If an attacker can inject malicious code into the command executed by the subprocess, they can potentially gain unauthorized access or perform unintended actions on the system.
To fix this issue securely, user input should be properly sanitized and validated before being passed to subprocess functions. One recommended approach is to use the shlex.quote() function to escape any special characters in the input, preventing them from being interpreted as shell commands. Additionally, avoid using shell=True in subprocess calls, as it can introduce additional attack vectors.
Code examples
# VULNERABLE CODE - User input is passed directly to subprocess without validation
import subprocess
user_input = input("Enter a command: ")
subprocess.run(user_input, shell=True)# SECURE CODE - User input is sanitized using shlex.quote() before subprocess call
import subprocess
import shlex
user_input = input("Enter a command: ")
sanitized_input = shlex.quote(user_input)
subprocess.run(sanitized_input, shell=False)Additional recommendations
- Follow the principle of least privilege and run subprocesses with the minimum required permissions.
- Implement input validation and whitelisting to restrict user input to a predefined set of allowed values.
- Consider using safer alternatives to subprocess, such as the
os.system()function, which does not invoke a shell by default. - Adhere to secure coding practices outlined in the OWASP Application Security Verification Standard (ASVS) and other relevant security standards.
- Regularly update and patch your software to address known vulnerabilities.
Rule ID: WS-I013-PYTHON-00141
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
teddyknox
changed the title
|
|
||
| def derived(path, phase, cases): | ||
| rows = [] | ||
| for suite in ET.parse(path).iter('testsuite'): |
There was a problem hiding this comment.
Unsafe XML Parsing Using xml.etree (CWE-611)
More Details
The application is using the built-in xml.etree package for parsing XML data. This package is known to be vulnerable to various XML parsing vulnerabilities, including Billion Laughs/Exponential Entity Expansion and Quadratic Blowup Entity Expansion attacks. These vulnerabilities can potentially lead to Denial of Service (DoS) attacks, where an attacker can craft a malicious XML payload that causes excessive resource consumption, crashing or freezing the application.
Additionally, depending on the Python version, more critical vulnerabilities like XML External Entity (XXE) injection may be exploitable. XXE vulnerabilities can allow an attacker to access sensitive data, execute remote code, or perform other malicious actions by leveraging the XML parser's ability to retrieve external resources.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
The use of the built-in xml.etree package in Python for parsing XML data can expose the application to various XML parsing vulnerabilities, including Billion Laughs/Exponential Entity Expansion, Quadratic Blowup Entity Expansion, and potentially XML External Entity (XXE) injection attacks. These vulnerabilities can lead to Denial of Service (DoS) attacks, where an attacker can craft a malicious XML payload that causes excessive resource consumption, crashing or freezing the application. Additionally, XXE vulnerabilities can allow an attacker to access sensitive data, execute remote code, or perform other malicious actions by leveraging the XML parser's ability to retrieve external resources.
To mitigate these vulnerabilities, it is recommended to use a secure XML parsing library that provides protection against these attacks. One such library is defusedxml, which is a Python library that provides a secure way to parse XML data by disabling external entity resolution and limiting the maximum depth of nested entities.
Code examples
# VULNERABLE CODE - The built-in `xml.etree` package is used for parsing XML data
import xml.etree.ElementTree as ET
xml_data = """<root>...</root>"""
tree = ET.fromstring(xml_data)# SECURE CODE - Using the `defusedxml` library to parse XML data securely
from defusedxml import ElementTree as ET
xml_data = """<root>...</root>"""
tree = ET.fromstring(xml_data)Additional recommendations
- Follow the principle of least privilege and only grant the minimum required permissions to the XML parser.
- Validate and sanitize all user input before parsing XML data to prevent injection attacks.
- Keep the XML parsing library and its dependencies up-to-date with the latest security patches.
- Implement input validation, output encoding, and other security best practices recommended by the OWASP XML External Entity (XXE) Prevention Cheat Sheet.
- Adhere to relevant security standards, such as the OWASP Application Security Verification Standard (ASVS) and the OWASP Top 10 Web Application Security Risks.
- Consider using a Web Application Firewall (WAF) or an XML Gateway to provide an additional layer of protection against XML-based attacks.
Rule ID: WS-I011-PYTHON-00055
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
| content = path.read_text(encoding="utf-8") | ||
| if re.search(r"<!\s*(?:DOCTYPE|ENTITY)\b", content, re.IGNORECASE): | ||
| raise ValueError("JUnit DTDs/entities are unsupported") | ||
| root = ET.fromstring(content) |
There was a problem hiding this comment.
Unsafe XML Parsing Using xml.etree (CWE-611)
More Details
The application is using the built-in xml.etree package for parsing XML data. This package is known to be vulnerable to various XML parsing vulnerabilities, including Billion Laughs/Exponential Entity Expansion and Quadratic Blowup Entity Expansion attacks. These vulnerabilities can potentially lead to Denial of Service (DoS) attacks, where an attacker can craft a malicious XML payload that causes excessive resource consumption, crashing or freezing the application.
Additionally, depending on the Python version, more critical vulnerabilities like XML External Entity (XXE) injection may be exploitable. XXE vulnerabilities can allow an attacker to access sensitive data, execute remote code, or perform other malicious actions by leveraging the XML parser's ability to retrieve external resources.
| Attribute | Value |
|---|---|
| Impact | |
| Likelihood | |
Remediation
The use of the built-in xml.etree package in Python for parsing XML data can expose the application to various XML parsing vulnerabilities, including Billion Laughs/Exponential Entity Expansion, Quadratic Blowup Entity Expansion, and potentially XML External Entity (XXE) injection attacks. These vulnerabilities can lead to Denial of Service (DoS) attacks, where an attacker can craft a malicious XML payload that causes excessive resource consumption, crashing or freezing the application. Additionally, XXE vulnerabilities can allow an attacker to access sensitive data, execute remote code, or perform other malicious actions by leveraging the XML parser's ability to retrieve external resources.
To mitigate these vulnerabilities, it is recommended to use a secure XML parsing library that provides protection against these attacks. One such library is defusedxml, which is a Python library that provides a secure way to parse XML data by disabling external entity resolution and limiting the maximum depth of nested entities.
Code examples
# VULNERABLE CODE - The built-in `xml.etree` package is used for parsing XML data
import xml.etree.ElementTree as ET
xml_data = """<root>...</root>"""
tree = ET.fromstring(xml_data)# SECURE CODE - Using the `defusedxml` library to parse XML data securely
from defusedxml import ElementTree as ET
xml_data = """<root>...</root>"""
tree = ET.fromstring(xml_data)Additional recommendations
- Follow the principle of least privilege and only grant the minimum required permissions to the XML parser.
- Validate and sanitize all user input before parsing XML data to prevent injection attacks.
- Keep the XML parsing library and its dependencies up-to-date with the latest security patches.
- Implement input validation, output encoding, and other security best practices recommended by the OWASP XML External Entity (XXE) Prevention Cheat Sheet.
- Adhere to relevant security standards, such as the OWASP Application Security Verification Standard (ASVS) and the OWASP Top 10 Web Application Security Risks.
- Consider using a Web Application Firewall (WAF) or an XML Gateway to provide an additional layer of protection against XML-based attacks.
Rule ID: WS-I011-PYTHON-00055
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
This branch has not been deployed
1 participant
Native RWX shadows cover 86/86 baseline CircleCI PR job occurrences (100%), with successful full native execution and resolved same-SHA original-report parity for every counted occurrence. All work stays in this single draft PR. Circle retains its four required gates and production publishers.
Authoritative routing and complete workload discovery select the same suites. Reusable producers build Go preparation, contracts, Cannon/prestates, Kona, op-reth and SP1 artifacts in parallel. Isolated Go, Foundry, Cargo target, sccache and Docker caches retain compiler/build inputs; verdicts execute freshly. Source/settings manifests and file hashes bind producers and consumers. CLI modes and protected compiler-only warming remain available.
The final three workloads passed complete original parity together at f821983 in Circle pipeline 135650, the native coordinator and native selector replay:
The L2 runner preserves the initialized Circle shell environment so nested Bash cannot overwrite its runtime relay URL. A shared native Contracts source producer supplies initialized submodules to every compilation and verdict worker. Existing consumers verify source hashes and revisions. The prior RPC and GitHub clone failures remain retained.
Native aggregate gates evaluate their original dependency sets and current engine-bound receipts. A failed, canceled or selected-but-skipped dependency fails the final status. Receipts and downstream observers retain independent task attempt numbers, so a successful native retry does not fail solely because an observer was rerun. Strict hosted parity still requires original first-attempt successful gate evidence. All 27 real Git/YQ PR-gate fixtures, eight E2E aggregate fixtures, eleven NUT provenance fixtures and eight strict E2E comparison fixtures pass. Coverage includes original failure, successful retry and a later failed retry. E2E records per-shard task attempts; NUT preparation and verification preserve the same runtime retry policy.
The implementation head before evidence cleanup, a1aa49a, passed all four required Circle gates, dependency review and all 23 optional RWX checks. Circle pipeline 135655 finished all seven workflows successfully. The native coordinator passed all sixteen workload groups, three aggregates and final statuses; Rust E2E passed all fourteen verdict shards and its aggregate. Earlier network and runtime retry-policy failures remain retained in the complete coverage index. Corrections were verified together; no per-job Circle replay was dispatched.
The chosen Go configuration remains 12 duration-balanced shards and parallelism 8, with 16 CPU / 32 GiB compilation and 8 CPU / 16 GiB verdict workers. Acceptance retains eight shards per variant. Further performance tuning is deferred; these parity observations establish no provider speed claim.
The chosen configuration now uses parameterized RWX local packages for Go, acceptance, contract suites, coverage/upgrades and shared Go/Foundry/Rust tool preparation. The experimental 24-shard Go tasks are removed. Compilation still overlaps Rust/prestate builds; runtime workers receive filtered inputs and validate the same sealed archives, without importing compiler caches or receiving credentials during setup. Native gate validation resolves the actual executable leaf while preserving caller states and all existing check names.
The five main definitions shrink from 5,380 to 2,122 lines. Including all 638 lines of new workload, toolchain and native-probe packages, the net reduction is 2,620 lines (49%). The package contracts document the input boundaries and native success, intentional-failure and warm-only proofs. Local helper/gate tests, ShellCheck and RWX lint pass. Native probes caught and verified corrections for package artifact arguments, static output filters and direct Rust E2E task references. The Kontrol fixture uses Git file transport to avoid unsupported snapshot hardlinks while preserving its revision. The refactor head ccaddc0 passed all seven workflows in Circle pipeline 135703, all contract variants and six live Kontrol fixtures. Its native Rust workspace run exposed an existing Cannon handoff assumption: the build recipe can rebuild its environment, so the offline consumer must verify the latest build producer's sealed image and ELF inputs. The correction and strict report comparer pass 26 targeted tests; stale or mismatched images remain rejected.
The preceding local-package refactor head, af0d89b, passed all 23 optional RWX checks, all four required Circle gates and dependency review. Circle pipeline 135706 finished all seven workflows successfully. The native coordinator passed all workload groups and aggregates, including all 12 fresh Go verdicts and all 16 acceptance verdicts; Rust E2E also passed. The corrected Cannon consumer completed fresh VM execution with guest exit code 0 at L2 block 47,600,000. Its 41 build/offline original files and exact build-image handoff hashes were verified and retained in two private copies outside Git. Original failures remain retained. No Circle benchmark replay was dispatched.
The helper refactor at 8ec3e62 removes runtime imports of offline comparers. Shared report I/O, subprocess capture/cancellation and artifact-byte checks now live in
ci-report.py; Go/JUnit decoding lives inci-test-results.py. Each suite retains selection, source/settings binding, freshness, retry limits and verdict rules. Contract comparison fixtures share report construction, while corrupt artifacts, stale caches, cancellation, retries and initial-failure evidence retain coverage. Existing input seals and isolated runner fixtures include the shared implementation files. Local verification passes 554 tests (512 passed, 42 opt-in/tool tests skipped), a final 57-test comparer/helper batch and RWX lint. The first native coordinator passed its shared helper tests, then exposed an omitted shared-module input in the filtered SP1 toolchain task. 57094f2 adds that file to the existing filter; eight package regressions, including an import from exactly the filtered bytes, and RWX lint pass. The corrected revision passes the hosted shared-helper task and the previously failing SP1 toolchain task in native coordinator 5544bed9. Full workload checks are still running on this revision; preceding hosted results remain historical.Validation includes routing/Circle adapter fixtures, artifact and failure behavior, meaningful helper tests, ShellCheck, RWX lint, merged Circle configuration validation and hosted full workloads. The coverage checklist links every workload closeout. Complete L2 originals, Contracts gate originals and selector originals retain exact revisions, run identities and all report hashes.
Protected cache-rebuild observation on develop, operational routing/cutover rehearsals, post-merge/release work and required-gate migration remain separate follow-ups.
Generated evidence is retained outside Git in two private copies. The archive index provides source provenance, exact hashes, retrieval/restoration commands and explicitly scoped historical gaps. Compression and deduplication retain 38.2 GB of logical originals in about 2.4 GB including metadata and a self-contained source bundle. The archive and bundle are not committed. The repository retains only the index, 92 summary checksums and human-written closeouts; their historical report links pin the captured revision. Existing earlier report commits remain in branch history; a future squash merge can land the final tree without importing those report blobs.
Evidence cleanup removes 92 generated files and reduces the PR from 2,490,367 to 45,080 added lines (98.09% fewer), across 308 final changed files. Both full archives passed compressed and original hash validation for all 23,141 objects / 216,558 paths. Restored L2, Contracts gate, selector and flaky-report comparisons pass; empty, changed-manifest, missing/corrupt-object and overwrite probes behave correctly. All 97 historical report links and 92 summary hashes were checked. This cleanup changes documentation and generated data only.
The standalone source bundle passed a clean clone to the archived revision and Git object integrity checks. The initial shallow-history clone failure and superseded bundle are retained explicitly; the index pins the corrected bundle checksum.
Evidence-cleanup revision:
899a926ae0e3a410fba7795da4c8054257a74f1c. Its archival results are historical; the latest implementation and validation appear above.