[ColinDKelley]

Summary

Merge upstream Prometheus v3.13.0 (LTS, supported until 2027-07-31) into invoca-2.55.1-base, creating the 3.x integration anchor for Invoca's fork.

Stacked on invoca-2.55.1-base (#27 chain). No Invoca rate-func features in this branch — promql was taken from upstream 3.13 wholesale (merge kept stale Invoca xrate parser entries; fixed in second commit).

Lineage

invoca-2.53.1-base
  └─ invoca-2.55.1-base (#27)
       └─ invoca-3.13-base (#28, this PR)     ← upstream v3.13.0
            └─ (future) port-rate-funcs        ← re-implement xrate/yrate + REPLACE_RATE_FUNCS

Why clean upstream PromQL?

Upstream 3.13 rewrote promql/functions.go (~1,600 lines changed vs 3.0). Invoca xrate/yrate from 2.55 will not cherry-pick — they must be re-ported against the new pickOrInterpolateLeft/pickOrInterpolateRight rate architecture. Starting from stock 3.13 PromQL avoids carrying 2.x fork debt forward.

Merge notes

• Conflicts in promql/engine.go, promql/functions.go, promql/promqltest/testdata/functions.test → resolved with upstream 3.13
• promql/parser/functions.go auto-merge kept Invoca xrate parser stubs → reset to upstream 3.13 in follow-up commit

Test plan

• go build ./...
• go test -count=1 ./promql/...
• Full go test ./... (optional; large)
• Staging spike checklist below before starting rate-func re-port

---

Pre-port spike checklist (ops / TSDB / integration)

Run these on this branch (or a throwaway deploy) before stacking invoca-3.13/port-rate-funcs. Goal: surface 3.x migration risk without touching Invoca PromQL yet.

Prerequisites

• 2.55.1 stack merged and staging has run on Invoca 2.55.1 for ≥ one retention window (TSDB bridge requirement per migration guide)
• Thanos pairing plan for 3.13 (likely v0.40.x+; 0.37.2 embeds 2.55-era prometheus only)

TSDB / data path

• Start 3.13 against TSDB written by 2.55.1 — confirm blocks load, no corruption errors
• Confirm downgrade path: 3.13 → 2.55.1 works; 3.13 → 2.53 does not (expected)
• WAL replay clean on restart after 2.55 → 3.13 cutover

Config / deployment breaking changes (migration guide)

• Scrape targets: Content-Type strictness — any targets need fallback_scrape_protocol?
• Alertmanager: api_version: v2 only (no v1)
• Remote write: http_config.enable_http2 default now false — verify remote_write still works if you rely on HTTP/2
• Feature flags removed from --enable-feature (now default or dedicated flags): expand-external-labels, no-default-scrape-port, agent, remote-write-receiver, auto-gomemlimit, auto-gomaxprocs
• scrape_classic_histograms → always_scrape_classic_histograms if used
• Log format changed (log/slog) — update any log parsers/alerts

PromQL behavior (upstream 3.x, no Invoca funcs yet)

• Spot-check dashboards using rate/increase on boundary-aligned subqueries — 3.x is (start, end]; subqueries like foo[1m:1m] may return fewer points (migration guide)
• Regex . now matches newlines — audit relabel/alert regexes if needed
• le/quantile label normalization — audit rules referencing integer le="1" (now le="1.0")

Thanos / ecosystem

• Build Invoca Thanos fork against 3.13 prometheus embed (new branch from v0.40.x?)
• Sidecar uploads blocks from 3.13 Prometheus
• Thanos Query evaluates standard PromQL against 3.13-embedded engine

Exit criteria for spike

• Staging shard runs 3.13 base for ≥ 24–48h without TSDB/scrape/alert regressions
• Known dashboard/recording-rule diffs documented (expected from 3.x semantics, not bugs)
• Only then: branch invoca-3.13/port-rate-funcs off this base

Related

• 2.55.1 feature stack: Fix xrate extended-range iteration and refresh rate-vs-xrate showcase (2.55) #21 → Add yrate/yincrease/ydelta (2.55) #22 → Align yrate/yincrease/ydelta with Prometheus 3.x (start, end] semantics #20 → Preserve upstream rate funcs as _rate when REPLACE_RATE_FUNCS is set #26
• LTS support table: https://prometheus.io/docs/introduction/release-cycle/

Wiz Scan Summary

⚠️ Many findings detected

Many findings were detected, but only a subset of the findings are displayed inline due to API constraints. To view all findings inline, please click here.

Scanner	Findings
Vulnerabilities	34  13  5
Sensitive Data	-
Secrets	-
IaC Misconfigurations	1  1  2  2
SAST Findings	14  24
Software Management Findings	-
Total	35  28  31  2

View scan details in Wiz

To detect these findings earlier in the dev lifecycle, try the Wiz Code extension for VS Code, JetBrains, or Visual Studio.

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentials
import (
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/credentials"
)

creds := credentials.NewStaticCredentialsProvider(
    "AKIAIOSFODNN7EXAMPLE",
    "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "",
)

// SECURE CODE - Using AWS credential provider
import (
    "github.com/aws/aws-sdk-go-v2/config"
)

cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
    // Handle error
}

// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

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

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentials
import (
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/credentials"
)

creds := credentials.NewStaticCredentialsProvider(
    "AKIAIOSFODNN7EXAMPLE",
    "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "",
)

// SECURE CODE - Using AWS credential provider
import (
    "github.com/aws/aws-sdk-go-v2/config"
)

cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
    // Handle error
}

// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

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

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentials
import (
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/credentials"
)

creds := credentials.NewStaticCredentialsProvider(
    "AKIAIOSFODNN7EXAMPLE",
    "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "",
)

// SECURE CODE - Using AWS credential provider
import (
    "github.com/aws/aws-sdk-go-v2/config"
)

cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
    // Handle error
}

// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

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

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentials
import (
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/credentials"
)

creds := credentials.NewStaticCredentialsProvider(
    "AKIAIOSFODNN7EXAMPLE",
    "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "",
)

// SECURE CODE - Using AWS credential provider
import (
    "github.com/aws/aws-sdk-go-v2/config"
)

cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
    // Handle error
}

// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

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

 SAST Finding

Non-literal regular expression usage leading to ReDoS vulnerability (CWE-185)

More Details

This rule detects the usage of non-literal regular expressions in JavaScript or TypeScript code. When a regular expression is constructed from user input or other non-literal sources, it can potentially lead to a Regular Expression Denial of Service (ReDoS) vulnerability. ReDoS attacks exploit the way certain regular expressions are processed, causing them to consume an excessive amount of resources and potentially causing the application to become unresponsive or crash.

The security risk lies in the potential for an attacker to craft a malicious regular expression that triggers catastrophic backtracking, leading to a denial of service condition. This could render the application unavailable to other users, causing disruption and potentially enabling further attacks. ReDoS vulnerabilities are particularly concerning in server-side applications where regular expressions are used to process untrusted input.

Attribute	Value
Impact
Likelihood

Remediation

Regular expressions constructed from user input or other non-literal sources can lead to a Regular Expression Denial of Service (ReDoS) vulnerability. ReDoS attacks exploit the way certain regular expressions are processed, causing them to consume an excessive amount of resources and potentially causing the application to become unresponsive or crash. This vulnerability can be exploited by an attacker to craft a malicious regular expression that triggers catastrophic backtracking, leading to a denial of service condition and rendering the application unavailable to other users.

To mitigate this vulnerability, it is recommended to use literal regular expressions or to validate and sanitize user input before constructing regular expressions. If user input must be used to construct regular expressions, it is crucial to implement proper input validation and sanitization to prevent malicious input from being used in the regular expression.

Code examples

// VULNERABLE CODE - Regular expression constructed from user input
const userInput = getUserInput(); // Untrusted user input
const regex = new RegExp(userInput);

// SECURE CODE - Using a literal regular expression
const regex = /^[a-zA-Z0-9]+$/;

// SECURE CODE - Validating and sanitizing user input before constructing regular expression
const userInput = getUserInput();
const sanitizedInput = sanitizeInput(userInput); // Implement input validation and sanitization
const regex = new RegExp(sanitizedInput);

Additional recommendations

• Follow the principle of least privilege and only use regular expressions when necessary.
• Implement input validation and sanitization for all user input used in regular expressions.
• Consider using a safe regular expression library or engine that is designed to mitigate ReDoS vulnerabilities.
• Adhere to the OWASP Injection Prevention Cheat Sheet and other relevant security standards.
• If user input must be used in regular expressions, consider alternative approaches such as using a whitelist of allowed patterns or splitting the input into smaller chunks before processing.

Rule ID: WS-I011-JAVASCRIPT-00003

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

 SAST Finding

