Salesforce Security Blind Spots: Securing 3rd-Party Access

Full transcript below

Andy Montoya:

Hello everyone, and thank you so much for being here with us today. This is our fourth in our Salesforce Security Blind Spot series, and we’re so excited to have Kyle Tobener from Copado with us, along with DigitSec CEO and Founder Waqas Nazir. And without further ado, I’ll go ahead and pass things off to these two security experts to introduce themselves and then kick things off.

Waqas Nazir:

Thank you, Andy. Welcome everyone. I appreciate everybody making the time to join us today. My name is Waqas Nazir. I’m the founder and CEO of DigitSec. We’re a cyber security company in the Salesforce ecosystem and help companies address security needs within Salesforce. And really excited to be speaking with Kyle Tobener from Copado, who’s the Head of Security, and I.T., and like him to briefly introduce himself.

Kyle Tobener:

Hi, Waqas. Yes. Thank you. So, like you said, I’m currently the Head of Security at Copado, and prior to that I spent 10 years at Salesforce on their enterprise security team. I was responsible for securing all the many, many Salesforce orgs at Salesforce.

Waqas Nazir:

That’s quite a challenge, I would imagine. Addressing security for so many internal orgs.

Kyle Tobener:

Yes, there were many, many, many, many orgs. So it was a scale challenge and also a depth challenge because we had some of the biggest Salesforce orgs in the world.

Waqas Nazir:

Yeah, so you’re probably quite familiar with complex security challenges. So we hope to learn from you a little bit today, in the short session that we have. So today we’re going to delve a little bit into the concept of 3rd-party security, delve a little bit into the supply chain within the Salesforce world, and maybe set the stage around what we should be doing as folks developing on the Salesforce platform to address the 3rd-party security challenges. What’s interesting is, like we saw last year was a big push towards addressing 3rd-party security. 

It was something that was always there, like a very understaffed department and many companies which would like basically to paper-based audits for vendors and for software suppliers. But we saw with SolarWinds; with Okta, like there’s a lot of concentrated effort now to address supply chain because we’ve seen practitioners often, dev environments and pre-prod environments and they’re target rich environments because people think that everybody’s concentrated on production. So, with that in mind, if you wanna maybe share some of your perspective around what you’ve seen within the Salesforce world around 3rd-party security; and then we can go into some of the specific areas around how to address it.

Kyle Tobener:

Yeah. So when I was at Salesforce very early days, I got tasked with building our vendor security function, which was our 3rd-party security function. And at that time, there really wasn’t a lot of attention in this space. When I looked around, you know, I had to talk to other people at large companies who had kind of had a headstart on Salesforce, and we were coming up with a strategy together, sharing in meetups how to do this. And now fast forward six, seven years and it’s exploded everywhere where supply chain security is a hot topic because we’ve seen major breaches occur. 

But I think it’s a really important area, especially for Salesforce, because Salesforce is not just an app that you run. It’s a platform and an ecosystem, and both of us are part of the ecosystem. We don’t work at Salesforce, but we are 3rd-party companies that interface with Salesforce. And there are many, many, many more, and not all of them are created equally. Some focus on security, some don’t; some introduce risks into your environment. So it’s important to understand how all of the interconnections between Salesforce and the Salesforce ecosystem work so you can secure your Salesforce org appropriately.

Waqas Nazir:

Yeah, and it’ll be interesting to see any Salesforce org that does not have a 3rd-party enabled solution, right? Like you said, it’s a platform. And by design the way companies use it is by extending it, right? Either they themselves create the 3rd-party integrations or they utilize a 3rd-party product off of their marketplace, and things like that. So speaking of the challenges with 3rd-party marketplaces, Salesforce offers app exchange, right? That is a rich marketplace of, I think, upwards of 4,000 solutions available to consumers. How easy is it for somebody to kind of just pick an app and install and start running with it in their org?

Kyle Tobener:

