Run a Security Audit on a Spring Boot App

The agent clones the app into its own cloud sandbox and reads how it builds before it reads any endpoint. In a Spring Boot app like WebGoat/WebGoat, pom.xml inherits spring-boot-starter-parent 4.1.1 and sets <java.version>25</java.version>, and AGENTS.md says to build with the Maven Wrapper (./mvnw), not an installed Maven. The agent installs JDK 25, runs the wrapper to build the single executable JAR, and starts it: application-webgoat.properties serves WebGoat at /WebGoat on port 8080. It registers an account through /register.mvc and signs in, so every finding is checked against the running app rather than argued from source alone.

Then it maps the lesson endpoints to the categories the prompt names. For injection it reads SqlInjectionLesson5a.java, whose /SqlInjection/assignment5a handler concatenates request parameters straight into a Statement.executeQuery string. For broken access control it reads IDORViewOtherProfile.java, whose /IDOR/profile/{userId} returns a profile for any id in the path, and MissingFunctionACUsers.java, whose access-control/users endpoint lists users. For each one it records the file and line, sends one request to the running app that demonstrates the behaviour, and notes what the response shows.

Authentication and sensitive-data findings come from the same reading. In JWTSecretKeyEndpoint.java the token is signed with HS256 using a secret picked from a five-word list (victory, business, available, shipping, washington), so the signing key is guessable, and WebSecurityConfig.java disables CSRF for the whole app. In the xxe and pathtraversal lessons the agent reads how /xxe/simple parses posted XML and how the profile-upload endpoints build file paths, and records what each exposes. Every finding carries a severity the agent assigns from impact and reach.

The prompt says to change no code, so the agent only builds, runs, reads and sends requests; it writes nothing back and opens no pull request. Every Maven command, the server start, and each request and response stay in the session transcript, and the result is security-audit.md returned as an artifact on the session. Because WebGoat is insecure on purpose with documented lessons, the report can be scored against known answers, which is what makes it a fair test of an agent's audit.

What comes back is security-audit.md as an artifact on the session, which the session read returns with a download link good for an hour. It opens with how the app was built and run (the JDK version, the Maven Wrapper build, the context path and port, the account it registered) so a reader knows the exact conditions each finding was checked under. Then it lists findings grouped by category: injection, broken access control, authentication, and sensitive data exposure.

Each finding names the file and line, states the behaviour in one or two sentences, shows the request the agent sent and what the response showed, gives a severity, and gives the fix in terms of the code it points at: use a PreparedStatement with bound parameters in the SQL lesson, check the authenticated user against the userId in the IDOR path, sign JWTs with a strong secret from configuration rather than a word list, and decide per route whether CSRF protection should stay off.

A reviewer checks the report against the app before acting on it: that each cited line is really there, that the request shown does what the report says, and that the severity matches the impact for their own deployment. Because the sandbox still holds the built and running app, a follow-up message to the same session can ask the agent to prove any finding again or to prepare the fixes as a pull request.

Add an automation to the Project with a github trigger on pull_request.opened, filtered with branch_patterns to your default branch, and this prompt. Each pull request gets a read-only run that builds the module with the Maven Wrapper, reads the controllers and Spring Security configuration the change touched, and comments its findings on the pull request with the class and line, so a new endpoint that skips authorization is flagged while the author is still on the branch.

Set a webhook URL on the API key and Rush POSTs run.completed when the turn finishes, with the session_url. Your server reads the session, takes the link to security-audit.md from its artifacts, and attaches it to the pull request or opens a tracking issue, so a new flaw is caught the day it is introduced rather than at the next manual review.

A security audit on a Spring Boot app means installing a JDK, running a full Maven build and then sending requests to the running server, which is slow and disruptive on a laptop and a poor fit for shared staging. In a Rush sandbox the agent installs JDK 25, builds with the wrapper, starts the JAR and probes it on its own disk and network, and nothing it does reaches your machine or another tenant. When the run ends the sandbox is torn down.

An audit is only worth acting on if you can check it. Because every build command, every request and every response is kept in the session transcript, the person reading security-audit.md can trace each finding to the exact exchange that demonstrated it instead of taking the agent's word. Several audits can run at once, one per application, up to the key's concurrent-run limit.

Will it change anything in my repository?

Does it build with Maven or Gradle?

Can it audit a private app?

How do I know the findings are real and not guessed?