Developers, thank you!

This was our conversation during the train ride to #JavaOne:

Eric: How many people do you think will show up for our presentation?

Me: I don't know, maybe a handful. We have a pretty dense topic in #appSec for #microservices and I don't know if developers would care.

Eric: It'd pretty disappointing to present to only 5 people.

Me: If only 5 people show up, we will just take them out for a good lunch in the city. Better way to spend the hour!

So what really happened?

tl;dr - We had 2 standing room only sessions - with over 400 people attending our talk.

tl;dr - Developers care about security more than you think they do.

The long version follows:

Our agenda was to appeal to the developers who have dealt with or are dealing with a #microservices oriented re-platforming initiative in their organizations. We wanted to talk to them about two things - designing software for security and operationalizing security in devops. As we scanned developers into the session, we knew that the developers had an agenda too - their agenda was to understand what they needed to do to do the right thing, which is #writesecurecode.

In our two very interactive sessions, we validated that a few things.

Developers care about designing software right, and that applies to security too

Developers' interest in security has never been more. Of the 400 or so developers we polled impromptu:

• less than 5% had ever implemented a Cryptographic algorithm
• around 25% of them were able to spot common vulnerabilities in code
• most of them felt that they were responsible for application security

Our audience enjoyed the discussion around secure design patterns (also available here) just because this audience intimately understood that its not just about fixing defects - but its really about designing the software right.

Developers like efficiency, and that applies to security too

We spoke about many inflections points in the sprint cycle where developers could scan code for security to make a difference. The two that stood out for this audience were - "pre-commit" and "pre-merge".

Developers are already running functional tests "pre-commit". But the key here is that these are really "ungoverned" tests. No one is beating 'em up for these tests' results. They run tests-find bugs-fix bugs-run tests until they are content. Why not do the same for security? The idea of running "ungoverned" unlimited pre-commit security tests with Scout appealed a lot to our audience.

For developers, security governance is too late in the cycle to be effective. Security testing has to be inline within the sprint.

AppSec needs to engage and not enforce

When asked about who they'd want to turn to learn more about security - developers said - in-house security experts and online resources.

Developers are cramped for time with shorter sprint cycles and they want to know which vulnerability to fix and why. That's it. Google can't tell them that - but in-house security experts, who know the application and who can quantify the risk, can.

The bottom line is: If security can rely on developers to know a little bit about securing applications and developers can rely on security to know a little bit about building applications - the sum is definitely going to be greater than its parts.

Developers, thank you.

I don't think we say this enough. To those 400+ developers who interacted with us - Thank You.

Thank you for telling us that you share the responsibility for security.

Thank you for being open about your challenges with security.

Thank you for all the software that drives the world today!