aws/eks-anywhere

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/curatedpackages/packagecontrollerclient.go line 161
Likely real: Yes, 99% confidence

Missing mutex unlock (`pc.mu` variable) before returning from a function. This could result in panics resulting from double lock operations

return err

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/curatedpackages/packagecontrollerclient.go line 164
Likely real: Yes, 99% confidence

Missing mutex unlock (`pc.mu` variable) before returning from a function. This could result in panics resulting from double lock operations

return pc.Enable(ctx)

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /designs/snow-integration.md line 126
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /designs/snow-integration.md line 131
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = Rq2AsrGU/RBCtzkReBl6PIneNX22WtNkeePw+WxzY

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/aws/testdata/invalid_credentials_no_access_key line 2
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/aws/testdata/invalid_credentials_no_ips line 2
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/aws/testdata/invalid_credentials_no_ips line 6
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/aws/testdata/valid_credentials line 3
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/aws/testdata/valid_credentials line 8
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/dependencies/testdata/snow/valid_credentials line 3
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/dependencies/testdata/snow/valid_credentials line 8
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/providers/snow/testdata/credentials line 3
Likely real: Yes, 99% confidence

AWS Secret Access Key detected

aws_secret_access_key = AfSD7sYz/TBZtzkReBl6PuuISzJ2WtNkeePw+nNzJ

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/executables.go line 107
Likely real: Uncertain, 46% confidence

Detected non-static command inside Command. Audit the input to 'exec.Command'. If unverified user data can reach this call site, this is a code injection vulnerability. A malicious actor can inject a malicious script to execute arbitrary code.

cmd := exec.CommandContext(ctx, cli, args...)

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/validations/upgradevalidations/testdata/git_nonempty_private_key line 1
Likely real: Uncertain, 45% confidence

Private Key detected. This is a sensitive credential and should not be hardcoded here. Instead, store this in a separate, private file.

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/validations/testdata/git_nonempty_private_key line 1
Likely real: Uncertain, 45% confidence

Private Key detected. This is a sensitive credential and should not be hardcoded here. Instead, store this in a separate, private file.

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/testdata/nonemptyprivatekey line 1
Likely real: Uncertain, 45% confidence

Private Key detected. This is a sensitive credential and should not be hardcoded here. Instead, store this in a separate, private file.

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /designs/Dockerfile line 18
Likely real: Probably noise, 23% confidence

By not specifying a USER, a program in the container may run as 'root'. This is a security hazard. If an attacker can control a process running as root, they may have control over the container. Ensure that the last USER in a Dockerfile is a USER other than 'root'.

