Slide 1

Slide 1 text

DevSecOps: an introduction for Salesforce developers and architects Lorenzo Frattini @lofrattini getclayton.com

Slide 2

Slide 2 text

Before we start ✓ Not your typical Salesforce developer talk ✓ We’ll tour of some key questions and concepts every architect must understand ✓ I’ll share some of my work on DevSecOps for Salesforce My assumptions: ✓ You are a Salesforce developer or architect ✓ You have some awareness of secure development concepts

Slide 3

Slide 3 text

My story About me ✓ 15 years in Professional Services Delivery (8 on Salesforce) ✓ Salesforce Certified Technical Architect since 2016 ✓ Formerly CTO of a Salesforce Platinum Consulting Partner ✓ Founded Clayton in 2018 Why I started Clayton ✓ Thought SAST for Salesforce was broken (inaccurate, clunky) ✓ I wanted a developer-centric, modern way to do security

Slide 4

Slide 4 text

My work What we do at Clayton? ✓ Automated code reviews for Salesforce ✓ We help Salesforce teams ship faster and worry less ✓ 500 million lines of code processed on a typical day How are we different from other static analysis? ✓ High-precision ✓ Scan anything (Apex, LWC, Aura, Visualforce, Flows, etc.) ✓ Source-driven

Slide 5

Slide 5 text

Why should I care about security?

Slide 6

Slide 6 text

The Equifax Breach (2017) The breach ✓ 147,000 credit card numbers compromised ✓ $1.4 B estimated damage How it happened ✓ Attackers exploited a known vulnerability in Apache Struts (CVE-2017-5638) ✓ The vulnerability was already fixed upstream ✓ The application was using a vulnerable version of the library

Slide 7

Slide 7 text

Our research Security in the Salesforce Ecosystem 20% professionals with no recent security training 33% teams don’t check security before release 66% Salesforce orgs have critical security problems 68% experts who believe security risks are underestimated

Slide 8

Slide 8 text

What most people think ✓ AppExchange Security Review What I believe ✓ Cyber-attacks are in top 10 global risks according to World Economic Forum ✓ More information in the cloud = more valuable assets to acquire ✓ Apex is not secure by default ✓ More breaches will eventually happen Arguments for promoting security

Slide 9

Slide 9 text

What is DevSecOps?

Slide 10

Slide 10 text

Target Operating Model Key Ideas ✓ Release continuously ✓ Automate, automate, automate ✓ Repository-centric Adding Security to DevOps ✓ Plan (threat modelling) ✓ Code, Build (SAST) ✓ Test (Pentests, IAST) ✓ Monitor (Crowdsourced Security)

Slide 11

Slide 11 text

What is a security vulnerability?

Slide 12

Slide 12 text

Security Vulnerability An unintended flaw in software code that leaves it open to the potential for exploitation (unauthorized access or malicious behavior).

Slide 13

Slide 13 text

Salesforce-related vulnerabilities ✓ SOQL/SOSL Injections ✓ Cross-Site Scripting (XSS) ✓ Cross-Site Request Forgery (CSRF) ✓ Insecure DOR ✓ CRUD/FLS Violations ✓ ...

Slide 14

Slide 14 text

Sources and sinks How to catch a vulnerability?

Slide 15

Slide 15 text

Sources and sinks Source ✓ Any entry point for data that is not trustworthy ✓ Any user-controlled input ✓ Data from the database Sink ✓ A place in your code where untrusted data could do something bad ✓ Dangerous functions ✓ Exploitable targets ✓ E.g. Database.query()

Slide 16

Slide 16 text

Spot the deadly bug!

Slide 17

Slide 17 text

Sources and sinks: pro tips ✓ You should code review during code, build and before release ✓ If at least one path connects any source to any sink → security vulnerability ✓ Sources/Sinks may be found in separate source files → call traversal ✓ Paths are invisible to linters (PMD, Eslint, etc.) → they can’t “follow” your code

