There are a few more ways to secure PL/SQL applications that the next few sections will touch on:
Educate the user
Avoid known vulnerabilities in Oracle
Watch out for batch programs
Scrutinize dynamic SQL and PL/SQL
Use the "virtual private database" feature
Encrypt source code
Although I present these topics in what I consider to be order of importance, the later ones may be more significant than the earlier ones for some applications.
With or without PL/SQL in the equation, the weakest link in the security chain is often the user. The age-old trick for breaking into the computer systems of a large company is for the Bad Guy to phone a user and say, "Hi, this is Bob from MIS. I am diagnosing a problem with your account. Will you please tell me the username and password you use when you log in?" There are other "social engineering" tricks such as "dumpster diving" (literally, going through a company's trash, looking for passwords and other secret information) to which criminals and troublemakers are willing to stoop.
Oracle does release information to the public about what it considers to be its worst security problems; check out:
Be sure your DBA is familiar with this page or has some other way of getting the information such as subscribing to the BUGTRAQ mailing list, which might see the news before ...