Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: "John B. Matthews" <nospam@nospam.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: The CERT Oracle Secure Coding Standard for Java
Date: Sun, 29 May 2011 16:17:06 -0400
Organization: The Wasteland
Lines: 51
Message-ID: <nospam-FD36DF.16170629052011@news.aioe.org>
References: <899ac5cb-b1e4-44b1-8e27-e6385b4fdcdb@24g2000yqk.googlegroups.com> <irq910$vd8$1@speranza.aioe.org>
NNTP-Posting-Host: LQJtZWzu+iKlBROuDg+IUg.user.speranza.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
X-Notice: Filtered by postfilter v. 0.8.2
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4701

In article <irq910$vd8$1@speranza.aioe.org>,
 "Nasser M. Abbasi" <nma@12000.org> wrote:

> On 5/27/2011 10:44 AM, rCs wrote:
> > The CERT Oracle Secure Coding Standard for Java has been completed and
> > is now ready for 
> > https://www.securecoding.cert.org/confluence/display/java/The+CERT+Oracle+Se
> > cure+Coding+Standard+for+Java.
> >
> > The CERT Oracle Secure Coding Standard for Java provides rules for 
> > secure coding in the Java programming language. The goal of these 
> > rules is to eliminate insecure coding practices that can lead to 
> > exploitable vulnerabilities.
> >
> > To review, you can create an account on the wiki and then post
> > comments to any of the pages, or respond directly to me.
> 
> I thought Java was already secured? i.e. no buffer overflow
> problems like with C, and the sandbox thing for applets and
> all of that. I did not know that Java can be not secured before.
> 
> But, would it be not better, if the language can be defined
> so that these remaining security holes that can make it not
> secure be closed at the language definition level, instead of
> having set of rules, that one need to print out and hang on
> the wall to look at while coding?  This way the compiler  job
> to spot them, not the programmer. Much better.
> 
> Just asking, that is all.

This related thread

<http://groups.google.com/group/comp.lang.ada/browse_frm/thread/bb14f1c1986544fb/>

adduced many of the same helpful responses seen in this thread itself:

<http://groups.google.com/group/comp.lang.java.programmer/browse_frm/thread/ed6b7366b0df754a>

One document mentioned there was particularly comprehensive: NASA 
Software Safety Guidebook:

<http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf>

FindBugs is especially handy for highlighting potential violations:

<http://findbugs.sourceforge.net/>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>