They're not general vulnerabilities in the library. They surface when people use a documented-dangerous function in a stupid way.
Obviously this stuff (security disclosure) isn't easy but with such a pervasive library near monthly findings is a growing chore.
Additionally, 2.10 deprecates the unsafe behavior and introduces a new, safer alternative. See the blog post for more information there.  That might be a valid reason to spend time upgrading.
Obviously, if you're actually affected, then yes, upgrading or backporting patches is a good idea.
I'd just point out that accepting any customer's policy as something you implicitly agree to support is inherently risky without an adequate contract between the relevant parties. Presumably, you've signed a contract with the customer, and if they have a no-CVE policy, there's SLAs that you can point to that say what is and isn't covered, and by what date. So it is just the price of doing business and both parties know that this'll impact the delivery of other features, bug fixes, &c. Otherwise, your business-people aren't doing a great job of covering the costs of doing business with said customer... :)
Without much better developer tooling, we'll always be trying to catch up with the people who find vulnerabilities. People aren't perfect. Tools aren't perfect either. But they can complement each other nicely and currently most projects err on the side of "too little" rather than "too much" tooling.
Someone who can solve this problem effectively could make some real money.
Second for a large enterprise with a lot of developed in house applications it’s impossible to validate every implementation and use case; so the default policy is updated or file for an exception in the exception process is upto the application owner in the business to make an argument to the security team why it’s not applicable.
No CVE policy is actually the smart way of doing things because it does moves the load form your security team which will be understaffed compared to the development staff (doesn’t matter if it’s in house or not) and they have better things to focus on than going over SCA or Vuln scanning CVE reports.
This - the vulnerability descriptions are usually incredibly poor. Snyk are bad at this too. What's particularly infuriating is when the descriptions tell you what a generic e.g. XSS or Java deserialisation vulnerability is. It's so incredibly patronising and doesn't tell you anything at all about the _specifics_ of the problem.
If you're really lucky you'll be able to find the patch that fixes the CVE on GitHub (often the commit messages are deliberately vague - I guess the devs think it'll be exploited less this way?) and then you can try to reverse engineer what the actual problem was and what you'd need to be to be exploitable.
So it's an intense cycle.
A great step might be for libraries to note when their implementation of a package is safe.
Stuff like this warrants a followup, but you have to have a good option in your vulnerability management to accept a vulnerable dependency (especially if - unlike this case - the upgrade path is not available or requires extensive other upgrades). In any case, casual high-rated CVEs for library edge cases like this contribute a lot to "alarm fatigue".
Despite the CVE database being problematic for libraries, there's no real alternative for answering the question "do my dependencies have security problems?", so you've got to accomodate.
1. JSON content is sent by an untrusted client
2. Must have one of those libraries in classpath: Logback, HikariCP, commons-dbcp, P6Spy
3. Default typing must be enabled with enableDefaultTyping (very insecure, if your program has this, it's insecure even after this patch)
4. There must be a property with permissive type (such as Object, Serializable, Comparable, Cloneable, and so on)
The only reliable fix is surely stopping serialization of arbitrary classes by not using or auditting any use of the DefaultTyping feature.
Curious as to what makes you think this - I was under the impression you needed to explicitly call `enableDefaultTyping` to get this unsafe behaviour. The wiki page explicitly tells you not to do this with untrusted input and the method is deprecated in the latest versions of the library.
Here is a much better blog by the library author themself: https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-...
It seems like it's a blacklist of types to not automatically de-serialize? If so, that's.... not good.
It must be noted that the vast majority of Jackson use cases is not affected, you need to enable an optional feature that has been known to be unsafe for years 
The most recent relates to blocking yet another gadget:
As another commenter mentions, this whole set of issues is only a problem if you call enableDefaultTyping during setup, and then deserialise data from untrusted sources. Doubtless, there are people doing this. But don't.
Block two more gadget types (commons-dbcp, p6spy, CVE-2019-16942 / CVE-2019-16943)
# Safe Default Typing (safe Polymorphic Deserialization)
In other words, it’s quite difficult to do without running some scanning process designed to look for this library, and for specific versions of it that are vulnerable.
The other jackson packages are mostly Java package hierarchy that don't affect this CVE (jackson-core, jackson-bom, jackson-parent, and jackson-annotations -- but we've also updated all of these to 2.10 on F30+).
rpm -qa | grep jackson-databind
As noted by other commenters just having the package isn't sufficient. You need a number of other libraries (most of which aren't shipped with Fedora, none of which are shipped on RHEL) on the classpath of the running JVM.
If you're not running any Java code, you're definitely not affected. If you're using any code distributed through the official channels, it is very unlikely that you're affected. You'll probably only be affected if you're using third-party projects. Which as always, are run at your own risk. :)
: Source: co-maintainer of the package via the Fedora Stewardship SIG.
F30 Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b1715548...
F31 Bodhi: https://bodhi.fedoraproject.org/updates/FEDORA-2019-cf87377f...