So at least in a Salesforce org, you do need elevated permissions to install packages. So not everyone in the org can install a Salesforce package, which is great. But, there are lots of them and lots of people will be requesting from their admins, “Hey, I want this package? Go get it.” So I think administrators and people who run the Salesforce environments need to have some kind of approval process in place to make sure that the packages that they’re adding meet the requirements of the org. Because there’s a wide variety of packages in the app exchange world. You’ve got the standard, fully reviewed… 

They’ve had a security review, they’re listed; those packages which can be small native packages all the way up to massive 3rd-party integrations. But there’s also lots of unlisted packages. Both those companies that have a primary listing may have lots of other packages that they can add on top of it. And there are people who just host unlisted packages on the app exchange and never go through the security review process and use their own external marketing to drive the installations. So understanding what you’re getting into when you’re installing a 3rd-party application is really important.

Waqas Nazir:

Yeah. Also what’s interesting is when you’re installing a package, you have the ability to limit who should be using this app, right? Sometimes we’ve seen that is overly permissive. Like if you have an application package that’s designed for subset of your users, exposing it to the entire user base, that’s not a good idea. So I think just having some control around what it is you are installing, but then who is the real end user for it is quite important. Because when an admin installs a package, they use their permissions, right? For the connections and the integrations and the APIs that get enabled for a specific application. What’s interesting and shouldn’t come as surprise to anyone is if it’s a Salesforce package, which has Apex in it, apex runs with system permissions.

So when you’re exposing a piece of code, you’re actually exposing the entire functionality of that piece of code to that user, right? Which has elevated privileges. So it’s important to understand that although you may be thinking that this is just a little widget that enables somebody to do something, there’s actually an opening up of further access to your entire system perhaps. Right? So have you seen that challenge and how do you think that can be addressed, especially with black boxed app exchange packages you don’t really know about?

Kyle Tobener:

Yeah, so that’s the thing is app exchange packages are a black box. The name space of the package prevents you from knowing a lot of what’s inside of it, especially the code. So when you get a package that’s gone through this security review process on Salesforce, that’s a point in time review, right? When that package was submitted to the security team. It looks for a lot of really fundamental things, lots of issues and tries to get them out of the packages, but then it’s only a point in time. 

That company that may be listing that package may have a lot of surface area that’s outside of the Salesforce app exchange. So you really need to understand the whole security posture of the company you’re bringing into your Salesforce environment. Because if it’s a one person company that is running a huge AWS environment that’s integrated and they don’t have the time or attention or resources to secure that AWS environment… Well, there may be some exposure to your Salesforce data versus there are some larger more security focused companies on the app exchange where you know that they have a SOC2 for example… That they’ve done the work to build up their security presence and you know that when they’re developing that code, they’re following security best practices.

But I mean, that’s an important thing to consider, for sure.

Waqas Nazir:

Right. Like you said, the vetting process is a point in time, right? And security is one thing that we know for sure that never is stagnant or the same. There’s a saying that you’re only as secure as the last time you reviewed yourself. Right? It is interesting that the attack surface that we’ve spoken of, outside of just that package is quite interesting, right? These solutions, like our solution included, interact with Salesforce outside of the defined parameters of that platform, right? What are some of these elements that somebody should be aware of when they’re creating a 3rd-party connection or integrating with a 3rd-party… what are the implications of this entire integration?

Kyle Tobener:

In the context of the app exchange, there’s a lot of focus on hybrid applications, which have some componentry in Salesforce and some componentry outside of Salesforce and native applications. And a lot of people would say native applications are perfectly secure because they only live in Salesforce, but that’s not always the case. I think one of the things about a hybrid application when it’s listed on the app exchange is they get a security review of the external components of Salesforce as well. People may not know that, but having done a lot of those app exchange reviews myself, we would do penetration testing on the package in Salesforce and the 3rd-party APIs and gateways that may exist outside of Salesforce versus when you have something that’s a hundred percent native, if it stays self-contained, great. 

