Blog: Webinar Recap | Architecting Salesforce Security Right in a Shift-Left World

Posted by Brian Olearczyk
Brian Olearczyk”
Find me on:

revcult webinar recap - architecting Salesforce security right

What does it mean to shift left, and why is it critically important for Salesforce security? We tackled that question in a recent webinar with three senior security leaders and Salesforce certified technical architects. 

Moderated by RevCult’s CRO, Brian Olearczyk, our guests were Lorenzo Frattini, CEO and founder of Clayton, Andrew Hart, director of technical architects at OwnBackup, and Craig Probus, director of product at OwnBackup.

In this article, we summarize the conversation from that webinar and highlight what you need to know about Salesforce data security and shifting left:

Salesforce Security Challenges: Macro Level Trends

Our speakers shared three high-level trends impacting CIOs and CISOs as the complexities around data security in Salesforce increase.

  • Volume: The digitization of business processes, paired with advancements in cloud computing, IoT, AI, machine learning, mobile devices, e-commerce, and social channels are flooding organizations with more data. Much of this data is stored in Salesforce and is mission critical. It must be protected from a variety of threats, ranging from well-intentioned but mistake-prone employees to nefarious actors seeking to do harm.

How can security leaders protect a torrent of data from a growing list of threats...and protect their businesses from the consequences of data breaches?

  • Variety: Data has different levels of sensitivity, ranging from public to highly confidential. Organizations must understand the different types of data held across their SaaS apps and put controls in place to ensure its security and resilience. In many cases, these initiatives must be met to comply with industry-specific or government-mandated regulations, such as SOX, HIPAA, PCI DSS, GDPR, etc.

How can security leaders understand what data they hold in Salesforce, who has access to it, and how much damage can be done?

  • Velocity: The speed with which data is being created is increasing at exponential rates--at the same time. It’s estimated that by 2025, 200+ zettabytes of data will be in cloud storage around the globe.) Additionally, stakeholder demands for rapid value and complex requirements are pushing CIOs and CISOs to accelerate digital transformation, without sacrificing with secure and reliable DevOps processes or regulatory compliance.

    How can security leaders safely leverage their data to accelerate digital transformation?

For CIOs and CISOs, these trends translate to an increased scope of responsibilities, and a need for better security controls. 

Risks to Customer Salesforce Orgs

These macro trends have significant implications on the Salesforce application, which has evolved from being a siloed platform that supports a line of business into a holistic, strategic tool used by the entire enterprise. Here are some key stats from reports published by OwnBackup, Clayton, and RevCult:

  • <1% of customers have been successful at classifying data in their Salesforce orgs
  • 18% of fields qualify as high-risk 
    • 95% of those high-risk fields aren’t tracked (no one knows how they’re used!)
    • 44% high-risk fields require some type of encryption and aren’t fully encrypted
  • 2 out of 3 Salesforce orgs have vulnerable code deployed in production
  • 89% of organizations don’t fully recover their lost data after an incident

Each of our speakers had some advice on the current risk landscape:

Craig Probus: “You need to have an inventory of what your data model is doing right now. If you don’t, it can be scary.”

Lorenzo Frattini: “The state of Salesforce security is very concerning. Most teams have vulnerable code deployed in production, and most are not even aware of it.”

Andrew Hart: “The asset is the data; it's the data that is exploited. If your Org lost even 100 accounts with all of the related data, how long and how much effort would it take to get back to where you were? When you think in those terms, it shines the focus left.”

Sources: RevCult | What 2020 Revealed About Salesforce Data Security;  Clayton - The State of Secure Development in the Salesforce  Ecosystem (2020); OwnBackup | 2021 State of SaaS Data Protection

Shifting Left: What Does It Mean?

Shifting left is the change every company needs to make in the way it builds software and ships innovation. The idea is not new, but has recently gained momentum.

