Salesforce DevSecOps: Avoiding Arrested Development
Salesforce is a feature-rich SaaS platform designed for custom development and user modification. Its business power is driven by the ease of customization from both AppExchange downloads and its massive developer ecosystem. However, when Salesforce is modified to streamline data access and boost business productivity, the application’s attack surface naturally grows, which increases the risk of data breach and violates the application’s default compliance status.
While this is true for virtually every SaaS solution that’s built to be modified, Salesforce stands out because it is a highly secure SaaS platform before modification. The process of customer customization inadvertently introduces application security vulnerabilities. This can be overcome through source code testing with the proper tools. Unfortunately, legacy testing tools that aren’t designed for SaaS testing commonly generate up to 70% false positives.
In my years of penetration testing SaaS applications, I’ve discovered most customized deployments have high-risk vulnerabilities hiding in them. Salesforce vulnerabilities are hard to detect because most security testing solutions were architected for general-purpose application security testing (AST), and don’t address the unique vulnerabilities created by SaaS customization and development.
Arrested Development
Whether downloading apps from the AppExchange, writing custom code, referencing third-party software libraries, or altering configuration settings, Salesforce users often unknowingly expand their SaaS attack surface with ongoing development and customization. This added “development complexity” is unique to SaaS and heightens cybersecurity and compliance risks while delaying development.
Protecting user data is the joint responsibility of Salesforce and its users, in general, but Salesforce is not responsible for any security vulnerabilities created by user development and customization, in particular. Users must validate and fix any development-related vulnerabilities they introduce if they wish to maintain a secure and compliant Salesforce environment.
In a Salesforce development project, the following types of modifications are common:
- Anonymous data coming from the internet using Salesforce’s Web-to-Lead or Web-to-Case feature. While this feature enables business teams, it also creates new attack vectors.
- Customized Apex controllers to handle user data and execute workloads. If the Apex controllers are not properly protected against common attacks, they can lead to data exfiltration.
- Third-party tools and integrations are common in most Salesforce deployments. This is an attack vector which is often ignored, but which can cause severe damage to the confidentiality and integrity of data in Salesforce.
- Enabling guest user accounts can potentially expose Salesforce data to anonymous internet users if not checked for security misconfigurations.
Security and DevOps teams have responded with an ad hoc patchwork of AST tools, each incapable of providing comprehensive security testing for Salesforce development. This kluge gains complexity with the addition of each tool, making the implementation of DevSecOps practices increasingly difficult.
Stop Using General Purpose AST Tools
Among the static application security testing (SAST) tools available, only a handful of source code scanners are capable of analyzing Salesforce Apex code. Furthermore, source code scanners regularly produce 30% to 70% false positives. Standalone SAST wastes developers’ valuable time with excessive false alarms.
Dynamic application security testing (DAST) and interactive application security testing (IAST) tools are often used for runtime execution analysis. IAST verifies that discovered bugs from source code analysis (SAST) are exploitable, thus significantly reducing false positives.
Another missing piece of the puzzle is software composition analysis (SCA). SCA tools detect common vulnerabilities and exposures (CVEs) in third-party software libraries, yet are rarely optimized for the Salesforce environment.
Accelerating Development: Shift Security Left into DevOps
Shifting security left in the development process empowers developers to fix vulnerabilities before they become a problem in production. Securing applications during the development process reduces risk and cost while at the same time accelerates the pace of deployment. Yet the kluge of AST tools makes it nearly impossible to integrate security into a CI/CD pipeline for Salesforce, undermining security posture while delaying the development process.
IBM found that the cost to fix a bug after product release was four to five times higher than if it’s uncovered during the design phase, and up to one hundred times more expensive if it’s identified in the maintenance phase.
To shift left, SaaS AST needs to be purpose-built. The myriad general-purpose AST tools and processes are delaying development and increasing security and compliance risk.
The Need for SaaS DevSecOps
Professional security assessments and application penetration tests are likely to produce the most thorough results when searching for security vulnerabilities. However, manual assessments are expensive and disruptive, and therefore performed infrequently – annually, at best. For legacy line-of-business applications which are rarely updated, annual assessments may be sufficient; but for SaaS environments where agile development is producing updates weekly, these point-in-time assessments are no longer effective application security coverage.
The ad hoc assembly of AST tools and processes needed to compensate for the weaknesses of each tool not only wastes time and money, but increases the risks of violating compliance frameworks, including GDPR, ISO-27001, PCI-DSS, HIPAA, Japan-APPI, SOX and CCPA. It also makes shifting security left and the implementation of DevSecOps less feasible.
The traditional software development life cycle (SDLC) does not require or prioritize security testing, but in the SaaS era, security must shift left and be integrated into DevOps as a continuous process: DevSecOps.
