How can we know if an application is "secure"? Can we tell, using
established metrics, how likely a program is to be "secure enough"?
What standards can we hold up against our code, to determine if
security quality is adequate? What, generally, does due diligence
require?

As practical matters stand, the answers to these questions are
simple. We can't know precisely. Additionally no widely accepted
standard(s) for secure application programming exist. Programmers
today must instead rely on technique, example, guidelines, rigorous
testing and an awareness of risks to be avoided in order to write
reasonably secure code.

Given the above, which are the best coding methods to apply? Which
are the most grievous pitfalls to avoid? Which architectural and
design principles give the best guidance? And what tools are
available to help a programmer check for vulnerabilities and other
security gaffes?

In the pages that follow we answer these queries with a summary of
current best secure application coding practices (circa 2001):

Explaining common threats, attacks, and vulnerabilities

Surveying and analyzing related formal standards, including
some under development

Recommending helpful policies, procedures, and processes

Describing widely accepted architectural principles for
designers

Demonstrating how good coding practice contributes to program
security

Providing language-specific security tips for C/C++, Perl,
and other languages

Documenting useful software tools available today to help
make code more robust

Listing a detailed survey of related literature and websites
for further study

2.2 About sources for this paper

The majority of quotations in this paper are from sources free of
any use restrictions. Some quotations did originate from copyrighted
material. We have treated such material carefully, with the intent
of complying with the "fair use" doctrine embodied in U.S. copyright
law. Any oversights brought to our attention will be remedied
promptly in a future version of this document.