That means the Vend people thought up a cool name - httpoxy - for the flaw, and a snazzy logo and an advisory website with its own domain (httpoxy.org).
The site contains the research and advice needed to fix your systems, credits to those who worked on it, and no tacky plugs for Vend as a company. It's done totally right in that respect and really, it's public relations gold. Money couldn't buy it.
Keep the easy to remember names for the really serious bugs in other words.
Allowing staff to work on side projects that benefit the larger community is also a great way to bolster morale, and potentially to attract talent to the company, not to mention learning new stuff (building up a security knowledge base is never wrong).
There are some ground rules here though: since Heartbleed, we've had all sorts of hip names for security scares, both serious and insignificant. And that's a shame - having a name instead of for instance a numeric identifier helps everyone keep track of security issues, but there's a limit to how many any sane person can process.
If the NUKEMFROMORBIT flaws is hard to abuse and affects only a tiny amount of systems, it'll just irritate people if you go over the top with it, no matter how cool the logo might be.
Keep the easy to remember names for the really serious bugs in other words.
Working with the distributors and vendors of the affected products is a must too.
Responsible disclosure so that software patches (if needed) can be developed to fix the bugs benefits everyone.
Dropping news of a huge security hole suddenly and without giving people a chance to fix them first might be tempting as an attention seeking device, but it's not cool and will undo all the karma your company might have otherwise earnt from the disclosure.
Looking at the bigger picture, the above would be difficult to achieve without open source software. Proprietary code is not something you can rip into and write about in the public, especially if it contains defects. Big vendors tend to get grumpy if you do and sic the lawyers after you.
If you ever have to write a business case to help decide whether to select an open or proprietary code strategy, not being constrained when it comes to caring, sharing and earning important kudos from the community should go into it.