But a lot of companies need the additional horsepower that comes with something like AWS or GCP or even Heroku that the governed limits of Salesforce can’t provide. So a lot of a hundred percent native packages have unlisted packages that they add on in order to add that horsepower with that 3rd-party integration. So if you have a 100% native package and then they offer you an unlisted integration package, just know that that’s not been reviewed by the Salesforce security team or anybody else. And it may not be as secure as something that is hybrid on the app exchange and has gone through that full review process.

Waqas Nazir:

Right. And I think there’s also the element of this hybrid solution, which requires you to integrate a 3rd-party in within the environment, right? And Salesforce enables that through what is called the OAuth connected applications, right? That is actually that, correct me if I’m wrong, is any user is able to do it because it’s using the user’s permissions. So whatever the user has access to, technically they can expose the same access to a 3rd-party, right? As long as you know, they have some [access]. So how can a savvy, security organization control that?

Kyle Tobener:

So this is really important to understand this distinction. So I’ll just clarify for everyone in the audience. App exchange packages get installed from the app exchange and into your org, then they may have 3rd-party integrations. OAuth integrations are that dialogue that you see that’s like, “Do you authorize this service to connect to Salesforce,” for example. And that doesn’t necessarily equate one-to-one to an app exchange package. Lots of companies out there have developed OAuth integrations for Salesforce that you can authorize that don’t come in through the app exchange and users, regular standard users, have the ability to attempt to do that OAuth authorization. There are security controls inside of Salesforce that let you lock down OAuth integrations. One of the most common is IP range restrictions. 

So if a connection request comes in from a 3rd-party that’s not within the IP range that’s on your profile, that might get rejected. So that’s a way that a lot of organizations control those OAuth integrations. But if you go into your connected apps inside of Salesforce, you can see all of the different OAuth connections that exist in your organization. And most people get really surprised when they look at their connected apps listings is there are probably quite a few they didn’t expect to see there.

Waqas Nazir:

Yeah. Also there’s the ability to limit which apps can be connected through OAuth. Because in the end that OAuth app is recognized by Salesforce, to some degree, because you have to generate a token on Salesforce. So some organizations have taken the approach where they’ve actually not allowed by defaults connecting apps and then they actually white list what can be connected. Actually it is a really good approach to addressing this issue. In addition to IP range restrictions… Because IP range restrictions actually help you just beyond the connection, right? It actually decreases your attack surface. 

So if you do trust, let’s say DigitSec or Capadlo, you only white list their ranges, right? So if somebody’s coming outside of Copado, you know, then you shouldn’t be talking to that particular app cause it’s probably a malicious request. So that’s another way to make it [less] like a Wild Wild West, right? Where folks are able to just use their own, “I’m just using my own permission,” right? And then “my own” sometimes is the admin. So it becomes quite interesting.

Kyle Tobener:

The OAuth-allow listing that you’re referring to is a really effective feature for controlling the OAuth connections and not enough people use that feature. Actually, I think one of the things that makes it challenging is you have to actually install the connected app into your org. But that extra layer of effort and sort of the administrative overhead that it requires does help control all the different apps that get connected. Which I think is a really good practice to maintain because when you actually look at your connected app history, you can see there’s so many connection requests from so many different 3rd-party applications.

And most of the time, what they’re trying to do, is export data from Salesforce and pull it into their solution to [provide] whatever value they try to provide their customers. But what that leads to is kind of the exfiltration of your Salesforce data to all these 3rd-party apps all over the place.

Waqas Nazir:

Right? That’s quite hard to trace as well, right? Because they’re typically speaking over API, so you won’t even know which…<chuckles> unless you’re doing event monitoring and things like that. It’s very hard to tell which app, took which data and where does it reside now, right?

Kyle Tobener:

Absolutely. Yeah.

