Name: Salesforce Security in 2025: Using DevOps to Ensure Speed and Protection
Uploaded: 2025-08-26T16:30:21.508Z
Duration: 1 h 2 min
Description: Salesforce Security in 2025: Using DevOps to Ensure Speed and Protection

Transcript for "Salesforce Security in 2025: Using DevOps to Ensure Speed and Protection": Good afternoon, good evening, and good morning, everybody. Welcome to this SalesforceBen webinar. My name is Peter Chittum, and I'm super pleased to be bringing you this webinar, sponsored by Flosom. This is Salesforce Security in 2025 using DevOps to ensure speed and protection. So if that's what you were hoping to listen to today, you're in the right place. Now here at Salesforce, Ben, everybody knows us, of course, by our amazing website where we have loads of great articles, both news related and technical related. But we also know that not everybody knows about the other things that we do. So we like to share about things like our newsletter that we have available. And we would if you enjoy this webinar, if you enjoy our content, why not sign up for that newsletter? It's the best way to get directly notified as to what's going on in the Salesforce world. We also have events and of course, some of our events are like this webinar, but we also do loads of events at in person Salesforce events. To that point, we have actually recently just opened up our registration for our Salesforce events that'll be taking place at Dreamforce this year. So be sure to check those out on the website. We also have a YouTube channel where we publish content virtually every day and a podcast which I will say is on hiatus, but at the moment, we're looking at, some new ideas for how to reboot that podcast. And with that, I'd like to go ahead invite our speakers today to come on to stage, including, we have Craig Idleman, Diana Martin, and Joe Morse. Just to go over, Diana Martin is the Salesforce platform director at AARP. I definitely feel obliged. A lot of people in across the world are not gonna necessarily tell what the AARP is. I'm pretty sure it's like the largest membership organization in The United States. It's the American Association of Retired Persons. I think I got both of the a's right there. And, it is a membership organization for retired people. They offer loads of services. I think insurance, newsletter, magazine. I know my grandparents used to get the magazine actually. And previous to that, Diana was the Salesforce solutions director at Blue Cross. So loads of experience with security and compliance, related implementations of Salesforce, I gather. We have Craig Art Eidelman, principal security architect at Salesforce, and previously did security and compliance at both Salesforce and Microsoft. So super, grateful to have Craig with us today from Salesforce. And finally, Joe Morris, head of solution engineering at Flosom. And I knew Joe ages ago as a distinguished solution engineer at Salesforce. So Diana, Craig, Joe, welcome to the webinar. Good to be here. Good morning, everybody. Alright. And with that, we're going to jump right into the topic of Salesforce security in 2025. And security is, of course, a big topic in Salesforce. When we talk about this in the context of DevOps, panelists, what are the specific aspects of security that you focus on? And I think we'll just start with Diana, and we'll work our way through the panel. So some of the things that we think about with DevOps is, audit trails, looking at seeing who's making changes in your sandboxes, change management policies, secure audit, storage artifacts, sandbox masking. How are you doing that? What are you using? Security logging, and how are you tracking your logging, and where are you putting that logging, and who's looking at it, and how frequently are you looking at it? It's really a big topic. I don't wanna take all of the topics, so I'm gonna hand it over to one of my other colleagues here who are on the board. Yeah. So, Joe, how about you? Would you like to jump in and talk a bit about that? Yeah. For sure. I think at Flosom, we focus on DevSecOps for the Salesforce platform. And what Diana said is absolutely right. There are a lot of things to consider. When we think about security, we often just think about production environments. We don't always think about the processes leading up to those product up to those production environments. And so, you know, let's face it. Security, infosec, and compliance, they're all not just processes, not just, things that you do. They are cultural as there are cultural aspects to it, and they are more holistic practices. And so from a DevOps perspective, we wanna do things like making sure that people are developers aren't accidentally enabling, overprivileged things for people and having that accidentally promoted production. We also wanna look at other things that are happening in that DevOps pipeline and data ops as well. So, it's a critical aspect of it. Salesforce has become an absolutely critical system in terms of sensitive data and important data. There's so many aspects of this that we could talk about. Thankfully, Salesforce has given us a very solid base to, to work from, and that's where Craig comes in. Yeah. Great segue. Yeah. Craig, we'd love to hear the Salesforce perspective on that. Yeah. Of course. I mean, really, it's it's enabling our customers to ensure that they have the development environment that they need to, to have a secure processes and secure technology. So, you know, Diana mentioned a whole bunch of the tools that we have from from sandboxes and logging and processes to make sure that we're giving, our customers what they need to track those processes, have the technology controls they have, in place to ensure that, they're meeting whatever compliance needs that they have because, you know, the development and having secure tools is important, to meet any sort of those compliance needs as well. So there's I always talk about I think we'll talk about this later is, between security. There's a nice Venn diagram between security compliance. Just because you're secure doesn't necessarily mean you're compliant, and just because you're compliant doesn't necessarily mean you're secure. So it's really making sure our customers have the tools that they need that we build into the platform. And if we don't have those tools or the right processes, we've got partners like Flossm that can come in and and fill that gap. 100%. So I think that's great. It's great to hear the perspective, I think, from the customer, the, app exchange provider, and then also Salesforce and how those all work together. Now, of course, one of the challenges I think that we bump up against a lot is, the conflict or maybe the false conflict between security versus innovation. Craig, do you wanna keep on going and talk a little bit about why that is actually a false dichotomy? Yeah. I mean, it really security should just be built into the processes and practices that that you have. That shouldn't be an afterthought. It should just be part of the overall, development process. And especially for your end users, they should probably know that things are secure, but don't necessarily have to do, things. They're just gonna log in and go about their day and do their jobs, as as they should. So when you're designing those those websites, those interfaces for those users, you know, it's gonna be secure by default. They should just know that it's there. They should be able to do their job without having unnecessary roadblocks, but know that they feel confident that they can be secure in what they're doing. That's great. And use the word secure by default. I wonder, Joe, if that's something that you could kinda jump on the back of and talk a little bit about how Flowsome maybe helps make that, possible. Yeah. I mean, ultimately, I think as Diana will probably attest to, it starts with your practices and your culture. Applying the principle of least privilege to your Salesforce development work is critical. I don't think there's actually a dichotomy between security versus innovation because, like with building any software product, you build a certain amount of infrastructure to do things very efficiently. And if you view security as just part of that infrastructure, there's really no dichotomy there. So at the end of the day, FlowSM focuses on the exceptions to that. We focus on helping you speed your changes to production, but also monitoring what you're doing for potentially problematic things according to your security rules. And that includes both metadata and data on the Salesforce side. So that's really interesting. The the idea of, like, the, you know, security as part of the infrastructure, how infrastructure actually makes efficiency possible. And, Diana, maybe you can talk about what that more feels like in the real world in your work at AARP. Yeah. So we don't think of security as one team and us as another team. We think of it as all of us together. And it's not like, hey, security comes last or we come first. It's how do we process this altogether. You know what I mean? Security isn't the last piece of it, and we're not the first piece of it. It's as we're building this, we're securing it altogether, and we're wanting to make sure that the process is secure. What we're building is secure throughout the entire process. So we work hand in hand with security to ensure that everything is secure from the beginning to the end, whether it's making sure that they have the right field access to the right permission access to is our code secure? Is what we're writing secure? So it's bringing security along with us and throughout that process and building those relationships and that trust. So it's not an us versus them. It's a, hey. We're in this together throughout the process. So it doesn't feel like, hey. They're regulating us. Hey. It's all about rules and relationships. It's about, hey. What can we do as a team to make sure that we're protecting our members, our code, our Salesforce environment for whatever comes our way? So that it's not just our code. It's everybody's code. It's everybody's security. So that it's not just our member's protection, it's everybody's job. Security is not just security's job or InfoSec's job. It's everybody's job. And that's really interesting you say that. I I wonder if some of what helps make that possible are the ideas of shift left so that you can sort of take on board, you know, that those security best practices and make them much more part of the software delivery life cycle but much earlier on. Do you wanna talk a little bit more about how the shift left principles apply there? Yeah. So I think I'll let Joe start that off, and then I will tag on to that. That sounds great to yourself. Perfectly fine. We should probably define shift left for the folks who haven't encountered it before on the audience. In DevOps, shifting left just means getting ahead of things. You can think of your Salesforce production org on the right and all the work your developers are doing in earlier environments on the left. And by shifting things like security, compliance considerations, refactoring and code productivity and architecture to the left, it just means you're getting ahead of it. And that's what a good DevOps tool can help you with. And so from a security perspective, shifting left is part technical. It's part cultural. It may mean that, your process now includes your developers building, you know, specific permission sets and including them in permission set groups for the features that they're building. It may mean you have a security review somewhere in the middle of it. The more you can get ahead of of security concepts, the more you do them earlier in your process, the more satisfied the infosec team is going to be. And they may even be involved in some of those early pieces as well as Diana has so much experience in. Yeah. So with our team, we've built in a process so that we have peer reviews into our process. We also have steps that we have developer guidelines. So, hey, you can't do this or you can't do that. We also have naming inventions that we put into place. So we have guidelines upfront. We also have process reviews in our steps. You can't move past one gate before you complete the steps. So there's gates and guardrails into our DevOps process. We worked very closely with our infosec team. There's also guardrails that say, hey. What the developer who developed this code can't be the person who pushes the code. So there are all kinds of guardrails that we have put into our system to ensure that we do have compliance, to make sure that you don't get to the end and then have to back up and redo it all. Nobody wants to do rework. We all learn from our mistakes, but sometimes the mistakes that we have to learn from, we don't wanna have to learn from. So it's good that we're able to put those processes in place upfront and just say, okay. We've learned our lesson from the past, so let's just make sure that we don't continue to follow those. So having that shift left aspect and internal audit loves this, I will tell you. They love the fact that they can look at the checklist and they go, hey. Look. This is already in place. It's a process that you can see that there's these gates and guardrails in here. I can see that nobody can get past this. And if they do get past it, there's an audit that's there that says why they got past it and if there's any reason for getting past it. So, I love the fact that that is all in there and it's reportable. Excellent. Yeah. Thanks for sharing that. That's, I think that's really interesting about, you know, how the guidelines, the guardrails. And then I especially appreciate the idea that, you know, one single developer can't move things from building to production. There's there's always some someone else who's looking at that. I think at this time, we were talking about having, Joe, you share a little bit about a real world world breach or an incident, so that we could kind of have some information to frame the rest of the discussion. Do you wanna share a little bit about that? Happy to. I mean, at the end of the day, through my fifteen, sixteen years with, being involved with the Salesforce platform, these things are rare, fortunately. Salesforce has built a very good platform. But there is, as we'll talk about, a shared responsibility model. You know, Salesforce customers do have to take up certain aspects of security. And because Salesforce is becoming so much more impactful within the organization and subject to regulations and subject to infosex purview as you're finding out with Diana's team. Sometimes these things do get out in the real world. We ran across something a few years back where Experience Cloud, which publishes a default profile for each site, kinda had some permissive, permissions on their default profiles. And one of our customers actually caught that using our trust center product because they had set up a set of security rules to monitor for profiles and and permissions that profiles should have. And so, you know, Salesforce later found out about this and corrected it in the product itself. But, you know, at the end of the day, Salesforce isn't gonna catch every security, you know, glitch or every potential security vulnerability that's out there, neither is any other vendor. And so kinda staying ahead of that in a DevOps process allowed our customer, in this case, to correct the vulnerability before Salesforce even found out about it. And there's a few things that have happened beyond that as well. I mean, bad practices around passwords, all the usual stuff within IT can actually create exposure within your Salesforce orgs. It's not as bad as other systems that you're running all the way down to bare metal in the operating system, but it is a shared responsibility model. And that's actually where we're gonna go next. And I think Craig will go to you. Would you like would you like to introduce for the whole audience, you know, what is the shared responsibility model? And how does that work in Salesforce, especially around application life cycle management and DevOps? Yeah. So just, it's basically the the model that most cloud providers, follows that, you know, Salesforce is gonna take care of that infrastructure. We're gonna maintain our own secure coding practices and and our compliance of the platform, whether it's running in in our, the Hyperforce environment or in our first party data centers. So, you know, you can go on our site, onto compliance@salesforce.com and trust@salesforce.com and look at all of the documentation that we have. And we're we're very open about how we do things, and we have our audit, audit documents and and and those, other other attestations over on that site. And then it's up to the customer to come in and and manage, their own platform within Salesforce. So when they're inside their Salesforce org or orgs, you know, most many customers have have more than one org. They have they've more than one sandbox. They need those processes. So that could be how do we, how do we move our data and seed our sandbox? Do we mask that data or or do we not? How do we co control permissions in those sandbox orgs and those development orgs? There's tools we have in Salesforce that can help bring some of that to light. We have our our health check, which is part, part of your Salesforce org. We also have, as part of security center now, the security insights, component, which gives you an ability to kinda see how you're managing your data and your permissions, with within your your Salesforce org. So we're, our customers do have to take up that responsibility to, manage those those aspects of Salesforce. But, again, we're gonna take care of making sure the platform is secure. We're monitoring what's going on. We're looking for any sort of adversaries that might be trying to attack Salesforce or try to get in Salesforce and be proactive for the customers when when those things if those things do happen. Yeah. I mean, that makes a lot of sense. I know myself also from Salesforce employee. Definitely understand how, you know, Salesforce kind of lays the infrastructure for all of that to to be possible, provides the tools. And I know you've talked a you know, at a high level, you've talked about some of the practices that you have, Diana, but maybe you can share a little bit, a little bit more depth on what your side of that shared responsibility model looks like as a customer. Yeah. So as we all want to in our Salesforce, journeys, we all would love to walk into a company and say, let's get a brand new Salesforce org, and let's build it from the bottom up. Right? So let's make the pristine permission sets. Let's make the pristine profiles. Let's set this up the way that it's supposed to be best practices. But, usually, we all walk into that job, and they're usually set up before we get there. Right? And sometimes they're not set up the way that we would want them set up. And sometimes we walk in and we're like, why was that done the way that it was done? And, I'm not sure what that looks like. And, with everything that's changing in technology nowadays with Agent Force and data cloud, we're all responsible for the setup and how it is the permission, and we all take that responsibility as the admins and the developers and the oversight. So we need to make sure that we're looking at that and taking that responsibility to say, okay. Is this set up properly? Are we hacking it on a frequent basis? Because let's say Joe today is reporting to Peter, but tomorrow he's reporting to Craig, but he's still at the same company, but he changed roles. So did somebody go in and change his privileges? He's still at the same company, but did somebody make sure his access was changed? Are we checking that? Are we doing the proper permissions and profile checks on a regular basis? Is the business involved in that? Because sometimes we're not looking at that because we're just we're so in-depth in making sure that our business is getting taken care of through code and configuration, that we're not checking our our access at a regular level. So we need to make sure that we're looking at, yes, our dev ops is happening, our permissions and profiles also happening. But also from the developer standpoint and the admin pro aspect, are we looking at the DevOps process and going through the aspects to make sure through the changes of our technology, are we keeping up with the DevOps process? So as agent force is coming out, are we keeping up with the DevOps process for that? As, data cloud is coming up, are we making sure that we're looking into that? Are we keeping up with our documentation and our governance processes? So we have to keep up with everything that is moving, and it's moving so fast that sometimes you can't keep up with the documentation, let alone keep up with what just happened yesterday to what's keeping up with what's happening tomorrow. So, it's on all of us to as a shared responsibility to work with our partners such as Salesforce, Flosom, keep up with the Salesforce Ben articles. I read them again all the time to say, what's going on with everybody? So it's very important to make sure that you know what's out there in the environment. And then just to say, okay. From this aspect, how can I make sure that my team is informed and that I'm also informing not only ourselves, but Infosec of what's going on and keeping up with everybody and everything of how the changes are going to affect us, affect the team, and how can I make sure that our environment is staying secure? You said a mouthful, I have to say. Sorry. I'm so sorry. No. No. No. I think in a great way. You really covered all the bases. And, you know, it reminds me of something I heard recently where somebody was talking about how, you know, the moment you get your Salesforce org, it's a 100% secure and then you touch it. Right? And you really, like, talked about all those pieces. And I wonder, you know, Joe, to wrap up this question, you know, about the shared responsibility model. I'm sure there's things that Flowsen brings to the table to sort of to be an another partner in that process. It's something that we realized as a company very early on that you couldn't separate security from DevOps. And it starts with that shared responsibility model because Salesforce gives you a ton of power. And like you said, the minute you get your Salesforce org, it's kind it's pretty secure. But then you start touching it, and it's not just your org. It's things like sandboxes, which may or may not have production data in them, that you need to anonymize it. Maybe things coming through those sandboxes that affect your security as it goes forward. And so, you know, it's just like your eyes get open the minute you start owning Salesforce, that it's not simply go into production, make a change here, and, and that it's there. You you start to bring a lot of nuance in it when you put a life cycle and management behind it, and that really gets to that shared security model or shared responsibility model because with great power comes great responsibility on the customer side. Salesforce will put appropriate guardrails in place better than just about any other vendor I've seen. But you still have a level of responsibility, and DevOps brings different dimensions of considerations to that. So that's the reason Flowsome focuses on it is because we view it as integral to that, things like deploying the smallest, security footprint possible with profiles or permission sets. It moves on to maybe monitoring what's going on in settings in your org and how they differ between environments. And so those are the types of things that FlowSOM is looking at as well as data considerations when you seed your sandboxes with data or you need to maybe scramble some data in a full copy sandbox in place. So we try to view it holistically and and fill in kind of the gaps that, all the practice considerations that Diana has, mentioned come up. Fantastic. Yeah. Now, I wanna circle back to something that you, sort of dropped a little bit earlier, Craig, into the conversation, but I think it's a good time to bring this in. We've talked a lot about security, but you also brought in compliance. And so this is probably a good time to talk about the difference between those and how do they interplay with each other. Yeah. So, when I work with customers and, for many years, we've we've talked about security versus compliance and how they're they like I said, there's an overlap that sometimes you can be secure or you have the right, settings, but it's not necessarily compliant. You're not meeting, what you need to do from a process standpoint with those control frameworks that are out there. And and, you know, The United States and globally, we've got all sorts of different control frameworks. Different countries have different rules. Different regions have different rules. Different United States, different states have different rules. So, you know, making sure you're compliant can be can be quite challenging. So when I talk to customers, it's it's a lot about, alright. Do you understand, the frameworks that you're gonna use, as that basic framework for your security controls? And then, how are you going to apply that? Sometimes it is through technical controls. So those are the the checkboxes and other things you might be doing. Sometimes it's through process controls. Do you have those processes written down? And are you taking advantage of those security controls to meet those process process controls? Especially if you're dealing in The United States or globally with health data, how are you managing to keep that data not only secure but also private? What what what do you have in place from a process standpoint to make sure that only certain people can look at that that health data? Are you, anonymizing it or de identifying it when necessary? So those, while they're not necessarily related to security, yes, they potentially can. You don't wanna have that data get out there. But, there's also the privacy aspect to it, which then applies to that compliance framework, which then they might apply to us very specific law. So, you know, it's really making sure as you look at, your Salesforce environment, understanding what data do you have in in Salesforce, who can see that data, and then from a DevOps standpoint, how are you controlling the developer's access to see that data, and then the right process controls in place during that development environment to make sure that the code that's gonna be coming out is gonna be secure and and meets those needs. Yeah. That makes a lot of sense. And, you know, to put it a slightly different way, compliance, that's really kind of the legal or possibly, you know, maybe based on some standard that I might have to follow as a, you know, maybe as a financial institution or a health care institution, or maybe a duty of care to a particular vulnerable population. Like, those would all be compliance issues. There's an overlap with security, but regardless of compliance, there's still security things that need to be taking place in that. So does is that sum up what you said just to make sure everybody on the call is on board with that? Yes. Yeah. Yeah. So, and again, Joe, I think it's probably a good time to have you comment a little bit about this and, you know, how FOSEM helps with with both of those aspects. Yeah. I mean, ultimately, I'll I'll reiterate what Craig said. That Venn diagram analogy is a really, really useful one. Sometimes the compliance frameworks that are in place are there for security. Sometimes they're in place for privacy or to prevent, bad actors. A great example of that is Sarbanes Oxley in The United States, and Sarbanes Oxley basically requires folks like Diana to keep a log of everything they've deployed to production. Now that was more intended at preventing accounting fraud that happened, you know, in the Enron era and during the great recession. But there are others that are aimed at privacy and aim others that are directly aimed at a cybersecurity as well. And so that's really what Flowsome tries to do. We try to build some of the best practices right into our DevOps tools. And then, you know, as you progress and as you advance your DevOps practice, we wanna start taking a look at both data and the flow of metadata between your, sandbox environments and production, making sure that they follow rules that you've configured and that we're alerting you and shifting the analysis of that left, to make sure that you're getting ahead of those issues before you reach production. Excellent. And then, is so is there really a, you know, how is it compliance or approaching compliance and building compliance into your DevOps process different or, you know, what what distinguishes that in your DevOps process from security? Diana, do you wanna jump in and talk a little bit about that diff the the focus on compliance versus security? Yeah. So I think that you want to build your compliance as you don't wanna slow down your delivery. Right? You never wanna slow down your delivery because we always have those business stakeholders who wanted it yesterday. And you always have six business stakeholders, and everybody thinks that their item is just as important as the next guy. We all have that. So we really wanna work with InfoSec to make sure that they're not seen as so they're seen as your partner, and you're working with them through the sprint planning process. You're working with them to make sure that they are your trusted partner, and throughout that process. So you're seeing them in the user story. You know, you're seeing that security process through the user story that you're building. And I'm talking as we use Agile here. I think that most, companies use agile nowadays through the DevOps process. So your story actually have the security in your user story. And then you're you're adding automation throughout your, DevOps process. So can you do code quality that's automated? Can you do, any checks that, you can get through that it's gonna be automation? You have those guardrails that I was talking about. You have any, policy, code reviews that are in there. You're also doing, like, feedback and review checks. Whenever you're doing your retrospectives, are you doing a a developer and admin retrospective with your, InfoSec team? Are you having those types of open conversations where everybody can actually, you know, speak their mind and they know that it's a trusted environment where they can actually talk and be open with each other and know that it's a safe environment. Because sometimes things can get heated, but they need the that space to say, I understand where you're coming from. I understand where I'm coming from. But I have this, priority. You have this priority, and they're clashing. So how can we get to a agreeable arrangement to make sure that, yes, we're secure, but, yes, I'm meeting the deadlines that I need to meet for my business partners? So giving them that area to discuss and that retrospective feedback loop to where they know that they're gonna have that time to talk and come to a conclusion. Because sometimes talking Salesforce jargon and Infosec jargon, they're not on the same page. Because one group's talking one way, the other group's talking the other way, and it's totally opposite worlds. And until you can get people on the same page and talking the same language, they don't understand each other's worlds, especially if one person has never worked in the Salesforce environment and one person's never worked in the infosec environment. So having that person who can actually come together and then take the time to speak each other's language and learn about what you're doing really helps. So you actually have to invest in each other. You said something that I'm gonna come back to in just a moment, that I think are really great to focus on. Before we do that, Joe, do you want to chat talk a little bit about, compliance in the DevOps process? Yeah. Well, I I wanna acknowledge that everything Diana mentioned is super important, and we're getting to the meatiest part of that issue that we're gonna discuss here, I think, in a minute around the culture and working together. But I think I wanna start by trying to think about this. Put yourself in the shoes of a Salesforce developer or and someone who handles release management for Salesforce. There's a lot you have to do already, and a lot of the compliance is kind of baked into that. Now what we find at FOSEM is that reducing the task load for those developers on the DevOps aspect of it, release managers and developers, can free up time to do things the right way. So if I'm a developer and I'm tempted to take a shortcut by enabling modify all data on a profile, sure. We want the DevOps tooling and and processes to catch that. But at the end of the day, if I don't have to then go spend twenty minutes resolving all my dependencies on a change a set of changes I'm making, then I have more time to do it the right way and kinda slow down to move faster. And that's the critical aspect of what I believe Diane was talking about. And that starts with a good relationship between, between the security teams and, and the Salesforce team, which are often very two very different people and oil and water, and sometimes there's a process to get to know each other. And and you said exactly the word that I want to spend a little bit of time focusing on and that's culture. And to begin with, I think, Diana, would you like to talk a little bit about the importance of culture in the shared responsibility model to begin with? Yeah. Culture is a big thing because a lot of our developers they're usually heads down. I type on my keyboard. I don't do a lot of talking, aspect, and it's very you gotta get them out of their shell, occasionally. At least that's my aspect that I've worked with developers. So trying to break the shell and work with developers and admins. Some of the admins are very more outgoing. So having that culture that, you know, you've got to find what aspects can you reach out to your developers and your infosec team. Can you try and meet them in the middle to find the likeness of where you can get, everybody so that they can find the agreeable point? And sometimes it's not Salesforce. Sometimes it's baseball. Sometimes it's golf. So at first, you have to find the aspect of where you can get everybody on the same page. And then from there, then you start talking about what is the point that you're actually trying to get to. So and then it's celebrating the wins because you're gonna have these hard losses, and sometimes it takes your team down. And it is horrible whenever your team has a loss, But it's the wins that you wanna start sharing. And then in the losses, what you wanna do is you wanna reflect on those and say, what could have we done better? How could have we fixed this? What could have we worked better to get this to succeed? So there's been times in my career that I was like, I was the problem. And how could I have made this aspect better? Or, you know, I didn't help the problem the situation. What could I have done to enable my team to be better? Or what could I have done to build a better relationship with another department in order to make this team succeed. So whenever we're looking at the DevOps process, some of the times it was, hey. I didn't give my team the right tools. So I had to fight for the right tools, in order to make sure that the guardrails were there, the aspects were there. And with automation nowadays and having guardrails and having the tools and, the compliance there or even understanding what does internal audit do. Because let's be honest, you have Infosec who is your proactive, and then you have compliance, which is your reactive. And internal audit is the reactive side that comes in at compliance after the fact that's checking all the boxes. Right? So you have internal audit coming in and going down the compliance checklist to say, did you do this? Did you do this? Did you do this? And you have to understand they're not a bad guy either. They're just doing their job. And you're like, okay. How can I make sure that I'm understanding how internal audit is working with Infoset, with the compliance, and how am I understanding what that language is saying to the Salesforce language? So it's understanding, like, six different languages compared to the Salesforce language. So you have to understand all the same pages. So it's building a relationship not with just InfoSec, but with your auditors and becoming partners with all of them so that everybody's on the same page. So it's all about, like, doing lunch and learns, doing, hosting little groups. And most of the Salesforce world is remote. So sometimes it's just about joining a little call with each other and getting to know those people and building that relationship. So I have found that relationship building is the biggest part of being able to build a culture in the Salesforce environment. So without relationships and without being able to get on the same page and getting in the same dictionary and language, you're going to stumble throughout your whether you're trying to build, better InfoSec relationships, better auditor relationships without being able to get on that same page, it's not gonna work well. Yeah. That's great. And, you know, I I I I really, what you talked about as far as the difference between infosec as sort of active and internal audit, that's the first time we brought in, I think, this the in internal audit into the discussion. And I think that gives us a really good picture of how complex the that sort of that shared responsibility model can look like from the Salesforce customer side of things. Joe, do you wanna talk at all about, how culture interacts with the shared responsibility model? I think this is critically important. So many at at any Salesforce organization, you're gonna have a team of folks or multiple teams like Diane's who live the Salesforce world and other teams that focus on security and other teams that focus on compliance. Really, you know, in in our day to day at Flowsome, we talk to organizations at all states of relationships. We talk to some organizations like Diana's where there's a good productive relationship and that culture has been established between the two, and they've figured out ways to go forward together. Sometimes, we talk to organizations that where there's no real relationship between, the Salesforce practice and security and compliance, and they're just getting an audit request for the first time and or maybe they're evaluating a DevOps tool or something like that. And our first interaction with InfoSec is a big 300 question document of what does your platform do with all of these questions informed by that InfoSec department's experience with other platforms. And, Diana, as you said, sometimes you've gotta find a way to meet them in the middle. We often find that we help broker introductions or help foster an understanding or at least that initial understanding of what Salesforce does, with the InfoSec team in the middle of of a cycle where they're evaluating a DevOps tool. So that culture is critical to start and build because Salesforce is unlike other platforms. You're gonna get people who come to you and say, how many virtual machines does Salesforce stand up, and how do I secure the perimeters? And the answer to that is none, and then you have to explain why. So getting on the phone with them or getting in person with them, like Diana said, is that critical first step in building that relationship. You can often short circuit a lot of hassle that's just present in a document or a security review just by doing that. Excellent. And, you know, I think continuing with this theme of culture, in the early part of the hour, we talked about a lot of things related to tools, the actual features to use. I think it'd be good to talk a little more about how to move beyond sort of purely enforced security versus building it into the culture of your team. And I know, Diana, you talked a little bit about this. So I wanna start this question with Craig and see, you know, as the Salesforce person who's maybe connecting with customers, is there anything that that you've been able to do or your experience in seeing, customers who've built this culture? Yeah. It's it's a lot of talking to customers about. This should just be part part of your your DNA is using security as just, you know, from your from all your daily requests, whether it's just your email, making sure people are are are are are it's part of their, looking at email and not sending out everything that, and clicking on every link. That also applies to what you're doing within Salesforce. So making sure you properly, setting permissions up if you're a Salesforce admin. Does everybody need to see everything? Is that should should that be part of the culture? It's like, well, we wanna be open and we wanna let people be able to look at stuff well. Does it have to be? Can they see enough to get their job done versus seeing every single aspect of the of your Salesforce work? And that kinda builds it into the culture of of only knowing, only doing what you need, to do to be successful in your job. And and that's important too. We want, you know, every one of our customers to be successful in their business, and all their employees to be successful in what they're doing. And and part of that is making sure that, you know, you you can have the data you need to do your job. The other part of it, I would say also, is integrating security into again, as we're talking about development, making sure that it's just part of what you do. When you're when you're developing, code and you're going as Diana, it sounds like they have a great audit and and review process, making sure that's just part of the culture is well, we shouldn't try to get around that. We need to make sure that they're our partners, and we're partnering with our audit team and our compliance team and our security team to to do this. That that's important. I've seen lots of customers that I've worked with. Sometimes there's a little adversarial relationship, and they're trying to get around some of those rules. But, the end of this is it's the best for everybody. It's a benefit for the company. It's a benefit for the organization. It's a benefit for customers, for your partners, for everybody. So, it just should be built built into the culture of what you do. And and part of it too is also looking at the at the industry. You know, there's all these different security certifications that are out there, you know, all these different, certification bodies. Encourage your teams to to to look at some of those certifications and certificates. It gets people started in thinking about security. You know, whether it's, you know, the the initial certificate or maybe some of the longer certifications that require, you know, you may have to have experience to get those certifications. That should also be part of the culture too is incurring that encouraging that with your security and non security teams as well. That's that's great. I think that's a really interesting, idea to to get the non security folks actually looking at, things like security specifications or compliance specs. And that that sounds, you know, I think it'd be great to dive a little bit deeper into that and have each of you talk a little bit about, other ways or tools that you can foster early collaboration between your developers and your security teams. Yeah. I I've seen a couple of those, Peter. I'm sure Diane has as well. It's it's really kind of a forcing function to establish that relationship. Right? So if you have, on the one side, folks who are in security and compliance who don't know a lot about Salesforce, on the other side, you have folks who know Salesforce really well and are still learning about security and compliance and figuring out how they can fold it in. One thing I've seen people do early on is have the Salesforce team walk the InfoSec team through the basics of Salesforce security and the concepts involved with profiles, permission sets, roles, and other pieces, and how that impacts the UI, the API, and everything else. That can often be an eye opener for InfoSec and opens that door to having that conversation, and then InfoSec can advise them there. The other tactic I've seen is to, you know, have, Infosec come in and maybe even run some security testing in a later environment, like a QA, UAT, any of those full copy or partial copy sandboxes so that they can learn the Salesforce piece with some guidance and do a bit of evaluation and start to address Salesforce security and understand how it's different. And then the Salesforce team, as their guide through that, learns a lot just through the process of osmosis. So it's kind of a way of putting people in the same room to learn together. Those are really interesting techniques, I think. You know, that idea of, almost doing a security training for the infosec team so they can actually get to know the knobs and the levers that they have available. And, you know, I mean, this isn't exactly what you said, but what I heard was, almost like red teaming, like, a later stage sandbox or something like that. I don't think that's exactly what you meant, but it's kind of where my mind went. Much that. I I think it very much is. I, I think Red Team is a great way to do it. Maybe not that adversarial, but doing it well. Exactly. And, Peter, I'll I'll add too. I I've worked with a lot of customers where I get on the I get on the phone with her, a web a web meeting with security, and it's the first time they're actually really ever interacting with Salesforce. They it's it's to a lot of security folks, Salesforce is just an app. It's one of the apps I've gotta manage. It's part of my my day. I've got all these things I gotta worry about in our infrastructure, our cloud application security infrastructure, all these different things. So sometimes it's just understanding, okay, what what is a what's an object? What does that mean? What is a field? What how does that work? And and once security folks tend to learn that and understand how Salesforce operates, then it's they start to look at it more holistically and say, alright. How can we build, Salesforce and the data that's in Salesforce into our security processes? And those are great examples, I think, of what Diana talked about earlier about building the collaboration between those different teams. And, Dana, I do wonder if you have maybe a particular story of, where you were able to foster that early collaboration. I know I'm putting you on the spot a little bit here, but I'm dying to learn more. You know, do you have an example of that or like a success story or even maybe one where it didn't go well that you can share? Yeah. So usually, Salesforce comes to you and says, hey. I need the SOC two document. You know? They're like, can you go to the trust site and download it for us? Give us the SOC two document so that we can just go through the document. And I'm like, do you really know what you're asking for? Do you really understand what the system actually does? And then I was like, hey. Do you know this thing called Trailhead? It's actually a flight that you can actually go out there and you can actually learn what Salesforce is. So, we've done some collaboration of, like, hey. I don't understand some of your language, and you don't understand some of my language. So can we do some sessions where, like, this is the verbiage I don't understand. This is the verbiage you don't understand. Can we come up and talk together of, like, hey. I wanna understand what you do. You wanna understand what I do. So in a previous job, I actually sat down and I was like, I really am very interested in learning what you do, and you wanna know what I do. So can we collaborate together? So I sat down with because we actually got hired on the same day. So and then the steps and then got hired on the same day as I. So we had to go through all of the training together. Right? So you're sitting in the HR room, and you're going through all this lovely training together that you have to sit through. And I was like and he's like, well, I have to check out your system. And I was like, well, can we learn together? So it was actually a benefit for us to sit together and learn through the process. So I learned that that actually helped me to understand better of how to build the InfoSec relationship in Salesforce. So that was more of my success story of how to get the InfoSec and sales teams on a better, playing field than how I've done it in the past. Because in the past, it was like oil and water. It was like, here's this up to document, and then they'd come at me. And I was like, yeah. Let's just continue to clash until I actually get to where I need to go. And that's what helped me to understand that it was more of a partnership. And once they understood what my language was and I understood what their language was, I could continue to move through this. But before then, I was just like, yeah. I'm just gonna continue to have this oil and water relationship, and I'll just continue to move through here. But now that I get that, that's whenever I was able to continue to grow, and then I was able to help my own teams. So that was my success story, Peter. Fantastic. That's a great story. You know what it makes me think of is, Mike Gerholt, back when he had his button click admins podcast, talked about Salesforce administration by walking around. But I'm gonna I'm gonna come up with a new initialization initialism called Salesforce security by working together. That's what I heard when you were just saying that. Joe, do you wanted to jump in? Sorry. I I love that you shared Trailhead with those folks. We Yeah. It that does a few things. Number one, it says, look, this stuff is all documented. Number two, it says it's approachable. But you're right. It's it's really about breaking down the barriers and getting them to open up and collaborate as opposed to them just trying to follow a process and live in their silos and fulfill their biases. Right? Which I think we could all learn not just in tech, but outside of tech in our regular lives too. The more we talk and understand each other, the better off we're gonna be and the more problems we're going to avoid. And, Diana, does that tend to build confidence if you can point your infosec people to, like, existing documentation, existing training? That kind of tells them this is a system that is well thought out, well built, and well planned. Yes. Especially with all of our partners, like, whether it's a DevOps tool or it's, a Salesforce tool. Whenever you have documentation, you can actually say, this is legit. This is where you can go. It does help a lot. And then, also, whenever you have experts like Joe and Craig that you can actually get on the phone and if there's a info sec problem or question, and they can actually ask ask the expert. That really helps too. So, we have people that we can actually call and say, hey. We have a problem or, you know, you can submit a support case and people actually get back to you. There's some times, there's companies out there that you submit a case to and it sits there dead in the water. But, luckily enough, with Salesforce and other companies like Flosam, and you don't have to worry about that. You have support that you need. Very cool. And, Joe, were you gonna jump in again there? Did I No. I yeah. No. Okay. Alright. No. Go ahead. It's like Oh, no. I was just saying for once I've I don't have anything to say. It was a great job. So we're coming to the end, and that's a good time to ask about postmortems. And you talked about this a little bit or you hinted at it, Diana. But what what role do blameless postmortems play in creating that secure and transparent DevOps culture? Blameless postmortems are very important. Whenever you're not blaming each other and you're blaming the problem and not the people, it could be a process problem. It could be a product problem. It could be a, hey. I didn't have the right requirement. Hey. I didn't have the right tool. It's usually not a person or it could be, hey. I didn't even have the right, knowledge. Like, you could be giving somebody the wrong job. I could be telling Joe to learn how to go speak French, and he doesn't know how to speak French. I could be telling him to go do something that he just doesn't have the knowledge to do. So it's important that we are open and we are honest about, hey. I wanted to try this. Hey. I didn't succeed. And it's okay to try something new and fail at it as long as you're willing to understand that, hey. I was going to do this. I knew that I was going to fail at it. And I told you upfront that, hey. There's a possibility I was going to fail at it. And those postmortems are saying but as long as you knew what the risk was upfront. You don't wanna put yourself in a security risk where, hey. If I do this, I'm going to open up my entire Salesforce or to lose all of my data. It's not a risk you wanna take. But if you're going to open up yourself to a risk to say, hey. In a dev org, I want to learn how to, write an agent force agent in a brand new dev org. Go right ahead. You know what I mean? That's something that I'm going to tell my team to do. But the types of things that you wanna do in a postmortem is you want to say, okay. What mistakes do we make? How can we learn from them? What things can we put into place? What guardrails can we put into place in the future to ensure that we are successful moving forward? How can Infosec help with that? How can we write compliance to help with that? What can we do to ensure success in the future so that somebody else doesn't have to go through the pain that you just went through? So that's what I look forward to ensure that my team doesn't have to go through that pain again or that person doesn't have to feel that self doubt or that self pain. I want to ensure that nobody ever has to feel the way that they're feeling today about themselves or that aspect. Because sometimes people take it on themselves as, hey. I screwed up. And sometimes it's not their failure. It's as a team, and I don't want the person to feel that insecurity or that blame. It's all as us as a team together. We either take it on together, and we take that failure as a team, and we take that win as a team. Nice. Nice. Joe, any comments on the blameless postmortem topic? I mean, Diana, you hit on the most important cultural aspects of that. I I think the the thing I'd wanna leave people with is to think about this. You're trying to create a safe space to honestly and forthrightly analyze what went wrong or where we added risk. And, you know, so many organizations are politicized these days, and this is really about depoliticizing them. And to my mind, this is a function of leadership of creating that culture where people can honestly assess what they could have done better, and people can honestly bring things up without creating blame on others. And that takes a very good kinda culture, and it takes a a cultural tone that I think is set by DevOps leadership and is set by company leadership in many ways. We wouldn't want a heavily politicized organization just to use this in a politicized way. Right? It's about creating that safe space and completely understanding it. And like you said, Diana, that comes with culture and that comes with time. It takes time to get to a point where you're able to do this. Yeah. I think that makes a really good point. You know, if, if people are afraid to speak up, you lose the eyes and ears of what's going on, don't you? Fantastic. So we have just a couple of more minutes, and I just thought to wrap up, it might be interesting, for each of you to kind of take around and talk about especially since so much we've talked about is culture. Are there any cultural myths or behaviors that devalue secure development practices? Anyone wanna jump in on that? I guess one one myth would be that Salesforce just takes care of it all and that there isn't a shared responsibility. Right? That's the very unproductive end of this. And I think that can inject a lot of risk into a Salesforce process. When I started with Salesforce back in 02/2009, it was not uncommon for a department, usually sales, to buy Salesforce on a credit card to assign one full time administrator, and that person just worked in production and it was a part time job. That can create all kinds of danger. Even though Salesforce is going to be secure by default, like you said, the minute you get into it, you start doing things that could potentially compromise that. So I think that orthodoxy is probably you know, Salesforce as an app is probably the most harmful thing that's out there. And it goes to what Diana was saying, crossing that bridge to other departments, to infosec, and others. The other ones that I hear is we're agile. We'll fix it later. And then you never get to it because, you know, the network that always comes up. So The problem with agile is something can stack itself on top of or before the important stuff. Right? Yeah. So just take care of it while it's there. It sort of, brings up that, I don't know if you all know the x k c d cartoon of, like, the big stack of blocks and then, like, one little tiny one that you have. So, excellent. Well, I think that pretty much takes us up to the end of the webinar. And I think, Joe, you wanted to go through and just cover off a few slides at the end. Right? Yeah. At the end of the day, we'll be quick about it. We we are thankful for everyone to for coming today. We know that this is a big topic. Salesforce is an absolutely critical system for most organizations, revenue impacting, support impacting, the master source of data for so many things. We have lost some focus on that, and we focus on helping people of all stripes from those coming off of change sets to those who have very sophisticated CICD processes and data management processes related to Salesforce, help speed and secure their, their Salesforce practices. DevOps product, which, Diana knows very well. And we do that with our Salesforce backup and archive product, which gives you data redundancy and data management. And then I think this is kinda part and parcel. We didn't want DevOps to just be DevOps. We wanted DevOps to have a critical piece of security in it, and that's why we built our trust center solution that flows somewhere. We focus on many of these things. And, like, we talked about shifting some of the practices and checks and gateways left so that you get ahead of them earlier in your dev cycle and that agile prioritization doesn't get in the way. So that's us. I won't belabor the point too much. It's just what we do, and, we love to talk to anybody who has a Salesforce practice. We're super curious about what you're doing with the platform and how it's impacting your business and what changes you're seeing. And at the end of the day, there may be areas where we can help with some of the aspects of this. And I think there's one more slide too. Yeah. And at the end of the day, that oh, yeah. Okay. So we have we've actually created a, oh, so we'll go back to this one. Yeah. And so this is just a little more detail. I mean, you know, with Salesforce, you have a ton of systems that impact what you're doing. You start opening those doors to other tools in your DevOps process, like your ALM and requirements management tools, your environment management tools that Salesforce gives you, version control systems, start to put your Salesforce metadata and other assets in other places. And then with quality assurance and security and compliance built into all of these, that's really what Flowsome focuses on, both as part of our DevOps solution and with our security add ons. And I think with the next slide, we've even published a bit of a a report on this. So the state of Salesforce DevOps is something that we try to do every year. There's a QR code that you can go get that report and see exactly what our customer base is finding, as well as, folks who aren't our customers as well. What's going on within the Salesforce ecosystem with regard to DevOps? What trends and patterns are they seeing from new things, like Diana mentioned, where we're trying to get ahead of AgentForce and data cloud, things that are very left field compared to traditional Salesforce? There are DevOps aspects to those. So take some time, read that white paper, and, if you have any DevOps concerns or data management concerns or if you wanna talk Salesforce security, we're happy to have that conversation with you. Fantastic. Well, thank you very much, to all of our audience for coming along, and thank you to our panelists, Joe, Diana, Craig. I think that was a fantastic discussion, and I hope everybody took something away from this. I know I certainly did. And with that, I think we're all done.