> 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 c...@veracode.com -----Original Message----- From: Jim Manico [mailto:jim.man...@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 > c...@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 _______________________________________________