Scan report

kubernetes-sigs / gateway-api-inference-extension

View on GitHub (opens in a new tab)
Go
770 stars
Scanned 24 Sep 2026, 07:24

Report Rescan

Vulnerability Medium

Could an attacker exploit mistakes in this code?

54 risk score

Real issues worth reviewing before you rely on this code.

High: 6
Medium: 14
Low: 9

Sources: Bandit, Semgrep, pip-audit

Malicious pattern Safe

Does this code look like it is trying to cause harm?

0 risk score

No issues of this kind were found.

High: 0
Medium: 0
Low: 0

Sources: YARA, ClamAV, GuardDog, dependency checker

Findings overview

29 total findings

Likely real: 7
Uncertain: 0
Likely noise: 22

The risk classifier rates every finding for how likely it is to be a real issue. Likely noise still counts, just much less.

What we found, in plain English

This repository has a medium vulnerability score of 54.0, which means there are several insecure coding patterns that an attacker could exploit to compromise the system. However, the scan also found zero signs of malicious intent, so the code itself is not trying to harm anyone intentionally. The most serious issues involve missing security features like gRPC credentials and TLS settings, as well as using variables with special characters that could let attackers inject harmful code into automated workflows. While some findings suggest a container might run with root privileges or contain binaries that could escalate privileges, these are likely standard practices rather than deliberate attacks. Overall, the repository is not safe to use without applying specific security fixes to address the identified gaps in configuration and coding standards.

Written by a local language model from the findings below. The risk scores come from the classifier, not from this summary.

Detections by engine

Semgrep 29

Pattern-based code analysis · Vulnerability

Score over time

Overall score each time this repository was scanned.

Findings

Highest severity first. Select a finding to see the code and what it means.

Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/pkg/lwepp/server/runserver.go line 136

Likely real
Yes, 99% confidence

Found an insecure gRPC server without 'grpc.Creds()' or options with credentials. This allows for a connection without encryption to this server. A malicious attacker could tamper with the gRPC message, which could compromise the machine. Include credentials derived from an SSL certificate in order to create a secure gRPC connection. You can create credentials using 'credentials.NewServerTLSFromFile("cert.pem", "cert.key")'.
```
srv := grpc.NewServer()
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/pkg/lwepp/server/runserver.go line 113

Likely real
Yes, 99% confidence

Found an insecure gRPC server without 'grpc.Creds()' or options with credentials. This allows for a connection without encryption to this server. A malicious attacker could tamper with the gRPC message, which could compromise the machine. Include credentials derived from an SSL certificate in order to create a secure gRPC connection. You can create credentials using 'credentials.NewServerTLSFromFile("cert.pem", "cert.key")'.
```
srv = grpc.NewServer()
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/.github/workflows/crd-validation.yml line 32

Likely real
Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".
```
run: |
          git fetch origin ${{ github.base_ref }}:upstream_base
          BASE_SHA=$(git rev-parse upstream_base)

          FAILED=0
          for crd in config/crd/bases/*.yaml; do
            if ! crdify "git://${BASE_SHA}?path=$crd" "git://HEAD?path=$crd"; then
              echo "❌ Incompatible change detected in $crd"
              ((FAILED++))
            else
              echo "✅ $crd is valid"
            fi
          done

          if [ "$FAILED" -gt 0 ]; then
            echo "::error::Validation failed! Found $FAILED incompatible CRD change(s)."
            exit 1
          fi

          echo "All CRDs are compatible."
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/.github/workflows/trivy-image-scan.yaml line 56

Likely real
Yes, 57% confidence

Using variable interpolation `${{...}}` with `github` context data in a `run:` step could allow an attacker to inject their own code into the runner. This would allow them to steal secrets and code. `github` context data can have arbitrary user input and should be treated as untrusted. Instead, use an intermediate environment variable with `env:` to store the data and use the environment variable in the `run:` script. Be sure to use double-quotes the environment variable, like this: "$ENVVAR".
```
run: |
          docker build \
            --build-arg COMMIT_SHA=${{ github.sha }} \
            --build-arg BUILD_REF=${{ github.ref }} \
            -t gwie-lwepp:scan \
            -f lwepp.Dockerfile .
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/hack/mkdocs/image/Dockerfile line 26

Likely real
Probably noise, 22% 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 ["/entrypoint.sh"]
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/lwepp.Dockerfile line 37

Likely real
Probably noise, 22% 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 ["/lwepp"]
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/.github/dependabot.yml line 4

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"
    directory: "/"
    schedule:
      interval: "weekly"
    labels:
      - "area/dependency"
      - "ok-to-test"
      - "release-note-none"
    groups:
      kubernetes:
        patterns:
          - "k8s.io/*"
    ignore:
      # Ignore major and minor versions for dependencies updates
      # Allow patches and security updates.
      - dependency-name: k8s.io/*
        update-types: ["version-update:semver-major", "version-update:semver-minor"]
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/.github/dependabot.yml line 21

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"
    directory: "/conformance"
    schedule:
      interval: "weekly"
    labels:
      - "area/dependency"
      - "ok-to-test"
      - "release-note-none"
    groups:
      kubernetes:
        patterns:
          - "k8s.io/*"
    ignore:
      # Ignore major and minor versions for dependencies updates
      # Allow patches and security updates.
      - dependency-name: k8s.io/*
        update-types: ["version-update:semver-major", "version-update:semver-minor"]
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/pkg/lwepp/server/runserver.go line 107

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.
```
creds := credentials.NewTLS(&tls.Config{
				Certificates: []tls.Certificate{cert},
				NextProtos:   []string{"h2"},
			})
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 251

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: epp
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 338

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: epp
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 425

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: epp
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 512

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: epp
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 710

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: epp
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 79

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: echoserver
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 623

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: echoserver-3004
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 593

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: echoserver-3002
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 563

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: echoserver-3000
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 167

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: echoserver
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 123

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: echoserver
```
Engine
Semgrep · Pattern-based code analysis

Counts towards
Vulnerability

File
/conformance/resources/base.yaml line 77

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
/conformance/resources/base.yaml line 121

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
/conformance/resources/base.yaml line 165

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
/conformance/resources/base.yaml line 247

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
/conformance/resources/base.yaml line 334

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
/conformance/resources/base.yaml line 421

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
/conformance/resources/base.yaml line 508

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
/conformance/resources/base.yaml line 561

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
/conformance/resources/base.yaml line 706

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:
```