I have been noodling the problem space of secure coding after attending a
wonderful class taught by Ken Van Wyk. I have been casually checking out
Fortify, Ounce Labs, etc and have a thought that this stuff should really be
part of the compiler and not a standalone product. Understanding that fo
Integration of some of the static techniques found in tools like fortify into
compilers does make sense. However, not all of the kinds of things should be
put in the compiler (how many coders do you know that use the -Wall??!). So
one use case for some of the knowledge would be compiler enforc
Sure it should be built into the language, and I assume it will be
eventually. Heck it only took 30 or 40 years for people to force developers
to use Try...Catch blocks.
-gp
On 12/21/06 9:30 AM, "McGovern, James F (HTSC, IT)"
<[EMAIL PROTECTED]> wrote:
> I have been noodling the problem space o
At 10:30 AM -0500 12/21/06, McGovern, James F (HTSC, IT) wrote:
> Content-class: urn:content-classes:message
> Content-Type: multipart/alternative;
> boundary="_=_NextPart_001_01C72514.FE7A042C"
>
> I have been noodling the problem space of secure coding after attending a
>wonderful class
Gunnar, I think the problem space of secure coding will never be pervasively
solved if it relies on the licensing of tools for every developer on the
planet. Folks have been conditioned to not pay for developer level tools and
now use Eclipse, etc. Putting it only in the hands of a few folks may
Once again though, using security-oriented constructs requires that the
developers use them and use them correctly. Static code analysis tools (like
Fortify) aren't after-the-fact, they should be inline during the process of
development. If you can create a development process and environment of
se
On 21 Dec 2006, at 23:19, ljknews wrote:
>
> Isn't the whole basis of Spark a matter of adding proof statements in
> the comments ?
You can achieve very similar goals by using unit tests. Although the
tests are not integrated into the code as tightly as something like
Spark (or enforcing rul
It would be worth knowing more about the basis you use for drawing the
conclusion, but if it's just the overlap between compilers and static
analyzers represented by the abstract syntax tree, I don't think that's
enough to warrant building one into the other (it might argue for
having a shared pars
"McGovern, James F \(HTSC, IT\)"
> I have been noodling the problem space of secure coding after attending
> a wonderful class taught by Ken Van Wyk. I have been casually checking
> out Fortify, Ounce Labs, etc and have a thought that this stuff should
> really be part of the compiler and not a
Katholieke Universiteit Leuven organizes an intensive course on secure
application development for experienced software practitioners, in
partnership with Solvay Business School and L-Sec (Leuven Security
Excellence Consortium), from February 26th to March 2nd 2007.
The course is aimed at softwa
At 11:38 AM -0500 12/21/06, McGovern, James F (HTSC, IT) wrote:
> This does beg another question of should the community be helping the
> folks who design languages to build in security-oriented constructs that
> we can leverage instead of waiting for after-the-fact find-it utilities?
Language de
James,
Response below.
> I have been noodling the problem space of secure coding after
> attending a wonderful class taught by Ken Van Wyk. I have been
> casually checking out Fortify, Ounce Labs, etc and have a thought that
> this stuff should really be part of the compiler and not a standalone
I have a better idead. Stop using C++. Jeeze.
gem
-Original Message-
From: Robert C. Seacord [mailto:[EMAIL PROTECTED]
Sent: Thu Dec 21 20:40:35 2006
To: McGovern, James F (HTSC, IT)
Cc: Thomas Plum; Secure Coding
Subject:Re: [SC-L] Compilers
James,
Response be
13 matches
Mail list logo
