Step-by-step: Creating a custom query to catch insecure deserialization in Java

Static analysis can't solve dynamic problems, but it's the only tool most teams have. The query isn't meant to be perfect, it's meant to be better than nothing.

Your wrapper example proves the point. If you have a method that sometimes returns user input, that's a source and should be treated as one. The filter isn't wrong, your source list is incomplete. That's a tuning problem, not a fundamental flaw.

You're right about the false sense of security though. The real failure is when teams treat a clean scan as "secure" instead of "less obviously broken."

Missing the end of your skeleton code snippet, but the foundational approach is valid. The real challenge, after you've defined your sinks and sources, is quantifying the signal-to-noise ratio in a production codebase.

You'll need to benchmark the query's runtime and false positive rate against a representative sample of your legacy services. I've seen similar custom queries degrade scan times by 40% or more if the CxQL isn't optimized, especially around the call graph traversal for DTO field use. Did you profile the performance impact?

You're not wrong about the high-maintenance list problem. That's exactly why I prefer structuring these queries to flag *potential* flows for review, not to auto-filter with brittle allow-lists. The real tech debt starts when you try to make the query "perfect" instead of treating it as a prioritized checklist for human review.

But calling it a fundamental tool limitation feels too fatalistic. Isn't the point of a custom query to adapt the static analysis to your team's specific framework usage patterns? You're right that it can't see runtime data, but a well-tuned query can at least map the *possible* highways the data could travel. That's still valuable for spotting architectural red flags.

Yeah, that makes sense. Treating the query output as a review checklist instead of a pass/fail gate is a much more realistic mindset.

But doesn't that just shift the maintenance burden from tuning the query to manually triaging the results? For a team just starting out, that could still be a lot of noise to sift through every time.

How do you decide what's a "high-priority" finding versus a low-probability "possible highway" that you can ignore for now?

You prioritize findings the same way you prioritize cloud spending: by cost impact. A false positive you waste time reviewing is a sunk cost. A missed vulnerability that gets exploited is a budget-wiping capital expense.

Map your "possible highways" to the data they actually carry. User-controllable input flowing into a library used by a public API endpoint? That's an EC2 instance running 24/7. Internal configuration data flowing through the same sink? That's a dev-stage reserved instance you can discount.

Start by filtering on code that's actually deployed to production. Then, filter out findings from services with no external ingress. That alone cuts 60% of the noise and focuses your manual triage where it might save real money.

The query skeleton cuts off at `FindByShortName("ObjectIn`. Is there a standard way you find constructors in CxQL, or do you have to search for method calls with the class name?

Filtering `Class.getResourceAsStream` as usually safe worries me a bit. Doesn't that assume the config file's contents are never influenced by a build process or deployment script? If an attacker can control a property file that gets bundled, wouldn't that bypass the filter?

Adding XMLDecoder is a good call. But doesn't treating setters as sources create a lot of noise if you have standard DTOs or entity classes? How do you filter out the harmless ones?

Default rulesets focus on known bad libraries because they're measurable. Your approach is better, but still theoretical until you quantify the results.

How many exploitable flows did this custom query actually find that the defaults missed in your legacy portfolio? Without that delta, you're just trading one form of security theater for another.