Elements of the Shift Left Model:

  • Security by Design - Plan first, then develop
  • Threat modeling (debuted at #4 on OWASP ’21 Top 10 List)
  • Source-driven development
  • Async pull requests (don’t block developers)
  • Test continuously
  • Automate everything!

In our webinar, Frattini provided a baseline definition of what it means to shift left: “In the traditional software development model, all aspects of quality and security assurance are dealt with late—for example, right before a release or once a year during an annual security review. In this model, you are addressing the security risk, but sacrificing velocity and speed.

“In the shift left model, you embed all aspects of quality and security assurance early in the process. This means doing security validation early and continuously. You address security risks, without giving up velocity or speed.”

The below diagram illustrates the differences between the traditional security model (gray) and shift left model (blue). Shifting left moves security considerations “up” into design and development stages, and delegates repetitive tasks to automation. So, the term applies to both processes and tools.


Shifting left clearly has significant strategic value, in regard to the speed of execution and innovation. It is ultimately about maintaining your velocity without increasing your exposure.

What Have Salesforce Security Risk Assessments Revealed?

While Salesforce’s organic growth as a mission-critical, enterprise-level platform has been beneficial from a business perspective, our speakers discussed how that growth can be detrimental to data security. Here is what security risk assessments, across different organizations in varied industries, have revealed:

Cross-Functional Blind Spots
Many organizations fail to understand that Salesforce is a system of record, supporting the sales and customer journey, and leveraging sensitive customer data. This results in blind spots such as:
  • Profile & Permission Set Sprawl: Most Org security models have grown organically, without a plan. “This allows you to build great functionality, but also allows too much sprawl,” noted Probus. “And it's very rare that anyone is incentivized to clean up and maintain profiles and permission sets because it’s probably going to break something and therefore a high-risk activity. Plus, it's also not very exciting for most architects and developers to take on profiles and permission sets.”
    But you have to do it. Having the courage to take on and manage profile and permission set sprawl will eliminate a major blind spot in most Orgs.
  • Revenue Recognition Issues: Salesforce is becoming a system of record. If you're managing your billing in CPQ, and your annual subscriptions, then you create a contract record in Salesforce. And that will expose you to more finance-related tension than you had in the past.
  • No Security Layer for Communities/Experience Cloud: A big growth area in the Salesforce world, particularly because many organizations rushed to digitize their environments in the wake of the COVID-19 pandemic, Experience Cloud, AKA Communities, is a powerful platform. But opening pathways to Salesforce data outside your organization can expose sensitive information, like PII, and greatly complicate your security model. Adding an additional level to the security model for Experience Cloud is rarely planned for, but must be done. 

No Playbook
Most enterprises lack clear security programs, as well as the habits, disciplines, and specific Salesforce security expertise they need to implement the proper security controls.

Gaps in Tooling
The results from our risk assessments showed that security teams are often missing what they need to get the job done right. The right tools include org backup and restore, data anonymization, static code analysis, data classification, and user access configuration.

More Evidence to Shift Left - Pitfalls in Code Review

Teams of all shapes and sizes build on the Salesforce platform. And even the best of the best can fall prey to security vulnerabilities at the code review stage. Frattini shared these common pitfalls from his experience working with countless Salesforce development teams as further evidence to shift left:

Development Blind Spots
Security vulnerabilities are often holistic; they’re rarely located in a single place. They are emergent, and this makes them tricky.

Many developers start by thinking that the Salesforce code is secure by default, but that’s not true. Because the platform is so flexible and broad, it's very common to introduce vulnerabilities. Vulnerabilities can be introduced with any config, code, and third-party dependencies, not just Apex.

It’s critically important to understand this fact, and the implications of the shared responsibility model, because you won’t be looking at security in the appropriate way otherwise.

Ineffective Peer Reviews
The concept of peer reviews is a fundamental idea embedded in the Salesforce product itself. But because security flaws are holistic and emergent, it's easy to overlook them in peer reviews, for both technical and practical reasons. Security is difficult to get right and doing peer reviews is a good practice, but be careful not to get a false sense of comfort from them.

Linters For Security
Linters are great tools that help Salesforce developers with the syntax and style of their code, but they are not designed for security scanning. 

To find security problems, you need to look at flows, components interactions, software composition, dependency analysis, and more. If you use tools like PMD and ESLint to perform those security scanning functions, expect partial coverage and a high false-positive rate. For larger development teams at the enterprise level, this will mean a lot of noise and overhead.

“We see a lot of teams failing to shift left because they either don't invest in the tooling for the job, or they overlook some of the tradeoffs,” explains Frattini. “There is no right or wrong way to handle security, but teams should be equipped to make the right call and understand the implications. At the end of the day, what vulnerabilities do is put data at risk.”

Top 5 Code Vulnerabilities in Salesforce

Source: Clayton - The State of Secure Development in the Salesforce  Ecosystem (2020)

It Starts—and Ends—With Data

When there are security gaps or vulnerabilities of any kind, the end result is exposed, corrupted, lost, or incorrectly used data. Hart broke down what to keep in mind when thinking about shifting left to secure your Salesforce data:

Unclassified Metadata =  🚩 🚩 🚩 🚩 🚩 🚩
When it comes to the data model, how do you know the appropriate actions if you have unclassified attributes? Security, access, encryption, testing, seeding, migration, OWDs, customization, and configuration are all driven from an understanding of your data and its sensitivity levels.

To shift left, you should be classifying metadata when it’s designed. It should be part of the requirements, the user stories, so that it’s very clear—very early—the implications if that data is breached.

You’ll Pay at Some Point
There is a saying in the aviation industry that if you think safety is expensive, you should try having a crash. Data governance is the same—it’ll cost you at some point. 

You can take control of it early, in a predictable way (like spending a few minutes on threat modeling). And the additional time will indeed cost you, but you’ll be in control of your application security and avoid the more unpredictable spend in the future. Or you can leave your Org unchecked and pay in lost productivity, lost records, security implications…even regulatory fines, should your vulnerabilities become that visible or severe.

Know Your Data
If you don’t know the lifecycle of your Salesforce data, you won’t be able to fully understand the security implications as it goes from creation, through integrations and enrichment, dormancy, and eventual archiving and purging. If you don't understand that full journey, you won't be able to properly do a threat assessment.

“COVID and remote working didn't fundamentally introduce security gaps.What it did do is have people working in isolation. So, be they developers or users, they don't have that person next to them they can tap on the shoulders. "Is this field sensitive, or is this the record I should be deleting?" And that actually drove some behavioral changes that put a different spotlight on security because there wasn't the control and the peer-governed approach to development and use that existed when everyone was in the office.”

Andrew Hart, Director of Technical Architects, OwnBackup

6 Short-Term Things You Can Do Today To Shift Left

What’s next if you’re ready to shift left with your Salesforce security model? Think long term, but start short term:

  1. Know Shared Responsibility
    Salesforce is responsible for security of the cloud; you’re responsible for security in the cloud (data, end points, account access and management). The shared responsibility model, as it relates to data, is true for security as well. Take time to educate your business stakeholders and product owners, so they understand that, too.
  2. Inventory Assets
    Create a list of your most sensitive data (this is not an external data dictionary). Salesforce has the tools to easily view your build, your data model, and other components—inventory everything you have that is responsible for the creation, manipulation, or storage of data, and see what that exposes. At a minimum, consult with Compliance as your guide.
  3. Make a Secure Development Checklist
    Make a short list for your repetitive security checks and use it to peer review all low-code, pro-code changes. Identify the key areas of vulnerability, or security areas that are essential to get right. Make it easy for developers to know the basic level of assurance that every development needs to go through.
  4. Do Threat Modeling
    Meet with stakeholders to make headway on developing a security program for Salesforce. Use existing architectural diagrams (or even free tools like Salesforce’s Schema Builder) to review the specific fields that will be involved in the code changes in your sprint or release. This is a low-effort, high-reward project. According to Craig Probus, you should have this anyway as an architect. "Don't be lazy!" he advises.
  5. Get a Lock on “Usual Suspects”
    At a minimum, get a handle on the “usual suspects” of system permission in Production: view setup & configuration; create & customize reports; export reports; view all: custom settings, data; send outbound messages, etc. Review who has access to those permissions. 
  6. Create a Staging Environment
    Do you have a Pre-Production environment that looks somewhat similar to what your Production Org looks like? Have a simple test suite to validate basic security controls in a staging environment to mimic what will happen when changes are deployed. 

3 Tips For Thinking Long-Term About the Shift-Left Model 

To wrap up the webinar, our guests gave their final takeaways and advice for shifting left with Salesforce security.

Andrew Hart: Build habit. Be the voice of security.
“Be that voice who says ‘Isn’t this a sensitive field? What are the security implications?’ or ‘Yes, we do need that Flow or Apex class—how do we secure and limit access to precisely what we need?’ The more people that ask these questions, the more the entire DevOps setup moves left.”

Craig Probus: Classify & monitor.
“Classify your data in Pre-Production and then upload to Production as part of deployment. (Cloud Security Cockpit® can help you do that.) Then, create a program to monitor sensitive System Permissions.”

Lorenzo Frattini: Simplify.
“Make security easy for your developers. We need to make sure our teams are never blocked by security.”

Remember, shifting left doesn’t have to be a huge undertaking. It can be a small level of additional effort early in the cycle that will pay dividends in the long term.

Watch the webinar, or listen to the podcast

For the complete webinar, click here to watch the on-demand recording and here to listen to the audio on our podcast.

Here's more to explore:

Topics: Blog, Articles

Subscribe to the Blog