I think his observation at a macro level is generally correct. Oracle seems to have arrived at the "secure coding" party late and has a significant C code base, some of which dates all the way back to around 1982. Many of the standard PL/SQL packages and associated C libraries were originally written in the early 1990's. A fun excursion is to look at the modification history of the $ORACLE_HOME/rdbms/admin SQL scripts -- you will see many of these scripts were created 10 to 20 years ago. Remember that the terms "buffer overflow" and "SQL injection" didn't really enter the lexicon until 1996 and 2000, respectively.
To judge Oracle on secure coding, you really need to look at the number of vulnerabilities affecting only recent versions of the database and application server. So far, the results are mixed, but encouraging. Although, more time has to elapse to see what security bugs are in the queue.
Mary Ann Davidson, Oracle CSO, frequently talks about secure coding and how vendors should be more public about their development practices. I would really like to know what Oracle is doing about the large database code base where over 150 security bugs have been fixed to date. Oracle has purchased Fortify as a source code scanning tool, but is there a team of 20 or 100 people dedicated to reviewing every line of code. Many of the security bugs being found today could have been found internally 3 or 4 years ago.