Open Redirect Vulnerability (CWE-601)

More Details

The rule detects instances where user-supplied input is used to construct a URL for an HTTP redirect. This can lead to an open redirect vulnerability, which allows an attacker to redirect users to a malicious website.

Attribute	Value
Impact
Likelihood

Remediation

The open redirect vulnerability allows an attacker to redirect a user to a malicious website, potentially leading to phishing attacks, malware distribution, or other malicious activities. This vulnerability occurs when user-controlled input is used to construct the redirect URL without proper validation.

To fix this issue, it is recommended to avoid using user-controlled input to construct redirect URLs whenever possible. Instead, use a predefined list of allowed redirect URLs or a whitelist of trusted domains. If user input is required, implement strict validation and sanitization of the input before using it to construct the redirect URL.

Code examples

// VULNERABLE CODE - User input is used directly to construct the redirect URL
func handleRedirect(w http.ResponseWriter, r *http.Request) {
    redirectURL := r.FormValue("redirect_url")
    http.Redirect(w, r, redirectURL, http.StatusFound)
}

// SECURE CODE - Redirect URL is validated against a whitelist of trusted domains
func handleRedirect(w http.ResponseWriter, r *http.Request) {
    redirectURL := r.FormValue("redirect_url")
    if isValidRedirectURL(redirectURL) {
        http.Redirect(w, r, redirectURL, http.StatusFound)
    } else {
        // Handle invalid redirect URL
    }
}

func isValidRedirectURL(url string) bool {
    // Implement validation logic here, e.g., check against a whitelist of trusted domains
    // Return true if the URL is valid, false otherwise
}

Additional recommendations

• Follow the OWASP Unvalidated Redirects and Forwards Cheat Sheet for best practices.
• Implement strict input validation and sanitization for all user-controlled input.
• Consider using a third-party library or framework that provides built-in protection against open redirect vulnerabilities.
• Regularly update and maintain the whitelist of trusted domains.
• Implement logging and monitoring to detect and respond to potential attacks.
• Adhere to relevant security standards, such as the OWASP Top 10 and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-I013-GO-00057

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

 Vulnerability Finding

The following vulnerabilities impact github.com/prometheus/prometheus versions <0.311.3: CVE-2026-40179, CVE-2026-42151, CVE-2026-42154, CVE-2026-44903.

These can be remediated by updating to version 0.311.3 or higher.

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

Suggested change

	github.com/prometheus/prometheus v0.308.1
	github.com/prometheus/prometheus v0.311.3

 Vulnerability Finding

The following vulnerabilities impact github.com/prometheus/prometheus versions <0.311.3: CVE-2026-40179, CVE-2026-42151, CVE-2026-42154, CVE-2026-44903.

These can be remediated by updating to version 0.311.3 or higher.

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

Suggested change

	github.com/prometheus/prometheus v0.307.4-0.20251119130332-1174b0ce4f1f // indirect
	github.com/prometheus/prometheus v0.311.3 // indirect

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentials
import (
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/credentials"
)

creds := credentials.NewStaticCredentialsProvider(
    "AKIAIOSFODNN7EXAMPLE",
    "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "",
)

// SECURE CODE - Using AWS credential provider
import (
    "github.com/aws/aws-sdk-go-v2/config"
)

cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
    // Handle error
}

// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

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

 SAST Finding

Hardcoded AWS Credentials in Go Application

More Details

Embedding static AWS credentials directly into a Go application using the credentials.NewStaticCredentialsProvider function poses a significant security risk. This practice exposes the AWS access keys and secret keys in plaintext within the application code, making them vulnerable to theft or misuse. If an attacker gains access to the application code or the compiled binary, they can extract the hardcoded credentials and potentially gain unauthorized access to AWS resources, leading to data breaches, financial losses, or other malicious activities.

Hardcoded credentials should never be used in production environments. Instead, applications should retrieve credentials securely from trusted sources, such as environment variables, secure key management services, or temporary credentials obtained through AWS Identity and Access Management (IAM) roles. Failing to properly manage and protect AWS credentials can lead to severe consequences, including data exfiltration, resource hijacking, and compliance violations.

Attribute	Value
Impact
Likelihood

Remediation

Hardcoding AWS credentials into an application poses a significant security risk. If the application's code is compromised or accidentally exposed, the hardcoded credentials can be easily extracted and misused by attackers to gain unauthorized access to AWS resources, potentially leading to data breaches, financial losses, and other severe consequences.

