On Thu, 7 Jun 2007, Michael Silk wrote:
and that's the problem. the accountability for insecure coding should
reside with the developers. it's their fault [mostly].
The customers have most of the power, but the security community has
collectively failed to educate customers on how to ask for
Hi Ken, welcome back from your sunny vacation. I wanted to reply to your
'invitation' on my thoughts for the next big thing:
One technological problem I have with secure programming is testing. I
cannot seem to stay on top of the latest methods of attacks and yet ask for
more billable time
and that's the problem. the accountability for insecure coding should
reside with the developers. it's their fault [mostly].
The customers have most of the power, but the security community has
collectively failed to educate customers on how to ask for more secure
software. There are pockets
McGovern, James F \(HTSC, IT\) [mailto:[EMAIL PROTECTED] writes:
the value of tools in this space are not really targeted at developers
but should be targeted at executives who care about overall quality and
security folks who care about risk. While developers are the ones to
remediate,
--- the software should work and be secure (co-requirements).
And already we have trouble, because this immediately raises not only
the question what does `work' mean? but also secure against what?.
And answering that correctly requires input from the customer. Which
we (TINW) won't have until
And answering that correctly requires input from the customer. Which
we (TINW) won't have until customers recognize a need for security and
get enough clue to know what they want to be secure against.
I can't exactly agree with this as there is a distinction (or should be
IMO) between security
And answering that [secure against what?] correctly requires input
from the customer. Which we (TINW) won't have until customers
recognize a need for security and get enough clue to know what they
want to be secure against.
If you are asserting that the customer must tell you how many
inline
On 6/6/07, McGovern, James F (HTSC, IT) [EMAIL PROTECTED]
wrote:
I really hope that this email doesn't generate a ton of offline emails and
hope that folks will talk publicly. It has been my latest thinking that the
value of tools in this space are not really targeted at developers but
Hi sc-l,
This month's installment of my darkreading.com column focuses some much needed
attention on the bug/flaw distinction that I think we need to pay more
attention to.
In particular, many of you will recall the discussion of Javascript hijacking
that Brian Chess posted to this list in
On Wed, 6 Jun 2007, Wietse Venema wrote:
more and more people, with less and less experience, will be
programming computer systems.
The challenge is to provide environments that allow less experienced
people to program computer systems without introducing gaping
holes or other unexpected
On Wed, 6 Jun 2007, Wietse Venema wrote:
more and more people, with less and less experience, will be
programming computer systems.
The challenge is to provide environments that allow less experienced
people to program computer systems without introducing gaping
holes or other
I've recently been working on providing better secure programming
defaults. There's a great opportunity for doing so for applications
written on top of frameworks/libraries.
See our paper Towards Security by Construction for Web 2.0
Applications at a recent W2SP workshop.
-Ben
On 6/7/07,
12 matches
Mail list logo
