This is the second post about our 2012.2 release. On February 29, Veracode released its second service update of 2012. Our 2012.2 release has a bunch of features aimed at simplifying a variety of parts of rolling out and engaging users in an application security program, including provisioning users, working with flaws on the desktop, and getting developers engaged in the process of fixing security issues.
Yesterday I discussed how Veracode's new Best Practices scans give a "green light" to developers when we find that they've successfully used security best practices--providing a more friction-free introduction to static scanning when rolling out to lots of development teams.
Today I'd like to highlight two more ways our latest release removes friction from the rollout process - automated self-service provisioning, and Veracode's newly updated Visual Studio plugin.
When you're scanning hundreds or even thousands of applications, and rolling out a security program to thousands of developers, it's important to think about eliminating friction from every interaction that developers and program leads have with the service. That caused us to focus attention on single sign-on last summer. Powered by SAML 2.0, the Veracode platform can defer to a customer's SAML compatible identity provider to authenticate a platform user. We've even got technology partnerships with Symplified and Ping ID, two leading SAML-as-a-service providers, to make getting single sign-on established as easy as possible.
But that still leaves the question of getting users provisioned in the first place. How can we tell what authorization rights a given single sign on user should have? Must the customer wait until they get an extract from their central directory or establish some sort of automated provisioning workflow? And, with the slow progress on the Security Provisioning Markup Language, have we no hope of getting a standards based solution to this problem?
Fortunately, there's a better answer. While SPML hasn't exactly lit up the world, many cloud providers are already using SAML with some simple lightweight extensions to drive automated provisioning. Veracode has added this capability in our 2012.2 release. A customer can add optional attributes to the SAML assertion providing required data like first and last name and email address, then can tell the Veracode platform to provision any previously unknown users as full Veracode platform users based on the contents of their sign-on assertion. The customer can even opt to assign default roles and permissions or approve each user when they attempt to sign in for the first time. This model, the same used by SalesForce and other cloud companies for user self provisioning, enables customers to rapidly provision developers simply by having them click a link. We've seen one customer roll out in this way to over a thousand developers in just a few short weeks--all without requiring the customer admin to do any heavy lifting. And it will be just as easy to add the next thousand.
Last but not least, there's an additional perceived friction point with asking developers to log into the Veracode platform. "Developers shouldn't have to use the Web to do their jobs," says this line of thinking. While this line of argument is incredibly patronizing to developers--how many developers do you know who aren't in the web browser at the same time they're writing code?--there certainly is some value to having security information in the IDE. Now with the latest updates to Veracode's IDE plugins, as of the 2012.2 release, it's now possible to perform virtually every part of the Veracode static scan workflow--creating an application profile, compiling, uploading files, starting a scan, checking results, and viewing call stacks for individual flaws--from within Visual Studio. This allows developers to stay focused on writing code but still allows them to get all the benefits of Veracode's full-program static scanning. An update to our Eclipse plugin that adds support for many of these features is coming soon! Stay tuned!