Waqas Nazir:

So it’s very hard to kind of contain the data security around that. I think the other interesting element when it comes to 3rd-party security and Salesforce is this concept of securing your actual supply chain, right? With your dev pipeline. Would you talk about some of the challenges that exist in that and how companies should tackle them?

Kyle Tobener:

Yeah, this is a really interesting one because I think for Salesforce, in a lot of cases, the engineering team or the developer team for Salesforce is often walled off from maybe the developers that exist in the rest of the company. And I think even what we’ve seen at Copado is a lot of companies aren’t even using source control for their Salesforce code. It’s just living on someone’s laptop and getting uploaded in change sets, not integrated with GitHub or GitLab or whatever. 

So when you step out of that developer environment, one of the ways that a lot of developers have been advancing over the past few years is something called Software Composition Analysis, which is having tools, scanners, and things that look at not only the code that you’re developing, but at the 3rd-party libraries that are in your code that maybe have their own security vulnerabilities and ensuring that you are maintaining the most recent versioning and the not-vulnerable versions of whatever libraries you have included in your code. And Salesforce is no exception from this. Salesforce allows you to include 3rd-party libraries, mostly like JavaScript libraries are what a lot of people use inside of their Salesforce code, to do UI and things. 

And you know, jQuery can fall out of date, and you have to maintain it. You have to patch it. You have to make sure you’re using the latest version that doesn’t have any vulnerabilities. And I think this is a missed area of security that a lot of people in the Salesforce ecosystem don’t think about.

Waqas Nazir:

Also, like you said, it’s an area that people think Salesforce is sometimes not affected by. And that’s a very dangerous assumption, right? Like when it comes to security and if you couple that with the fact that Salesforce encourages packageless development. So typically with SCA you recommend that there’s no point in maintaining a 3rd-party package that you rely on, it’s better to reference it, right? So you’re always building with the latest version of that. But Salesforce, you know, recommends self-contained and not referenced, resources.

So if you wanted in a package to reference an external resource, you actually have to clear the Content Security Policy to say, “Hey, go to this 3rd-party and grab this resource and load it within my application”. So while that’s a security control to not allow every untrusted domain to load within Salesforce from a composition analysis standpoint, it becomes a bit more complicated.

Because now you actually have to, as part of your build process, or as part of your dev process is have some script that actually gets the latest version of whatever libraries you’re using and then build it into your pipeline and then deploy. So it is a multi-pronged challenge because of Salesforce being a platform and then this recommendation around getting package-based development and the control on the platform itself to ensure, you know, you can’t just reference evil sites, or whatever, within your domain.

Kyle Tobener:

You also make a really interesting point too about updating the Salesforce packages. I think Salesforce, a lot of people love it because it focuses so much on backwards compatibility. You know, there’s API versioning going back years and what we’ve seen at Copado is a lot of people will use very old versions of managed packages even 2, 3, or 4 years out of date. Which from you know, a stability perspective, sure. Not making changes to your environment maybe gives you the appearance of stability. But in this day and age, security patches should be a regular thing. 

You should always be updating and patching anything you can because companies are constantly releasing security fixes as they find security flaws in their code. So if you spend four years ignoring the packages, you know, package updates, that’s four years. You don’t know how many security updates were in those package updates, but probably a lot. And those should have been applied to your environment.

Waqas Nazir:

That’s a very good point. It’s like backward compatibility is not in line with the security objectives, especially with known issues which are available. Then another interesting element when it comes to Salesforce 3rd-party security is this unofficial 3rd-party packages, right? Which are not App Exchange, they’re basically nice, cool utilities that people have created open source projects for and many people contribute to it. Do you see that being a concern and what are some of the ways that we can look out for those? Because they are typically unmanaged. They sometimes don’t even have a name space and they may exist in your environment and maybe you are not even aware of it.

Kyle Tobener:

