Description
Salesforce teams can unknowingly expose data at every stage of the DevOps lifecycle. Sensitive data can be exposed in sandboxes, permission sets can be misconfigured, and backups — meant to be a safety net — can actually introduce new risks.
Join DevOps Architect Andy Barrick as he outlines where vulnerabilities hide at each stage of the DevOps lifecycle and best practices for embedding security without slowing down innovation.
Learn more:
Transcript
Hi, everyone. I am Andy Barrack. And today, we're gonna be diving into one of the biggest challenges for Salesforce teams, which is security.
Now weak security puts business operations, compliance, and trust at risk. However, a lot of teams are reactive to security issues rather than being proactive in designing a secure process that stops issues before they escalate.
Being reactive to security issues implicitly means that there will be some period of time between the issue being deployed and it being identified and then fixed. And during those times, you'll have an insecure state.
Now no one would want to accept an insecure application as a sort of byproduct of their normal practices.
So what can we do about it?
Well, the answer is that security needs to be built into every stage of your DevOps life cycle, and that's what we'll discuss today.
But first, let me introduce myself. I'm a DevOps architect at Gearset, and I've been here three years. Yes.
Before that, I worked at Salesforce ISVs as a lead engineer and technical architect. I've worked with countless Salesforce teams over the last decade to help them build security into their DevOps process. I've seen firsthand what robust and what problematic security practices look like, so I'm looking forward to sharing my experience with you all today.
So in this webinar, I'm gonna discuss how to embed security throughout the DevOps lifecycle. We'll start with a quick outline of the DevOps life cycle, defining what it is, and how it's a useful way of viewing your development process.
Then I'll walk through the six stages of the life cycle and explain what key actions you can take at each stage to embed security.
And we'll finish up, as Rachel said, with a brief q and a session for any questions that came out during the presentation.
So let's start by defining that DevOps life cycle. When we talk about the life cycle, we're talking about the entire process of delivering and managing changes using Salesforce from the moment a feature or fix is planned all the way through to deployment and ongoing monitoring, which will raise feedback, which in turn generates new features or fixes.
The challenge is that security can't be an afterthought.
If we don't consider it at every step, we risk exposing sensitive data, misconfiguring permissions, or deploying changes that create vulnerabilities.
That's why today, we're gonna break down exactly where these risks hide and how you can embed security into every stage without showing slowing down your development.
So although the loop is is infinite by design, we need to start somewhere. Now if you think about an individual feature, you're typically gonna start by panning that out. So So that seems like a good place to start.
So if we consider the the planning stage and security as an ongoing strategy, then security really isn't just about reacting to threats. It's about proactively designing a long term approach that evolves with your team and with your Salesforce.
Security starts with how you plan, gather requirements, and decide what to build. Now if security isn't considered at this stage, then vulnerabilities will be baked into your pipeline from day one. A secure DevOps process isn't something you set up once and forget about. It needs to be continuously refined to keep up with new risks, org changes, and team growth.
So how can teams get this right?
Well, regular security reviews. As your org evolves, so will your security risks. Policies and processes will need to be updated regularly.
Now you can get help here from free platform tools like the Salesforce health check-in the setup menu.
This will give your org a score against Salesforce defined standards for various security measures as well as advice on how to rectify things, which might be as simple as activating a feature. Make sure you continue to check regularly, though, as platform functionality changes. Of course, ensure that any actions you take in the health check don't negatively affect your org's functionality.
Educating teams. Now security isn't just an admin's responsibility.
Everybody working with your Salesforce environment needs to understand their role in protecting data.
Understand your user base.
Do you know who's using your application and how? Being able to define requirements in their terms significantly helps getting the security aspect right first time.
Creating personas to represent your user base helps to ensure that you've got consistent language and expectations across your requirements.
They help everyone involved in the delivery of features to formulate an understanding of the users and how they work.
It's often much easier to see incorrect security aspect when you consider them through the lens of a known persona rather than having to think about a collection of permission sets, for example.
And thinking about how requirements are defined, you you might want to make security considerations or requirements on feature templates.
This helps to ensure that they're always thought about even if they're not relevant for some items.
You might even have a list of headings of things to consider, which should be regularly reviewed given how the platform develops.
Think, for example, about all the new security requirements around data cloud and agent force, which might not have been on the template twelve, eighteen months ago.
I've I've found this approach especially useful when, like, the product owner or business analyst wasn't necessarily particularly experienced with Salesforce, and these items can become a starting point for a conversation about how to implement.
And development teams may very well not want to commit to any feature where those security considerations haven't been completed at all. So at this stage, you're really building the security in by having it almost as a quality gate.
You should plan for scalable security processes. As your org grows, so will the complexity of security management. And are you prepared for this?
You should define role based access controls, also known as RBAC, to ensure that users, new users, automatically have the right permissions.
You should implement automated security checks in CICD pipelines so that security enforcement scales with development velocity.
And you should regularly review API access and integrations, especially as more third party tools are introduced.
So by making security part of your long term DevOps strategy rather than an afterthought, you can ensure that your org stays protected without slowing down development or causing friction between teams.
If we move on into the build phase now, well, security has to be part of your DevOps pipeline from the start. If security gaps exist in lower environments, they can easily make their way into production. That's why protecting sensitive data from day one is so important.
And don't forget that data security is largely controlled by metadata.
So what does this mean in practice?
Well, you should mask sensitive data in sandboxes.
Sandboxes can often contain real customer data, which creates a security risk if it if they're misconfigured or accessed by the wrong people.
Tools such as gear set sandbox seeding and data masking let teams work with realistic but anonymized test data, which protects sensitive information.
You should mask production data as it's being copied into a sandbox in order to protect sensitive information while still enabling realistic testing.
You should watch that misconfigured permissions don't create long term security gaps.
Overly profiles and permission sets could grant unnecessary access, and clone profiles can inherit insecure settings.
You should follow the principle of least privilege to make sure users only have access that that that they need.
Now Salesforce recommends starting with all grade defaults, and that's sound advice.
I've worked on a project myself where those were only defined late on and made much more restrictive at that point.
This led to a significant regression testing effort late in the project. The whole application had to be reviewed, and bugs were found late on.
Now Salesforce recommend that you start with the most restrictive settings and only open them up selectively as the need arises, and then do that through sharing rules rather than changing the defaults.
But if you don't have the luxury of starting afresh like that, then do make sure you take a really close look at the org wide defaults in the sharing settings menu in the setup menu.
And anything that's set as public read right means that any user can potentially see and edit any record of that object.
And think it's a really any business object which exists in your CRM for which you're happy with every single user in theory being able to edit. It's not a particularly common scenario, but that's what you'd enable with that setting.
Now if these concepts don't sound particularly familiar to you or others involved in the delivery features, then take time to study the data security modules in Trailhead.
It's gonna be really difficult to implement a great security model in your application if you aren't entirely familiar with the way in which data security works in Salesforce.
Far from being simply a technical consideration, security is everyone's responsibility.
So by embedding security practices like data masking and least privilege least privilege access early in the process, you reduce the chance of security issues creeping into production.
A secure foundation makes every stage of the DevOps life cycle more resilient.
If we move on now into validation, then well, fixing security issues late in development is a headache as we just discussed with the or by default a second ago. So the earlier you catch them, the easier they're gonna be to fix.
But basic code scans often miss the bigger picture. They overlook real risks in Apex and in metadata.
So security validation needs to happen in real time alongside development, but not as an afterthought.
Don't forget that developers are often system administrators in their own orgs with the associated elevated privileges, so other methodologies are required really in order to conduct realistic security testing.
So let's have a look at some of the key ways teams can make security a seamless part of their validation process.
Firstly, let's strengthen security and code reviews.
Code reviews are a natural checkpoint in development, but they often focus on functionality rather than security.
And without a structured security review, risks like excessive permissions, API misconfigurations, and missing CRUD or FLS enforcement can slip through unnoticed.
You should automate security with static code analysis.
Manual security reviews are time consuming and inconsistent.
Static code analysis, like we see in Gearset's code review powered by Clayton, automate security checks by scanning for vulnerabilities as code is written.
So the catching issues like SOQL injection, improper access controls, and hard coded secrets before they become a problem.
This shift left approach helps developers write secure code from the start, reducing the need for last minute fixes.
Now digital experiences, they're now these have been problematic areas for data security in the past.
Salesforce have timed things up a bit in recent releases, but there still remains at the core of them the concept of guests or in some of them, at least, the concept of guest users in public facing experiences, which in theory could be anybody on the open Internet.
You should pay very close attention to how data is exposed on digital experiences and, equally, your data cleanliness.
For example, a contact assigned to the wrong account may well be able to access that account's data in a digital experience.
Ultimately, the earlier you catch security flaws, the easier they're gonna be to fix. Security should be validated alongside development and not left up until the end.
If you're planning on launching on the AppExchange, for example, part of the submission is a security review. You don't really wanna find out at that stage that you've got months more work to do in order to implement security.
And the same applies if you're releasing to a production production org.
But it's it can often be your users who find these issues rather than a Salesforce invoked security scan.
If we head on now into the release stage and think about deploying changes or how to deploy changes without introducing risk, well, speed obviously matters in deployments, but tight deadlines often mean security can get overlooked.
A release that isn't properly controlled doesn't just ship new features. It can also introduce vulnerabilities that put your entire org at risk.
So security needs to be an integral and repeatable part of the release process, ensuring that every change is both functional and secure.
There are some key practices teams should follow then to make security a reliable and repeatable part of their release process.
Firstly, implementing quality gates to prevent risky deployments.
Every release should pass through automated quality gates that check from those misconfigurations, permission changes, and security vulnerabilities.
Apex offers the system dot run as method for you to create tests which execute in the context of specified users. So you should use this to enforce positive and negative test cases around data access and manipulation.
And this is made far easier when you adopt that persona based approach we spoke about earlier. These defined users can be configured in a single place in the code, and these tests can effectively be executed as those personas rather than there needing to be a or the continual assessment and reassessment of permission set assignments across all Apex tests.
You should aim to reduce human error in security reviews.
Now when teams are under pressure, obviously, rush reviews and last minute changes can increase the risk of security flaws and technical debt.
It's very easy to miss permissions updates with those misconfigurations, risky code patterns when deadlines are tight.
By baking in security processes ahead of time, like automated checks, structured reviews, standardized workflows, This helps ensure consistent quality even when teams are working at speed.
And you should keep an eye on permission creep. Profiles and permission sets change frequently, yet they're rarely reviewed in real depth.
Over time, permissions accumulate, granting broader access than necessary.
Every deployment should validate access controls, ensuring permissions remain aligned with the security policies and the principle of least privilege.
You should consider how permission sets are structured.
They permission set should be based around actions in the application, view account, those opportunity, run billing, and so forth, and contain only what these actions need in order to be achieved.
Mission sets permission sets should not be a proxy for profiles.
And in fact, you should consider moving away from using profiles for data security entirely. Now not long ago, Salesforce intended to reinforce the removal of all object and field permissions from profiles. They didn't make that change in the end, but they still recommend that applications are architected using those principles. The reason is really the same as we mentioned before for permission sets. Users are almost always looking to achieve actions rather than to be given a specific profile, I guess, unless they become a system administrator perhaps.
Permission set groups can represent collections of permissions which map much more closely to job titles, and these groups can be assigned or unassigned as needed.
Ultimately, every deployment is an opportunity to strengthen security or to weaken it. A structured release process ensures that security keeps pace with development.
Once we've released, we're into the operate stage. And here, well, a secure production environment isn't just about having a backup. It's about proactively managing risk.
Backups do provide a safety net, of course, but they're not a complete security strategy.
Now not all backups are created equal. While backups are essential for disaster recovery, the way that they're managed makes all the difference. A backup that can't be quickly restored without reintroducing security risks isn't much of a safety net.
A well managed environment should focus on minimizing risks, those misconfigurations, excessive permissions, or accidental data loss so that backups are rarely needed.
Relying solely on backups means reacting to problems rather than preventing them. We discussed at the start what that means.
We should think again here about the interplay between data and metadata.
Sharing rules, for example, are metadata, but the access they grant is stored as data.
Whilst you can't restore platform generated sharing records from backups, you can restore manual sharing rule data. So for complete security in that situation, you need to ensure that your metadata and data backups are aligned and that you back up all correctly created manual sharing rule records.
Data exports introduce new risks of their own. So backing up your data doesn't just mean it's secure. Right? When when you export Salesforce data, especially CSVs, it becomes separated from the platform security model.
And so once data leaves Salesforce, it's no longer protected by profiles, permission sets, sharing rules, or encryption, which increases the risk of unauthorized access or exposure.
You must ensure that backups maintain data integrity, security controls, and rapid recover rap rapid recovery capabilities, and that's just as important as having them in the first place.
But what else should teams be doing to protect their orgs?
Well, secure recovery and proactive monitoring.
A backup is only useful if you can restore it quickly without breaking security controls.
Recovery should maintain profiles, permission sets, and sharing rules, restoring only the data that's needed without reintroducing outdated access permissions.
Having data and metadata backups harmonized and available together vastly increases your ability to react.
Regular security audits prevent risk from building up over time.
Reviewing permission changes, API access, and metadata modifications helps catch privilege creep and misconfigurations before they become security gaps.
Don't give out access without understanding the reason.
System administrators are powerful users, and granting this profile to users to be able to debug or investigate something is largely a sign that something isn't right elsewhere in the permissions model.
You should ensure that users only get access to what they absolutely need and to do that incrementally.
You should assume that if a user has access to some data, that they're looking at it.
Ultimately, backups are your safety net and not your security plan. You should keep on top of permissions, misconfigurations, and data exposure to make sure that you're preventing problems and not just reacting to them.
And so we reach the end of the life cycle and the observed stage. So how to spot security risks before they become incidents?
As as you can probably expect, security doesn't stop after deployment.
And without continuous monitoring, risks can go unnoticed until they can cause real damage once they're in production. So the best way to stay secure is to shift left, catch issues early, tracking changes, monitoring access, and identifying threats before they escalate.
What steps then can teams take to support to spot the security risks early and prevent them from becoming bigger issues?
Well, they should track metadata and data changes.
Unauthorized changes to metadata or data can weaken security without anyone realizing it. Monitoring these changes helps teams catch misconfigurations, excessive permissions, and accent accidental data exposure before they turn into incidents.
You should set up alerts for high risk changes.
Some changes pose a greater security risk than others. Permissions to edits, API access updates, and integration changes should trigger alerts so that teams can investigate and act before something goes wrong. You should have user use context aware security reviews. Not all security risks are obvious. Now Gearset's code reviews powered by Clayton analyzes both new changes and production configs, flagging issues like misconfigured permissions, risky Apex patterns, and unsecured integrations so teams can fix gaps before they become exploitable threats.
And finally, implement observability best practices for release readiness and compliance.
You know, security isn't just about reacting to incidents. It's about preventing them.
Archiving, audit history, and proactive change monitoring help teams validate deployments, ensure compliance, and ultimately maintain long term security.
To summarize, end security isn't a one and done job.
Keep an eye on changes, access, and integrations to help you catch risks early before they turn into something bigger.
Okay. Well, thank you very much for joining me today. I hope this session has shed some light on where the security gaps may lie in your DevOps life cycle and how you can think about proactively fixing them. And so at this point, I think it's a good time to open up the q and a.
Great. Thank you, Andy. That was really insightful.
We have a question.
So if you could choose, what would you say is the most common gap that you see teams overlooking?
I think I I do think it's probably that development of of profiles and permission sets and the the the drift away from the specific role based functionality of them into something that's a bit more monolithic, let's say, where a lot of DevOps succeeds by breaking down monoliths into smaller chunks, and it's very tempting for permission sets to to go the other way. They're ultimately, like, a a business process decision, a business analyst decision to to understand the users, the user base, what permissions make sense.
Otherwise, they become too granular, you know, based on specific objects. Like, can I read an account? Well, maybe lots of users need to read an account, so it becomes almost like a pointless permission.
But then if they become too granular, it's very difficult to grant somebody an extra permission to, say, run the billing process without making them like a super admin with access to everyone's salary information or something like that, which is completely unnecessary.
So staying on top of those user personas and then tying that to a a a sort of regularly reviewed permissions model around profiles and permissions. And, ideally, like, Salesforce pulled it because it's obviously such a big change, and there was a lot of pushback. Like, I can't recommend enough move trying to move that object and field level security off profiles onto permissions.
But at the very least, the metadata API is so much friendlier with permission sets than it is with profiles. It will make your life ultimately a lot easier.
Brilliant. Thank you. So you talked about static code analysis, as one of the security checkpoints.
Mhmm.
What what are some, vulnerabilities that it captures, in Salesforce development?
Okay. Well, we could we could spend the same time again probably talking about this. I I think the one the one that probably comes to mind most and and the one that probably really demonstrates very good static code analysis tools from from the rest is the ability to track a transaction through its life cycle. So if you think about Apex for for those on the call who who know Apex well, the idea of of the with sharing without sharing modifiers on Apex classes. Now something that can spot that some a a code path is switching into a without sharing context, which implicitly means that it's got access to all the data, and all records. The sharing rules are being ignored.
That means especially if it if that's tracking back to a UI thing and surfacing data that the user shouldn't be able to see outside the the Salesforce sort of native UI, then that's that's very dangerous, obviously. But it should it should stand to reason that the if there are records that a user can't shouldn't be able to see, but they can because this this this without sharing code is being used, That that can be very difficult to spot because you have to test maybe as a specific user, and it's a narrow gap that in in the execution paths that this is surfaced through. So So static code analysis that can say, at least to you, hey.
Look. There's a way in which I can get to this point and see more data than I should be able to is is really, really valuable because that's that that could be very difficult to find and would probably be found by a user who shouldn't be seeing it. And whether they tell you about it or not, you don't know. So static code analysis will always tell you if they found these vulnerabilities.
Brilliant. Thank you. We have, one more, but we are running out of time. So worth answering this one really quickly if you can do.
I shall.
And we can send a more detailed reply, as a follow-up. But, how would you integrate security e g PMD into, legacy code base in the org, which is often an excuse for devs to bypass security? I think that's what, you're getting at there in that question.
Yeah. I think it it has to be done it has to be done sensitively and incrementally. I I think you've got to start with a picture of of what it the full thing looks like. So you've gotta do a scan on everything, and there's probably gonna be an explosion of warnings and issues and errors. You've got to then use that to pick an area to focus on, like, well, what really matters to you?
And even if it's just one or two rules to start with, focus explicitly on those, get those worked through, and then just gradually add more and more in as you go through. You're not it's not a one and done thing. I mean, that's the phrase that we've used throughout the the webinar.
Start small and make it bigger over time.
Cool. Well, thanks, thanks very much for joining everybody. If you're looking for a tool that helps you put security at the heart of your processes, then GearSec can help you on many fronts from backup and archiving to data masking and sandbox seeding, code reviews, and change monitoring. If you book a demo, then one of our DevOps experts will be happy to show you gear set in action, and you can go through this QR code that we're looking at now. Anyway, thanks very much again, everybody, and have a great rest of your day.
