Misconfigurations at scale: Why Salesforce drift is the new Shadow IT

In this article:

Cybersecurity researchers love to raise the alarm about new apocalyptic threats. AI? It's going to empower attackers and create a wave of unstoppable malware. Post-quantum computing? Kiss all your secrets goodbye. Have you heard of the Year 2038 problem? You soon will.

But there's one massive threat that lies dormant in tens of thousands of companies worldwide, happily toiling away as its misconfigurations, poorly coded extensions and third-party apps build up a critical mass. That threat is Salesforce.

"Enterprises still treat Salesforce as an app or just a CRM [customer relationship management program]," explains Prasanth Samudrala, VP of Products at AutoRABIT. "In reality, it is a programmable platform which has its own permissions, which has its own data model, which has automation that works every day."

It's not that Salesforce itself has weak security. Quite the opposite. But Salesforce encourages its clients to customize their builds, to create their own extensions and applications, and to add third-party apps to the Salesforce platform. Doing all that creates problems.

"As soon as you change anything in Salesforce, you are now responsible for securing your information," says Lindsay Duran, Chief Marketing Officer at AutoRABIT. "As soon as you change a permission, as soon as you add a field, as soon as you change a configuration out of the baseline, you have taken over responsibility for securing that application layer."

Salesforce provides low-code/no-code development tools that let teams without much coding experience develop their own applications and extensions outside of the normal application-development processes, and often without observing application-security best practices.

"That's what makes Salesforce operate outside of traditional IT and software development structures, to be shadow IT that is often managed and worked on by people without any sort of traditional software development training and expertise," says Duran.

Salesforce is much more than an application

Salesforce started out in 1999 as just a CRM tool, and a very effective one at that. But its clients soon realized that it could handle many other business functions, including accounting, invoicing and billing, marketing, inventory management — and more.

"People are using it in the healthcare sector for patient data," explains Justin Hazard, Principal Security Architect at AutoRABIT. "People are using it in the legal sector for contracts, M&As, all of those types of things. Fintech uses it pretty heavily to manage customers and where their balances and trades are at."

More recently, Salesforce has branched into AI, business analytics, software development, online advertising and cloud services. It even owns Slack.

"Salesforce's own go-to-market strategy has been to evolve from the Salesforce core to the different industries," says Samudrala. "It's not a CRM. It's company-management software."

But in many companies, Salesforce management and implementation is handled by a dedicated Salesforce team without much input from the IT or security teams.

Management may not understand, and the IT and security teams not realize, how quickly the Salesforce ecosystem can grow into a parallel IT universe with its own application-development and identity tools, nomenclature, and practices.

For example, Salesforce has unique programming languages, chief among them Apex. It has its own development frameworks, including Lightning, Visualforce, and Agentforce (for AI), and an automation tool called Flow.

Salesforce uses something very close to SQL but calls it SOQL (Salesforce Object Query Language), and yes, there can be SOQL injections. To be fair, Salesforce developers also use HTML, JavaScript and Python.

"There are the Salesforce devs and admins that know Salesforce really well, and then you have the traditional security folks that know security really well and understand application security," says Hazard. "After a decade of doing this stuff [at AutoRABIT], we're trying to bridge that gap between the two because they don't talk the same, the vernacular's different."

Unwise practices

Isolated from the rest of the company, a Salesforce team may not be aware of common security mistakes like excessive permissioning and privileges, sloppy coding, and poor protection of sensitive information.

"You would be shocked," says Duran, "at the amount of PII and PHI data that is stored in Salesforce. Salesforce is in fact one of the largest repositories of confidential information of any solution."

Then there's Salesforce configuration drift, when base configurations change over time due to multiple small mistakes and oversights. One example is when permissions for new Salesforce users are created by cloning the profiles of existing users.

As any identity-security professional can imagine, that quickly leads to users having privileges and permissions they don't need and, under the principle of least privilege, shouldn't have. It's analogous to putting random users into a Microsoft Active Directory group that has top admin rights.

