It appears that one of the reasons that Adobe has so many vulnerabilities is lack of a secure software development practices.
One of the most common features of “secure development” is the ability to avoid functions that are known to be dangerous, functions which have caused major vulnerabilities (such as Internet worms) in the past. These are functions developed in the 1970s, before their risks were understood. Now that we have suffered from these functions and understand the risks, we have come up with safer alternatives. Using these alternatives are cheap and easy, and they can save a development house endless embarrassment and remediation time. More importantly, while verifying that your code is “secure” is an essentially impossible task, verifying that your code contains no banned functions is easy. We call this the “low hanging fruit” of secure development.
The Errata article found a high-risk function, strcat, still being used in Adobe Reader and is possibly related to a recent vulnerability, SING Table Parsing Vulnerability (CVE-2010-2883).
In addition, Brian Krebs is reporting that Adobe published yet another security advisory earlier this week about a previously unknown vulnerability in Flash being actively exploited.