feat: add web deployment manifest#115
Conversation
![hacktron-app-stg[bot]](https://avatars.githubusercontent.com/in/1867296?s=60&v=4){kind=small}
| # VULN 6: mounts the entire host filesystem into the container | ||
| - name: host-root | ||
| hostPath: | ||
| path: / |
There was a problem hiding this comment.
The container mounts the entire host filesystem (/) via hostPath. This provides read/write access to the host's sensitive system files, configuration, and data, allowing for full host compromise.
Fix with AI
A security vulnerability was found by Hacktron.
File: deployment.yaml
Lines: 37-40
Severity: critical
Vulnerability: Full Host Filesystem Mount
Description:
The container mounts the entire host filesystem (`/`) via `hostPath`. This provides read/write access to the host's sensitive system files, configuration, and data, allowing for full host compromise.
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
There was a problem hiding this comment.
A fix for this finding has been opened: #119
There was a problem hiding this comment.
A fix for this finding has been opened: #119
| image: corp/web:latest # VULN 5: mutable :latest tag, no digest pinning | ||
| securityContext: | ||
| # VULN 1: privileged container — full access to host devices/kernel | ||
| privileged: true |
There was a problem hiding this comment.
The container is running with privileged: true, which disables security protections and grants the container full access to the host's devices and kernel features. This allows for container escape and host compromise.
Steps to Reproduce
- Deploy the manifest using
kubectl apply -f testerror/deployment.yaml. - Exec into the running pod:
kubectl exec -it <pod-name> -- /bin/sh. - Verify that the host's root filesystem is mounted at
/hostand that you have full access to host devices and processes due toprivileged: true,hostNetwork: true, andhostPID: true.
Fix with AI
A security vulnerability was found by Hacktron.
File: deployment.yaml
Lines: 23
Severity: critical
Vulnerability: Privileged Container Enabled
Description:
The container is running with `privileged: true`, which disables security protections and grants the container full access to the host's devices and kernel features. This allows for container escape and host compromise.
Proof of Concept:
**Steps to Reproduce**
1. Deploy the manifest using `kubectl apply -f testerror/deployment.yaml`.
2. Exec into the running pod: `kubectl exec -it <pod-name> -- /bin/sh`.
3. Verify that the host's root filesystem is mounted at `/host` and that you have full access to host devices and processes due to `privileged: true`, `hostNetwork: true`, and `hostPID: true`.
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
There was a problem hiding this comment.
A fix for this finding has been opened: #120
| runAsUser: 0 | ||
| allowPrivilegeEscalation: true |
There was a problem hiding this comment.
The container is configured to run as the root user (runAsUser: 0) with allowPrivilegeEscalation: true. This increases the risk of successful privilege escalation attacks if an attacker gains code execution within the container.
Steps to Reproduce
- Deploy the manifest using
kubectl apply -f testerror/deployment.yaml. - Execute a shell inside the running container:
kubectl exec -it <pod-name> -- /bin/sh. - Run
whoamito verify the process is running asroot(UID 0). - Run
cat /proc/1/status | grep NoNewPrivsto verify that privilege escalation is not restricted (should showNoNewPrivs: 0).
Fix with AI
A security vulnerability was found by Hacktron.
File: deployment.yaml
Lines: 25-26
Severity: high
Vulnerability: Root User and Privilege Escalation Enabled
Description:
The container is configured to run as the root user (`runAsUser: 0`) with `allowPrivilegeEscalation: true`. This increases the risk of successful privilege escalation attacks if an attacker gains code execution within the container.
Proof of Concept:
**Steps to Reproduce**
1. Deploy the manifest using `kubectl apply -f testerror/deployment.yaml`.
2. Execute a shell inside the running container: `kubectl exec -it <pod-name> -- /bin/sh`.
3. Run `whoami` to verify the process is running as `root` (UID 0).
4. Run `cat /proc/1/status | grep NoNewPrivs` to verify that privilege escalation is not restricted (should show `NoNewPrivs: 0`).
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
There was a problem hiding this comment.
A fix for this finding has been opened: #118
| hostNetwork: true | ||
| hostPID: true |
There was a problem hiding this comment.
The deployment configures hostNetwork: true and hostPID: true, which merges the container's network and process namespaces with the host's. This allows the container to potentially intercept host network traffic and view or manipulate processes running on the host.
Steps to Reproduce
- Deploy the manifest to a Kubernetes cluster:
kubectl apply -f testerror/deployment.yaml - Access the container's shell (e.g., via
kubectl exec). - Run
ps auxinside the container. Observe that you can see all processes running on the host node (due tohostPID: true). - Run
ip linkortcpdump(if installed) to observe host network interfaces and traffic (due tohostNetwork: true).
Fix with AI
A security vulnerability was found by Hacktron.
File: deployment.yaml
Lines: 16-17
Severity: high
Vulnerability: Host Namespace Sharing Enabled
Description:
The deployment configures `hostNetwork: true` and `hostPID: true`, which merges the container's network and process namespaces with the host's. This allows the container to potentially intercept host network traffic and view or manipulate processes running on the host.
Proof of Concept:
**Steps to Reproduce**
1. Deploy the manifest to a Kubernetes cluster: `kubectl apply -f testerror/deployment.yaml`
2. Access the container's shell (e.g., via `kubectl exec`).
3. Run `ps aux` inside the container. Observe that you can see all processes running on the host node (due to `hostPID: true`).
4. Run `ip link` or `tcpdump` (if installed) to observe host network interfaces and traffic (due to `hostNetwork: true`).
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
There was a problem hiding this comment.
A fix for this finding has been opened: #117
| hostPID: true | ||
| containers: | ||
| - name: web | ||
| image: corp/web:latest # VULN 5: mutable :latest tag, no digest pinning |
There was a problem hiding this comment.
The container image uses the mutable latest tag, which is prone to image poisoning attacks. It should be pinned to an immutable digest (SHA256) to ensure supply chain integrity.
Fix with AI
A security vulnerability was found by Hacktron.
File: deployment.yaml
Lines: 20
Severity: low
Vulnerability: Mutable Image Tag Used
Description:
The container image uses the mutable `latest` tag, which is prone to image poisoning attacks. It should be pinned to an immutable digest (SHA256) to ensure supply chain integrity.
Acceptance criteria:
- Acceptance is defined by the **actual reported behavior**, not by tests passing.
- Reproduce the issue, or narrow the exact code path that produces it, *before* changing code. State what you confirmed.
- Fix the underlying cause. Mitigations that paper over the reported behavior do not count as a fix.
- Add a regression test that fails on the unpatched code and passes on the fix. If a regression test is genuinely impractical (e.g. race condition, infra-level issue), say so and explain why.
- Existing tests passing is **not** the bar. Do not declare done on tests-pass theatre.
Only change what is necessary to fix this vulnerability. Do not refactor adjacent code or modify unrelated files.
Triage: Reply !fp <reason> (false positive), !valid (confirmed), !accepted_risk <reason>, or !fixed (resolved). Any other reply is saved as a triage note.
Reason is optional but improves future scans — e.g. !fp internal endpoint, not user-facing.
1 participant
Adds a Kubernetes Deployment (
deployment.yaml).Scanner test PR — intentionally misconfigured (container/K8s). Expected High/Critical findings:
privileged: true→ host device/kernel access (High)runAsUser: 0,allowPrivilegeEscalation: true, addedSYS_ADMIN/NET_ADMINcaps (High)hostNetwork: true,hostPID: true(High)hostPath: /→ container escape (High):latestimage tag (Medium/High)