Yeah, so unmanaged code is essentially just as if you wrote the code yourself. You know, you put it in the org, it has no name space protection like you said. The name space is really important when it comes to protecting secrets, specifically if you have an API key or an OAuth token or something, because the best practice in Salesforce for protecting secrets is either named credentials, or what we call a Managed Protected Custom Setting. So if you have an unmanaged package that involves some kind of integration, for example, and it doesn’t use named credentials because named credentials aren’t the right solution for every situation in code, you could have secrets in your code, which is a really, really bad practice. 

That’s another sort of supply chain exposure. If you’ve got a password or an API key in your code to a 3rd-party anyone in the org who has access to the setup could go and find that password in the code.

Waqas Nazir:

Absolutely. I think you bring up another interesting point that sometimes people don’t realize is shared credentials to 3rd-party integration. So let’s say a vendor has not really thought through their integration and they put all their tenants on the same secret. So in essence, Salesforce is doing their part in making sure that they’re protecting your secret per se, but they’re not protecting your design, right? So if you don’t have per tenant secrets all your tenants have the same credentials. So if that credential is compromised somehow, not only does that tenant’s users have the ability to go to the backend, but actually they can impact cross tenants, right? 

So one tenant can look at the other tenant’s data or config, whatever that application does. So sometimes we see people make this big assumption that since Salesforce is going to protect my credential, if I put it in a protected custom setting then I can share that credential across all my deployments for all my customers.

That is a pretty dangerous scenario. So it’s important to generate per tenant credentials and secrets. So in the event that they might get compromised, even though Salesforce gives you named credentials and custom settings and things like that, you don’t have the exposure across them. So I think that’s an important element to understand when you’re integrating a 3rd-party. Like, “Hey, how do you manage secrets for your integration within your Salesforce package? Is it just secret for me or is it the same api?” 

So unfortunately some 3rd-party vendors don’t think of these attack vectors because they’re thinking that everything is self-contained in Salesforce. There’s no possible way to get to the credential. We don’t say, “Think about the one scenario that actually can happen.” It’ll be a pain to address that security breach, right? Not only do we have to contain it, but we actually have to go across how customers are actually generating a credential. So it’s gonna be a nightmare.

Kyle Tobener:

I feel like Salesforce has been releasing some features this year, some security features that were things I’ve wanted FOR-ever. So on the topic of shared credentials, one of the challenges we always had is if you have an integration user, a user in your org that’s specifically dedicated to 3rd-party integrations, really the best practice should be you have a unique user for every integration because you want to make sure that the permissions assigned to that user are only what the 3rd-party needs. 

So for example, let’s say you have Copado, and then you have DocuSign, for example, do you really want to give your DocuSign integration the same permissions you give Copado to deploy code? Probably not. You want DocuSign to just have access to opportunities and accounts where you’re doing your signatures, and then for Copado you don’t want to give Copado access to your opportunities or accounts.

You want to give Copado access to your metadata, but nothing else. So these separate accounts are important, but what I always heard from people was “Yeah, that’s great, but it’s really, really expensive. I need a dedicated user license for every single integration.” That is a huge bill. So earlier this year Salesforce released a licensed tier for integration specifically. 

That’s much, much cheaper. I think that’s a fantastic, fantastic feature because it takes out this negative incentive of the credentials for each 3rd-party integration. It now makes it much cheaper to dedicate the right level of permissions to every integration.

Waqas Nazir:

I think that’s a really good point. People should utilize that feature, especially if it’s an API connected app, there’s no reason why you not shouldn’t be using an integration license is they’re designed specifically to limit exposure within Salesforce. So a very good point. The other interesting element is in the roadmap for Salesforce is read only metadata versus, write. So we’re a vendor which only needs read access, right? Copado probably needs write access, but we, by design, have write access because Salesforce doesn’t allow it. 