To fix this issue securely, applications should retrieve AWS credentials from secure sources at runtime, such as environment variables, AWS credential files, or AWS credential providers. This approach ensures that credentials are not embedded in the application's code and can be easily rotated or revoked if needed.

Code examples

// VULNERABLE CODE - Hardcoded AWS credentials
import (
    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/credentials"
)

creds := credentials.NewStaticCredentialsProvider(
    "AKIAIOSFODNN7EXAMPLE",
    "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "",
)

// SECURE CODE - Using AWS credential provider
import (
    "github.com/aws/aws-sdk-go-v2/config"
)

cfg, err := config.LoadDefaultConfig(context.TODO())
if err != nil {
    // Handle error
}

// AWS credentials are retrieved securely from the environment or other sources

Additional recommendations

• Follow the AWS best practices for managing AWS access keys and secret access keys.
• Implement least privilege access principles by granting only the necessary permissions to AWS resources.
• Regularly rotate AWS credentials and revoke unused or compromised credentials.
• Consider using temporary security credentials (AWS STS) for enhanced security and auditing capabilities.
• Adhere to relevant security standards and guidelines, such as the AWS Security Best Practices and the OWASP Application Security Verification Standard (ASVS).

Rule ID: WS-GO-00051

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

 Vulnerability Finding

The following vulnerability impacts http-proxy-middleware versions <3.0.7: CVE-2026-55603.

It can be remediated by updating to version 3.0.7 or higher.

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

Suggested change

	"http-proxy-middleware": "^3.0.6",
	"http-proxy-middleware": "3.0.7",

 Vulnerability Finding

The following vulnerabilities impact google.golang.org/grpc versions <1.83.1: CVE-2026-84303, CVE-2026-84304, CVE-2026-84445, GHSA-hrxh-6v49-42gf.

These can be remediated by updating to version 1.83.1 or higher.

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

Suggested change

	google.golang.org/grpc v1.81.1 // indirect
	google.golang.org/grpc v1.83.1 // indirect

 Vulnerability Finding

The following vulnerabilities impact google.golang.org/grpc versions <1.83.1: CVE-2026-84303, CVE-2026-84304, CVE-2026-84445, GHSA-hrxh-6v49-42gf.

These can be remediated by updating to version 1.83.1 or higher.

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

Suggested change

	google.golang.org/grpc v1.81.1 // indirect
	google.golang.org/grpc v1.83.1 // indirect

 Vulnerability Finding

The following vulnerabilities impact google.golang.org/grpc versions <1.83.1: CVE-2026-84303, CVE-2026-84304, CVE-2026-84445, GHSA-hrxh-6v49-42gf.

These can be remediated by updating to version 1.83.1 or higher.

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

Suggested change

	google.golang.org/grpc v1.81.1 // indirect
	google.golang.org/grpc v1.83.1 // indirect

 IaC Finding

Missing User Instruction

More Details

This rule checks whether a `USER` instruction is specified in the Dockerfile. The rule fails when the `USER` instruction is missing, causing the container to run with root privileges (UID 0). If an attacker compromises an application running as root, they gain the privileges needed to potentially escape the container and attack the host node. It also increases the blast radius of a breach, allowing full control to modify files or install malware within the container. Enforcing a non-root user is a fundamental security measure that minimizes the attack surface and contains the impact of a potential compromise.

Expected

The Dockerfile stage should contain the 'USER' instruction

Found

The Dockerfile stage does not contain any 'USER' instruction

Security Frameworks: wf-id-264

Rule ID: fb18fd60-ca0d-4e75-98f1-720a8ec407d0

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

 IaC Finding

Image Version Using 'latest'

More Details

When building images, always tag them with useful tags which codify version information, intended destination (prod or test, for instance), stability, or other information that is useful when deploying the application in different environments. Do not rely on the automatically-created latest tag

Expected

FROM quay.io/prometheus/busybox-linux-amd64:latest@sha256:267c901b759acf876e23c8d36eb9e50315f7b795d651dc4062d0d02151698e25 should use a specific version instead of 'latest'

Found

FROM quay.io/prometheus/busybox-linux-amd64:latest@sha256:267c901b759acf876e23c8d36eb9e50315f7b795d651dc4062d0d02151698e25 uses the 'latest' tag

Rule ID: 91ba29eb-0fe8-4885-9fd8-7f3667a8b689

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

 SAST Finding

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