Hmm, I'm not sure that selection of Objective System's tools would count as going with the lowest bidder. Choosing one of the crummy toolsets for ASN.1 would be that.
Looking at the advisory reveals that the bug affects their C/C++ toolset. That'll be the one in mobile phones, etc. I've used that one quite extensively too, though not with my current employer, but generally found the experience to be good. I hope former chums are keeping their eyes peeled...
And whilst the advisory explores the behaviour of the code on Windows, that runtime compiles up from a common source code base for every platform. So the bug will likely be present on anything that uses C/C++. That area of the runtime is also very ancient now, so I expect it's affects far more than this single version of the code.
The one good thing is that that toolset has been very stable for a long time, In theory fixing affected products is simply a case of upgrading and recompiling. I'm not anticipating any remedial coding work being required by developers who have used it.
ASN.1 remains one of the most useful old technologies out there. It leaves Google Protocol Buffers standing (in fact GPB are slowly adopting most of the useful features found in ASN.1). The only other serialisation technologies that are roughly comparable are XSD (XML schemas) and JSON schemas. Why? These three are the only ones where it is possible to define size and value constraints on message fields.
If used, size and value constraints allow one to automatically defend oneself against buffer overruns, etc. Ironic, isn't it?
(ps. I don't work and haven't worked for Objective Systems).