DigitSec and UST Global host webinar to help secure Salesforce Orgs
Watch the full webinar above to learn about security assessment challenges, the shared responsibility model, common security threats, Salesforce security scanning and more!
Salesforce is secure out-of-the-box but becomes less so with every modification. Salesforce modifications can introduce security vulnerabilities into the environment which is your responsibility, as Salesforce is not liable for security from user changes.
Waqas Nazir, DigitSec CEO and Meera R. Nair, UST Global Salesforce Architect & Salesforce MVP 2021, dive into security assessment challenges companies face. Those can include:
- Available tools support code scanning only
- Generic scanning tools not built for Salesforce
- Needing multiple security tools
- Complex CI/CD plugin process
Salesforce Security is a Shared Responsibility
Many companies may not realize that Salesforce security is a shared responsibility. As
Waqas states in the presentation, Salesforce is built to protect your data but the modifications you make shift the security liability on to you. Salesforce is responsible for the security of applications, network controls, operating system, etc. But as the customer, you’re responsible for the security of information and data, adhering to relevant compliances, custom code/libraries and more.
Waqas and Meera then talk about the state of security and how ransomware attacks, and the money that along goes with them, are doubling year over year. Meera also goes over common security threats while Waqas shares statistics on the biggest vulnerabilities seen in Salesforce environments. We even get to see a real-world use case for an internal access bypass and external SOQL injection.
Salesforce Security Scanning Finds Vulnerabilities
The presentation shifts to how DigitSec’s S4 and UST Global’s security options mitigate security risks. S4 has a 4-step source code security scanning process, it’s purpose-built for Salesforce, it reduces false positives and provides suggestions on how to fix vulnerability issues. UST provides four different security offerings that include comprehensive security assessments, briefing of findings, high-level plans for fixing critical security issues and more.
In the end, security for your Salesforce Org is a non-negotiable and this webinar sets the stage for how to solve for security within your environment.
Check out the webinar transcript below to read the full details of Waqas and Meera’s discussion!
Adrian Szwarcburg from DigitSec:
Hello, everyone. Welcome to a joint webinar between DigitSec and UST. We’ve had a lot of people register for this. The idea of this is to be a knowledge-sharing webinar. We have some great speakers today, Meera from UST, who is a Salesforce MVP, and Waqas, who is the CEO of DigitSec, to talk about how to secure your Salesforce environment more correctly, and with more diligence than maybe some of you are doing today. We hope you find this session very useful for you. I’ll hand it over to a Prasan to say a few words from UST. Thank you.
Prasan Vyas from UST Global:
Thank you, Adrian. Good morning. Good afternoon. Good evening. Whichever part of the world you’re in. Thank you for joining this webinar. We hope this will be a of value and of interest to all of you in the Salesforce ecosystem. We all are Salesforce evangelists, so it’s wonderful to have you all here. Part of UST is a Salesforce Gold system integrator partner of Salesforce and we have partnered with DigitSec to bring you this webinar. We have had a number of Salesforce ecosystem partnerships, but with a 500 people practice, we like to focus on some of the key ones like DigitSec to bring the most value-adding partner and partner offerings in the Salesforce space for all of you.
So without much further ado, I’ll hand it over to Meera and Waqas, the two key people on the webinar today. Enjoy the show and we look forward to good interactive talks and discussions post-webinar as well. Thank you all once again for joining and over to you Meera.
Meera Nair from UST Global:
Thank you so much Prasan and Andy for the introduction. So like Prasan mentioned, UST has around 15 years of experience in supporting many large Salesforce instances for multiple customers in various Salesforce platforms. We engage with customers in multiple ways, which includes ongoing development, support of new Salesforce instance implementation, new cloud feature implementation, new feature implementation, and also Org analysis to suggest areas of improvement.
As part of all the analysis, we assess multiple aspects of current implementation of an instance like governance issues and implementation issues. Since Salesforce is coming up with innovative integration approaches, it is very important for us to assess our existing framework and upgrade it with the latest features for better performance and easy maintainability. Also many times we have seen that governor limits related issues faced by many instance are because of bad framework, bad trigger framework and not following development best practices. Also components for deprecated features can also cause performance and maintenance related issues in the system. So it’s critical to remove those from the system.
We also have to identify components causing performance issues. In addition to this, monitoring and exception handling mechanism are also equally important to maintain good health of an Org. So we assess a better framework to handle this. And security violations come on top of all these issues. Later, Waqas will be giving more insights into why damage security violations can cost you an Org and suggest improvement ideas to fix each of the identified issue. In addition to performing security review, as part of an Org analysis during the development process, we will be performing static code analysis to make sure we are following all coding best practices and this checking is also part of security process to make sure components are not getting deployed in case of any critical violation.
If you had an ISV partner, you know that passing Salesforce security review is a critical phase of app exchange listing. In the past, we have faced multiple challenges with the internal security review process. Like many of the available tools, they support core scanning only and if you need to do scanning on configurable components, it’s not easy. And with most of the generic scanning tools, if we need to customize it for Salesforce specific rules, we end up in creating our own rules. Most of the time for Salesforce security scanning, a single tool is not sufficient.
If you need to perform Org analysis, most of the time we need to download components stored in your local system, then perform the analysis. But for implementations, it’s very difficult to download and perform or execute it locally. But again, the process is not simple and with most of the existing tools you might end up creating or writing complex script logic to handle this. And if you’ve got that old Org, it’s difficult to find unused or deprecated certificates and static resources because most of the time we have seen as part of static resources, you have old versions of JavaScript which can affect your security.
Andy Montoya from DigitSec:
Andy, from the DigitSec side here with our first of two polling questions. I will go ahead and launch it. And I would ask that you please answer, “are you currently doing any security scanning of your Salesforce environment?” I’ll give everyone a couple of seconds to be able to answer. You should see the screen in front of you and I can already see the answers coming through. At the end of the pole, I’ll go ahead and share so that way we can see where everyone is. We’ll take another five seconds here. Okay. And here we can see the results. We can see that it’s split, reinforcing the need for security scanning of your Salesforce environment.
Meera Nair
Thank you Andy. So I would like to ask something to Waqas. So Salesforce as a platform has got its own features to handle Salesforce security. Then why as a customer or as an implementation partner, why do we need to take care of security?
Waqas Nazir from DigitSec:
Thank you, Meera. That’s a great question. And I think that’s a very important question to answer from a security perspective. We’ve seen that a lot of issues come when this understanding does not exist between somebody who’s consuming a platform like Salesforce and the provider, which is Salesforce in this instance.
So Salesforce has a shared security model, which basically means that between Salesforce and the customer that using Salesforce is a joint responsibility to make sure that their data is secure. And this is basically laid out in Salesforce security guide, which basically says that anytime you add any customization to your environment or make changes to your environment, you as a user are responsible to make sure that they’re secure. So unless this understanding exists, it is very hard for any user of Salesforce to secure their environment.
So if you look at what a SAAS provider is responsible for versus you as customers are responsible for it, it’s laid out in this easy to understand graphic. Salesforce as a provider is responsible to make sure that the network is secure, the operating system in which your application is going to run is secure, there are no issues with the physical hosts, the data center is secure, and the application that is built by Salesforce out-of-the-box is secure. But you as a customer or we as customers are responsible for making sure that when we put our data into Salesforce, it is actually secure from a perspective of not being able to be executed or accessed by malicious users and things of that nature.
When we add data to Salesforce, we are responsible to make sure that we have all the controls in place to make sure that data access is compliant. When we start writing custom code or adding new integrations within the Salesforce environment, we as consumers are responsible to make sure that our code is secure and we’re not adding any vulnerabilities into the environment. We as customers are responsible for making sure that the identity provider that we’re using, the identity studies that we’re using, and the session settings we’re using, are secure. And then lastly, we as consumers of an environment are ultimately responsible for our data that we put into the environment. And if we make any mistakes, we will be ultimately responsible for causing that harm within our Org.
So if you look at the general state of security, we will understand what’s happening in the world. Generally, we find that a lot of exploits today are just happening for a reason of committing crime and profiting from someone’s vulnerability. So a lot of the attacks now are geared towards a financial incentive. Average data breach costs in the U S can be up to $8 million. We seen that ransomware attacks are up by 150% last year, and this is projected to double this year. And now we have these services, which are basically ransomware as a service where you actually don’t need to create ransomware. You can just rent it for as low as $39, and sometimes you don’t even need to pay anything. You can just use the ransomware and the creator of the ransomware gets a card when you get paid.
We know that the cyber crime industry is $3 trillion and is projected to grow. We also know that there are some times ransoms being paid, which don’t make the news. For example, sometimes as low as $40,000 could be paid and it never makes the news because it’s not a big enough impact. Hackers are becoming very innovative. They’re starting to do double extortion. So they will not only take your data locally, but also encrypt your data as in the backup and then threaten you to release that data so that you get compliance fines on top of it.
Now, interestingly, Salesforce contains a lot of PII, so it’s a very attractive target for hackers and malicious users. And we know that if you disclose PII and it’s a mistake on your part your fine can be 4% of a company’s revenue. So as things are progressing, as Salesforce is becoming more pervasive, the security of that environment is very important. So then I’ll turn it over to Meera to talk about some of the common threats that we see with Salesforce implementations.
Meera Nair
Thank you Waqas. So in the slide, let us see some common security threats that we have seen in Salesforce implementations in the past. One of the main security threats is authorization or access bypass. It can be because of multiple reasons. We have listed a few here, like Apex Classes without sharing keyword. In this case, current user access is bypassed and core will be getting executed in system context, and all records will get processed violating current user access. We can see a use case later. If you are not taking current user permission before doing insert update or delete permission inside an apex class, there are high chances that users who actually do not have access to perform this operation can still perform it using Apex and you’ll end up in serious security issues.
When you’re executing SOQL coding, there is the Salesforce practice that you should utilize security enforce as part of the query. It’s to make sure current use field of security and object access is taken care of during query. If you’re not following this, users will get access to additional field data. Storing sensitive data in code is also a serious threat. We have seen many times people hard coding sensitive information like passwords to connect to an external system or access tokens, encryption keys, or even Personally Identifiable Information as part of apex code. Anyone who is getting access to your code can retrieve this kind of information very easily.
Passing sensitive information through url is a serious threat and hackers will be able to easily phish this kind of information. A SOQL injection is another kind of threat. This is caused by dynamic SOQL or SOSL that accepts user inputs. This is again a very common serious vulnerability that can happen with dynamic queries where user inputs are not getting validated and users can input any kind of string that can modify the SOQL statement and trick the application into performing unintended commands.
Usage of old JavaScript or Bootstrap libraries also will cause issues to your system because there might be known issues with these libraries and if you use these as part of your application, there are high chances of security threats. Another threat is related to external attacks. If you have a community or Experience Cloud implementation, guest users, partner users or customer users can get additional data access in the system because of misconfiguration or code issue. This is more critical than internal threats because external facing data is very sensitive. Later, we will see a use-case for this.
Andy Montoya
Hello everyone, Andy here again for your second of two polling questions here. Given all the threats that will Waqas and Meera have discussed, we’d like to ask “do you have security measures in place to protect yourself against these common security threats?” Again, I’ll give everyone a couple of seconds here to answer, and then we can all take a look at the results after. I’m seeing the answers coming in. I’ll give everyone about another five seconds. We’ll go ahead and close the poll and I’ll share the results. That is good to see that over half of you do have measures, but there’s still some that need to add additional protection. Thank you.
Meera Nair
Waqas, since you have done analysis of a Salesforce instance for these kind of security threats, it will be good to see some statistics around this.
Waqas Nazir
Sure, thanks Meera. So as Meera mentioned, some of the common threats that exist within Salesforce implementation, we also see that there’s a trend in our analysis of hundreds of scans that have come through our platform. We see that the most common threat is around authorization, which is basically not enforcing proper permissions on code. 47% of the time, this is the type of vulnerability we’re seeing. It stems from fact that people don’t understand that Salesforce code runs with a system permissions by default and developers need to enforce access checks and things of that nature.
The second most common thing that we find is a lot of misconfigurations with deployments and that’s roughly 18% of the issues we deal with – common security misconfigurations – which are easy to fix, but are very critical from a security perspective. We also see a lot of third-party libraries within environments. This is your static resources, which are not updated or are being used with components like Bootstrap and jQuery, which have known exploits. So attackers know how to exploit those environments by just using those publicly available exploits. So 10% of the time we see that. We also see cross-site scripting pretty commonly, roughly 8% of the time.
SOQL injection which is a very interesting attack, seen about 4% of the time. Data leak is about 3% but it could be very critical from a security perspective. So if you’re leaking personal information or financial information or health-based information from this, it can cause a serious harm to your company. And then there’s some other issues like cross-site request forgery, having hard coded secrets, escalation of privileges, weak cryptography and open redirects. And roughly about 2% of the time we’ll see these exports.
We’ll walk you through a couple of real life threat scenarios and Meera will direct over them. The first one deals with how an internal malicious user or an attacker would attack a Salesforce deployment. And then the second one Meera will share would be from an external standpoint, how an attacker could potentially gain access or more access to your Salesforce data. So with that, Meera why don’t you walk us through these threat vectors.
Meera Nair
Sure Waqas. So in this use case, we can see how we can get access violation if proper security checks are not happening within your Apex code. So here you can see, I have got the home-based component, which is created utilizing LWC. The user will be able to select a particular account. And once the account is selected, I will be getting a screen to create a new contact under that particular account.
So you can see once the account is selected, your user will be getting a screen to be able to enter information to create a new contact. This is an internal admin user so he definitely has full access in the system and was able to successfully create new record. He’s entering all the record information, like first name, last name, email, and phone number. Once the data is entered, user will be able to click on create contact and they will be getting a popup, which says contact creation is success or if it is a failure. Okay, here you can see the contact got created successfully. Since it’s an admin user, there is no issue with that execution.
Now let us see another user called asset user. This belongs to a custom profile called asset management profile. And if we opened this profile under the access for custom or standard objects, we can see that for contact this user or this profile has just gotten real permissions, meaning he would now be able to create, update or delete contact records. Now in another window, I have loaded as this particular asset user. This is the asset user and on the homepage for this user, we will be able to see the same component. But this can be because of a configuration issue. The component is still visible for the asset management user. Now let us see what is happening when he is selecting an account and trying to create a new contact. Since he does not have permission, what we would expect is the creation should be a failure. But in another scenario, the apex is not properly validating the access of the current user.
In that case, let us see what is happening. Once he’s clicking on create contact. You can see the current contact was created successfully, irrespective of if he has access at the profile level. And we can go and verify this at the account level, you can see that the contact got created successfully and it is visible under that particular account. So this is a serious internal security threat. The user was able to create the contact even if he does not have access to create that.
Now we can see an external scenario. I have got a partner account created. As part of this partner account, I have got a contact also here. We have created an experience site for partners. It’s basically a partner community. Well, this particular contact will be able to log in. For that, let us go to this particular contact detail page. You can see a log in to experience as user option at the door. Using that option, let us log in to the portal. This is the site creator for partners and on the screen again you can see a custom component here. This is where a user may be able to search for a contact listing by entering the last name. Since it’s the partner user configuration he should be able to see only contacts belonging to his partner.
But here you can see once we do the search, he is able to see contacts even from the internal account, which is a serious access violation because he is getting additional data access here. Now, let us perform another search where the user is trying to modify the query itself. Instead of last name, he is trying to use a string to use first name like Smith or active equal to no or email like Gmail or first name like John, meaning a combination of source filtering he is trying to enter here.
Let us see what is going to happen. If you’re properly validating the input, the code should not give us any results. But if you’re not validating the input string, you will be getting all the records based on the user entered criteria. You can see your records with domain as Gmail, users or contacts with the active equal to no, even with first name as John, and you will be able to see the record. This is called a SOQL injection where users will be able to modify the string. And if you’re not properly validating, he’s going to get additional data access or additional data filtering option. So since we have seen these internal and external threats, I would like to ask Waqas how DigitSec will be able to identify these kind of issues.
Waqas Nazir
Thanks Meera. So one of the challenges as Meera mentioned is making sure that when you’re deploying custom code or custom components, you’re not exposing your data to malicious users, whether they’re internal or external. And a challenge exists on how to do this at scale when you have multiple developers writing code all the time, making a lot of releases with the proliferation of DevOps tool and development tools. We find that the velocity of deployments has increased. So there’s more changes that are happening in a shorter amount of time. Our product is designed to find these bugs, as developers are making these changes and as they’re pushing things through their pipeline.
And here’s an example of the first issue that Meera shared, where a piece of code is not validating a user’s permissions before inserting a contact type record. Our product basically gives you a walk through of how this class gets initiated, what is the function that has been called, what are the parameters coming into this function, and where is the actual DML statement happening. It makes it very easy for a developer or an architect to look at this and see there is actually an issue that they should fix prior to releasing this into production. It’s an easy way of identifying this at scale with your DevOps practice.
Next, we will look at the second issue that Meera shared, which was in relation to an external threat where not only the user permission validation is not happening but also there’s a SOQL injection issue. So since our product has the ability to look at a Salesforce environment within its deployment context, we can actually tell that this controller has a SOQL injection and it’s actually exposed as well. So you can see there’s two screens. One screen is taught, basically walking you through the SOQL injection issue with a detailed trace of the class, the method and where the input is coming from, and then where it’s actually getting executed as a SOQL statement and where the injection is. But also on the bottom right you see there’s a small screenshot, which basically shows that this particular controllers are exposed to the guest user profile.
So combining these two things, you can see that this is actually an external SOQL injection. So now you can actually triage it at a higher severity and fix it. So we, as a platform, allow companies to look at their security holistically and we do this by doing four key things. Most Salesforce security scanning focuses on one or the other, and they’re not able to give you a complete, accurate picture of your security posture for Salesforce. Our four-step process includes reviewing the source code, looking at the things that we find in the source code to then feed into our runtime analysis which is basically simulating a hacker to validate whether the things that we found in the source code analysis are actually exploitable or not. Much like the way Meera demonstrated how a malicious user can try to get more data.
So the second step is basically validating our findings that we find from the Salesforce code scan and also simulating a malicious attacker.
Then we look at all the static resources within a Salesforce environment, whether they’re are part of your local development or remotely referenced, and we identify known vulnerabilities with that. And then the last thing that we do is look at the configuration of the environment to give you the overall threat picture. What’s exposed, what’s not exposed, what’s the real risk behind a bug – and that gives you a perspective on what needs to be fixed and triaged.
All this has done in the cloud and it’s efficient. It can scale as you scale your environment. We reduce false positives by using a runtime analysis so there’s accurate findings out of the process. We then allow you to be plugged in to your DevOps platforms and our findings have detailed recommendations on how to go about fixing those things. So with that, I’d like Smitha to talk about some of the ways that we can help companies secure their environments and keep them secure as they make changes through their life cycle.
Smitha Nambisan from UST Global
Thank you Waqas. This is the UST offering powered by DigitSec’s S4 for Salesforce. As you can see on the slide, we offer a variety of options to engage. For more details, please email us at the address given below, and we will get in touch with you right away to discuss your specific needs. And now Andy will take us through to the Q&A segment of the webinar.
Andy Montoya
Absolutely. Thank you, Smith. So we do have some questions that came through, and again, if anyone has any questions on anything in the presentation, please use the Q&A button down there at the bottom of your zoom screen and we’ll be happy to answer. I will be asking these for Waqas and Meera to answer. The first question being: what is PII?
Meera Nair
Waqas may be able to add more, but it’s basically personally identifiable information – any data element by which we will be able to identify a particular person in the system. It can be a person’s name, it can be a unique identifier, or it can be anything associated with that user. Waqas would you like to add anything?
Waqas Nazir
No. I think you did that very well Meera. So any piece of element that could be used to uniquely identify an individual, whether that’s a phone number or an email address, and anything of that nature – or a financial record or a health record – is PII.
Andy Montoya
Thank you both. Next question: Can we get a recording of the session? Absolutely. Every registration whether they attended or not, we’ll be able to get a recording of the session by next week. Our next question is: For a small or mid-sized company, how often should a security scan be done? Once a week, once a quarter, annually?
Waqas Nazir
That’s a great question. So I think it depends on the model changes that they’re making in that environment. Ideally, they should enable security all the time because there are new exploits coming out regularly in the public space. There are new bugs being reported publicly. So even though you may not be making changes, the world around you may be changing.
So it’s a good practice to place controls in an environment which are available all the time. Continued security is the best option. So enabling your environment to be looked at daily should be the best practice or whenever there are new changes being made. Also, we recommend that our security be enabled all the times and it shouldn’t be done at one point in time because you can do it today but tomorrow you may be vulnerable again.
Andy Montoya
Thank you. The next question is: Does DigitSec have external software which scans these loopholes? I imagine they are talking about the security threats.
Waqas Nazir
Our platform is available externally. It is a cloud-based service and it can be utilized by anyone that wants to use it. We also offer a trial where companies can come and do a quick assessment on their own time and get a high level understanding of the number of issues that may exist within their environment. And then they can engage with us and look at the details of those findings and things of that nature. So the tool that we have is a cloud based service, which is available externally.
Andy Montoya
Thank you. Next question is: I have a code analysis tool, including Salesforce Shield, in my Org. What extra features can S4 give to aid security?
Waqas Nazir
That’s a great question. So as I shared, our approach to security is that we want to give you accurate understanding of your environment. So we look at not just the code, like a static code analysis, but we actually simulate an actual malicious user in an automated fashion trying to exploit the issues that we found through a code analysis. So not only do we do code analysis, we actually verify those bugs through that analysis, which no other platform does. On top of that, we also look at third party risks, which code analysis tools don’t do. And you can have an understanding of the third party risks within my Salesforce deployment.
Then we look at configuration which can help verify the things that you’ve put in place from a Salesforce Shield perspective – that you’re actually not missing out anything. So think of us as an assessment tool that can verify whether you’ve implemented controls accurately within your environment or not. Also the benefit of using us is that we give you a complete threat picture of your Salesforce environment and then you can refine your deployment you’re implementing with Shield to make sure you’re catching the right issues within your event monitoring and things of that nature. It enhances your usage of that product as well. We of course do much more than code analysis as I’ve shared.
Andy Montoya
Thank you a Waqas. The next question is: Can we have some scenario explained for usage of old JavaScript/Bootstrap libraries?
Waqas Nazir
Meera, you want to take that?
Meera Nair
Sure Waqas. What we have noticed as part of custom code we have seen is people are placing very old JavaScript libraries which have known vulnerabilities. So like some operations or some kind of checking, which is available with the latest version, is not supported in the old versions. You might be seeing those kinds of issues when you are doing specific operations. Waqas if you would like to add something else, please go ahead.
Waqas Nazir
I think in those cases, you can isolate the vulnerabilities. So if there’s absolutely no way of updating your core to work with the new libraries, then there’s an approach to isolating the vulnerable code which is a bit more involved for the developer. They can ask what are the issues with this old library and can someone exploit them. It may be a case where you find it’s not exploitable, then you can absorb that risk.
But if it is exploitable, then you have to make the case to put this on the roadmap and remove this old library from your development. We may have to make more changes in the existing code base, but that’s the right thing to do for the long run.
Andy Montoya
Thank you both. And now our final question that we have here is: We don’t modify our Salesforce code or config, but we have downloaded apps from the app exchange. Do we still need to worry about security or is SFDC responsible for our security?
Waqas Nazir
Salesforce does a great job of making sure that the applications that they publish on app exchange go through a security review process. They have this process defined and those that have gone through it know that it’s a very thorough process. It is always good to have some level of assurance on your platform. We always recommend that there’s no harm in assessing your environment, even though you think that you have everything covered.
If you have everything covered, our tool would tell you thumbs up, you’re in good shape. But if you have something missing from the picture, it will identify it. So there was always no harm in assessing your environment from a security perspective and making sure that you’re doing the right things. So this question would become easier for you to answer now ye’ve actually tested using a tool. And we know for sure we actually don’t have any exposure. So this will answer it for you. And an easy way of doing it is to run an assessment and find out if there are any exposures,
Andy Montoya
Thank you Waqas. And I spoke too soon before and some further questions that come through. The next one is: How easy is it to integrate your solution with CI/CD tools? And are there any recommended CI/CD tools for this as well?
Waqas Nazir
So the product itself can be integrated into all the Git repositories. Github, Azure DevOps, Bitbucket, and GitLab. We also have integrations for Jenkins. We have an integration with Copado and it can be utilized by other custom CI/CD environments. We expose a public API or a developer can write their own tooling around it, but we’ve spent a lot of time making sure that our tool is integrated into the CI/CD pipeline. We can point you to our help site to look into the integrations and how easy it is to consume within CI/CD pipeline.
Andy Montoya
Perfect. Thank you, Waqas. And one more here: Does the tool provide solution approaches along with identifying the issues?
Waqas Nazir
Yes, absolutely. So we provide detailed recommendations on how to go about fixing the issue. We also talk about why this issue came up and it can give a developer or an admin the perspective into how this come about within their environment. So they get the background and then also the recommendations on how to fix it.
Andy Montoya
Thank you Waqas. One more here: What are CVEs and can they change my Salesforce security posture even if we don’t modify our org?
Waqas Nazir
It does. So CVE’s are Common Vulnerabilities and Exposures. There’s a list maintained by NIST which documents publicly disclosed vulnerabilities. And in the Salesforce context, this is all your static resources. Interestingly, we’ve seen even really secure environments have an insecure library, creating a lot of vulnerabilities within their works. So it’s important to be always checking the current posture of your environment because CVE’s keep popping up every day or every month, depending upon the technology. We see that with static resources as well.
Andy Montoya
Perfect. Thank you Waqas. And one final one here: Do we have categories listed within issues like high, medium, or low?
Waqas Nazir
Yes. So we categorize everything based on our understanding of the environment, but a customer also has the ability to change that whether they think something is high-risk. They can change it to critical or something we think is critical they can change to high, depending upon their scenario. We provide some flexibility with that.
Andy Montoya
Great. And that does it for the questions. Thank you so much, everyone. Great questions. And thank you Meera and Waqas for answering those.
Adrian Szwarcburg
Thank you everyone for attending. Thanks for our hosts and we look forward to speaking to any of you that might be interested in learning more about USTs services built around DigitSec’s S4 product, and we hope that you’ll join us again in the future for future informational webinar, such as this. Thank you very much.