That’s some of the things that Salesforce recognizes and then addresses as they progress their platform. If you are not utilizing them in the risk of the earlier point you made that don’t touch it. If it doesn’t break, don’t touch it, then you’ll may be missing out a lot on a lot of security features that can help you with 3rd-party security. I know we want to keep this session short and we’re at the 30 minute mark here. Before we start taking questions, any final thoughts or comments?

Kyle Tobener:

To your point, I think the world of Salesforce is constantly evolving. So we’ve talked about some of the new features that Salesforce has announced here. I think, you know, staying up to date on the latest security features of Salesforce is always a good idea for anyone watching this webinar. Even myself, I read the release notes every release, because I think there’s some really good, really security conscious people on the product team over at Salesforce and they are making advancements that I think are really good for the platform. And so hopefully, in another six months we could do another webinar like this and have a whole new set of things to talk about.

Waqas Nazir:

Yeah, absolutely. Andy, do we have questions or how are we looking?

Andy Montoya:

Yes, absolutely. So yes, I have one here. “What’s the best way or process for updating a package that hasn’t been updated in years? What things should I take into account?”

Waqas Nazir:

How do you wanna take that one?

Kyle Tobener:

Yeah, I mean it’s a complicated answer because if you haven’t updated it in years, you’re gonna probably expect some kind of complication. So using a sandbox, a test environment to do the update there first and running through your tests in that org. If you’ve got a testing solution like a functional testing solution, Copado offers a testing solution… not to pitch our products or anything… but you running your test suite and ensuring that everything functions the way you expect once you make that patch is critical because if you wait too long, two years is a lot of changes. 

There’s going to be something unexpected in that change, that’s where I like DevOps and the idea of continuous deployment because the more frequently you’re making changes, the smaller that Delta is, and so the easier it is to overcome those hurdles. So I think it may seem counterintuitive, but I think more rapid patching can lead to better stability because you make the hurdle much smaller to jump over every time.

Waqas Nazir:

Yeah, and I think one point that I can maybe add to this is sometimes versioning up many releases is hard, but versioning up if it’s four releases taking it in steps is easier because typically companies or packets, 3rd-party developers say, “Hey, we have compatibility for the latest in the last two,” right? 

So if you’re not in the latest in the last two, chances are it’s going to be a lot of headache for you to version up to the latest one. So sometimes it makes sense to break up the upgrade to a lower version first and then version up depending on if you want to take the chances and version up and then try to troubleshoot it with the vendor. That’s another approach that we’ve seen that can work well.

Andy Montoya:

Sounds great. Thank you guys. Absolutely. And yeah, we got another one here as well. “Is there a good security checklist to go through when connecting a 3rd-party app?”

Kyle Tobener:

So oftentimes if you are at a company that has a security team, they have a process for new third parties. So I think it depends, it always is, in my opinion, relevant to check with your security team and say, “Hey, I want to bring a new 3rd-party in. What are your requirements?” I think most commonly looking for signs of security maturity can be important. 

So SOC2 or ISO 27001, for example, those are security certifications that show that a company is invested in a baseline of security controls. And so working with companies that invest in those levels of security, I think is a good practice. But if it’s an unmanaged package, for example, that you want to add into your org, if you have some kind of security scanner that can look at that code and look for any vulnerabilities in that code, that can be a good first step too.

Waqas Nazir:

I think the question kind of alludes to this… Not having this requirement is a red flag. So if you’re thinking about “What should my requirements be to onboard a 3rd-party?”, then if the answer is, “there’s no requirements” that’s a red flag. But if you do have, like Kyle said, a security team, which actually has some protocol around, “Hey, if you want to onboard a 3rd-party, this is what we should collect from them to ascertain whether they’re secure or not,”  then you’ll be in a better spot. But what’s interesting and what we’ve somewhat realized is sometimes when you’re onboarding a 3rd-party on top of a 3rd-party, there’s an abstraction layer, right? 

