How to Win over that Elusive Developer with Adhiran Thirmal

Micro Focus Contributor
Micro Focus Contributor
2 0 1,687

Micro Focus Fortify is proud to be the exclusive sponsor of the TestGuild Security podcast hosted by Joe Colantonio. This weekly podcast, dropping every Thursday, aims to be 30 minutes or less, interview-style series speaking with some of the top Security Testing experts in the field.

How to Win over that Elusive Developer with Adhiran Thirmal.jpgThis episode of the TestGuild Security Podcast, How to Win over that Elusive Developer, features Adhiran Thirmal. He is the Security Solution Architect for Micro Focus focusing on the Fortify and WebInspect product suites that cover Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). This interview gives you tips on how to get your developer on board with your security testing efforts by better understanding some conflict resolution styles. Discover the key to implementing a successful application security testing program and obtain the buy-in of your developers, DevOps, and architects. Here are some highlights from the interview:

Overview of conflict styles and how it relates to security

AVOIDING: “Avoiding ultimately is kind of that classic ‘do nothing approach’. (…) A lot of organizations unfortunately run their security program this way as well, where they just do not really start off anything when it comes in towards security itself within their application development. They just hope that it'll happen. But realistically, this is kind of a lose/lose situation. The developers are typically lost because they don't really know what a security team is trying to expect out of them. And there's just a lot of miscommunication. And ultimately, this just results in pure chaos.”

ACCOMODATING: “Accommodating is more of a style where ultimately, it's a bit of a lose/win. You feel as though you want to give up something so that the other individual would win. In the case of application security, the way that this transpires is security programs ultimately let developers do whatever they feel like. (…) We obviously do want to win over that elusive developer and we want to get some of their buy-in, but they need some guidance (…) As we all know, as developers, there're so many things kind of going on within the developers’ heads.(…) And so unless security is top of mind and unless there is a bit of guidance in terms of ‘this is how you perform security in a proper mechanism,’ accommodating kind of takes over and developers just again create a state of chaos.”

COMPETING: “Competing is probably the most interesting style to see. Typically, the way that this elicits itself is a competing security program will ultimately shove security down their developers’ throats and they’ll shove security down, you know, to various other stakeholders (…) So with this combativeness, you have this notion of win/lose, where ultimately the security program will win and the developers and the development teams will lose. (…) A lot of times this competing scenario really comes through after an attack has transpired. (…) and security becomes top of mind. (…) If you get into a competing scenario, you might achieve security. But it's only in the short-term because ultimately, you're going to be sacrificing things that you might not actually see as a security team.”

COMPROMISING: “This is ultimately a lose/lose. You realize that the developers need to be at a certain barre, and you don't actually really negotiate getting towards that particular state. (…) This is a really tough scenario because the developers lose, the security program loses, and again, this ultimately lends itself to a state of chaos. (…) It’s a recipe for disaster. (…) I think, honestly with compromising, it’s a bit of a temporary state. You will typically fall in towards one of the other for conflict resolution scenarios fairly quickly. It's just a matter of that temporary approach.” 

COLLABORATIVE: “This is Nirvana state. (…) Just like any relationship that's out there is you start by listening. (…) So, from a security program perspective, what's going on with that elusive developer? What do they care about? What's top of mind and how do you actually invoke some change within what they're actually doing? (…) Through collaborating, ultimately, you create a true win/win situation where the developers get the time to do what they need to do, but they also get some time to focus in on some of the other aspects, like security. (…) One of the things that I thought about when it comes to the elusive developer is, typically a lot of illicit developers are gamers, they might not all be gamers, but some of them are. And this might be a perfect opportunity. So, as you are sitting at home on Fortnite or whatever others game that you might be playing currently, that might be a perfect opportunity. Maybe you ask that elusive developer: ‘hey, what are you playing during this time?’ (…) You can actually talk to your developers (…) and some stuff will actually kind of come out and surface. Once you build that relationship and you start listening, you're going to start to understand what the developer is worried about, what they're focusing in on. And you have the ability to ultimately influence what they're going to do. (…) If you don't actually just shove security down people's throats, but you influence them to be able to actually introduce security into their own programs, you have the ability to kind of guide them through creating appropriate metrics, through creating appropriate advice, so that you get your developers to focus on what you need to worry about.”

What’s the ideal scenario for your organisation’s security analysis?

“Ultimately, the nirvana state is where security is just embedded in. Developers stop thinking about, ‘Oh, I forgot to do security, let me go to the security team, let me run, you know, whether it’d be security tests or getting a security approval.’  (…) The ideal state is as developers are actually writing code, (…) there are some integrations in place to be able to provide that feedback (…) Ultimately, you want to be able to get security as early as possible. (…) Security teams are able to implement test and implement measures to be able to assess risks and then be able to mitigate them at a fraction of the cost that it would cost if you were to mitigate issues within production or even right before a feature is about to head out the door.”

About software composition analysis

“One of the big things that I think is coming up with security programs is a lot of times code isn't necessarily fully, completely developed within an organization. Sometimes code is brought in. Whether that be a third-party library or whether that be an open source component. And a lot of times your risk comes from those specific components. And there are a number of software composition analysis tools that are coming out to the market which allow you to be able to identify issues within those components and be able to figure out which particular version of that component is free from security vulnerabilities.”

Make sure to listen to Adhiran Thirmal’s full interview, How to Win over that Elusive Developer! 

About Micro Focus Fortify

Fortify offers an end-to-end application security solution that secures and protects code throughout the entire development lifecycle of any type of software—from development to testing, release to production and every iteration in between. Fortify static, dynamic, interactive, and runtime security testing technologies are available on premise or on demand, offering organizations the flexibility needed to build an end-to-end software security assurance program.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.