Application Security Testing on EKS
Trivy, OWASP ZAP, OpenRASP, and Amazon Inspector layered on an EKS pipeline, verified by a live SQL injection blocked twice: once by ZAP at scan time and once inside the running JVM.
A dependency scanner catches known-vulnerable libraries but misses application-logic injections. A dynamic scanner attacks the running endpoint but stops at the perimeter. Neither is watching when an exploit attempt hits the running process.
Four independent techniques on the same pipeline: Trivy scans source and dependencies at commit, OWASP ZAP attacks the running endpoints from outside the container, OpenRASP (a Java runtime agent) evaluates every request inside the JVM at the point of execution, and Amazon Inspector scans both the built image and the worker nodes. The agent-on and agent-off runs use the same container image with a one-line manifest diff, so any behavioural difference is attributable to that one variable.
A tool confirming it saw an attack is not the same claim as it stopping the attack.
The same SQL injection payload gets blocked at two independent layers: ZAP's active scan reports 56 blocks across the SQLi payload set, and OpenRASP returns HTTP 302 with intercept_state: block at 90% confidence inside the running process, with the query never reaching Postgres.
- OpenRASP's official plugin ships with all_log: true; enforcement only turns on after flipping that flag
- GitHub OIDC trust policy scoped to the account's immutable numeric IDs, not just repo names