"If you are adding a new user and you would need to give them a specific profile, you're just going to copy their permission set over from a profile that already exists," says Duran. "It's not uncommon for us to see that you might have copied a profile and now 2,000 people have API-enabled access into your org, or you have given large groups of people the ability to just download all of the records in Salesforce without knowing it."

"What's old is new again, because the AD problem is rearing its ugly head again," observes Hazard. "It's just in Salesforce this time."

One way to combat permissions drift is to create templates of tools and profiles with the least possible privileges and abilities, and to clone those instead of the profiles of existing users and tools.

"You should have a baseline, bare-minimum user that you can clone, that is approved," says Hazard. "Then you add those permissions to it so that you're not going the opposite way."

Salesforce itself, as a SaaS application, has very robust security and can quickly update itself.

"The security within that Salesforce ecosystem ... is probably second to none," says Hazard. "But there's only so far that Salesforce can go into an [customer] environment."

That customer environment is almost always customized, and Salesforce takes no responsibility for misconfigurations, coding errors, or other vulnerabilities that arise because of that customization.

"No company runs Salesforce out-of-the-box," says Duran. "You have custom-built applications built on top of it and portals that are open, public websites where you can have users log in and access information."

"That is your responsibility as the buyer of Salesforce, and I think people have significantly misunderstood or underestimated their responsibility in that instance," she adds. "Most compliance teams and CSOs are surprised when they find out just how much sensitive data actually lives in a Salesforce application that they were not aware of."

Bringing AppSec to Salesforce development

One of the top reasons for this heightened Salesforce risk, Hazard says, is that Salesforce developers aren't familiar with AppSec practices and tools. And regular AppSec tools don't delve as deeply into Salesforce code as they should.

"There's a ton of scanners out there for SAST and DAST," he explains. "But nobody was really looking at the low-code/no-code space, and specifically Apex logic. We wanted to put something in place so that people could see if they're introducing vulnerabilities in their environment."

Using low-code or no-code tools to develop software shouldn't be an issue if the proper DevSecOps practices are observed, but in organizational Salesforce teams, that often isn't the case. Given that Salesforce implementations hold huge amounts of sensitive information, this lack of awareness can become critical.

"You have a group of people who are not trained in those security principles who are making decisions and making changes," says Duran.

"As you think about the ease with which people can now code and how vibe coding and using AI to code is only increasing in popularity, now you can produce a much greater volume of code," she adds. "If you don't have the proper checks in place in order to make sure that that code isn't introducing vulnerabilities, then you have a problem."

To that end, AutoRABIT has its own Salesforce-adapted static code analysis (SCA) tool called, well, CodeScan. It's tailored for Apex, Visualforce and Lightning Web Components, as well as Salesforce's unique metadata and rules.

"We scan all of the five proprietary Salesforce languages, as well as APIs," says Duran. "If you were to do a side-by-side comparison between us and another more generic tool, we are going to find and uncover a lot more security vulnerabilities and technical-debt issues within Salesforce. And we're going to have fewer false positives."

It also has a new tool called Guard that continuously checks for excessive permissions among users, apps and other Salesforce processes and identities. 

"It's scanning every production org that a company has," says Duran. "You need to be able to continuously do those scans because people are always making changes in Salesforce, so it's not a one-and-done. That configuration drift happens over time and is continuously changing."

Hazard hopes that as more Salesforce clients see the risks of poor coding practices and of blindly trusting third-party apps, Salesforce developers will quickly learn proper AppSec.

"As people start to realize what is in Salesforce, they're starting to realize that this is actually an application-security problem," he says.

"You're going to see the exact same thing that always happens in security," he adds. "It's heavy-handed at first, and then we figure out what the pragmatic approach is. And then once we figure out the pragmatic approach, then it's going to be, 'These are the best practices.'"