Speaking from personal experience, having Tsipenyuk as a last name can be inconvenient due to pronunciation and spelling errors, but the last name O'Neil can cost you an identity. I came to realize this when I got married and, being convinced by many around me, exchanged my complicated scary-looking Ukrainian last name for this simple and straightforward Irish one. Turns out, my problems were just beginning.

I will skip over describing the pain and frustration of filling out millions of request forms asking to change the last name on millions of the accounts from one to another, and making millions of photocopies of the marriage certificate to send along with the forms as a proof. I won't start a discussion on why changing your last name on a credit card account is significantly less painful than doing the same for an airline frequent miles account. I will proceed straight to the really good stuff.

• The Social Security office simply dropped the single quote from my last name even though my request form clearly contained one. When I inquired about it, the response was that their system automatically does this and treats O'Neil and ONeil the same.
• TD Ameritrade and Wells Fargo sites (as well as many others) don't allow single quotes in their passwords.
• The zenTrack project management and bug tracking software escapes single quotes, but does so incorrectly, leaving backslashes for display.

The list goes on--these are just a few examples of what I keep running into. I am sure some of you see what I'm getting at. Clearly, all of the mentioned inconveniences are caused by the fact that single quote is a special character that needs to be correctly handled by software behind all these institutions. Some institutions choose to deal with the problem by simply not allowing special characters, others attempt to escape them. Still others--remain vulnerable. It boggles my mind that this one character causes so much pain and makes it necessary for me to remember what version of my last name I should use at which point. Why is there still no standard way of dealing with this problem? Why is everyone still doing their own thing?

It shouldn't be a surprise to you that my advice to the software developers writing code for these institutions is to create standards that allow them to be consistent and correct in their handling of names as "special" as O'Neil. I still hope that one day the standard everyone adheres to will exist, and then I will be an O'Neil at all times. Until then we'll keep running into problems similar to this one.

Last spring Howard Schmidt and I took our advice on software security to Washington DC. We spoke to just about anyone who'd listen about ways the federal government could build security into the code they build, buy, and commission. Here's an article on what we had to say. Point #1: Appoint a Leader.

Apparently there were more people listening than we realized. President Obama has named Howard the new Chief of Cybersecurity. Congratulations Howard!

Today we are officially launching Fortify on Demand. You can upload your compiled code, and we'll generate a vulnerability analysis report. Give us the source code too, and we'll include information about the offending lines of code. Give us a URL where the code is running, and we'll create an integrated static/dynamic analysis report, with the dynamic results courtesy of our friends at WhiteHat Security. (Press release here.)

I got started on static analysis in order to help programmers write better code, but I've learned there's a lot to be said for simply creating a code assessment. Non-programmers deserve answer questions like "Did I get what I paid for?" But non-programmers aren't usually in a position to make static analysis fly. And even if they are, the norm is a static analysis report that says things one way and a dynamic analysis report that says them another. Our early adopters (thanks guys!) are big on the ease-of-use factor. Multiple assessment techniques coming together in one report without any fussing around with code. What could be better?

If you want a closer look at what we've built, sign up for the webinar Jacob West and Jeremiah Grossman are giving on Jan 14. Register here.

You might have noticed some new rulepacks showed up on your virtual doorstep just before the Thanksgiving holiday in the US. If you haven't gotten into the nitty gritty details yet, as of this release, the Fortify Secure Coding Rulepacks detect 436 unique categories of vulnerabilities across 18 languages and over 600,000 individual APIs. In brief, our latest release includes support for:

- Python (new language)

- Microsoft SharePoint

- Adobe Blaze DS (Server-Side Flex API)

- Spring Annotations

- Apache Commons FileUpload API

As always, we're very excited about the release and encourage Fortify users to play around with the new features as soon as possible.