Description
Integrating automated code review in your DevOps workflows is an essential, proactive measure to keep your Salesforce deployments secure. Learn how to identify security flaws early in the development lifecycle, and what you need to be compliant with Salesforce security best practices.
Speakers
Lorenzo Frattini: Founder, Clayton
John Belo: Director, Product Management, Salesforce
Transcript
So welcome everybody to our session, keeping Salesforce secure, why automated code reviews is, are nonnegotiable.
This will be a conversation between experts around some very important topics, certainly, topics I deeply care about.
I'm Lorenzo Frattini, the founder of Clayton, now a Gearset product.
I am Salesforce CTA. I've been I spent the last seven years building Clayton, focusing deeply on code analysis, developer security. So super passionate about this stuff. And joining me today, is John Bello, fellow CTA, director of product management at Salesforce.
Hi, John.
Thank you so much.
Lorenzo. How are you? Thank you for inviting me.
Oh, it's a pleasure, and I I'm so excited about this session. I told you already backstage. I told you when I first, reached out to you.
There are few people in the world that are so, that that spend so much time thinking about these topics and caring so much about the developer experience and how, I guess, we can use technology to help developers write better code and better software faster.
So not many people spend so much time on these things, and I love talking about this stuff. So Yeah.
Yeah. But but but, you know, to be honest, I remember many years ago when we sat down in Salesforce tower here in London, and, you had this idea of building something to help partners prepare for the application security view, to scan their code, and all of that stuff. Right? And and here we are. So also congratulations to you on the on the Clayton, acquisition by by Gearset.
Thank you, John. I'm very excited. And, you know, we love Gearset. We love I I think one of the the things we really are really excited about is the impact that the combining the forces and the product and the vision really will have on the ecosystem, how we can help, more teams really because this is what I what we care about.
Our story is a story of, I guess, embracing the box. The Yeah. A little bit of digression, but, Clayton was a small company, and we started it really, we wanted to build a very difficult and complex product and realized early on, we need to automate a lot. That is the only way we can really build something this robust and it will work and maintain agility. So we had to care. We had to really embrace DevOps as a way of doing things.
And so, yeah, this is, this is why we probably care so much.
So, let me share a little bit my screen because, hopefully, our viewers are here because they care about DevOps. They want to hear, I guess, they want to learn something to help them make, a step forward in their journey. So, hopefully, we can share some valuable insight. The plan for today's session is really to have an open conversation, John, with you, hear a bit about your perspective. You're clearly an expert. You're looking, at the the box life cycle at Salesforce, in, from various lenses, code scanning being one of them.
So the there there are a few, focus points that I would love to to talk to you about, and, hopefully, the, audience will will, will get some insights that are relevant to what they're doing.
The first one was mentioned by, Kevin and Karen, early on is about shifting left.
What does it mean and why teams should care?
And then I would love to talk about AI for developers, but because so much is going on right now, obviously, agent force is all is going to be all over, TBX, and it's such a crucial part of space space force vision moving forward. So we'd love to talk about that with you, some of the opportunities and the risks of AI and how you're thinking about that. And then hopefully spend some time around, you know, what's how do you see everything beyond, I guess, this shifting left?
I guess, how how do you see DevOps in general? What excites you? What can we learn from from the top performing DevOps teams that we see? And if we have time, hopefully, we will have a few questions from the audience and, we we can answer them. So that's the plan for today and I think why don't we start the conversation from shifting left? We we heard, about this.
What do we mean by shifting left and why should team care?
Well and I think, you know, can I really touch on some of these points as well?
We we believe that, first of all, you know, people need to be aware that if a bug makes it to production, it can be quite costly to to actually go there and and fix it. There's a reputational risk for the people involved as well.
There's potentially a trust risk. If a security issue goes all the way to prod, there's a vulnerability, someone takes advantage of it, and there's a data leak. Right? So the cost sometimes can be kind of unbounded. Right?
We believe that, with the right approach, with the right tools, we can empower developers, low code and pro code, to identify and solve solve these issues earlier on in the in the process. Right? And that means, having the right culture in place to enable these teams to look for those things. It also means that, you're not just a developer. Right? You're a developer, but you're also a QA engineer.
Right? You're also a security consultant all in one because you need to to worry about these these landscape of problems when you're developing a a a solution. Right? You need to think about performance for yourself.
Right? Or when I we we were kind of reviewing this slide before this presentation and ask you, well, can we actually add quality? Because, yeah, security is quite important. Right?
But think about performance, think about just ensuring that your code files best practices, ensuring that your developers are actually creating, say, proper unit tests, I guess I guess, the code that they are writing. Right? So all of those things are quite relevant to to to the tools that we create to hopefully help developers address those. Right?
So, really, I guess, you're describing a culture of accountability in which everybody cares, everybody's an advocate for all these important stuff.
Absolutely.
Absolutely. Because, again, it's not just about writing code. Right? It's about the bigger the bigger picture.
You're you're developing apps or you're developing projects. Those have an intention of delivering some value to your users that that happen to be in the production environment. Right? So taking that journey from wherever you are developing the solution all the way to to production Except that everyone should be aware of.
They they need to understand the vision for the value that they are trying to deliver and all of that cannot needs to trickle down into dev ops strategy, into testing plans, into your data strategy as well because we're not just deploying metadata anymore. We need to think about data for for some some, some things. We have many products out there where data is used as a configuration mechanism, and that needs to be deployed as well. We need to think about that.
We need to see think about how data is provided to developers so that they could actually build solutions that are, meaningful. Right? I guess the right the right data that is representative of their production environments. Right?
So all of those things are are quite relevant, and people need to be thinking about this. They need to have conversations about this. Right?
I I really, really agree. I mean, these these teams are so, so important, and I've seen so many teams struggling with with these topics. Now, I think in a way, Salesforce is a is a is a particular is a special platform in a way because it does so much to accelerate the development.
And there are so many things that are done for you that as the developer, you often don't think much about, the stuff that you should be thinking about. You focus so much on the business value and the end users. And then there is all this stuff that is taken care of for you.
That's an interesting angle because, you know, sitting within developer experience at at Salesforce, we think the opposite. We're like, oh, we're not doing enough. We need we need we need we need to do more. We need to to to, you know, help our developers be our developers, like, get local, their product, be more efficient, give them better tools, provide them an opinionated perspective of how they could follow these best practices. Right? So, yeah, I agree that if you look back and, maybe, like, last three, four years, even longer if you were to go all the way to the introduction of Salesforce DX. Right?
We've done a lot. Yes. We've we've had a lot of tools. I'm very happy that our story together our story of our tools these days is basically unified story where all the all of these tools are talking together, CLI, ID, DevOps center, all that stuff. But, you know, we still believe that there's a lot that we need we need to do to help all of these teams out there be even more impactful, deliver faster, deliver with quality.
And so those are the things that ultimately drive our our road maps as we think about these things. Right?
Yeah. And this is this is great to hear because some of the, things that were really, I guess, guiding principle about how we built Clayton was really this idea of can we make the developer experience better, more modern? Can we bring stuff that, you know, exist outside?
Exactly.
And it's so common in other technology stacks and developers are used to do these days. Can we bring this to Salesforce?
So And and and let me just add that angle there because, yeah, a little you kept talking about, some of the tools that we we've been creating, you know, like, self agent for developers, sales force colonizers, all that stuff.
But you guys, you know, the part the partner ecosystem is critical to this. Right? This part definitely part of our developer experience. Right?
Be it DevOps tools, code scanning tools, tools that focus more on, I'd say, a level of scale and performance testing. We have some of those as well. Right? All of those are quite important to to our ecosystem.
And and, again, it's really up to the customer to decide what is the right portfolio for, for the tools that they need. Right?
And a little bit of the background, I guess, why do we care? Right? We are we are talking we are diving into these topics. We are talking about these various ways of testing.
This was mentioned before, but I think it's worth spending a minute on this, John. Like, why do we even care about shifting left? What is the, I I guess, the underlying principle that lead us to care so much about this approach? The idea that most defects will end up costing more, I guess the preventing defects is always always always cheaper, than than than fixing them after the fact.
Assuming assuming you have people actually using the the stuff in production. Right? So, which is which kinda touches on the observability angle. Right? It's it's quite important, yes, for us for us to have this this culture of, yeah, delivering value all the way to prod. But the story does not stop there. We we need to ensure that whatever we deliver, we are monitoring.
We're ensuring it is the right thing for our users. We keep evolving it because, yeah, we actually from a certain perspective, we actually want our apps to be at at kind of risk of of being impacted if there are bugs because they're they're actually being used. They're actually relevant to to our user base. Right? So DevOps coming back to the that helix. It's in that entire cycle. Right?
So we need to think about yes. We are we are delivering value because there are people there that will actually be impacted if there's a bug. Right? And therefore, you need to do the best we can to ensure that they are not.
Right? And our suitability could could the cost will be an early indicator that things are actually going wrong. Right? And that and that you need to do kind of odd fixes or something like that.
Right?
So that's why I think I think there's so many angles to this and so many hats that we as developers, need to think about when when we're creating a solution. We need to think about all of this.
Right?
Absolutely. And and perhaps going back a little bit on the topic of security that we, obviously want to talk about today, I wanted to share some of the data. We we scan a lot of code at Clayton.
I think we are averaging around one billion lines of code, which is mind blowing to me because we started from, you know, very, very little and small beginnings, but we we we we see a lot of code. We we help a lot of teams, writing code that is vulnerability free, that's good quality.
And, last year, we did this interesting analysis and we kind of looked at, I think a a thousand four hundred, fourteen hundred more or less, teams building on Salesforce. What were what over the course of twelve months, what were the key challenges? What were the most common issues? So we did a little bit of a research and and figured out, actually, I wanted to share this with you. We'd love to hear your thoughts that security issues are actually quite common, surprisingly common.
We see I guess, we we clustered all these sharing crowd FLS by bypass, this idea that essentially your code could you could have a very, very well architected sharing, logic or or, architecture in your application, but then your code could bypass that. And, obviously, this could lead to nasty, consequences.
We find these in sixty sixty three percent of the application we scan.
Cross site scripting, which is a, I guess, a vulnerability that is coming from the web development world in general is not Salesforce specific, but we see that in many, many teams struggling with this. And not storing data that is sensitive, securely enough is also something that is is quite prominent. Mhmm. I guess, what do you, what's your take on this data? Why do you think many teams struggle with these topics?
Yeah. Well, it's a combination of maybe the enablement materials that are out there not focusing enough on ensuring that these these these teams follow best practices. Right? Two tools simply not being used.
You know, Clayton, Salesforce, and many of the other code schedules. A lot of them will actually detect diseases and and and allow developers to fix them early on. Right? But I think primarily, coming back to kind of the cultural and enablement aspects, it's really about empowering those developers with learning what those best practices are in the first place.
And ensuring that going forward, they they avoid them. Right? And, when I look at this, yeah, I'm very familiar familiar with the with the first one there on the left. It's actually been one of the main reasons why our FH partners that actually need need to go through through a thorough score review, why they usually fail it.
Right?
But I can also say a few things that, over the last year or so, we actually made it a lot easier for, developers to to adhere to this to these guidelines and best practices. Right? So through some new mechanisms that we introduced in SOCL and, any in Apex. Right?
So on one hand, we are making it a little easier for developers to follow these these best practices, but they still need to be aware what they are and they need to to follow them. But to be honest, when I look at this, the thing that concerns me the most, it's not even the percentages, it's really the the time it's taking to remediate these, these problems, which is, like, I mean, it's for security issues like this.
This is way, way, way too long. Right? Yeah.
This is I agree I agree with you. It's absolutely and and sorry. I didn't mean to No. Interrupt.
But it's like I feel so much that these, problems are solvable, and it's just a matter of, I think to your point, it's true. I I I I I I see what you mean when you say, you know, we want the tools to do more because in a way developers have so much responsibility. We expect them to ship the thing they are sup that it's on the ticket that is supposed to defeater in in a way, but they also need to think about all this stuff. Right?
All the they need to have a strong understanding of how to keep their code secure. We know the code is not secure by default, so they need to have that understanding.
And, also, the nuances of Salesforce, how do you do performance, how you do scalability, how you ensure that your code will have a good throughput and that your your you have high scalability to large volumes if if that is relevant for your application. Yeah. All this stuff is in a way on the shoulders of the developers. So there is there is so much that, they are kind of we expect from them. Mhmm. And that, I think, in a way, is why I I I I believe so much that tools are essential. In a way, it doesn't really matter what is your tool of choice as long as you automate because there is so much that the tool can can get out of your developer's plate.
I don't know. One thing that I was saying to you is you you say that. Yeah. Tools tools are important, of course. But for some something like this, when I look at this data, this is also partly kind of a leadership problem that needs to to be addressed. Right? Leadership teams that are managing the these teams of developers, they need to incentivize developers to care about these problems, to fix them earlier, to to ensure that there's bandwidth to address these problems, especially when these problems are present in production environments.
Because, otherwise, you you are at risk. Right? Your users are at risk. Your data is at risk.
And, and this is not not very easy there. Right? And, from from the perspective of what we can do in Salesforce, yes, we we are providing you with the tools to to help you resolve these problems. We're we were we were going to be helping you with even fixing this some of these issues automatically.
I mean, I I guess it starts to lead us into the next topic through the through AI. Right?
But, ultimately, I think leadership teams really need to to empower the developers to search and fix these issues. Right?
I I, I I really, agree with you. I think there is so much that, I guess, in a way, one of the things that throughout my journey I've I've seen is obviously, a CTAs as architect, we often deal with these larger teams that the most complex deployments, the most complex application. And, of course, at that level, at that scale, they would probably care about security already.
They would probably care about quality already. They would struggle with code reviews. They would struggle with technical depth. So there is a shape of teams that naturally care about these things already, but I feel that there is so much that, value that the smaller teams would get from embracing this mindset. Mhmm.
So I guess, that I agree there is a little bit of a cultural challenge there Yeah.
Because we really need to make our, teams care, our companies care about this stuff.
I I I I really agree. And maybe just just realize that we are a little behind on time, but, you suggest that, you know, Pyxies and AI, and this is this is actually something I'm I'm very, very excited about.
Why don't we, move into that topic a little bit. Right? So AI for developers, you mentioned this, a bunch of times. Yeah. What are some of the opportunities, and risks of AI and cogeneration?
So my personal perspective is that everyone should at least be trying out consideration.
Right? And, we make it easy through agent force for developers, which again is basically Salesforce providing you with a tool that, has been trained specifically for for Salesforce. But, you know, there's many tools out there.
ChatGPT, DeepSeq now now in the news. Right?
I recommend people to to try it out. And it's that opportunity to to learn how to how these tools can actually make you potentially more productive. Right?
There's so much, you know, kind of grinding work that the developer needs to do every day. Right? That can be accelerated and allow the developers to actually focus on more, you know, innovative creative stuff through these tools that I think, they should not be discarded then, and they should actually be embraced. They're only getting better. Right? And they're getting better very quickly.
And I see huge value in, in these tools not not only helping you write code, but also helping you refactor your code and addressing issues. So that's one of the things that we're gonna be talking about the TDX around, you know, this integration between colonizer and agent for support developers to automatically fix issues as colonizer detects them. Right? And that's a model that we want to keep evolving.
Right? We are big believers that, that AI is here to stay, and it's here to really empower developers and and even elevate their concern. Maybe maybe even giving them the bandwidth that they need to follow this dev ops best practices that we've been talking about. Right?
Yeah. No. I love this. I love, I love automated fixes, by the way. This is something that, we really, we really cared about making possible at Clayton. We started this.
I guess, our opinion on this is that, AI, I think we are all very excited about AI, but there are some things that AI is very, very good at. Like, for example, summarizing code, explaining code. Mhmm. So we are thinking we are using AI at Kaiton, for example, to generate, documentation, documentation of methods where it it doesn't exist. So we we really see a very strong potential there and a very, very high efficiency and efficacy of AI.
And then there are other things where, obviously, AI is getting better Mhmm.
But it's still not, probably as reliable.
And writing code, I feel, is still a little bit on the, cusp. Obviously, it's getting better, but, you know, code for all the reasons. Right? It needs to be secure. It needs to be scalable. All the stuff that we were talking about.
So I feel that there is a little bit, it's definitely exciting, but it's also, so important that we have the right set of tools and the right set of safeguards.
I think I I think the the challenge is that, you know, I I think AI is getting really good at, generating code that works. So you can you can very quickly even create a game, an application with a few with a few prompts. Right?
The gap that we see, and that's what the one we're investing heavily in, is the gap the gap between, an working or working code, working application, and one that follows best practices. Right?
And that, from our perspective, is training. Right? So making sure that that we we, we use best code that files best practices as an input into the into the training process for that model, which is why we've invested so much in agent force for developers to ensure that when it is generating code, when it is fixing calls that colonizer where colonizer detects issues, that, yeah, it provides you with something that is or should be be following best practices. Right? And while it might not be perfect, we are definitely moving in the in that direction. Right?
And I I I think this is going to be such an impactful change for developers. And interesting, I I I don't know if you've read the Dora research this year, but every way every year, there is this amazing report.
I think that, like, super rigorous about out of the box, is evolving.
And, it was interesting to read that AI, for most developers, there is an improvement in productivity. There are still so many people that, I guess, thirty nine percent, I think, of participants have little or no trust in AI generated code. So there is clearly so much that we can do still Yeah. As, you know, the folks writing the tools, using the models, training the models, in our case, creating, those, deterministic set of checks to make sure that everybody would be adopting AI. So we need to make sure that whatever code is written, no no matter if by a human or by a tool is, you know, done right.
Exactly. Exactly. No. I I I agree with that. And, and when we move to a model where we want to empower, say, low cost users to build applications, and those applications might have a layer of code that is written by AI pretty much entirely.
We want to ensure it is done correctly. Right? And that's ultimately the model that we that you'll see all the companies moving towards. Right?
That is gonna be really easy for you to create an application. But that means that, yes, we need to have the right models in place.
Be sure that all the various layers of an application are are implemented correctly. So, anyway, so that's for us to to continue investing in and delivering delivering on that vision. Right?
Very, very interesting. And I think we are, almost at time. So I guess very briefly, is there, I guess what else are you excited about? Is this anything that, beyond code scanning that you are thinking about and, I guess, as a product leader excites you?
Yes. Definitely. Definitely. I'm thinking about all l hilarious around that we talked about earlier. So testing not only for both, but but, also using our credit partner ecosystem to come up with a, you know, a portfolio of good testing solutions around, DevOps center, which we have in our DevOps testing product that we will be launching in a few months.
I think a lot about observability.
Today, we have some really cool good tools that we build for our IT partners, but we're also thinking about different aspects of observability and usage data that we would want to provide to our, to our customers. Right?
I think about data and how data can play a role in all these DevOps operations. Right? So how can we empower to help push it to the right level of tools that really integrate deeply with the all the other stuff that they're doing around the DevOps, around testing, and all that stuff to make sure that everyone is served with best possible tools as they they operate here in the in the Salesforce ecosystem.
Absolutely. I I couldn't agree more. I I'm very excited. And and I was in a session this morning. We are, talking a lot at Gears at around the observability, for example.
So I've seen some early demos of of the product and the stuff that we're working on. And, you know, I'm so excited about, you know, how these things will make an impact on, so many teams, in the coming months. Very, very excited about what, I guess, all these innovation in DevOps will bring to Teams. So, thank you so much, John. It was a pleasure talking to you. I think Pleasure.
Pleasure. Go on.
So, mate. Yeah. I I could go on for a very long time. You probably can see that.
Thank you. Thank you so much. It was a pleasure having this session, having this chat with you. Thank you to all, everybody in the audience for tuning in.
