In today’s digital landscape, the implementation of robust security tools is crucial for safeguarding our systems. One such vital tool is the SCA (Software Composition Analysis) tool. As businesses increasingly rely on these tools to fortify their cyber defenses, the challenges and intricacies of implementing them come to the fore.
In our latest discussion, Oscar invited Farshad Abasi, the CEO of Forward Security, Ingeborg Carr, and Kelly West. Together, they unravel the challenges faced by marketing and security professionals alike when it comes to getting their tools and software accepted and implemented across departments. From building relationships to understanding the technical nuances and the importance of human touch, this dialogue offers a comprehensive overview of the journey to integrate an SCA tool successfully.
Stay informed, invest in the right tools, and embrace emerging technologies to stay one step ahead of cyber threats.
How to get your SCA tool implemented - Video Transcription
Oscar: Here we are again with MergeBase, and we are also very happy to have Forward Security as a guest.
Quick introduction. So, my name is Oscar van de Meer at MergeBase. We have an external guest, Farshad Abbasi, the CEO of Forward Security. They provide a suite of AppSec tools and have a lot of expertise. We have our fractional CMO, Ingeborg Carr, also of Altair Strategic Marketing. And then, last but not least, our new CTO, Kelly West.
I think marketing people have the same problem as security people.
How do you get time from other department resources to help you implement your product?
Farshad: So, you know, oftentimes, we operate in the application cloud security space. And the tools that we often implement in their environments are things that are related to the development pipeline.
As you can imagine, we use tools like MergeBase and other scanners, we bundle them, and we help the development team put that in their pipeline. So, right off the bat, certain access permissions are required to those pipelines where they can actually go and edit them. And then beyond that, what they need to do is in order to security work on them, use these tools, they need to create the right groups and roles in their environment.
So, let’s say, for example, a client is using Azure or AWS; then we need to create a role in their environment that the tool can assume and do certain things that the tool needs to do. So, right there, you’re now dealing with having to change permissions in their DevOps pipeline.
So if they’re using Jenkins or Azure DevOps or whatever, you’ll need to get an administrator involved so that lets you know that that person can let that person edit those pipelines. Often, that is not going to be the engineer using that. And then you also need the person that holds the keys to the identity service. Identity access management service.
In many organizations, that would be the team that manages Active Directory, or in organizations that use Google Identity, that would be the team that manages that identity. So, it’s often a central IT team or an operational team.
So now you’ve got your DevOps team involved who needs to provision permissions to the CI-CD pipelines or one of the pipelines. You’ve got the IT team that needs to come and give you access control, and then you’ve got the actual end user, who’s the developer that wants to just install this and start using it.
It can often be more people depending on how large the enterprise is. In smaller, medium-sized enterprises, it often ends there. But if you have larger enterprises, there often might be secondary approvers or other parties involved in that process. But that’s all in terms of the implementation and rollout.
What about before rolling it out? What about actually buying the tool? And then there are a number of parties that could be involved there in terms of who actually uses the tool, who approves the budget, and who signs off on it.
And again, in small companies, that could just be two people. It’s the end user, the engineer, and the CTO often. But when you go to a larger organization, the CFO has to approve it as well because of some budgetary constraints. And then you run into hurdles, not just from a financial perspective, like convincing them, but also prioritizing because many companies, especially in the current economic times, have a limited budget to work with, right?
So why would they buy the tool we’re talking about versus spending it elsewhere in their security? And the typical organization, you know, budgets for about 10% of their annual revenue for IT and then only 10% for security. So it’s like a really small fraction of their budget.
Oscar: 10% of 10%, basically.
Farshad: 10% of 10%, which is small, right? And that’s all they got to work with. So why should they buy MergeBase, Eureka, a product, or something else where they could spend that money somewhere else?
It becomes a way of prioritizing and really showing the management that, hey, this should be prioritized, and how do you go about it, right? So, one way is to take a risk-based approach to really say, hey, this is.
The risk that we’re going to face if we don’t implement this product, and then really prioritizing in that risk-based manner, saying, hey, this year there are six security initiatives in front of us, but these two pose the highest risk, right?
As we all know, the software supply chain and all the software security problems are at the front and center. So, really presenting that risk view to the people who are in charge of signing off on it will help the buyer be more successful in that journey.
Budget and Implementation
Oscar: Yeah, well, I think it has changed over the years. I mean, first talking a little bit about the budgeting and perhaps on the implementation, but on the budgeting a few years ago, I would spend a lot of time kind of helping people make a business case and essentially getting the importance of application security and software composition analysis across the foot line.
But that has kind of changed because we’ve seen that software supply chain attacks have increased tenfold over the last two years. So, a lot of organizations kind of are moving in that direction.
There are a lot of regulations coming as well, or are there already in a number of different industries? So there are also predictions from Gartner that I think in two years, 80% of companies will have a software solution in place.
So, the discussion on budgeting kind of is shifting a little bit. Yeah, the budget is one thing for the tool, but that’s actually not the total impact on the organization. Okay, now we have the budget for the tool, but it has a massive impact, potentially, these security processes on the productivity of our engineers.
And so that is becoming a much, much bigger concern. And so we’re having a lot of discussions on like the productivity features that we have in our tool that can really help organizations, you know, avoid, you know, negative impact on productivity. That’s the majority of the time I think, you know, that we are spending right now.
And then, once you get into implementation, you’re running into a lot of these issues that you mentioned. For instance, one of our customers has purchased SSO and still, a year later, has not implemented single sign-on because they needed to get a Microsoft Active Directory kind of administrator to perhaps do probably 20 minutes’ worth of work. But that can be very, very difficult if you don’t have direct control over that type of resource.
And we’re seeing similar things with potential; sometimes firewall changes are needed. We’ve had customers who installed new Kubernetes security features, and suddenly, a lot of things stopped working. And it takes quite a bit of time to fix.
So, it’s often little things that are difficult to plan for. Right? It’s not that we’re saying, okay, we need 2000 hours of somebody, and here, you know, is, is all approved. No, we need 20 minutes of somebody, and that can be more difficult than the 2000 hours.
Kelly: Sometimes it feels like a friend; he’s an application architect for Shopify. And we were talking about the challenges of putting tools like this in place. And given that all the, you know, the predictions from Gartner and all the trends are suggesting that the same way everybody has a firewall for network security, everybody’s gonna have to secure their software supply chain.
It’s going to be ubiquitous. But the path there is difficult for a lot of the stakeholders involved. He said he used this phrase, and it really resonated with me: “If you want to roll out a tool like that, especially in an agile shop where autonomy is spread out amongst a large number of teams, you need them to believe it’s not gonna increase their technical toil.”
Technical toil is the phrase he used that landed that this can’t be a tool that slows things down and just adds work. And so the critical part of things like, you know, SCA tools are not identifying all the vulnerabilities and creating a long to-do list.
It’s actually streamlining remediation processes and providing guidance, reducing false positives, and reducing that technical toil. But he also said, you know, you’re going to have to convince people of that. And so it’s a bit of a change management exercise that way.
Farshad: At a sales call, that’s the first thing some of them will ask is like, is this going to slow down our, our CI/CD pipeline? One of the clients was like, my developers pay attention to every second this thing takes. If this, like they measure the seconds, if this is gonna slow it down, they’re not gonna want this.
So, to your point, the tool needs to, you know, do a good job reducing false positives and really not be a hindrance to the agility of the DevOps pipelines, which is one of the reasons that we’ve come up with this platform is like, how do we make the results more valuable and how do we make the more results more meaningful and then be able to get the developer what they need in a quicker timeframe by correlating and aggregating all the issues that come from different data points and data sources.
But again, we need to convey that message to the people who are up above us. So, like as an engineer that’s going to buy this, you know, they need to understand, and then they need to convey that appropriately to the other people that are involved in that decision-making process.
Oscar: And it all sometimes feels that, on the one hand, security is kind of now accepted. Yes, we need to have strong security. But the fact that security needs to be an integrated part of work in progress, I think, is that kind of a way to describe it?
Farshad: You know, and I’d like just to add to that, like how many times, even when I was at HSBC, I go to the developers, and I’m like, oh, how’s it going with that SaaS or SCA tool that we bought you? They’re like, we turned it off. I’m like, why’d you turn it off? The answer was that it takes a long time to scan. And when it does, it produces too many false positives, right?
And usually, when I go to clients, I’m like, hey, if you want to be successful with this program, the number one thing you need to do is you, before you put this in your pipelines, you need to reach a baseline level of zero issues. So take that time and help do that initial cleanup. If you’re going to put MergeBase or any other SaaS or SCA tool in place, before you go into automation, run it manually and clean everything up so all the tech debt is removed.
Either the false positives were identified and excluded, or you fix them. Now you’ve got a baseline of zero issues; now you can put it in the development pipeline. So if tomorrow someone introduces a new vulnerability and I do a pull request, hey, that’s on me. I just checked in a new piece of code. It had a vulnerability. That one issue that’s found, that’s something I got to fix, right?
As opposed to how most companies are doing it, they just buy the tool, they put it in, and then it just keeps recording all the tech that. So every time the developer does a pull request, they’re getting 200 issues reported, and they just will stop using that tool, right?
Kelly: That’s right. And I think we actually faced some headwinds because people in this space might’ve been exposed to some of the open source tools or some of the first generation tools that were really good at creating problems and not really good at, you know, helping you fix them.
And they haven’t seen more sophisticated tools like Eureka or like MergeBase where actually, um, streamlining that remediation is the focus.
Oscar: Okay. I just want to briefly go back to kind of the implementation challenges that we continuously see. And I think that’s an area where we probably can learn a lot from our marketing folks because they’re struggling with this.
I think all the time, a lot of marketing initiatives require a little bit of time here and there from IT people and others. And so they seem to kind of always get that done. So, Inge, how do they get that done?
How to get tasks done
Inge: Great question. And I think a lot of people are always struggling with that. I have been a software developer, so I’ve been in the absolute tech world. Now I’m in marketing. And so I have bridged both worlds where I was very focused on just what was happening within my own internal technical department and looking to get things done that way and now living completely outside of it and indeed involving not only the technical people, the engineers on the team and then the organization, but sometimes also legal or products.
There’s always another person that we need to engage to get things done in marketing and to optimize our marketing strategy. For me, the key is balancing our tech tools, personalization with the human touch, and that emotional connection rather than just seeing it as a routine task.
The moment we see something as a routine task, we, as the ones asking for this task to be done, have the complete vision perspective of what it will do for the organization or will do for other people or our customers. But we forget that we may be solitary in that. And in today’s world, things are much more fluid. We were definitely in a digital age, and now we’re more in a social age where collaboration is key.
And I think it’s important to find partnerships identifying those people that not only do the process but can influence the doers. So, for example, what I find sometimes is the implementation of a key project, and it may be something a simple thing to do or smaller projects to implement like SCA or a big one that really crosses the organization.
I have found that successful implementation always hangs on to just a couple of people who actually need to put their fingers on the keyboard and actually get it done. So it is engaging those people. Making it more social, understanding their problem and their situation, talking with them, not only with our tech tools through email or chatting or whatever we have, but approaching it on a personal level and asking them questions and evolving them and making them feel in power and in control of the task that they need to do, but make them understand the bigger picture.
So explain the numbers, explain the threats, explain the situation if it doesn’t happen on time, and ask them, when can you do it? Okay, well, I can do it in six months. Well, we were looking for next week. What needs to happen to get this done next week and work with them and have a conversation with them about the issue.
And sometimes that is not enough. Sometimes, people say, no, I’m focused on this. And then it’s time to actually talk to those influencers and stars around them. And it may be their boss, but it may be a buddy on the team and involving them and, say, have a conversation with them as a group and create that enthusiasm and excitement, but also that you know what, this is really urgent.
We need to get this done. So approach it from that perspective, be respectful, and say thank you. I think that a little thank you goes a long way, and just involving them in the task of what needs to be done. Don’t make them feel, oh, I just need to get this done, and Oh, marketing is on my back, or oh my God, this engineer is on my back, or Here’s a CEO with another thing that I need to get done.
So give them context and make it personal. Yeah.
Oscar: So, basically the key message is don’t treat it like a routine task, and really, the human touch is important. Now, uh, you know, if I talk about kind of engineers and a lot of organizations have an agile development process, what I often hear is, you know, people come back to me and say, well, you know, uh, I’ve, we’ve asked this in this person to do something, and they just don’t do it or, or this vendor, like, you know, they’re not responding.
And then you ask, well, how did you ask them? Well, we sent them an email four weeks ago. Right?
Yeah. So I was wondering, Kelly, perhaps you can talk a little bit about how you can translate that human touch that Ing is talking about into an agile development process?
How to translate the human touch into an Agile Development Process?
Kelly: You know, Agile is implemented in slightly different ways in different organizations. But one thing that tends to be true is there’s a movement to push decision-making to individual agile teams. And so instead of having sort of centralized command and control and somebody says, please implement this tool, and that’s it, it flows down the command chain, it doesn’t work that way.
It has to go across all of these autonomous agile teams who need to decide to, if not implement the tool, maybe only one team needs to implement it. They need to incorporate it into their practices; often, in different agile teams with different responsibilities, different people need to do things.
And, so you take what Inge was talking about, and then you essentially multiply it by a number of agile teams, because in each case, you have to identify how it meets their needs, how it’s going to prevent technical toil for that team, how it’s going to be a fit for them and can help them. One thing that I’ve seen, I was just talking to one of our clients recently, and they have an agile team structure with about ten agile teams.
And the approach they took is that they went to one Agile team first. That team adopted the tool first and worked with the platform team that could implement it so that you had a direct relationship amongst the essential people right away. And then that Agile team became the example.
They used it actually for months before it rolled out to the other teams. And that way for the other teams, you know, they trust their peers a lot more than they trust probably management and vendors. And so when that agile team says, yes, we’ve done this, it’s good for these things, it works well this way. Yes, here are some challenges you’re gonna have to face down. We’ve done it this way; it’s working for us. And that’s a very powerful way to get that buy-in across the agile organization.
Farshad: I was gonna say, yeah, championing that. We’ve done that with a few clients. Like we have one client that had 30 DevOps teams, but we started with like a small handful. I think it was five, and we championed the processes with the five of them. Just to demonstrate to the larger organization how well it could work in using it as a reference so that the rest of the company could buy into it.
Oscar: That’s fantastic. Yeah. So Farshad, I mean, I think a big part of it is also creating some enthusiasm within the organization about it. So you seem to me like a guy who can do that very, very well. So what is your secret?
How to create enthusiasm in a Team?
Farshad: Well, I was just going to say Inge touched on a really important point, adding context and building relationships. And you also sent something about the emails. Maybe I’ll talk about the emails first, right? Because we all get hundreds of emails every day, right? It’s like stuff gets lost in my inbox.
So it’s not that I didn’t like you or didn’t want to respond to you. I just didn’t even see it. So if you send that one email, you’re like, oh, I sent the email four weeks ago. Chances are the person may not even see it. So usually, what you should be doing is maybe picking up the phone, or better yet, a happy medium is Slack or Teams, right? So what we do is build a channel so that you can have that real-time communication rather than an email that gets lost in the inbox. Just ping that person and have a chat, but also build a relationship.
Like I know at the bank, I’d have certain situations where I’d file a ticket for an IT change request, and it would take weeks, and no one would respond. You know what I did is I ended up meeting the people on that team and just building relationships with them. Once they got to know me, I needed whatever, it was done instantly. I needed that ticket; my tickets would get prioritized because I knew them, and I was a nice guy, right?
So it’s just like building relationships, not relying on email to get things faster, and then just championing things and setting an example. And then the other thing that Inge, you said is the context, really making people understand what the risks are, right?
Like a lot, even developers themselves, if I just go and say, hey, you got all these vulnerabilities, you got to fix them. They’re like, ah, why do I need to fix them? But when I go thread model it, I’m like, hey, here’s an attack scenario. Attacker does A, B, C, D, and then there it is. This, they can exploit this vulnerability. They’re like, whoa, okay, I didn’t know. But you bring that real-life context, you actually form it in English, and you present that threat scenario.
That makes a world of difference. And all of a sudden, it is real. They can touch it. They see, oh yeah, the attack step one, the passwords can be found from any breach password database. Number two, you don’t have this; you have this particular vulnerability that can use X, Y, and C and then exploit it.
And the outcome is every record in your database is now dumped into the public, right? That brings it, brings more context, and it makes it real. Hey, if we didn’t have the SCA tool or if we weren’t doing automated scanning or whatever, we could be missing these issues, and this is what could happen to us.
So, making it more real and adding context is a really good way to get buy-in for sure and build relationships.
Inge: And added to that, Farshad, I also think the context, indeed exactly what you’re talking about, like for the organization, but also for them. Don’t make them feel that they are at the bottom of the totem pole and they’re just an implementer.
Demonstrate how important their role is that we’re all even and equal within this organization and we all have an important role and function to fill. And the person you’re asking the question to do something is making them understand and make them feel that that’s the place you’re coming from, that this is important, you are important, and having that personalization, I think, is important.
” It’s all the human touch, building relationships, and bartering.”
Oscar: It’s all back to kind of even though we’re all dealing in IT, it’s all back to the human touch.
Farshad: The first thing my boss taught me when I got my first job, he was like, it’s all about relationships. Like he said, if in this job, if you want to succeed, you got to build relationships with the the development team. And then the other thing was he told me about the emails. He’s like, you know, don’t just send emails, message them, or call them. Because you know, you’re not going to get traction if you’re firing emails away.
Inge: But you also mentioned something very important earlier: reputation building. That’s how I would encapsulate it. It’s like you get if people start to get to know you and know you are not just asking something just for asking just to make their life more difficult and put more work into them.
But if they really know, hey, if so and so asks me something, there is a real reason. And I like working with that person. So, let me get this done. I think it is a very important thing. And added to that, too, is what I find, and I didn’t think I talked about that earlier; it’s bartering.
Sometimes, when the person says, but I got this and that on my plate, I don’t have the time right now. It’s like, okay. I get that we’re all crazy busy, and we’re just getting busier and busier the more we need to get things done.
So, what is on your play that I can take off or make it less of a priority that you think is a priority right now? Or what can I do for you, like me personally? Is there something I can do for you that will help you make your life easier type of thing?
Oscar: It’s all back to the human touch and building relationships, and you know, if needed, you bartering. So, hopefully, this conversation is helping our audience to get the projects across the goal line quicker.
And so especially when you implement application security tools, like advanced tools that, you know, for security and MergeBase are using, and they actually will help you with engineer productivity, but still you need to get a tool in place as well. So, I’m happy to have to have this conversation.
Thank you all very much.