Slide 18

Slide 18 text

Vulnerable third-party components Is open source secure?

Slide 19

Slide 19 text

Using Open Source The good part ✓ There are countless reasons to love open source ✓ 100 million open source projects on GitHub in 2018 The risky part ✓ On the average project, 60% of the code is from open source components ✓ Attackers like exploiting open source vulnerabilities ✓ Most teams don’t keep components up-to-date with security patches ✓ Using components with known vulnerabilities is now an “OWASP Top 10”

Slide 20

Slide 20 text

Vulnerable components and Salesforce ✓ Third-party JS components typically used in Visualforce, Aura ✓ Using third-party components is discouraged, but still possible with LWC / Lightning Locker ✓ Most likely exploitability via JS code injection (XSS) ✓ Not picked up by the Force.com Security Scanner (Checkmarx) ✓ Static Resource Bundles may not be picked up by Retire.js, Snyk, etc.

Slide 21

Slide 21 text

Demo What we are building getclayton.com

Slide 22

Slide 22 text

Confusion Matrix How good is your bug detection?

Slide 23

Slide 23 text

Confusion Matrix ✓ Concept used in machine learning and classification tasks ✓ Useful way to compare predicted values to actual values ✓ Easy way to understand effectiveness of a classifier, SAST, etc. ✓ Accuracy, Precision, False Positive Rates can be calculated from Confusion Matrix

Slide 24

Slide 24 text

Example Accuracy How often is the algorithm correct? (TP + TN) / Total = (100 + 50) / 165 = 0.91 = 91% Precision When it predicts yes, how often is correct? TP / predicted yes = 100/110 = 0.91 = 91% False Positive Rate When it’s actually no, how often does it predict yes? FP / actual no = 10/60 = 0.17 = 17%

Slide 25

Slide 25 text

Pro-tips ✓ Don’t be fooled by number of rules ✓ Consider accuracy and precision when evaluating static analysis ✓ Low accuracy / low precision are typically acceptable with small teams and low complexity ✓ Higher accuracy and precision let you automate more

Slide 26

Slide 26 text

Threat modelling Are all vulnerabilities equally bad?

Slide 27

Slide 27 text

Threat Modelling Threat modeling is a process by which potential threats can be identified and mitigations can be prioritized. The purpose of threat modeling is to provide defenders with a systematic analysis of what defenses need to be included, given the most likely attack vectors, and the assets most desired by an attacker.

Slide 28

Slide 28 text

Threat Modelling 101 1. Entry Points What are the entry points available to attackers? 2. Asset Targets What are the assets in which an attacker may be interested? What is the business impact if they are compromised? 3. Rank and Prioritise Rank the entry points in order of value for an attacker.

Slide 29

Slide 29 text

A simple example Entry Points ● Custom Feature A (Internal Org) ● Custom Feature B (Partner Community) ● Custom Feature C (Customer Community ● Custom Feature D (Knowledge Base) Assets Targets ● Personal Data (PII) ● Transaction History ● Confidential Information Entry Point Assets Score Feature A - 1 Feature B Confidential Information 2 Feature C PII, Transaction History 3 Feature D - 1 → We can ignore any vulnerabilities in features A, D

Slide 30

Slide 30 text

Thank you Feel free to connect @lofrattini getclayton.com

Slide 31

Slide 31 text

Resources Useful Tools ✓ Clayton: AI-powered code reviews for Salesforce ✓ Retire.js Good Reads ✓ World Economic Forum’s Global Risk Report ✓ Equifax's Data Breach Costs Hit $1.4 Billion ✓ The State of the Octoverse Learning Resources ✓ Threat Modeling (OWASP) ✓ Threat Modeling 101 (Video) ✓ Sources and Sinks (Video) ✓ Trailhead: Security for Lighting Components ✓ Trailhead: Threat Prevention and Response ✓ Trailhead: Get Started with App Security