┌──────────────────┐│ 84 Code Findings │└──────────────────┘ benchmarks\benchmark.py ❯❱ python.lang.security.audit.dynamic-urllib-use-detected.dynamic-urllib-use-detected Detected a dynamic value being used with urllib. urllib supports 'file://' schemes, so a dynamic value controlled by a malicious actor may allow them to read arbitrary files. Audit uses of urllib calls to ensure user data cannot control the URLs, or consider using the 'requests' library instead. Details: https://sg.run/dKZZ 271┆ urlretrieve(url, path) benchmarks\install_dependencies.sh ❯❱ bash.curl.security.curl-pipe-bash.curl-pipe-bash Data is being piped into `bash` from a `curl` command. An attacker with control of the server in the `curl` command could inject malicious code into the pipe, resulting in a system compromise. Avoid piping untrusted data into `bash` or any other shell if you can. If you must do this, consider checking the SHA sum of the content returned by the server to verify its integrity. Details: https://sg.run/KXz6 27┆ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)" benchmarks\utils\system_under_test.py ❯❯❱ python.sqlalchemy.security.sqlalchemy-execute-raw-query.sqlalchemy-execute-raw-query Avoiding SQL string concatenation: untrusted input concatenated with raw SQL query can result in SQL Injection. In order to execute raw query safely, prepared statement should be used. SQLAlchemy provides TextualSQL to easily used prepared statement with named parameters. For complex SQL composition, use SQL Expression Language or Schema Definition Language. In most cases, SQLAlchemy ORM will be a better option. Details: https://sg.run/2b1L 205┆ execute(f"docker pull {docker_image}", wait=True) benchmarks\windows_install_dependencies.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'Popen' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 13┆ stderr=subprocess.PIPE, shell=True) binaries\s3_binary_upload.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'run' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 45┆ s3_command, check=True, stdout=subprocess.PIPE, universal_newlines=True, shell=True examples\FasterTransformer_HuggingFace_Bert\Bert_FT_trace.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 128┆ torch.load(os.path.join(checkpoint, 'pytorch_model.bin'), map_location='cpu')) examples\Huggingface_Transformers\Transformer_handler_generalized.py ❯❱ python.lang.security.audit.logging.logger-credential-leak.python-logger-credential-disclosure Detected a python logger call with a potential hardcoded secret "[tokenizer.cls_token_id] %s" being logged. This may lead to secret credentials being exposed. Make sure that the logger is not logging sensitive information. Details: https://sg.run/ydNx 452┆ logger.info("[tokenizer.cls_token_id] %s", [tokenizer.cls_token_id]) examples\LLM\llama\chat_app\docker\Dockerfile ❯❯❱ dockerfile.security.last-user-is-root.last-user-is-root The last user in the container is 'root'. This is a security hazard because if an attacker gains control of the container they will have root access. Switch back to another user after running commands as 'root'. Details: https://sg.run/5Z43 8┆ USER root examples\LLM\llama\chat_app\docker\torchserve_server_app.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'run' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 20┆ shell=True, examples\MMF-activity-recognition\handler.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 82┆ state_dict = torch.load(serialized_file, map_location=self.device) examples\cpp\aot_inductor\llama2\compile.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 10┆ checkpoint_dict = torch.load(checkpoint, map_location="cpu") examples\dcgan_fashiongen\dcgan_fashiongen_handler.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 43┆ state_dict = torch.load(os.path.join(model_dir, CHECKPOINT), map_location=self.map_location) examples\image_classifier\vgg_16\vgg_handler.py ❯❱ python.lang.security.audit.non-literal-import.non-literal-import Untrusted user input in `importlib.import_module()` function allows an attacker to load arbitrary code. Avoid dynamic values in `importlib.import_module()` or use a whitelist to prevent running untrusted code. Details: https://sg.run/y6Jk 20┆ module = importlib.import_module(model_file.split(".")[0]) ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 27┆ state_dict = torch.load(model_pt_path) examples\intel_extension_for_pytorch\intel_gpu.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'check_output' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 15┆ out = subprocess.check_output(cmd, shell=True, timeout=5, text=True) examples\large_models\ipex_llm_int8\llm_handler.py ❯❱ trailofbits.python.automatic-memory-pinning.automatic-memory-pinning If possible, it is better to rely on automatic pinning in PyTorch to avoid undefined behavior and for efficiency Details: https://sg.run/jz5N 427┆ self.calib_dataloader = DataLoader( 428┆ calib_evaluator.dataset, 429┆ batch_size=1, 430┆ shuffle=False, 431┆ collate_fn=calib_evaluator.collate_batch, 432┆ ) examples\large_models\segment_anything_fast\custom_handler.py ❯❱ python.lang.security.deserialization.pickle.avoid-pickle Avoid using `pickle`, which is known to lead to code execution vulnerabilities. When unpickling, the serialized data could be manipulated to run arbitrary code. Instead, consider serializing the relevant data as JSON or a similar text-based serialization format. Details: https://sg.run/OPwB 85┆ serialized_data = pickle.dumps(data) examples\large_models\segment_anything_fast\inference.py ❯❱ python.lang.security.deserialization.pickle.avoid-pickle Avoid using `pickle`, which is known to lead to code execution vulnerabilities. When unpickling, the serialized data could be manipulated to run arbitrary code. Instead, consider serializing the relevant data as JSON or a similar text-based serialization format. Details: https://sg.run/OPwB 46┆ masks = pickle.loads(decoded_data) examples\large_models\tp_llama\llama2.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 483┆ state_dict = torch.load(state_dict_pth) ⋮┆---------------------------------------- 507┆ state_dict = torch.load(state_dict_pth) examples\text_classification\train.py ❯❱ trailofbits.python.automatic-memory-pinning.automatic-memory-pinning If possible, it is better to rely on automatic pinning in PyTorch to avoid undefined behavior and for efficiency Details: https://sg.run/jz5N 137┆ train_dataloader=DataLoader(split_train_, batch_size=batch_size, shuffle=True, collate_fn=collate_batch) ⋮┆---------------------------------------- 138┆ valid_dataloader=DataLoader(split_valid_, batch_size=batch_size, shuffle=True, collate_fn=collate_batch) ⋮┆---------------------------------------- 139┆ test_dataloader=DataLoader(test_dataset, batch_size=batch_size, shuffle=True, collate_fn=collate_batch) ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 168┆ torch.save(vocab, args.dictionary) examples\text_to_speech_synthesizer\WaveGlow\waveglow_handler.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 43┆ tacotron2_checkpoint = torch.load( 44┆ os.path.join(model_dir, "nvidia_tacotron2pyt_fp32_20190427.pth") 45┆ ) ⋮┆---------------------------------------- 67┆ waveglow_checkpoint = torch.load( 68┆ os.path.join(model_dir, "nvidia_waveglowpyt_fp32_20190427.pth") 69┆ ) examples\usecases\llm_diffusion_serving_app\docker\Dockerfile ❯❯❱ dockerfile.security.last-user-is-root.last-user-is-root The last user in the container is 'root'. This is a security hazard because if an attacker gains control of the container they will have root access. Switch back to another user after running commands as 'root'. Details: https://sg.run/5Z43 18┆ USER root examples\usecases\llm_diffusion_serving_app\docker\server_app.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'run' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 77┆ shell=True, frontend\archive\src\main\java\org\pytorch\serve\archive\utils\ArchiveUtils.java ❯❱ java.lang.security.use-snakeyaml-constructor.use-snakeyaml-constructor Used SnakeYAML org.yaml.snakeyaml.Yaml() constructor with no arguments, which is vulnerable to deserialization attacks. Use the one-argument Yaml(...) constructor instead, with SafeConstructor or a custom Constructor as the argument. Details: https://sg.run/L8qY 64┆ Yaml yaml = new Yaml(); 65┆ try (Reader r = 66┆ new InputStreamReader( 67┆ Files.newInputStream(file.toPath()), StandardCharsets.UTF_8)) { 68┆ 69┆ return yaml.load(r); 70┆ } catch (YAMLException e) { 71┆ throw new InvalidModelException("Failed to parse model config yaml file.", e); 72┆ } frontend\server\src\main\java\org\pytorch\serve\ModelServer.java ❯❱ java.lang.security.audit.active-debug-code-printstacktrace.active-debug-code-printstacktrace Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information. Details: https://sg.run/4K8z 114┆ t.printStackTrace(); // NOPMD ⋮┆---------------------------------------- 522┆ e.printStackTrace(); // NOPMD ⋮┆---------------------------------------- 567┆ ignore.printStackTrace(); // NOPMD ⋮┆---------------------------------------- 578┆ e.printStackTrace(); // NOPMD frontend\server\src\main\java\org\pytorch\serve\device\interfaces\IAcceleratorUtility.java ❯❯❱ java.lang.security.audit.command-injection-process-builder.command-injection-process-builder A formatted or concatenated string was detected as input to a ProcessBuilder call. This is dangerous if a variable is controlled by user input and could result in a command injection. Ensure your variables are not controlled by users or sufficiently sanitized. Details: https://sg.run/gJJe 155┆ ProcessBuilder processBuilder = new ProcessBuilder(command); frontend\server\src\main\java\org\pytorch\serve\ensemble\WorkFlow.java ❯❱ java.lang.security.use-snakeyaml-constructor.use-snakeyaml-constructor Used SnakeYAML org.yaml.snakeyaml.Yaml() constructor with no arguments, which is vulnerable to deserialization attacks. Use the one-argument Yaml(...) constructor instead, with SafeConstructor or a custom Constructor as the argument. Details: https://sg.run/L8qY 159┆ Yaml yaml = new Yaml(); 160┆ try (Reader r = 161┆ new InputStreamReader( 162┆ Files.newInputStream(file.toPath()), StandardCharsets.UTF_8)) { 163┆ @SuppressWarnings("unchecked") 164┆ Map<String, Object> loadedYaml = (Map<String, Object>) yaml.load(r); 165┆ return loadedYaml; 166┆ } catch (YAMLException e) { 167┆ throw new InvalidWorkflowException("Failed to parse yaml.", e); 168┆ } frontend\server\src\main\java\org\pytorch\serve\snapshot\FSSnapshotSerializer.java ❯❱ java.lang.security.audit.active-debug-code-printstacktrace.active-debug-code-printstacktrace Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information. Details: https://sg.run/4K8z 85┆ e.printStackTrace(); // NOPMD ⋮┆---------------------------------------- 101┆ e.printStackTrace(); // NOPMD ⋮┆---------------------------------------- 113┆ e.printStackTrace(); // NOPMD frontend\server\src\main\java\org\pytorch\serve\util\ConfigManager.java ❯❱ java.lang.security.audit.active-debug-code-printstacktrace.active-debug-code-printstacktrace Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information. Details: https://sg.run/4K8z 356┆ e.printStackTrace(); // NOPMD frontend\server\src\main\java\org\pytorch\serve\util\TokenAuthorization.java ❯❱ java.lang.security.audit.active-debug-code-printstacktrace.active-debug-code-printstacktrace Possible active debug code detected. Deploying an application with debug code can create unintended entry points or expose sensitive information. Details: https://sg.run/4K8z 64┆ e.printStackTrace(); frontend\server\src\main\java\org\pytorch\serve\wlm\ModelManager.java ❯❯❱ java.lang.security.audit.command-injection-process-builder.command-injection-process-builder A formatted or concatenated string was detected as input to a ProcessBuilder call. This is dangerous if a variable is controlled by user input and could result in a command injection. Ensure your variables are not controlled by users or sufficiently sanitized. Details: https://sg.run/gJJe 235┆ ProcessBuilder processBuilder = new ProcessBuilder(commandParts); ⋮┆---------------------------------------- 345┆ processBuilder.command(commandParts); kubernetes\AKS\templates\model_store_pod.yaml ❱ yaml.kubernetes.security.run-as-non-root.run-as-non-root 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. Details: https://sg.run/dgP5 ▶▶┆ Autofix ▶ spec: securityContext: runAsNonRoot: true # 5┆ spec: ❯❱ yaml.kubernetes.security.allow-privilege-escalation-no-securitycontext.allow-privilege-escalation-no- securitycontext 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. Details: https://sg.run/eleR ▶▶┆ Autofix ▶ securityContext: allowPrivilegeEscalation: false name 11┆ - name: model-store kubernetes\AKS\templates\nvidia-device-plugin-ds.yaml ❱ yaml.kubernetes.security.run-as-non-root.run-as-non-root 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. Details: https://sg.run/dgP5 ▶▶┆ Autofix ▶ spec: securityContext: runAsNonRoot: true # 20┆ spec: kubernetes\EKS\templates\efs_pv_claim.yaml ❱ yaml.kubernetes.security.run-as-non-root.run-as-non-root 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. Details: https://sg.run/dgP5 ▶▶┆ Autofix ▶ spec: securityContext: runAsNonRoot: true # 20┆ spec: ❯❱ yaml.kubernetes.security.allow-privilege-escalation-no-securitycontext.allow-privilege-escalation-no- securitycontext 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. Details: https://sg.run/eleR ▶▶┆ Autofix ▶ securityContext: allowPrivilegeEscalation: false name 26┆ - name: model-store kubernetes\GKE\templates\pod.yaml ❱ yaml.kubernetes.security.run-as-non-root.run-as-non-root 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. Details: https://sg.run/dgP5 ▶▶┆ Autofix ▶ spec: securityContext: runAsNonRoot: true # 5┆ spec: ❯❱ yaml.kubernetes.security.allow-privilege-escalation-no-securitycontext.allow-privilege-escalation-no- securitycontext 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. Details: https://sg.run/eleR ▶▶┆ Autofix ▶ securityContext: allowPrivilegeEscalation: false name 11┆ - name: model-store kubernetes\Helm\templates\torchserve.yaml ❱ yaml.kubernetes.security.run-as-non-root.run-as-non-root 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. Details: https://sg.run/dgP5 ▶▶┆ Autofix ▶ spec: securityContext: runAsNonRoot: true # 44┆ spec: ❯❱ yaml.kubernetes.security.allow-privilege-escalation-no-securitycontext.allow-privilege-escalation-no- securitycontext 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. Details: https://sg.run/eleR ▶▶┆ Autofix ▶ securityContext: allowPrivilegeEscalation: false name 50┆ - name: torchserve kubernetes\examples\mnist\deployment.yaml ❱ yaml.kubernetes.security.run-as-non-root.run-as-non-root 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. Details: https://sg.run/dgP5 ▶▶┆ Autofix ▶ spec: securityContext: runAsNonRoot: true # 16┆ spec: ❯❱ yaml.kubernetes.security.allow-privilege-escalation-no-securitycontext.allow-privilege-escalation-no- securitycontext 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. Details: https://sg.run/eleR ▶▶┆ Autofix ▶ securityContext: allowPrivilegeEscalation: false name 22┆ - name: torchserve kubernetes\kserve\Dockerfile ❯❯❱ dockerfile.security.last-user-is-root.last-user-is-root The last user in the container is 'root'. This is a security hazard because if an attacker gains control of the container they will have root access. Switch back to another user after running commands as 'root'. Details: https://sg.run/5Z43 16┆ USER root kubernetes\kserve\reference_yaml\pv_pod.yaml ❱ yaml.kubernetes.security.run-as-non-root.run-as-non-root 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. Details: https://sg.run/dgP5 ▶▶┆ Autofix ▶ spec: securityContext: runAsNonRoot: true # 5┆ spec: ❯❱ yaml.kubernetes.security.allow-privilege-escalation-no-securitycontext.allow-privilege-escalation-no- securitycontext 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. Details: https://sg.run/eleR ▶▶┆ Autofix ▶ securityContext: allowPrivilegeEscalation: false name 11┆ - name: model-store setup.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'check_call' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 97┆ subprocess.check_call(build_frontend_command[platform.system()], shell=True) ⋮┆---------------------------------------- ▶▶┆ Autofix ▶ False 135┆ build_plugins_command[platform.system()], shell=True ts\handler_utils\preprocess\dali.py ❯❯❱ python.lang.compatibility.python37.python37-compatibility-importlib2 Found 'importlib.resources', which is a module only available on Python 3.7+. This does not work in lower versions, and therefore is not backwards compatible. Use importlib_resources instead for older Python versions. Details: https://sg.run/eL3y 1┆ import importlib.resources as pkg_resources ts\handler_utils\utils.py ❯❱ python.lang.security.audit.non-literal-import.non-literal-import Untrusted user input in `importlib.import_module()` function allows an attacker to load arbitrary code. Avoid dynamic values in `importlib.import_module()` or use a whitelist to prevent running untrusted code. Details: https://sg.run/y6Jk 21┆ importlib.import_module(f"{module_prefix}.{module_name}") ⋮┆---------------------------------------- 23┆ else importlib.import_module(module_prefix) ⋮┆---------------------------------------- 26┆ module = importlib.import_module(module_name) ts\model_loader.py ❯❱ python.lang.security.audit.non-literal-import.non-literal-import Untrusted user input in `importlib.import_module()` function allows an attacker to load arbitrary code. Avoid dynamic values in `importlib.import_module()` or use a whitelist to prevent running untrusted code. Details: https://sg.run/y6Jk 153┆ module = importlib.import_module(module_name) ⋮┆---------------------------------------- 159┆ module = importlib.import_module(module_name, "ts.torch_handler") ⋮┆---------------------------------------- 164┆ module = importlib.import_module( 165┆ module_name, "ts.torch_handler.request_envelope" 166┆ ) ts\protocol\otf_message_handler.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 138┆ torch.save(val, buff) ts\torch_handler\base_handler.py ❯❱ python.lang.security.audit.non-literal-import.non-literal-import Untrusted user input in `importlib.import_module()` function allows an attacker to load arbitrary code. Avoid dynamic values in `importlib.import_module()` or use a whitelist to prevent running untrusted code. Details: https://sg.run/y6Jk 340┆ module = importlib.import_module(model_file.split(".")[0]) ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 355┆ state_dict = torch.load(model_pt_path, map_location=map_location) ts\torch_handler\densenet_handler.py ❯❱ python.lang.security.audit.non-literal-import.non-literal-import Untrusted user input in `importlib.import_module()` function allows an attacker to load arbitrary code. Avoid dynamic values in `importlib.import_module()` or use a whitelist to prevent running untrusted code. Details: https://sg.run/y6Jk 73┆ module = importlib.import_module(model_file.split(".")[0]) ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 83┆ state_dict = torch.load(model_pt_path, map_location=self.map_location) ⋮┆---------------------------------------- 114┆ tensor = torch.load(io.BytesIO(image)) ts\torch_handler\text_classifier.py ❯❱ python.lang.security.audit.logging.logger-credential-leak.python-logger-credential-disclosure Detected a python logger call with a potential hardcoded secret "text_tensor tokenized shape %s" being logged. This may lead to secret credentials being exposed. Make sure that the logger is not logging sensitive information. Details: https://sg.run/ydNx 121┆ logger.info("text_tensor tokenized shape %s", text_tensor.shape) ts\torch_handler\text_handler.py ❯❯❱ trailofbits.python.pickles-in-pytorch.pickles-in-pytorch Functions reliant on pickle can result in arbitrary code execution. Consider loading from `state_dict`, using fickling, or switching to a safer serialization method like ONNX Details: https://sg.run/NwQy 58┆ self.source_vocab = torch.load(source_vocab) ⋮┆---------------------------------------- 60┆ self.source_vocab = torch.load(self.get_source_vocab_path(context)) ts\torch_handler\unit_tests\test_utils\model_dir.py ❯❱ python.lang.security.audit.dynamic-urllib-use-detected.dynamic-urllib-use-detected Detected a dynamic value being used with urllib. urllib supports 'file://' schemes, so a dynamic value controlled by a malicious actor may allow them to read arbitrary files. Audit uses of urllib calls to ensure user data cannot control the URLs, or consider using the 'requests' library instead. Details: https://sg.run/dKZZ 21┆ with request.urlopen(model_url) as fin: ts_scripts\marsgen.py ❯❱ python.lang.security.audit.dynamic-urllib-use-detected.dynamic-urllib-use-detected Detected a dynamic value being used with urllib. urllib supports 'file://' schemes, so a dynamic value controlled by a malicious actor may allow them to read arbitrary files. Audit uses of urllib calls to ensure user data cannot control the URLs, or consider using the 'requests' library instead. Details: https://sg.run/dKZZ 55┆ urllib.request.urlretrieve( 56┆ serialized_model_file_url, 57┆ f'{model_store_dir}/{model["serialized_file_remote"]}', 58┆ ) ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'check_call' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 91┆ subprocess.check_call(cmd, shell=True) ts_scripts\print_env_info.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'Popen' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 62┆ command, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True ts_scripts\regression_utils.py ❯❱ python.lang.security.audit.dynamic-urllib-use-detected.dynamic-urllib-use-detected Detected a dynamic value being used with urllib. urllib supports 'file://' schemes, so a dynamic value controlled by a malicious actor may allow them to read arbitrary files. Audit uses of urllib calls to ensure user data cannot control the URLs, or consider using the 'requests' library instead. Details: https://sg.run/dKZZ 35┆ urllib.request.urlretrieve(serialized_model_file_url, serialized_model_file_name) ts_scripts\tsutils.py ❯❯❱ python.requests.security.disabled-cert-validation.disabled-cert-validation Certificate verification has been explicitly disabled. This permits insecure connections to insecure servers. Re-enable certification validation. Details: https://sg.run/AlYp ▶▶┆ Autofix ▶ requests.post(url, params=params, verify=True) 130┆ response = requests.post(url, params=params, verify=False) ⋮┆---------------------------------------- ▶▶┆ Autofix ▶ requests.delete(url, verify=True) 147┆ response = requests.delete(url, verify=False) ⋮┆---------------------------------------- ▶▶┆ Autofix ▶ requests.post(url, params=params, verify=True) 169┆ response = requests.post(url, params=params, verify=False) ⋮┆---------------------------------------- ▶▶┆ Autofix ▶ requests.delete(url, verify=True) 176┆ response = requests.delete(url, verify=False) ts_scripts\utils.py ❯❯❱ python.lang.security.audit.subprocess-shell-true.subprocess-shell-true Found 'subprocess' function 'run' with 'shell=True'. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and variables, which makes it much easier for a malicious actor to execute commands. Use 'shell=False' instead. Details: https://sg.run/J92w ▶▶┆ Autofix ▶ False 63┆ subprocess.run([cmd], shell=True, check=True)