ENTRYPOINT [ "java", "-XX:-UsePerfData", "-jar", "/plantuml.jar" ]

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 63
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return fmt.Errorf("getting templates info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 94
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return "", fmt.Errorf("getting templates info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 123
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return fmt.Errorf("getting service offerings info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 155
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return fmt.Errorf("getting disk offerings info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 198
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
		if err != nil {
			return fmt.Errorf("getting affinity group info - %s: %v", result.String(), err)
		}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 229
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return "", fmt.Errorf("getting zones info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 457
Likely real: Yes, 100% confidence

Variable `destroyResult` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

destroyResult, err := c.exec(ctx, profile, destroyCommand...)
		if err != nil {
			return fmt.Errorf("destroying virtual machine with name %s and id %s: %s: %v", vm.Name, vm.Id, destroyResult.String(), err)
		}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 451
Likely real: Yes, 100% confidence

Variable `stopResult` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

stopResult, err := c.exec(ctx, profile, stopCommand...)
		if err != nil {
			return fmt.Errorf("stopping virtual machine with name %s and id %s: %s: %v", vm.Name, vm.Id, stopResult.String(), err)
		}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 430
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return fmt.Errorf("listing virtual machines in cluster %s: %s: %v", clusterName, result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 379
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return fmt.Errorf("getting accounts info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 334
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return fmt.Errorf("getting network info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 313
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
			if err != nil {
				return fmt.Errorf("deleting duplicate network with ID %s - %s: %v", network, result.String(), err)
			}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 298
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return fmt.Errorf("getting network info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/cmk.go line 260
Likely real: Yes, 100% confidence

Variable `result` is likely modified and later used on error. In some cases this could result in panics due to a nil dereference

result, err := c.exec(ctx, profile, command...)
	if err != nil {
		return domainId, fmt.Errorf("getting domain info - %s: %v", result.String(), err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_rest_control_plane_upgrader_pod.yaml line 25
Likely real: Yes, 99% confidence

Pod is sharing the host process ID namespace. When paired with ptrace this can be used to escalate privileges outside of the container. Remove the 'hostPID' key to disable this functionality.

hostPID: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_first_control_plane_upgrader_pod.yaml line 25
Likely real: Yes, 99% confidence

Pod is sharing the host process ID namespace. When paired with ptrace this can be used to escalate privileges outside of the container. Remove the 'hostPID' key to disable this functionality.

hostPID: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_worker_upgrader_pod.yaml line 25
Likely real: Yes, 99% confidence

Pod is sharing the host process ID namespace. When paired with ptrace this can be used to escalate privileges outside of the container. Remove the 'hostPID' key to disable this functionality.

hostPID: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/dependabot.yaml line 6
Likely real: Yes, 99% confidence

This Dependabot configuration does not set a cooldown period. Newly published packages can be malicious or unstable. Add a `cooldown` block with `default-days: 7` to each `package-ecosystem` entry under `updates` to wait 7 days before proposing updates to newly published package versions. Reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#cooldown

- package-ecosystem: "github-actions"
  directory: "/"
  schedule:
      interval: "weekly"
  labels:
    - "dependabot"
    - "ok-to-test"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networking/cilium/testdata/cilium_manifest.yaml line 529
Likely real: Yes, 99% confidence

Pod may use the node network namespace. This gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. Remove the 'hostNetwork' key to disable this functionality.

hostNetwork: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/awsiamauth/testdata/UpgradeAWSIAMAuth-manifest.yaml line 93
Likely real: Yes, 99% confidence

Pod may use the node network namespace. This gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. Remove the 'hostNetwork' key to disable this functionality.

hostNetwork: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/awsiamauth/testdata/InstallAWSIAMAuth-manifest.yaml line 93
Likely real: Yes, 99% confidence

Pod may use the node network namespace. This gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. Remove the 'hostNetwork' key to disable this functionality.

hostNetwork: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networking/cilium/testdata/cilium_manifest.yaml line 756
Likely real: Yes, 99% confidence

Pod may use the node network namespace. This gives the pod access to the loopback device, services listening on localhost, and could be used to snoop on network activity of other pods on the same node. Remove the 'hostNetwork' key to disable this functionality.

hostNetwork: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/dependabot.yaml line 16
Likely real: Yes, 99% confidence

This Dependabot configuration does not set a cooldown period. Newly published packages can be malicious or unstable. Add a `cooldown` block with `default-days: 7` to each `package-ecosystem` entry under `updates` to wait 7 days before proposing updates to newly published package versions. Reference: https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#cooldown

- package-ecosystem: "gomod"
  directories:
  - "/"
  - "/release/cli"
  schedule:
    interval: "weekly"
    day: "monday"
  ## group all dependencies in one PR to avoid churn.
  groups:
    all-go-mod-patch-and-minor:
      patterns: [ "*" ]
      update-types: [ "patch", "minor" ]
  ignore:
  # Ignore CAPI since we have our own fork with a replace.
  - dependency-name: "sigs.k8s.io/cluster-api"
    update-types: [ "version-update:semver-major", "version-update:semver-minor",  "version-update:semver-patch" ]
  # Ignore CAPI test since it should be updated in tandem with CAPI.
  - dependency-name: "sigs.k8s.io/cluster-api/test"
    update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
  # Ignore CAPC since we have the API structs in tree to reduce dependencies.
  - dependency-name: "sigs.k8s.io/cluster-api-provider-cloudstack"
    update-types: [ "version-update:semver-major", "version-update:semver-minor", "version-update:semver-patch" ]
  # Ignore tinkerbell since minor versions usually come with breaking changes and it depends on controller-runtime.
  - dependency-name: "github.com/tinkerbell/cluster-api-provider-tinkerbell"
    update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
  - dependency-name: "github.com/tinkerbell/tink"
    update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
  # Ignore nutanix provider to avoid issues with controller-runtime.
  - dependency-name: "github.com/nutanix-cloud-native/cluster-api-provider-nutanix"
    update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
  # Ignore vsphere provider to avoid issues with controller-runtime.
  - dependency-name: "sigs.k8s.io/cluster-api-provider-vsphere"
    update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
  # Ignore controller-runtime as its upgraded manually.
  - dependency-name: "sigs.k8s.io/controller-runtime"
    update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
   # Ignore k8s and its transitives modules as they are upgraded manually together with controller-runtime.
  - dependency-name: "k8s.io/*"
    update-types: [ "version-update:semver-major", "version-update:semver-minor" ]
  labels:
    - "dependabot"
    - "ok-to-test"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /cmd/eks-a-tool/cmd/vspherelogoutsessions.go line 97
Likely real: Yes, 81% confidence

A session cookie was detected without setting the 'HttpOnly' flag. The 'HttpOnly' flag for cookies instructs the browser to forbid client-side scripts from reading the cookie which mitigates XSS attacks. Set the 'HttpOnly' flag by setting 'HttpOnly' to 'true' in the Cookie.

cookie := http.Cookie{Name: sessionCookieKey, Value: session}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/certificates/ssh.go line 84
Likely real: Yes, 55% confidence

Disabled host key verification detected. This allows man-in-the-middle attacks. Use the 'golang.org/x/crypto/ssh/knownhosts' package to do host key verification. See https://skarlso.github.io/2019/02/17/go-ssh-with-host-key-verification/ to learn more about the problem and how to fix it.

HostKeyCallback: ssh.InsecureIgnoreHostKey(),

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /internal/pkg/oidc/server.go line 44
Likely real: Yes, 53% confidence

Detected SHA1 hash algorithm which is considered insecure. SHA1 is not collision resistant and is therefore not suitable as a cryptographic signature. Use SHA256 or SHA3 instead.

sha := sha1.New()

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networking/cilium/testdata/cilium_manifest.yaml line 504
Likely real: Yes, 53% confidence

Container or pod is running in privileged mode. This grants the container the equivalent of root capabilities on the host machine. This can lead to container escapes, privilege escalation, and other security concerns. Remove the 'privileged' key to disable this capability.

privileged: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_first_control_plane_upgrader_pod.yaml line 24
Likely real: Yes, 53% confidence

Container or pod is running in privileged mode. This grants the container the equivalent of root capabilities on the host machine. This can lead to container escapes, privilege escalation, and other security concerns. Remove the 'privileged' key to disable this capability.

privileged: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_rest_control_plane_upgrader_pod.yaml line 24
Likely real: Yes, 53% confidence

Container or pod is running in privileged mode. This grants the container the equivalent of root capabilities on the host machine. This can lead to container escapes, privilege escalation, and other security concerns. Remove the 'privileged' key to disable this capability.

privileged: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_worker_upgrader_pod.yaml line 24
Likely real: Yes, 53% confidence

Container or pod is running in privileged mode. This grants the container the equivalent of root capabilities on the host machine. This can lead to container escapes, privilege escalation, and other security concerns. Remove the 'privileged' key to disable this capability.

privileged: true

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /internal/thirdparty/capc/api/v1beta3/cloudstackfailuredomain_types.go line 32
Likely real: Yes, 53% confidence

Detected MD5 hash algorithm which is considered insecure. MD5 is not collision resistant and is therefore not suitable as a cryptographic signature. Use SHA256 or SHA3 instead.

return fmt.Sprintf("%x", md5.Sum([]byte(fdName+clusterName))) // #nosec G401 -- weak cryptographic primitive doesn't matter here. Not security related.

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/certificates/scanner.go line 154
Likely real: Yes, 53% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

conn, err := tls.DialWithDialer(dialer, "tcp", net.JoinHostPort(ip, port), &tls.Config{
		InsecureSkipVerify: true, // We just want to get the certificate, not verify it
	})

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/registry/client.go line 47
Likely real: Yes, 53% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

transport.TLSClientConfig = &tls.Config{
				RootCAs:            or.certificates,
				InsecureSkipVerify: or.insecure,
			}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/crypto/validator.go line 52
Likely real: Yes, 53% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

conf := &tls.Config{
		InsecureSkipVerify: false,
		RootCAs:            roots,
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /cmd/eks-a-tool/cmd/vspherelogoutsessions.go line 86
Likely real: Yes, 53% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

TLSClientConfig: &tls.Config{InsecureSkipVerify: viper.GetBool(tlsInsecureFlag)},

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /cmd/eks-a-tool/cmd/vspherelogoutsessions.go line 97
Likely real: Yes, 53% confidence

A session cookie was detected without setting the 'Secure' flag. The 'secure' flag for cookies prevents the client from transmitting the cookie over insecure channels such as HTTP. Set the 'Secure' flag by setting 'Secure' to 'true' in the Options struct.

cookie := http.Cookie{Name: sessionCookieKey, Value: session}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /cmd/eksctl-anywhere/cmd/copypackages.go line 245
Likely real: Yes, 52% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

TLSClientConfig: &tls.Config{InsecureSkipVerify: c.dstInsecure},

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/crypto/validator.go line 24
Likely real: Yes, 52% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

conf := &tls.Config{
		InsecureSkipVerify: false,
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/dependencies/factory.go line 571
Likely real: Yes, 52% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

skipVerifyTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/dependencies/factory.go line 1641
Likely real: Yes, 52% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

skipVerifyTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/files/reader.go line 56
Likely real: Yes, 52% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

t.TLSClientConfig = &tls.Config{}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/govc.go line 656
Likely real: Yes, 52% confidence

`MinVersion` is missing from this TLS configuration. By default, as of Go 1.22, TLS 1.2 is currently used as the minimum. General purpose web applications should default to TLS 1.3 with all other protocols disabled. Only where it is known that a web server must support legacy clients with unsupported an insecure browsers (such as Internet Explorer 10), it may be necessary to enable TLS 1.0 to provide support. Add `MinVersion: tls.VersionTLS13' to the TLS configuration to bump the minimum version to TLS 1.3.

skipVerifyTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/golangci-lint.yml line 20
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

- uses: actions/setup-go@v7

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/go-coverage.yml line 20
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

- uses: actions/setup-go@v7

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/golangci-lint.yml line 19
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

- uses: actions/checkout@v5

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/golangci-lint.yml line 26
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: golangci/golangci-lint-action@v9

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/label.yml line 20
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

- uses: actions/labeler@v6

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/stale-labeler.yaml line 24
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

- uses: actions/stale@v9

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/vulnerability.yml line 24
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/checkout@v5

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/vulnerability.yml line 28
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/dependency-review-action@v5

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/vulnerability.yml line 36
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: actions/checkout@v5

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/vulnerability.yml line 40
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: golang/govulncheck-action@v1.1.0

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/vulnerability.yml line 46
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: golang/govulncheck-action@v1.1.0

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/go-coverage.yml line 28
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

uses: codecov/codecov-action@v5.5.5

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /.github/workflows/go-coverage.yml line 19
Likely real: Yes, 52% confidence

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. `uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608`.

- uses: actions/checkout@v5

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /internal/aws-sdk-go-v2/internal/endpoints/awsrulesfn/internal/partition/codegen.go line 13
Likely real: Yes, 51% confidence

When working with web applications that involve rendering user-generated content, it's important to properly escape any HTML content to prevent Cross-Site Scripting (XSS) attacks. In Go, the `text/template` package does not automatically escape HTML content, which can leave your application vulnerable to these types of attacks. To mitigate this risk, it's recommended to use the `html/template` package instead, which provides built-in functionality for HTML escaping. By using `html/template` to render your HTML content, you can help to ensure that your web application is more secure and less susceptible to XSS vulnerabilities.

"text/template"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/providers/vsphere/vsphere.go line 9
Likely real: Yes, 51% confidence

When working with web applications that involve rendering user-generated content, it's important to properly escape any HTML content to prevent Cross-Site Scripting (XSS) attacks. In Go, the `text/template` package does not automatically escape HTML content, which can leave your application vulnerable to these types of attacks. To mitigate this risk, it's recommended to use the `html/template` package instead, which provides built-in functionality for HTML escaping. By using `html/template` to render your HTML content, you can help to ensure that your web application is more secure and less susceptible to XSS vulnerabilities.

"text/template"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/signature/manifest.go line 27
Likely real: Yes, 51% confidence

When working with web applications that involve rendering user-generated content, it's important to properly escape any HTML content to prevent Cross-Site Scripting (XSS) attacks. In Go, the `text/template` package does not automatically escape HTML content, which can leave your application vulnerable to these types of attacks. To mitigate this risk, it's recommended to use the `html/template` package instead, which provides built-in functionality for HTML escaping. By using `html/template` to render your HTML content, you can help to ensure that your web application is more secure and less susceptible to XSS vulnerabilities.

"text/template"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/templater/templater.go line 7
Likely real: Yes, 51% confidence

When working with web applications that involve rendering user-generated content, it's important to properly escape any HTML content to prevent Cross-Site Scripting (XSS) attacks. In Go, the `text/template` package does not automatically escape HTML content, which can leave your application vulnerable to these types of attacks. To mitigate this risk, it's recommended to use the `html/template` package instead, which provides built-in functionality for HTML escaping. By using `html/template` to render your HTML content, you can help to ensure that your web application is more secure and less susceptible to XSS vulnerabilities.

"text/template"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /release/cli/pkg/signature/manifest.go line 26
Likely real: Yes, 51% confidence

When working with web applications that involve rendering user-generated content, it's important to properly escape any HTML content to prevent Cross-Site Scripting (XSS) attacks. In Go, the `text/template` package does not automatically escape HTML content, which can leave your application vulnerable to these types of attacks. To mitigate this risk, it's recommended to use the `html/template` package instead, which provides built-in functionality for HTML escaping. By using `html/template` to render your HTML content, you can help to ensure that your web application is more secure and less susceptible to XSS vulnerabilities.

"text/template"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/api/v1alpha1/cluster.go line 573
Likely real: Yes, 50% confidence

Deserializing into `interface{}` allows arbitrary data structures and types, which can lead to security vulnerabilities (CWE-502). Use a concrete struct type instead.

var yamlObj interface{}
		err := yaml.Unmarshal([]byte(c.Spec.ControlPlaneConfiguration.AuditPolicyContent), &yamlObj)

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/signature/manifest.go line 190
Likely real: Yes, 50% confidence

Deserializing into `interface{}` allows arbitrary data structures and types, which can lead to security vulnerabilities (CWE-502). Use a concrete struct type instead.

var input interface{}
	if err := json.Unmarshal(jsonBytes, &input); err != nil {
		return nil, fmt.Errorf("unmarshalling JSON: %v", err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /release/cli/pkg/signature/manifest.go line 211
Likely real: Yes, 50% confidence

Deserializing into `interface{}` allows arbitrary data structures and types, which can lead to security vulnerabilities (CWE-502). Use a concrete struct type instead.

var input interface{}
	if err := json.Unmarshal(jsonBytes, &input); err != nil {
		return nil, fmt.Errorf("unmarshalling JSON: %v", err)
	}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /hack/cherry_pick_pull.sh line 85
Likely real: Uncertain, 49% confidence

The special variable IFS affects how splitting takes place when expanding unquoted variables. Don't set it globally. Prefer a dedicated utility such as 'cut' or 'awk' if you need to split input data. If you must use 'read', set IFS locally using e.g. 'IFS="," read -a my_array'.

function join { local IFS="$1"; shift; echo "$*"; }

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/certificates/scanner.go line 154
Likely real: Uncertain, 49% confidence

Checks for disabling of TLS/SSL certificate verification. This should only be used for debugging purposes because it leads to vulnerability to MTM attacks.

conn, err := tls.DialWithDialer(dialer, "tcp", net.JoinHostPort(ip, port), &tls.Config{
		InsecureSkipVerify: true, // We just want to get the certificate, not verify it
	})

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/executables/govc.go line 656
Likely real: Uncertain, 49% confidence

Checks for disabling of TLS/SSL certificate verification. This should only be used for debugging purposes because it leads to vulnerability to MTM attacks.

skipVerifyTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/dependencies/factory.go line 1641
Likely real: Uncertain, 49% confidence

Checks for disabling of TLS/SSL certificate verification. This should only be used for debugging purposes because it leads to vulnerability to MTM attacks.

skipVerifyTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/dependencies/factory.go line 571
Likely real: Uncertain, 49% confidence

Checks for disabling of TLS/SSL certificate verification. This should only be used for debugging purposes because it leads to vulnerability to MTM attacks.

skipVerifyTransport.TLSClientConfig = &tls.Config{InsecureSkipVerify: true}

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/tar/untar.go line 57
Likely real: Uncertain, 48% confidence

Detected a possible denial-of-service via a zip bomb attack. By limiting the max bytes read, you can mitigate this attack. `io.CopyN()` can specify a size.

_, err = io.Copy(file, tarReader)

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networkutils/ipgenerator.go line 5
Likely real: Uncertain, 39% confidence

Do not use `math/rand`. Use `crypto/rand` instead.

"math/rand"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /internal/pkg/ec2/create.go line 6
Likely real: Uncertain, 39% confidence

Do not use `math/rand`. Use `crypto/rand` instead.

"math/rand"

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_worker_upgrader_pod.yaml line 23
Likely real: Probably noise, 29% confidence

In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain `setuid` or `setgid` binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container in the pod, with the parameter `allowPrivilegeEscalation` set to `false`. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding the `allowPrivilegeEscalation` parameter to your the `securityContext`, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

securityContext:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_rest_control_plane_upgrader_pod.yaml line 23
Likely real: Probably noise, 29% confidence

In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain `setuid` or `setgid` binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container in the pod, with the parameter `allowPrivilegeEscalation` set to `false`. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding the `allowPrivilegeEscalation` parameter to your the `securityContext`, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

securityContext:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_first_control_plane_upgrader_pod.yaml line 23
Likely real: Probably noise, 29% confidence

In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain `setuid` or `setgid` binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container in the pod, with the parameter `allowPrivilegeEscalation` set to `false`. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding the `allowPrivilegeEscalation` parameter to your the `securityContext`, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

securityContext:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networking/cilium/testdata/cilium_manifest.yaml line 499
Likely real: Probably noise, 29% confidence

In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain `setuid` or `setgid` binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container in the pod, with the parameter `allowPrivilegeEscalation` set to `false`. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding the `allowPrivilegeEscalation` parameter to your the `securityContext`, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

securityContext:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /config/manager/manager_image_patch.yaml line 11
Likely real: Probably noise, 27% confidence

In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain `setuid` or `setgid` binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container in the pod, with the parameter `allowPrivilegeEscalation` set to `false`. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding a `securityContext` to your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

name: manager

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networking/cilium/testdata/cilium_manifest.yaml line 742
Likely real: Probably noise, 27% confidence

In Kubernetes, each pod runs in its own isolated environment with its own set of security policies. However, certain container images may contain `setuid` or `setgid` binaries that could allow an attacker to perform privilege escalation and gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container in the pod, with the parameter `allowPrivilegeEscalation` set to `false`. This will prevent the container from running any privileged processes and limit the impact of any potential attacks. By adding a `securityContext` to your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

name: cilium-operator

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /pkg/certificates/config.go line 59
Likely real: Yes, 93% confidence

Detects reading of environment variables (credential access, often contains secrets) [threat-runtime-environment-read]

if pass := os.Getenv("EKSA_SSH_KEY_PASSPHRASE_CP"); pass != "" {
		config.ControlPlane.SSH.Password = pass
	}

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /pkg/certificates/config.go line 55
Likely real: Yes, 93% confidence

Detects reading of environment variables (credential access, often contains secrets) [threat-runtime-environment-read]

if pass := os.Getenv("EKSA_SSH_KEY_PASSPHRASE_ETCD"); pass != "" {
		config.Etcd.SSH.Password = pass
	}

Engine: GuardDog · Supply-chain attack heuristics
Counts towards: Malicious pattern
File: /cmd/eksctl-anywhere/cmd/deprecated_importimages.go line 69
Likely real: Yes, 93% confidence

Detects reading of environment variables (credential access, often contains secrets) [threat-runtime-environment-read]

registryUsername := os.Getenv("REGISTRY_USERNAME")
	registryPassword := os.Getenv("REGISTRY_PASSWORD")
	if registryUsername == "" || registryPassword == "" {
		return fmt.Errorf("username or password not set. Pr...

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_rest_control_plane_upgrader_pod.yaml line 6
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /config/default/manager_config_patch.yaml line 8
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /config/default/manager_webhook_patch.yaml line 8
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /config/manager/manager_image_patch.yaml line 8
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/awsiamauth/testdata/InstallAWSIAMAuth-manifest.yaml line 89
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/awsiamauth/testdata/UpgradeAWSIAMAuth-manifest.yaml line 89
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/clustermanager/testdata/eksa_components.yaml line 13
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networking/cilium/testdata/cilium_manifest.yaml line 402
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/networking/cilium/testdata/cilium_manifest.yaml line 704
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_first_control_plane_upgrader_pod.yaml line 6
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

Engine: Semgrep · Pattern-based code analysis
Counts towards: Vulnerability
File: /pkg/nodeupgrader/testdata/expected_worker_upgrader_pod.yaml line 6
Likely real: Probably noise, 25% confidence

When running containers in Kubernetes, it's important to ensure that they are properly secured to prevent privilege escalation attacks. One potential vulnerability is when a container is allowed to run applications as the root user, which could allow an attacker to gain access to sensitive resources. To mitigate this risk, it's recommended to add a `securityContext` to the container, with the parameter `runAsNonRoot` set to `true`. This will ensure that the container runs as a non-root user, limiting the damage that could be caused by any potential attacks. By adding a `securityContext` to the container in your Kubernetes pod, you can help to ensure that your containerized applications are more secure and less vulnerable to privilege escalation attacks.

spec:

aws / eks-anywhere

What we found, in plain English

Detections by engine

Score over time

Findings