Everyone is talking about AI-assisted security. Fewer people are being honest about what it actually looks like in practice.
I used Claude throughout the MFlix remediation project — for understanding vulnerabilities, planning upgrades, writing migration code, and reviewing my remediation decisions. This article is an honest accounting of where it helped, where it was confidently wrong, and what the experience taught me about the appropriate role of AI in security engineering work.
How I Used It
Four distinct use cases across the project:
- Vulnerability explanation — understanding what a specific CVE actually enables
- Remediation planning — figuring out the right fix approach for complex upgrades
- Code generation — writing the migration code for API changes
- Decision review — sanity-checking suppression decisions Each use case produced different results. Let me walk through them honestly.
Use Case 1: Vulnerability Explanation — Where AI Genuinely Shines
When Snyk flagged spring-beans@5.0.7 with a Remote Code Execution at CVSS 9.8, my first question was: what does this actually enable? The CVE database entry is often terse. The Snyk description gives you the vulnerability class but not always the attack mechanics.
I asked Claude to explain exactly how the spring-beans RCE worked — what an attacker needed to control, what the exploit chain looked like, and how the application's specific configuration affected exploitability.
The explanation was excellent. It walked through the class loading mechanism in CachedIntrospectionResults, explained why certain HTTP request parameters could trigger it, and was clear about the conditions required — HTTP endpoint exposure, specific Spring MVC configuration, no input filtering at the framework layer.
More importantly, it helped me think through MFlix's specific exposure: yes, the public movie search endpoint is unauthenticated, yes it accepts HTTP parameters, yes the Spring MVC configuration in MFlix matches the vulnerable pattern.
This kind of contextual vulnerability analysis — "here's the CVE, here's my application, am I actually exposed?" — is exactly where AI adds value. It accelerates the analysis that a security engineer would do manually, and it's good at it because the underlying information (CVE mechanics, Spring internals, application patterns) is well-documented and within training data.
Accuracy: High. I cross-referenced the explanation against the Spring Security advisories and the CVE detail page. The core mechanics were correct. The application-specific analysis was sound.
Use Case 2: Remediation Planning — Mixed Results
Planning the jjwt 0.9.1 → 0.12.0 migration is where I first encountered AI's most significant failure mode: confident incorrectness.
I asked for a migration guide from jjwt 0.9.1 to 0.12.0. The response was detailed, structured, and plausible-looking. It included code examples showing the old and new API patterns, explained the artifact structure change (monolith to three separate artifacts), and described the key type requirement change.
Three of the code examples were wrong.
Not subtly wrong — wrong in ways that would cause compile errors or runtime failures. The Keys.hmacShaKeyFor() usage was correct but the import path was from a version that didn't exist. The Jwts.SIG.HS256 syntax was correct but the surrounding builder pattern had a method that was removed in 0.11.x, not present in 0.12.0. The claims parsing example used .getBody() which is the 0.9.x API, not .getPayload() which is the 0.12.x API.
When I pointed out the errors, Claude corrected them — but the corrections introduced new errors. The model had detailed knowledge of jjwt 0.9.x and general knowledge of the 0.12.x direction, but its specific knowledge of the 0.12.0 API surface was unreliable.
This is the pattern I encountered repeatedly: AI is excellent at explaining concepts and patterns, but unreliable on specific API signatures for library versions that changed after its training data cutoff or that were underrepresented in training data.
The correct workflow I developed: Use AI to understand the shape of what needs to change, then verify every specific API detail against the official documentation or source code. Never trust an AI-generated import path or method signature without checking it.
Accuracy: Medium. Conceptually correct, specifically unreliable.
Use Case 3: Code Generation — Useful With Verification
For the Spring Security configuration migration from WebSecurityConfigurerAdapter to the SecurityFilterChain bean pattern, I asked Claude to rewrite the existing configuration in the new style.
The generated code was largely correct. The SecurityFilterChain bean structure was right. The authorizeHttpRequests lambda syntax was right. The SessionCreationPolicy.STATELESS configuration was right.
Two issues:
The antMatchers() → requestMatchers() rename was handled correctly in the authorizeHttpRequests block but missed in a separate method I hadn't shown in my prompt. This is a prompt engineering failure as much as a model failure — I didn't include the full configuration, so the model couldn't see everything that needed changing.
The AuthenticationManager bean configuration was slightly wrong — the generated code used a deprecated method for retrieving it from the AuthenticationConfiguration. The correct approach required checking the Spring Security 6.x migration guide.
The workflow that worked: Provide the complete existing code in the prompt, ask for the migration, then run the tests. The tests caught both issues immediately. AI-generated code that passes tests is trustworthy; AI-generated code that you haven't run is not.
Accuracy: High with verification. Tests are not optional when using AI-generated code.
Use Case 4: Suppression Decision Review — Surprisingly Valuable
This was the use case I expected least from and got most from.
Before finalising any suppression decision, I described the finding and my reasoning to Claude and asked it to challenge my logic. "I'm planning to suppress this jackson-databind deserialization finding because we don't use polymorphic deserialization. Here's my evidence. What am I missing?"
The responses were genuinely useful — not because the model had superior security knowledge, but because articulating the reasoning to an external entity forced me to be more precise, and the model asked clarifying questions that identified gaps in my analysis.
For the jackson-databind suppression, it asked: "Have you verified that no third-party library you import configures Jackson's default typing on your behalf?" I hadn't checked that. I checked. Nothing did. But the question was right — a common source of polymorphic deserialization vulnerabilities is a transitive dependency that configures Jackson in the background, not direct application code.
For the MongoDB driver suppression, it pushed back on my "Atlas TLS enforcement mitigates the MitM risk" argument more effectively than I'd expected. The counter-argument: Atlas TLS enforcement prevents cleartext transmission but doesn't fully mitigate driver-level certificate validation failures, which can be exploited even over an encrypted channel under certain network conditions. The suppression was still justified, but the reasoning needed to be more precise.
Accuracy: High for challenging reasoning. Using AI as a devil's advocate for security decisions is one of its most effective use cases — not because it's always right, but because the process of explaining your reasoning exposes gaps.
The Failure Mode That Matters Most: Confident Incorrectness
Across all four use cases, one failure mode appeared repeatedly and is worth naming explicitly: confident incorrectness on version-specific details.
The model would state that a method existed in a specific library version with complete confidence — no hedging, no "you should verify this" — and be wrong. Not wrong about the concept, wrong about the specific API surface at a specific version.
For security work this is particularly dangerous. The difference between setSigningKey(String) (vulnerable in jjwt 0.9.x, accepts weak keys) and signWith(SecretKey, SignatureAlgorithm) (secure in 0.12.x, enforces key strength) is the difference between a secure and an insecure JWT implementation. If you trust the AI's method signature and it's wrong, you might implement the old vulnerable pattern thinking you've implemented the secure one.
The rule I developed: Trust AI for concepts. Verify AI for specifics. Any method name, import path, version number, or configuration value that AI provides should be cross-referenced against official documentation before use in security-sensitive code.
Where AI Added the Most Net Value
Ranking the use cases by net value delivered:
1. Vulnerability explanation — highest value, highest accuracy. Understanding attack mechanics is conceptual work that AI handles well.
2. Suppression decision review — high value, unexpected. Using AI as a challenger rather than an oracle is an underrated pattern.
3. Code generation — medium value, requires verification. Fastest when used as a starting point with tests as the quality gate.
4. Remediation planning — lowest net value due to reliability issues. Better to read the official migration guide directly and use AI to clarify specific points you don't understand.
What This Means for the NerdWallet Role
The job description explicitly mentions building AI-powered security systems including RAG pipelines and automated code review. Having done this project gives me a concrete, honest perspective on AI in security work that I think is more valuable than enthusiasm.
The engineers who will build effective AI security tools aren't the ones who think AI is magic. They're the ones who understand:
- Where AI is reliably accurate (concepts, pattern recognition, reasoning challenges)
- Where AI is unreliably accurate (specific APIs, version details, novel configurations)
- How to design systems that route the right tasks to AI and keep humans in the loop on the wrong ones
- How to test and validate AI outputs in security contexts where confident incorrectness is dangerous An automated code review system that uses AI to identify suspicious patterns is valuable. The same system that uses AI to generate specific remediation code without human verification is dangerous — because the AI might generate code that looks like a fix but implements the vulnerable pattern.
The appropriate role of AI in security engineering is augmentation, not replacement. It compresses the time to understand a vulnerability, challenges your reasoning on risk decisions, generates starting points for remediation code. It does not replace reading the documentation, running the tests, or applying security judgment.
The Honest Bottom Line
AI made me faster on this project. It did not make me more accurate on its own — accuracy came from verifying AI outputs against authoritative sources and running tests.
The productivity gain was real: vulnerability analysis that might have taken an hour of reading took fifteen minutes with AI assistance. The jjwt migration planning took an afternoon partly because I trusted the first AI-generated migration guide more than I should have. The security configuration migration was straightforward partly because the AI-generated starting point was close enough that tests caught the gaps quickly.
Net verdict: meaningful productivity improvement with a significant failure mode that requires active management. The failure mode — confident incorrectness on specifics — is dangerous enough in security contexts that using AI without verification is worse than not using it at all.
That's not an argument against AI in security work. It's an argument for understanding what you're working with.
The completed MFlix project — remediated pom.xml, .snyk suppression file, security configuration, and full test suite — is at github.com/pgmpofu/mflix.
This concludes the MFlix/Snyk series. The full portfolio now spans three projects and twenty-one articles covering SAST tool design, ML-powered secrets detection, and real-world SCA remediation. If you found this series useful, the best thing you can do is star the repositories and share the articles with someone who's thinking about the AppSec transition.
Top comments (0)