Salesforce in itself is a 3rd-party, right? So some people think that since we’ve onboarded third Salesforce already anything above it is it’s kind of okay. And the whole concept is that every 3rd-party, even if it’s on top of a 3rd-party, should be considered a 3rd-party, right? You should have the same rigor that when you brought in Salesforce you did. “This is a 3rd-party that we’re giving our data to. So here’s another 3rd-party within Salesforce, but we still have access to some of our systems and data.” So that’s important.

Andy Montoya:

Thank you gentlemen. All right. We have a couple more here. Next one up is, “Can I set up security checks as part of the DevOps lifecycle?”

Kyle Tobener:

You can. So to set the stage here, by default, Salesforce has just released their DevOps center, which has a very light, sort of DevOps approach to deployments to Salesforce. But there are other tools. You know, I work at Copado, there are others out there as well. Maybe you’ve built your own using something like Jenkins. So theoretically you have set up a deployment process, a DevOps process to get code moving from lower environments up into your production org. 

If you haven’t done that, then I’d say that is the first step is just even having a DevOps process to begin, with getting your source code checked into something like GitHub or GitLab. There are lots of security tools built into the big Git providers that just give you a step up from nothing. But once you have that pipeline of moving code from lower environments to higher environments with whatever tool you have, then yes, most DevOps tools have hooks that allow you to bring in different kinds of checks into your deployment process, be it security scanning on the code, or potentially compliance checks on the metadata.

These can be really important features to ensure that changes going into your environment meet a baseline set of requirements. So for example, one metadata check I think is really important in this day and age is if you have a community, for example, like a customer portal… Making sure that you aren’t exposing records on the community license; or the community permission set or the guest user permission set that potentially could expose data very broadly. 

So Salesforce, there’s been a lot in the news about Salesforce and sites’ guest users and community users exposing data. So you can actually do checks like that in your deployment process to ensure that no changes are made to those permission sets.

Thank you Kyle. And then we got one more here. “How to manage in DevOps, CICD, or is it possible to do it?”

I think that’s kind of an extension of the question we are just talking about. So by default, Salesforce has a brand new thing called the DevOps Center, which is kind of like DevOps light. It’s got a limited number of in integrations to GIT providers. If you are a larger Salesforce environment and that doesn’t work for you, your options are either go with a, a 3rd-party provider like Copado that offers a robust DevOps solution, or you can build your own with something like Jenkins, which is another solution that people use sometimes.

Waqas Nazir:

Yeah, and I think, like Kyle mentioned, these automations actually help you to do things consistently. For example, if you had built a control in your pipeline and you were actually rigorously following that pipeline, sometimes people just say, “Hey, stay away. It’s a fire drill.” But if you consistently follow that pipeline that you’ll define, you can actually implement consistent checks, right? 

That’s the whole purpose of putting in DevOps, every time you ship, you ship the same to the same standard. So security actually should be addressed within the DevOps pipeline. In the best possible way because you can define the security checks that you want as part of your DevOps pipeline, and they will get deployed consistently across every change. Then there’s the other thing that we talked about before which was “you’re only as secure as the last time you were reviewed.” 

You are also only as secure as your last change that was reviewed. So even a small change that you are adding to your environment can have security implications. So it’s important to do things uniformly. That’s where companies like Copado and the Salesforce DevOps Center can help address those challenges.

Andy Montoya:

Sounds good. Gentlemen, thank you so much. And with that, I don’t see any more questions, so I think we’re good to wrap up. And are there any final parting words before we go?

Kyle Tobener:

Thank you all for all the questions and thank you for listening.

Waqas Nazir:

Yeah, thank you Kyle for making time. Appreciate your insights and your experience. So hopefully our, audience was able to learn how to address 3rd-party security within Salesforce, so you know, food for thought for them.

Kyle Tobener:

Great conversation. Thank you.

Andy Montoya:

Sounds good. Thank you all.