Description
Catch up on this webinar about driving innovation with Salesforce DevSecOps best practices in collaboration with Silverline, moderated by Jill Harrison (Managing Director, Silverline) with guests Greg Grinberg (Certified Technical Architect, Silverline) and Rob Cowell (DevOps Advocate, Gearset).
Over the last few years, the digital transformation roadmaps for so many Salesforce teams have become much more demanding. The platform has grown by leaps and bounds, and there are so many tools and technologies at our fingertips. Many firms are trying to figure out how to innovate faster while ensuring security is at the heart of their program. While many teams may already follow DevOps best practices, there’s a new concept quickly emerging in the Salesforce ecosystem: DevSecOps!
In this webinar, you’ll find out about:
- The important concepts you need to know about DevSecOps
- How you can design a great DevSecOps team
- Which processes and skills are fundamental to develop
- Which technologies can help you drive secure innovation
Learn more:
Transcript
Alright. I think we're going to go ahead and get started because we have an exciting topic today and some wonderful folks that have joined to help educate, this team on what DevSec DevSecOps is and why the top innovative organizations are really paying very close attention to how to manage their DevSecOps practice inside of their Salesforce program. So as we get started today, we'll do some intros first up, but I wanted to sort of start and share with the team here that, really at Silverline, one of our core values is that we are always learning.
And one of the emerging topics that we've had much discussion about internally with amongst our team, amongst our architects, our DevSecOps best practices.
This is a concept that, you know, some people may be familiar with. You may be more familiar with DevOps traditionally, but we really have been having a lot of discussion about what DevSecOps means and how to bring it to bear with your Salesforce program. So without further ado, I'm really excited to, introduce the panel today. And, my name is Jill Harrison.
I'll be moderating the session today. I run our capital markets and asset management practice at Silverline, and I've been in the Salesforce ecosystem since two thousand five. Much has changed in that time, including our ability to really handle complex security use cases, and innovate faster. And I will I'm very pleased to have a couple of distinguished panelists with me today.
I'll kick it over to you, Greg. I would love for you to introduce yourself to the crew here today.
Thanks, Jill. So I'm a senior technical architect at Silverline as well as a certified Salesforce certified technical architect. I've been in the Salesforce space, since two thousand nine, primarily in consulting roles.
Devops and security, definitely two of my passions. So chatting about DevSecOps is something I'm very excited about today.
Awesome. And with us today, we also have Rob. Rob, please introduce yourself, sir. It's great to have you today.
Thanks, Jill. So, yes, I'm Rob from Gearset. I am a a DevOps advocate over there. That basically involves, helping folks understand Salesforce, DevOps, and DevSecOps, and helping them kind of adopt some of that best practice that we'll be talking about today. Prior to that, I was a Salesforce consultant.
I've been in the ecosystem around twelve years as various sort of dev architect roles, partners, end users, freelancing, bit of everything really. So definitely sent a lot of deployments and hopefully picked up some of that best practice that I can share with you today.
Awesome. Thank you both so much for being here. And, you know, to those of you that are listening in, please, please, please feel free to submit some questions for the panelists today. We wanna have some good dialogue at the end.
We're gonna really spend the first part of our session today talking about what DevSecOps is and why it's so important. And so if you have, you know, thoughts, if you have sort of points of clarification you'd like us to make, I'll be monitoring the chat and monitoring the questions as they come in. So we're happy to kind of answer anything that might be top of mind for you. So as we get started, let's talk about what the DevOps process looks like.
You know, I think more familiar to many Salesforce admins and Salesforce developers might be what development operations means. And so, you know, as I think about the the topic at hand, DevSecOps, let's first unpack what is DevOps and why is it different, and why is DevSecOps different than DevOps?
So Yeah.
Can you help us unpack this a little?
Absolutely, Jill. So DevOps, you know, kind of that continual, development and deployment process, right, as opposed to DevSecOps is really taking that security lens, right, in terms of both people process and tooling and shifting it left and embedding it in your DevOps process so that you're thinking about security at the planning, building, testing, release, and deployment steps. Right? And so that it's part of your continual DevOps and software development life cycle and not something that happens at the end or as an afterthought.
So talk to me today about how organizations are really considering you know, how are they making the shift from DevOps into DevSecOps? Where what is sort of, prompting this evaluation? I know it's very top of mind for all the heavily regulated industries that we work with, like financial services and health care, but what's shift you know, what's prompting the shift?
Yeah. And, you know, I'll open this up to Rob as well. But from what I'm seeing, you know, the the data that you have in Salesforce, the power of the platform, it keeps expanding. Right?
Salesforce is an extremely powerful tool, and that naturally means it's a tool that, you know, you can get yourself into some trouble with from a security perspective. Right? And we have many, many customers with all kinds of PII or other sensitive or confidential information, in Salesforce that needs to be secured. And, you know, it's very much, on and has been on IT's radar and something that CSOs were looking at.
But now that, there's really more of a mature DevOps process that many companies are using for Salesforce where they're iterating quickly on the platform in an agile manner. Right? They need to be applying that security lens in the same way, and they can't be doing it, you know, on a monthly or quarterly cadence. It needs to be something that's front and center all the time.
Yeah.
Rob, any anything you wanna add to that? Yeah.
No. Absolutely. I mean, I think, you know, the the the key phrase that you've used there is is front and center. I think there's definitely a a shifting mindset in a lot of these organizations, you know, be they regulated or otherwise, that, you know, security is something that they they want to to get right so they don't have to deal with it kind of after the fact.
And I think, you know, a lot of folks are, you know, taking that kind of more of a a cultural mindset approach to to security and and kind of making it baked into all steps of their process and not just, you know, at the the technical level. So way scaling way back, you know, shifting left as as Greg says, you know, back to the design process, the requirements gathering, you know, and identifying, like, what are the potential risks if we don't get security right? Because too many folks have have seen what happens when it goes horribly wrong If you don't get security right. But I think also some of that has has both prompted and shored up legislation.
So, you know, over here in in Europe, we have the the GDPR, for example, around that PII data. You know, we in in California, they have something very equivalent to that. You know, it's it's not quite national in the US, but certainly more states are are picking up those types of concerns. So I think, you know, that's kind of focusing the the attention on on the security aspect of of delivery for for more and more organizations.
I think that's a great point. You know, as, like, what Greg said, you know, as Salesforce becomes more of a core enterprise platform and, regulatory speaking, we have a lot more scrutiny around what security policy means for those core enterprise systems.
You know, in in some ways, this is a, an exercise in building trust inside of a team around an application development process, which leads me to sort of my next question. Right? Like, I think DevOps in general has always been positioned as sort of a process to follow to increase your sort of throughput, your agility, the speed to innovation. You know, there's a lot of benefits to it. So can we talk for a minute about, you know, what are what are both the business the business benefits to a really strong DevOps and or dev DevSecOps practice as well as what are the technical benefits. I'd like to unpack that a little bit too.
I don't know who wants to start start that.
Yeah. I'm I'm happy to kick us off. Yeah. I mean, there there's quite quite a few, and I think you you hit on a key point there, Jill, which is it's about building trust. Right? By engaging security, I e compliance or the security team or your CSO or your risk team early in the process and engaging, you know, your architectural review board or other folks who kind of have a have a strong security POV, throughout that entire Salesforce development life cycle, you can really help build that trust and make sure that your Salesforce build team is enabled, appropriately to be able to build solutions that are not only quickly delivering business value, but they're delivering it in a secure way that's not going to lead to, you know, data breaches or reputational risk that's compliant with regulations and so on. So that that's really what, DevSecOps provides above and beyond your traditional DevOps model.
Yeah. Absolutely. Team. Yeah. Go ahead, Rob.
No. I think I think, again, you know, Greg is is is knocking it out the park with his assessment there. I think that, you know, the reputational risk and the, you know, the perception of your your company outbound means that you start to sort of look at DevSecOps not so much as, you know, what can we do to adopt this, but why aren't we doing this? Because, you know, the the safeguards that it that it enshrines around, not just your technical delivery, but your overall way of thinking, is is kind of fundamental to a business, really. I think it's it's becoming an expectation. More and more organizations are being trusted with our data.
You know, we want to make sure that those those safeguards are in place. So it becomes an expectation of companies, not just, you know, something that they can ease themselves into now. And I think, you know, as more organizations have matured with with DevOps, you know, we see elements of of DevSecOps creeping into that by default because if you have a mature enough DevOps process, you kind of inherit some of those traits of DevSecOps.
And the, you know, the benefits speak for themselves, really. You know, it's it's all about safeguarding and and and protecting your reputation, protecting your customer's data. You know, it's it's very much in my mind a question of, you know, why wouldn't you?
Right. Well and I think, you know, I think we've each experienced projects in the past or, you know, client relationship in the past where, technology teams are reluctant to pull in infosec or compliance because they're worried that someone is going to say no as opposed to yes. And the whole point of DevSecOps is introducing sort of that trust building exercise so that it's it becomes a yes and, You know, it's it's how can we ultimately embed that security mindset to your point and bring it sort of left into the planning process. So, you know, thanks for kind of helping unpack the different business benefits and the technology benefits. I I wanna talk a little bit next about, you know, what DevSecOps really means. Because I think for many people that might be on the call today, or watching this later, they're more familiar with what is sort of that, you know, the infinity loop here of dev DevOps and how they can think about their DevOps process.
But when we think about shifting security left and bringing security kind of first and foremost into the the fold, let's talk about what does the process look like? How does it look different, and what are the steps in sort of introducing that DevSecOps mindset? What are we moving to? So the first, you know, first and foremost, there is always a big planning stage to a DevOps process or a DevSecOps process. So, Greg, can you help me kind of narrate through some of these phases and what people should be thinking through and and looking out for to plan accordingly?
Yeah. Absolutely, Jill. And, you know, one thing I wanna call out is we've just talked about some of the key elements here of how DevSecOps, would be brought in to your DevOps process. Right?
There is more than one way to skin a cat. And, you know, this is kind of just some of the key items that you should be thinking about. And, you know, planning in a DevOps sense is something that happens continually. Right?
And I think, there there's a couple key pieces here. Right? Number one, as we've said, right, you have to involve InfoSec compliance. Right?
If you don't have your security stakeholders, if you don't have, you know, your risk team, InfoSec compliance, whoever that may be, in the room and kind of providing their point of view as to the policies and, you know, platform capabilities and requirements for Salesforce, you're just gonna run into a bigger issue down the line.
It's about education. Right? In many ways, it's about educating on the possibilities.
Yes. And it it's about getting alignment and making sure that you know what that those teams expect at the end of the day.
Data classification and threat modeling are also key. You know, in Salesforce terms, most of the time, the thing you're protecting is your data. Right? That that's your major security item that you're kinda should be laser focused on of how what is my data in the Salesforce org? What's my sensitive and confidential data? What's my PII, etcetera?
You know, as that's gonna really define the risk.
And if you don't know what's out there in your sales for Sorg, it's it's very hard to appropriately, you know, put the right security controls in place and go through a a true threat modeling exercise. Right?
Lastly, having those design and development standards in place, right, of, you know, a combination of following sales for security best practices or should be embedded into your software development life cycle.
So I hear in between the lines here, you know, that this planning phase involves really your security leadership, be that, like you said, Infosec, CISOs, you know, risk compliance, etcetera. It's also who else is sort of us has a seat at the table in this planning phase? You know, I presume it's also your devs and your admins and your sort of program architects or, you know, program leadership.
Who who do we think about as needing that seat at the table to have that sort of trust building exercise top of mind?
Yeah. I mean, I think the the leads of your Salesforce team, right, really the key, whether that's, you know, your Salesforce architect or your Salesforce team lead or what have you. I mean, those those are the key folks there. Right? Who can represent the Salesforce development and build team? Who could represent, you know, the folks hands on keyboard who are actually building things within your Salesforce org.
Okay. I would probably add to that also so the business analysts as well because, you know, it's it's also quite easy to identify potential security concerns at the point of gathering your requirements. You know, it's but, right. Okay.
Who who are we looking to serve with this data? Whose data are we collecting? What data points are we collecting? You know, I I always like to kind of frame it, you know, whether it's DevOps or DevSecOps.
You know, the the the principle still applies that, you know, everybody that's involved in some way in the delivery of change from end to end should at least have that awareness of the the security concerns in there, because, ultimately, that is a strand of your deliverable. You know, you want to deliver quality deliverables. You want to make sure that they're robust, they're tested, and that they stand up to that security scrutiny. So, yeah, I would extend that out even further beyond the tech folks. You know, if you're in that pipeline of delivery, then You know, not not everybody a seat at the table, but certainly certainly represented at the table by, you you know, your needs.
Sure. And I think, you know, as as you move from planning through to the next phases, I think to your point, Rob, it's super important because it helps you know, by including all of the business folks at the table early on, it helps ground our development process in sort of, like, acceptance criteria about how applicable it is to, you know, your security model and the threat modeling that you have done in this early stage.
So, you know, great points all around. As we sort of proceed into, like, the build phase that classically comes with the DevOps model, I'd love to start to, you know, discuss what is what is DevSecOps how does DevSecOps look a little different here? You know, how are we how are we embedding these principles into the actual build of features?
You know, and this is an area where there's been quite a lot of evolution around the Salesforce developer, workflow and the DevOps life cycle for a hands on keyboard developer with all the investments Salesforce has been making into SFDX themselves, all the kind of, tools that are coming out there either from the community as open source or paid products. So this is something where you can really, leverage a lot of kind of the modern things that have maybe only even, become available in the last year or two to make sure that your developers, need your admins as well, the folks building declarative functionality, are really getting that feedback, with a security lens of, hey. This needs to be tweaked or, you know, there's a a violation in terms of, like, this wasn't built with this best practice. They're getting it right there in their ID in real time.
So I I would say that's, you know, probably my number one item for that actual build workflow of leverage that modern tooling and modern workflow so that you can get that feedback right away when this user story is being built rather than, you know, two weeks or four weeks down the line.
Hand in hand with that, right, there's now a number of products out there, in the ecosystem that will perform static code analysis.
And doing that together with, your traditional, code review process where another developer or admin is reviewing the work that somebody else has done is a very powerful tool for making sure that you're building things in a secure way from the start and don't have to go back and do rework.
Yeah. And I I like that you've you've kind of drawn upon the the human element there, Greg, because, you know, that's something that I I often champion. The you know, as you rightly say, there are a lot of good tools that will do a lot of the automated work for you. But, yeah, sometimes there's just no substitute for a second pair of eyes on something.
You know? And I think, you know, historically, with the the DevOps process, the the review of code or or changes of any kind has always been from the focus as, you know, does it work? Does it pass tests? Okay.
Ship it. And I think more and more as we move into DevSecOps, you know, the the focus has changed to not just those things, but also, you know, does it stand up to sort of poking a bit? You know, are the permissions right? Am I not granting more access to things than is absolutely necessary?
You know, that principle of least privilege that, we we try and adopt in the Salesforce world. So I think, you know, the human element also helps with that, and I think, you know, people saying, are you sure you want to do this? You know, the automated testing takes us a heck of a lot of a way. But, yeah, the the the human factor you know, it increases the collaboration as well and things that we might not have picked up earlier in that process, which brings us on to those those better quality deliverables.
These are all really great points. You know, I think you even touched on something, Rob, earlier that I I think about, in some cases, when you're building functionality as part of the build life cycle here, your acceptance criteria, like, explicitly inside of your user story backlog should have some consideration and, you know, explicit consideration for security.
And if it doesn't, I think it's worthwhile to ask the question, why doesn't it? Because that's, you know, a really critical consideration for some functionality to actually pass. And as we, you know, move into the testing phase to, you know, consider how are we going to test if that security consideration and requirement is being met.
So Yeah.
It's you know, with the user stories, it's not just as a user, I should be able to do this. You also have as a user, I should not be able to do this. You know, that's where the Very true. Security aspect starts coming in now.
Very true. Great. So next up, it's really, you know, if if we're doing peer reviews, we're helping sort of oversee the the the build and the inclusion of security with automation and with sort of manual sort of testing in the build phase, how does this look in the true kind of traditional testing sense? What does DevSecOps look like when operationalized through testing?
Yep. So I I think there's a few elements to that. You know? Number one, you have your unit test that you're writing today, right, that, you know, are required already for deploying to production of custom functionality.
And, you know, I think it's making sure really that, number one, those unit tests are not just using the system administrator profile, but are written to actually make sure that, your custom code is doing what it needs to be from a security perspective.
Right?
I think hand in hand with that is that security acceptance testing, right, which which we touched on. But it's really making sure that, you know, when you have a user story, and it's for a specific user persona, right, you're testing with that profile. You're testing with those permissions as you're making sure that, hey. This user persona is only able to do the things that they need to be able to do in the system. Right? And it's making sure that that's part of your, you know, QA process for user stories, both from an automated and from a manual testing perspective.
You know, lastly, there's been a number of tools that have come out around, dynamic application testing and interactive application testing that now support the Salesforce platform.
So, historically, you're really only able to build automated unit tests for security, but now you can kind of move up that automated testing ladder and build automated, front end and UI tests and automated end to end tests. And you can have things that are fuzzing your Salesforce org and things like that. So there's a lot more tools in your toolbox that you can apply, from an automated security testing standpoint to Salesforce.
I think those are great tips. What about you, Rob? What how do you see this differing?
Yeah. I mean, you know, I one interesting sort of side effect that I see from some of those approaches that Greg's outlined there as well is that it lends itself to an evolution of your quality and your testing. Because, you know, through applying some of those tools, you learn new best practices, new things that you might not have considered that are are potential risks, and then those fold back into your build cycle so that you you know to to cover those ahead of your tests. So you're reducing that feedback loop of dev, test, rework, retest. You know, you're you're shortening that that delivery life cycle, which is, you know, the the DevOps part of of DevSecOps.
But by making sure that you're you're shifting left, and and kind of nailing those things early, you know, your test time is not so much the testing, but certainly the rework as a as an output of testing, because, you know, iteratively, you know, project one, you identify five four things. You You address them for that project. You feed them back into your learning. Project two, you know, you're not gonna have those same or you hopefully don't have those same four issues. So I think, you know, there's always a perception that by, you know, adding in the security testing that it's extra work. And maybe upfront, that that could be true. But I think over the course of a of a larger chain of projects and deliverables, especially if you take a more modular, granular approach to delivery, which is one of the things that DevOps promotes, I think, you know, the learning that goes into that and the feedback means that your quality graph definitely improves.
One question that I have that I'd like to, sort of double click on is, you know, Greg, you mentioned security acceptance testing, and I presume this is sort of in the same vein as user acceptance testing. And, you know, traditionally, we'll have pretty robust user acceptance testing plans, and you'll really explicitly called out things that users should be able to do and the steps that they should be able to take in order to do those, you know, jobs to be done. Can you help me understand, like, what does a security acceptance testing plan look like? You know, if if folks aren't familiar with what that what form that could take, help us understand, like, at what point in this process does that get created and kind of what does it look like high level.
Yeah.
And, you know, I was also referring to, security acceptance testing in the sense of having acceptance criteria Okay.
And QA around security at a user story level. Right? Because we're still kind of talking about that continual kind of process where this is being applied each and every sprint within each and every user story. Right?
So this is just having that security lens of, you know, we're gonna build our test cases. Not only does the feature work, but is it only giving, you know, these this user personal access to the things they need? Did we accidentally, you know, open something up we shouldn't have? Do they are they unable to do something that, you know, should the system should block them from doing?
And that helps a lot. Thank you. You know, the other thing that sort of comes to mind too is there there could be an interesting intersectionality there between how you're doing your testing and bring your CSO, your risk, your compliance teams back in to sort of show them and guide them through the testing process as you are performing it to align to those security posture, you know, ex acceptance criteria on the actual user story. So I think there could be some interesting opportunity to, like, do hands on trust building and bring them back in to show them, if they're not that involved with the development life cycle.
So I'd appreciate that.
That that's definitely sort of speaks to sort of something I've seen in in some of those sort of regulated industries we've talked to before where, you know, one of the things we like to do with with DevSecOps is is that, you know, continued path of delivery and the the the, you know, rapid iteration and and trying to sort of close those loops. And, historically, what we've seen is we get to a certain point in a in a deliverable, be it a sprint or whatever other mechanism we're doing, and then we have to stop and wait for security sign off. Okay? And then they review things kind of after the fact, and and it slows down you know, it breaks that that loop that we we see on the slide there.
And what we try and encourage with with a more of a DevSecOps model is engage early, engage often. Right? And and trying to make sure that they're part of that process ongoing as it's kind of cycling through the loop there, so that we, you know, we don't hit that kind of break point of waiting for for process to to hamper progress.
Right. And I think, you know, some of your top clients at GearSat, I think, Rob, I've I've heard, you know, are creating or they're they're developing and releasing and shipping code, in some cases every couple of days and, like, very small incremental releases. So are there ways that your organization can involve the security team, the compliance team really early on and get more and more agile at really shipping, you know, sort of discrete and smaller versions of improvements and enhancements while doing so really securely, and with sort of info sec top of mind. So I think figuring out how to involve them in the testing process is incredibly it could be incredibly powerful to your entire velocity as a development team.
Yeah. So And that's that's why we kind of promote engagement and culture above technology and tooling. You know? If if you get the people process right, the rest will follow far smoother.
Right. Okay. So moving along, let's talk about the release phase. You know, how how do you incorporate best practices around DevSecOps into releasing?
Yeah. And, you know, I think Rob, touched on this in a great way just just now about making sure that the architectural review board or that kind of security quality gate, is embedded in your, DevOps life cycle. Right? And and that's really where this kind of compliance validation and or policy as code comes into play. And, you know, what I mean by that is, if you can have your security architecture or security SME, even in there on the pull request, reviewing things and giving that security sign off right right there as part of your DevOps life cycle rather than three months down the line when there's gonna need to be a lot of rework done and it's kinda throw a wrench in the works, that's where you can really get a lot of those, kind of DevSecOps benefits of continuous delivery with security front and center.
Salesforce metadata security assessments. This is this is where really making sure that the functionality you're building, not just the code, but the declarative functionality as well, is kind of, following the various Salesforce best practices, which are evolving every release.
You know, within the Salesforce platform security shared responsibility model, there's actually quite a lot of security pieces that don't really fall under code, and fall more on the declarative side. How are you doing your authentication? What are your session security settings? You know, how have you kinda set up your profiles and sales level security?
And that's where tools that kinda monitor your Salesforce, instances on either a real time or a scheduled basis and can kinda give you some useful reports and insight into is your Salesforce setup kinda following security best practices can come really in handy. And you can see, hey. You know, as part of this release or as part of this user story, we're getting, you know, a flag or warning that we we kinda move the security needle in the wrong direction.
And then, you know, lastly, feature toggles. I did wanna call this out. It's just something that I think the Salesforce platform supports very, very well, in terms of allowing you to incrementally release features to subsets of users via custom permissions or profiles or or controlling page layouts and really embedding that and and leveraging that those aspects of the Salesforce platform and being thoughtful about how you're releasing stuff and who you're releasing it to, just naturally lends itself well to kind of enforcing that security mindset.
Anything you'd add, Rob, about what you're seeing in the release process?
Yeah. I mean, I think, you know, a a lot of that is is kind of sort of, you know, what Greg Swaddlers is kind of Salesforce side, and that's really kind of where a lot of that sort of heavy lifting of the security aspects of of release is is done. You know, when you look at the the mechanics of delivery, you know, the mechanics of the release with a tool such as Gearset, you know, Gearset is a secure product. Of course, it is.
But I think, you know, from a the security of what you're delivering, you know, that very much sits on on the Salesforce side. You know? We do things like, you know, anything we transmit, is is obviously gonna be encrypted heavily. You know, we have secure authentication against Salesforce.
So a lot of these type of, you know, potential points of entry as part of that release process where we're moving code from a to b, you know, be that via, you know, org to org, whether that's via source control or, you know, whatever your kind of process looks like. You know? We make sure that we kinda close the door on all of that. And that's the you know, a lot of the nice things about, you know, Salesforce as a platform, you know, they do a lot of that, thought for you.
So, you know, they are encrypted. You know, they are, you know, do take security best practice for the parts that they're responsible for.
And much like a lot of cloud platforms, if not all, you know, there is this delimiter of the parts that we're responsible for as as customers versus the parts that Salesforce look look after for us. So, you know, as part of that release process, you know, we don't need to worry about is this, you know, is the server that we're deploying things secured? You know? Is it is the data center secured? All of that's kind of looked after for us, and that really kinda makes sure that, you know, our focus is is on the parts that are under our control. You know, some of those things that, Greg's described around, you know, checking that your configuration is correct, checking that, you know, you're only delivering those features that are relevant to the people that need them.
Right. Right.
So last but not least, you know, once all of the release process has, completed and we were, you know, looking to deploy and start getting users sort of live with the features that you're building to, let's talk about what does DevSecOps look like when we're in this sort of operating and monitoring phase. Help me understand, understand, you know, what's what's the mental checklist of things that you're going through to kind of keep security top of mind?
Yeah. And, I mean, this is all around your Salesforce production instance or instances. Right? The this is about kind of, you know, what's your process of monitoring changes that are going in to your production environment. Right? Because you might have, you know, multiple teams and vendors in there and, you know, Salesforce makes it quite easy for somebody with the right permissions to deploy things to production or even do them directly in production.
So applying that monitoring and making sure that, you know, any changes have been approved. And if something goes through that shouldn't have gone through, you have a way to roll them back quickly and easily is key.
Right? That's something a lot of our customers who use Gear Set, right, who are pretty enterprise focused, they heavily leverage that feature.
Data backup and recovery. Right? I mean, coming back to the to the original point, your your data in Salesforce is often one of the key things, that you need to protect. And while I would say in some traditional DevSecOps models, right, or applications, you wouldn't consider data, I would say for Salesforce, it's key. Right? Because if you don't have a data backup and recovery strategy, you know, there's definitely a piece of the puzzle missing.
Right? And if you have an integration that goes haywire and, you know, overrides the data or somebody fat fingers something in production, right, you need to have that as part of your process. And it naturally lends itself well into a DevOps process for Salesforce because you need that anyway for sandbox seeding and and other capabilities like that.
Yep. And I I would add metadata backup to that too because there are cases where, you know, with your, rogue integrations or or faulty deployments or, you know, whatever whatever the the cause may be, you know, it it's just as easy to wipe out the metadata that contains that data as it is the data itself. So we always like to encourage that as part of the backup process as well. If nothing else, you know, it means that your data is guaranteed to have somewhere to land when you are restoring it. But also, you know, it it just kinda smooths out the process of of getting back up to business as usual in in the event of of something not going right. You know, we want to make it as painless a process as possible.
Yep.
Great.
Great. So sort of, you know, lighting up all of the phases of the DevSecOps process, it it it does look like there are some material differences between sort of DevOps and DevSecOps, which is which which is the direction these sort of industry is going. I do have some questions and certainly invite anyone that is, is listening live to submit any questions that you might have as well for for Greg or Rob. But I you know, there are a couple of things that are top of mind for me.
You know, put a different way, and I liked your example earlier, Rob, about sort of, a user story typically states, like, what a user should be able to do, and a security user story might state, like, what a user should not be able to do.
In that vein, like, what are the risks of not really incorporating security into this planning process? What, you know, what what's the risk of not doing this, and what are the sort of things that you see that sort of materialize if you're not really being thoughtful about security early on?
Yeah. I mean, in my mind, you know, the the the sort of beginning of that process is, you know, if if you're not capturing that as a as a user story, then you're not giving the full picture to your development teams of of what or how to deliver effectively.
You know, we don't want to be prescriptive to to developers and say, like, you have to code it in this very tightly confined way. But what we do need to do is make sure that no considerations are overlooked. Okay?
Because that materially changes how they develop, you know, for, you know, for the for the developers, you know, amongst us, you know, it it's the difference between with sharing or without sharing, you know, for, you know, things like, you know, check that this user actually has permissions on this field before we go and do this operation. You know, it's little things like that. But getting those requirements quite specific means that you deliver correctly first time, and then that impacts your whole timeline across your your DevSecOps life cycle. You get it right first time, you know, you're you're saving so much time in in that kind of rework thing.
You know, that's as a as a former developer, on the Salesforce platform, you know, that was the thing I hated the most, rework. It's like, oh, I've gotta go back into that piece of Apex code or that flow or whatever because, you know, there was a requirement that someone hadn't clarified or, you know, I didn't realize that group b wasn't allowed to do this. And I you know, it's it's that type of kind of time wasting, I think, that we really want to kinda close out with with that approach. So I think yeah.
Absolutely, you know, bake the security needs into the into the requirements early. And, you know, by the time we get further around to the, you know, the testing, the c the security acceptance testing, we're gonna ace that board. Right?
And I think there are probably more risks that are potentially fear mongering risks around data leakage and some of the, you know, privacy concerns, but I agree with you. No developer I've ever met really wants to waste their time doing things more than once. So I think that's a great point. Sure. We also have a sort of a question coming in too about, you know, my read on this is with Salesforce, traditionally, it's been sort of a very in, you know, internally focused, like, operating system for many businesses, but there's so many new capabilities for custom mobile apps, portals, experience, cloud, Heroku apps. Like, there's all these sort of external ways that we can take Salesforce and and turn it into experiences for our clients, our partners, etcetera.
When you're working in these sort of heavily externalized application development environments, what are the things you know, what are the tips that you might have for bringing DevSecOps into that? Because those tend to be, like, more complex development cycles.
Whoever would like to take that.
Yeah. I I can chat about that a bit. You know, I I think this really comes back in to the threat modeling, right, of, you know, whether you have an internal business facing application, and that's how you're using Salesforce, or you have an external web facing application.
Right? The the threat models are very, very different there. Right? If it's just your employees and Salesforce is handling the authentication versus you have an experience cloud site or a Heroku app or or what have you out there that's accessible on the public Internet.
You know, and I see customers who are, using the Salesforce platform for more than just their internal business. Right? I see them applying, some of those web development, DevSecOps standards to Salesforce. Right? Things like pen testing even, and and really hammering the system. And as as if it's any other web application, which, you know, it it effectively is. So that that's what I'm seeing for customers who are building it out to be extern more externally facing.
Yeah. And I I I've seen that with the, you know, the more mature, organizations. And by me, more mature, I mean, with their their DevOps and DevSecOps processes is that, you know, they're very good at that threat modeling. They identify the the points of ingress, the points of egress, and they work out, okay, who who should be able to to get to these points? What should they be able to see? You know, they they model at every point, be the internal or external, and then react accordingly.
Yeah. And, you know, I think that the thing with Salesforce is you have so many, different parts of the platform where the security is a shared responsibility. Right?
Where, you know, Salesforce will handle the network and infrastructure security. You know, you're jointly responsible for some of the next level up items. And then, you know, what are you responsible for as somebody building things on the platform as an application developer? Being very aware of that and understanding where the responsibility lies is key because you can get so much power, you know, out of the box from just using Salesforce and kind of configuring it properly and and leveraging the declarative tools from a security perspective, but you have to kinda take advantage of what's out there and the tools that Salesforce gives you.
Great. Great. So I know we're coming up close on time here. I have another final question for both of you.
You know, knowing that we work we're both security and and sort of DevOps and and like minded in all of those arenas. I'd be curious, you know, from your standpoint, Rob, how Gearset is really helping address DevSecOps needs, and then from your your standpoint too, Greg. So let's start with you, Rob. Like, what are the key value propositions, and how are you, you know, how are you helping clients day to day with planning for all of this?
Absolutely.
So at the very sort of high level sort of non product side of things, you know, we we do have a fantastic team of folks that are deeply embedded in Salesforce, DevOps, and DevSecOps. That's that's what we do all day. You know, we have a like, our customer success team handle these types of questions and and, you know, concerns pretty much all day. For the bigger meatier stuff and the sort of planning of of projects and best practice stuff, as well as myself and Jack, the advocates, we have some DevOps architects, that specialize in the the more conceptual, the more sort of structural and and, sort of high level vision approach, and certainly can guide on some of this best practice.
So that's kind of the human element. And then from the the, the the aspect of our platform, we kinda cover all the sort of pillars of of DevOps. So we have the deployment as you'd expect. And as part of that, as we go through, we do automated testing.
We have, our problem analyzers, which amongst all the other sort of technical things they do, is very much a security focus, and it will highlight, you know, are you sure you really want to be doing this type of issues, so that you can actually sort of address those? So we call those out as part of our analyzers.
We do have a backup solution, which does cover both data and metadata.
And, you know, for restoring, it manages all your relationships and and gets you back into business should the worst happen from the security aspects.
We have org monitoring, which Greg touched upon earlier, and this is kind of, you know, continually sort of checking for key changes or, you know, potentially, you know, you could set a threshold on accounts as an example of, you know, if more than fifty accounts get deleted, you know, between checkpoint snapshots, there might be something going on here. So that sort of alerting and monitoring aspect is is something that's that's very key to us. So I think, you know, if you combine all of those facets of the the solution together, I think it, you know, very well lends itself to, you know, a DevSecOps approach as much as it does a DevOps approach.
And I love what you all do to promote community in this space too. I know you have conferences multiple times a year because I think a lot of practitioners in this space are hungry to kind of learn from each other and bounce bounce ideas off of each other so they can all kind of learn, you know, learn and grow together. So that's awesome. That's awesome.
Greg, what do you think? How do you how do you see it most embedding in our work together at Silver Line?
Yeah. Absolutely. I mean, I think there's a couple ways I see this play out, for us. You know, number one, we're advising clients, both on how to, enhance their DevOps process or stand up their DevOps process and include security in that and and really have a a well thought out DevSecOps process and, you know, tooling around that as well as kind of the training and enablement for the team.
We also bring in, our team to do a security risk assessment offering for maybe existing legacy orgs that are out there that, you know, are now getting more attention from, the CSO or compliance or what have you. For our own projects, you know, because we deal so heavily in regulated industries such as FINS and HLS. Security is just kind of in our DNA. Right?
It's something we're doing naturally on every single project because all our clients want it.
You know, we can also come in, from a managed services perspective and and really help with the remediation of any kind of security issues that are found and and working through that process of getting them resolved and getting the org in a better state.
Cool. That's great. And so, you know, on on sort of a final note, I wanted to mention to those out there that we've actually written a a a book together, sort of an ebook that overviews a lot of the DevSecOps best practices and comes with some checklists and some really great, materials that if you're interested in learning more, we would love to have a you know, offer offer a conversation if you wanna chat more about some of these concepts in your in your organization.
And certainly, the the lot of us are traveling to San Francisco, where we have a perennial sort of appearance out in, San Francisco for Dreamforce. And, certainly, there will be events later this year and early next, following on from that. So, thank you all so so much for your time today, and thank you, Rob, and thank you, Greg, for sharing all of your insights. I know this is an emerging concept in the ecosystem, and we're happy to share what we're learning and help educate the Salesforce community at large because, man, the the pace of innovation is not slowing down any right now. So thank you to everybody for tuning in, and hope you have a wonderful week.
