Next, unfortunately saying you are using WS-Security doesn't mean all that much. As Brian Chess and I talked about in our RSA talk last year, the spec leaves ample room to shoot yourself in the foot at design time and that's even before you get to implementation. You can use weak token types, lack integrity, open up information disclosure, replay and a host of other vulns, all while still being WS-Security compliant, depending on the profile.
Consider the scenario where WS-Security is being used encapsulate X.509 Certificates as a means of "authentication", but without any associated signature, nonce, or timestamp. This means that anyone with access to the client's public key could access the Web Service. Basically the client is saying "Here is my X.509 Certificate, let me in". And, the X.509 Certificate is publicly available anyway. Sending it in a WS-Security message proved nothing. I saw this scenario recently (and explained why it was insecure!).
The scenario of "We will let messages signed by a trusted client into our Web Service" is frighteningly common. You may ask "Why is that bad?". The answer is that anyone who can get their hands on a signed message (e.g. from log files) can replay the message through, and get the response. There are *many* such "roll your own" use cases of WS-Security out there. And, in 99% of cases, the recipient is only checking the signature over the SOAP Body, not over the routing information (leading to a routing-based attack by an attacker inserting a bogus "ReplyTo") or a creation/expiry times (if these are even present).
When I give training on this, I always recommend that people look to the WS-I Basic Security Profile, not directly to WS-Security. The WS-I have profiled how WS-Security can be used in a secure and interoperable manner.
An additional problem with WS-Security is its name. It leads to the assumption that the usage of WS-Security makes a Web Service secure. However, you can have a Web Service which is using WS-I compliant WS-Security, and receives a signed, encrypted, authenticated message from a trusted client, only to be hit by a SQL Injection attack, a virus in an attachment, or a DTD-based "XML Bomb" attack.
PS: My own view on why WS-Security is gaining usage is because (a) XML Gateways make it easy to deploy WS-Security without writing code, and (b) the Microsoft WCF (plus Geneva, etc) make extensive of WS-Security within their messages. But it's the "roll your own" solutions I'm worried about.