Re: InformIT: comparing static analysis tools

[Chris Eng <ceng () veracode com>]

> Please note, it's trivial to convert bytecode to source code in both the
> .NET and Java ecosystems. This distinction feels more sales centric, but
> is not technically correct, IMO.

You can convert bytecode to something that will recompile (usually) but you can't truly renerate source code.  Code 
comments aren't preserved, for example.  And if the project wasn't built with javac debug info on, you get even less.  
This is a subtle difference, but an important one.  I understand where you are coming from, though.

I suspect -- having pen tested many a corporate network in my time -- that we protect customers' IP better than they do 
on their own internal networks.  Oh, the irony.  :)

I think Chris Wysopal's reply hit the nail on the head though; we've been vetted by countless customers and a number of 
three letter government agencies, and we've always managed to overcome objections.  I believe people will become more 
comfortable over time, as cloud services become more prevalent.  A decade ago, some companies were afraid to let you 
pen test their web apps!  



Chris Eng
Senior Director, Research
Veracode, Inc.
Office: 781.418.3828
Mobile: 617.501.3280
ceng () veracode com 


-----Original Message-----
From: Jim Manico [mailto:jim.manico () owasp org] 
Sent: Friday, February 04, 2011 11:34 PM
To: Chris Eng
Cc: Chris Wysopal; Secure Code Mailing List
Subject: Re: [SC-L] InformIT: comparing static analysis tools

Hello Chris,

Thanks for replying!

I think the reaction from "my boss" was not so much knee-jerk, but a
reasonable concern. The risk of persisting intellectual property on a
cloud service is real. And that risk differs depending on your business
(as well as many other factors). I'm eager to see vendors like Veracode
publish more assurance evidence, especially around how they write
software (I'm a lot less worried about the infrastructure in play, that
is pretty much a solved issue. Building secure software is not).

I published an OWASP Podcast with ChrisW recently
http://www.owasp.org/download/jmanico/owasp_podcast_80.mp3 and frankly,
I was impressed. The only issue that I thought was NOT answered in depth
was regarding software centric assurance evidence - especially since
that is your core business.

> (automated scanning plus manual penetration tests, multi-factor
authentication, extremely granular roles and access controls,
per-application backend encryption of results, flexible retention
policies, etc.).

Now this is a great start. I'd like to hear more. How do you do data
contextual access control? How you do key management for backend
encryption?  Are you encrypting db backups? How do you do input
validation and contextual encoding? How do you ensure that all queries
are parametrized/bound? Etc..etc... Perhaps we can get one of you on the
show to discuss how YOU write secure software, and how you prove that to
your clients? Assessment is interesting, but lessons in "building
security in" is much more important to our industry right now, IMO.

> First, the customer needs to understand that they are NOT, in fact,
uploading their code.They are uploading binaries -- compiled code, or
bytecode -- not their source.

Please note, it's trivial to convert bytecode to source code in both the
.NET and Java ecosystems. This distinction feels more sales centric, but
is not technically correct, IMO.

Regards,
Jim



> I'm not the Chris you posed the question to but I'll answer anyway.  :)
>
> Usually the type of response you described is a knee-jerk reaction.  It's a different model than people are used to, 
> and sometimes people are averse to change, whether that's warranted or not.  It's important to get past the initial 
> reaction and actually have a substantive conversation.
>
> Naturally, we try to understand each customer's specific hang-ups, but generally speaking there are a couple of 
> things we always cover.  


> Viewing this with a wider lens, there are a lot of factors involved in selecting a tool/service vendor.  One factor 
> that comes into play for us is simply that our solution scales, and many others do not.  We can address the 
> application supply chain problem in ways that others can't.  
>
> -chris
>
>
> Chris Eng
> Senior Director, Research
> Veracode, Inc.
> Office: 781.418.3828
> Mobile: 617.501.3280
> ceng () veracode com 


_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________