Salesforce DevOps Needs Guardrails

With pandemic-induced urgency, organizations of all sizes are taking bold steps to accelerate digital transformation. To move quickly, enterprises increasingly use software-as-a-service (SaaS) apps like Salesforce, ServiceNow, and dozens of others as enterprise application delivery platforms. Unfortunately, some companies have driven their software-as-a-service DevOps process too hard, and while striving for speed, have neglected requiring security to be part of that process.

It is as if the sales executive has a shiny new Salesforce org and loads it up with rapidly developed application enhancements, tosses in a tank of nitrous oxide, and then takes it out for a spin along Mulholland Drive in Los Angeles, with its hidden hairpin curves along cliffs overlooking the city. Our rushed executive decides to floor it on a straightaway and doesn't see the hairpin turn until it is too late.

When using Salesforce applications to deliver a strategic application, you need security best practices woven into the process, from start to finish, to ensure your developers and admins don't fly off a cliff and expose customer personally identifiable information (PII) on the Internet. You need security guardrails embedded in your DevOps process to deploy customized Salesforce development with assurance and confidence. Let's find out how you can do that.

Platform Cybersecurity
A basic security measure is to have a systematic way to make sure SaaS platforms are set up properly. This task or function is often called configuration management. But getting this job done manually is growing impossibly complex, so configuration management should now be seen as a key cybersecurity concern.

In systems like Salesforce especially, there are intertwined connections of overlaid security models. When looking at SaaS configuration security packages, compare the features of their metadata-based approaches. This is where a service first ingests the metadata of the SaaS tenant, creates an intelligent internal model, and then generates a report of data security and setup concerns.

Some vendors go a step further to include a form of automated SaaS penetration testing called interactive application security testing (IAST), often referred to as fuzzing or runtime testing. In this case, the service uses metadata intelligence to create a custom runtime testing harness. This allows for periodic functional tests that determine if actual system performance matches the desired outcome.

Developer Cybersecurity
When we talk about shifting cybersecurity concerns "left," or earlier in the app development cycle, it's important that developers don't feel like all the work is shifting left as well. Application security testing (AST) on SaaS platforms needs to get easier by giving developers SaaS-specific scanning tools that tightly integrate with their development or CI/CD pipeline.

Software security tools for enterprise apps written on top of a SaaS platform usually check that any code put into the system does not introduce any security vulnerabilities. This is where a Salesforce developer mistakenly opens themselves up to a cross-site scripting or SOQL injection attack, for example. Source code scanning is known as static application security testing (SAST), and it's a basic guardrail in SaaS developer cybersecurity.

The next step up in developer cybersecurity guardrail protection is to make sure all the third-party packages and open source software libraries used in an application are secure. Software supply chain security is now a major concern with public libraries like GitHub and NPM widely in use, and new software supply chain attacks happening all the time. To address this critical concern, software composition analysis (SCA) is needed to alert developers to new Common Vulnerabilities & Exposures (CVE), which are publicly reported exploits.

To address developer needs, better API and CLI access are needed to smoothly integrate application security testing into DevOps workflows. SAST and SCA should be better integrated into interactive developer environments (IDEs) like VS Code and IntelliJ. Using advanced Salesforce security scanners should be as easy as using a language linter.

Don't Crash Off the Cliff
In 2021, the Biden administration issued an executive order mandating stricter cybersecurity practices. And more recently, as directed by EO 14028, NIST has issued its Guidelines on Minimum Standards for Developer Verification of Software, which require analysis of both source code (SAST) and software libraries (SCA), as well as mandates fuzzing and runtime testing (IAST) for its minimum application security testing requirements. All of these guardrails are now required for government DevOps.

Global enterprises should be taking these requirements seriously, not only if they are trying to deliver custom SaaS development services to the government, but also for their own protection of their sensitive SaaS data and customer PII. As PII is the No. 1 target for attackers, all industries must be vigilant and make comprehensive application security testing an integral part of their SaaS DevOps processes, especially Salesforce, which is chock-full of PII.

Caring about a data breach tied to a platform or developer cybersecurity flaw often only happens after a multimillion-dollar mistake. Manage this risk and do platform owners and developers a favor by investing in easy-to-use cybersecurity scanning tools.

Results for “"implementers"”

Salesforce DevOps Needs Guardrails