Why I chose Contrast

As many of you know, I launched and scaled the DevSecOps transformation program at Comcast for the last 5 years. Now it's time to transform myself, and I'm super excited about joining the Contrast team, but I want to take a few paragraphs to describe the core beliefs behind the program at Comcast because it helps explain why I chose Contrast.

1. Coaching and Toolsmithing, not Gatekeeping

We started by trusting development teams and empowering them to take ownership of the security of their products. We understood that security's role was shifting from being gatekeepers/police/auditors to toolsmiths and coaches. We made the right thing to do be the easy thing to do with our toolsmithing. We helped development teams pick one, maybe two, but no more than three DevSecOps practices to adopt in the next 90 days and then coached them to successful adoption on those before coming back and helping them pick another 1-3 practices for the next 90 days.

2. Learning by doing, not from compliance standards, the latest shiny tool, or expensive consultants

We created a tool named Greenhouse nominally to assist in scaling the coaching group to cover all the development teams, each getting a DevSecOps workshop or re-sync every 90 days. It also allowed us to gather practice adoption data to correlate with outcomes data in the research I describe below.

However, the least appreciated value of creating and evolving Greenhouse is that it served as a platform for dogfooding the practices, tools, and policies our security organization was pushing down to development teams. I cannot tell you how many times an internal security leader or expensive consultant felt strongly about one particular practice, some security group acquired a tool they wanted development teams to use, or someone had a new or improved policy they wanted development teams to comply with. Before we coached teams on these things, we tried them out on our own development work in the form of Greenhouse. If it didn't have the easy button or didn't align with modern DevOps development, we could provide valuable feedback to the sponsors and avoid trust-destroying false starts. This "learning by doing" on our own development gave us deep insight into both the effort and value of each practice so each could be priority ranked in our coaching. See, our duty was not just to do good things. Rather, our duty was to see that the practices with the best return on investment were adopted first.

3. Immediate feedback directly to the developer for learning, moreso than remediation

We would refuse to run scans for teams. Rather, we helped them integrate DevSecOps tools directly into their CI/CD pipeline, which often required helping them mature in basic DevOps practices and sometimes in helping/motivating them to create their first CI/CD pipeline. We surfaced all feedback as branch protection status checks in the pull request, so developers had to resolve findings on the code they wrote this morning before it is merged into the next higher level branch in the afternoon. We would help teams understand findings, often by showing where to click to see a lesson on that particular finding so they could self-service on learning going forward. See the pattern? It's more about learning how not to write vulnerabilities in the future. The current finding is mostly just a hook to motivate and make the learning sink in. As any teacher knows, the immediacy of feedback is key. For students of learning theory, this approach maximizes the situated, social, and distributed cognition elements of contextual learning for developers.

4. Visualization and research to improve the program and persuade leaders to change their priorities, perhaps moreso than as feedback on the team's performance

A significant portion of our toolsmithing involved pulling the findings from many sources and rendering them into a single visualization that teams could use in their planning and as feedback for their performance. We also used these visualizations to engage leaders in supporting the program into their part of the enterprise.

However, perhaps the most valuable use of the data is that it enabled research to identify patterns, like which tools and practices were conducive to the best resolution curves or which areas posed the most risk so that we could incorporate that into improvements either to tooling, coaching, training, etc. I published the findings from some of this research at RSA 2020 with my Impact of DevSecOps Quantified talk. Some of that research challenges the status quo, giving us evidence to persuade leaders both inside and outside of Comcast to change their thinking. Other parts of the research quantified the effectiveness of commonly recommended practices, giving leaders the confidence to move forward more rapidly with the most effective ones.

5. Gamification, rather than cajoling

As I left Comcast, we were days short of launching a new gamification system modeled after Jennifer Czaplewski's PI program at Target. This system brings all the qualitative and quantitative data together and takes the team's context into account to recommend the next actions to improve their score. It also serves as an internal marketplace for security groups to get development teams to pay appropriate attention to their group's data, weighted against the data from other security groups, and aggregated into a single but drill-down-able score. The early feedback was very positive, but I can't wait to see how much it changes things at Comcast, particularly how much less effort security teams spend cajoling development teams to pay attention to their data.

My next big thing

I knew I wanted to get back to the vendor side and the startup world, but only a few vendors align with my dev-first vibe. In the end, there was only one place that would allow me to leverage my experience at Comcast, continue to empower development teams to take ownership of the security of their products and allow me to continue to learn and grow.

That place is Contrast.

Let's take the list above one at a time.

1. Coaching and Toolsmithing, not Gatekeeping

"Coaches and toolsmiths, not gatekeepers" is a phrase I adapted early on from none other than Jeff Williams, co-founder, and CTO of Contrast.

2. Learning by doing, not from compliance standards or consultants

I have to build stuff. Whether it's an outdoor kitchen, a tool like Greenhouse, or an open source project. That's just who I am. Jeff Williams is one of the first leaders in the DevSecOps community to which I showed Greenhouse. Being an open source developer himself, he has long been aware that I'm the author of a dozen or so open source projects, one of which gets almost 1M downloads per month. Contrast is also aware that I have the start of an open source effort named MatrX under development that serves much the same purpose as Greenhouse. Right from the start, it was clear that Contrast wanted me to continue that. I believe it's necessary to make sure that what I preach is practicable. Besides, I try out every possible DevOps or security tool on my open source projects, allowing me to have a deep insight into the tool landscape and learn from others. Good ideas can come from anywhere... especially competitors, and Contrast should benefit from my input on product decisions as we advance because of this intentional learning.

3. Immediate feedback directly to the developer for learning, moreso than remediation

The first demo I saw of Contrast Assess over 4 years ago showed feedback going directly to the developer as she tested her application. I never had to remind Contrast reps of our dev-first approach like I had to do with most other vendors. That was the default and still is today at Contrast, even as both Contrast and I have gotten better at persuading traditional security practitioners into this way of thinking.

4. Visualization and research to improve the program and persuade leaders to change their priorities, perhaps moreso than as feedback on the team's performance

I'm known for saying that SCA tools (aka "analysis for code imported") are 10x-20x better bang for the buck than "analysis for code written" tools like SAST and IAST. The ROI for the bad guys is better, they are less expensive, and they are highly accurate when equipped with reachability or execution analysis like WhiteSource's, Veracode's, or Contrast's SCA offerings (but surprisingly not Snyk's or most others'). Until recently, I used to add to that list that they also represented a bigger attack surface because they often make up 80-90% of the application. Jeff Williams has been telling me that was off for some time now, but Contrast recently published the State of Open Source Security 2021 report, with the research to prove it. It turns out that even when 80% of the application is made up of open source code, only 32% of the actual execution is in that open source code. That's the kind of research I want to help create -- the kind that changes my mind and those of the industry!

5. Gamification, rather than cajoling

I've long been a fan of the attack tracing approach that Shannon Lietz at Intuit has been talking about for some time now. Whether or not Contrast ever releases a gamification product or functionality, Contrast, with our RASP product, is one of the few vendors with the ability to gather attack data which is critical to gamifying the right things.

Contrast is going to win

All of the above is very much about who I am and where best do I fit, but that only captures a part of why I chose Contrast. There are no guarantees, and many boats are rising in this DevSecOps wave. Still, the bottom line is that Contrast has the people, products, next-up roadmap, and market position to come out on top of the DevSecOps tool market disruption that’s really just starting. Everybody wants to be part of a winning team, and I believe that Contrast will win!