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 _______________________________________________