Transcript
new features for us to check out. In our past video on this Cursor 1.0 release, we took a look at the BugBot feature that enables you to review code changes that are being implemented and let you know of any issues that BugBot might find in them. In this video, we're going to take a look at the one-click MCP install feature that it talks about that lets you install MCP servers with the click of a button. Now, Cursor has curated a shortlist of official MCP servers that we can add to Cursor, so we're going to take a look at that now and get started with trying this out. All right, I'm going to click on this link. Here are all the MCP servers via Cursor's tools page, and we have Notion, Figma, GitHub, but there's one in particular we should take a look at. Sneak, the vulnerability scanning of your codebase. Let's try adding that now. It's prompted me to open Cursor. I'm going to go ahead and do that. Okay, great. So, it opened up Cursor, and it's going to install an MCP server. It's asking us what we want to name it. Sneak. The type is standard input output, and the command is sneakmcp-t, standard input output, and we add the experimental flag there. So, I'm going to click on install. Technically, this is two clicks. All right, and with that, Sneak MCP server has been set up as a tool, and there's six tools available. We can see Sneak Auth, Sneak Auth Status, Sneak Code Test, Sneak Logout, SCA Test, and Version. All right, now let's give this new MCP tool a try. We're going to open up Cursor's prompt here. All right, we're going to use the default options for Cursor chat here. We're going to have it in agent mode and using the Gemini 2.5 Pro model. So, what we're going to do is ask it to scan all these projects you see here above me in this monorepo for vulnerabilities in the dependencies that we have here. All right, let's send that in and see if it starts calling the MCP server from Sneak. I've decided that the MCP Sneak SCA Test is suitable for finding vulnerabilities in the workspace project's dependencies. Okay, that's cool. It knew to use that tool that's available to it. I'm authenticated already with Sneak, and now it's going to do the test. The scan is still coming up empty, which is unexpected. I'll take a look. Okay, so this is interesting. What I do when I have a monorepo like this is I add a flag to Sneak that says hyphen hyphen all projects so that it looks at all of the projects, and the Cursor chat here, the model Gemini 2.5 Pro, recognized that that's what I was trying to do, but for some reason something has gone wrong. So, it's going to try a more direct approach and scan the root project specifically first. That scan was failing. I tried a few different ways. Still not getting any results, which is odd. I'll now examine your package JSON to see. CloudSonic 4 is clearly a Node.js project that should scan. All project commands should have caught it, but since it didn't, I'll target that directory directly with the next scan. Okay, cool. So, what it decided to do then, based on how the MCP server is set up, keep in mind this is experimental right now from Sneak. What the model decided to do was target a specific project folder first, one at a time. So, it went into CloudSonic 4, that project, and the code that was generated from that model, ran npm install, and then it is going to scan. The scan was successful after running npm install and uncovered several vulnerabilities in the cursor project, including high severity issues in electron updater and micromatch. All right, so now it's going to each project, basically, and scanning all of them for me. The sneak scan was interrupted. I'll assume that was unintentional and restart the scan on the current directory. Okay. Oh, that's super interesting. So, it used npm audit to check for vulnerabilities that way, and then it's using sneak scan on the current directory for a second opinion. All right. So, that was a kind of rough test. I kind of threw too much at it at once, I think. What I'm going to do now is go into a specific project to keep it isolated to just that one and ask the AI model to scan that for vulnerabilities and see if it uses the sneak MCP tool and see what the results come from that. All right. I jumped into one of our more recent projects output for Gemini 2.5 Pro from May 2025, and now I'm going to ask it to scan this project for vulnerabilities in the dependencies. All right. Let's see if it has a better time looking at this. All right. Immediately went to the tool call for sneak, successfully authenticated as me under my account, and now it's running the test. By the way, SCA not only is a genre of music spelled differently, but it stands for software composition analysis. So, it's looking at all the open source dependencies that compose of the entire project that you're depending upon and looking for vulnerabilities in those. All right. So, the scan is complete. Let's look at what the tool came back with. 231 dependencies and found three issues, 14 vulnerable paths. So, Bcrypt is one of the vulnerable paths. Csurf is another vulnerable path dependency that we have in there. What was the other one? I think SQLite. SQLite is another one too, right? All right. So, that was interesting. The tool picked up on that. Scan is complete. They found three vulnerabilities. So, the model recognized the tool reported three vulnerabilities, and it's going to try and address them actually. So, this is interesting. The in-flight vulnerability, which requires a Bcrypt upgrade to do that, it's going to first locate the package.json file. Then it's going to fix these vulnerabilities by upgrading Bcrypt to that 6.01. So, I didn't really ask it to do this, but because it's in agentic mode, agent mode down here, it's likely thinking it needs to resolve the problems, even though I told it just to find them. So, it's being a little bit overzealous in what it was asked to do, which is a little concerning, worrisome, because again, I want to have more control over these types of things as a developer. I just wanted to know about vulnerabilities in it. I didn't want it to actively go and fix them just yet. Let me tell it to do that, right? I want to lead the AI. I don't want the AI leading me. So, then it seems like it should have resolved that with that upgrade, and then it's going to investigate the Csurf and cookie problem that was reported there. So, Bcrypt got upgraded to 6.0 from 5.11. NPM install is done. Audit shows seven vulnerabilities now to the Csurf XSS vulnerability. It's researching it online with the search term Csurf cookie vulnerability. Interesting. So, with that, it removed... Oh, this is nice. So, in the past, I've talked about how these models, when I give it a one-shot prompt to generate an application that's secure, it tends to lean on the Csurf module to help with mitigating cross-site request forgery in the application code. And in this case now, it recognized it shouldn't use that package, Csurf, and instead went the cookie parser and then the CSRF-CSRF package, which I've mentioned in the past videos too, as an alternative to the Csurf module that is now deprecated. So, that's cool that it picked up on that and it went to go update the package JSON for those. And I wonder if it's going to result in any code changes too. So, I'm a little bit behind in catching up. NPM install Csurf failed for some reason. Why is that? So, it double-checked that that's the correct package and that's the version, the latest version, 403. The previous installs failed with an eTarget error for 231. Interesting. Likely due to registry or proxy issue? Not for me. All right. Gave it a more specific version. Okay. It successfully installed that. It's still working. You can see the scroll bar here. I got a lot to catch up on. So, now it's replacing the custom CSRF middleware with CSRF-CSRF package use. It's updating the code here from Gemini 2.5 Pro from earlier. Deleted the middleware file. It's updating the server.js file to use cookie parser and the double CSRF functionality from that NPM package. It looks like the configuration for double CSRF takes in the secret via an array like that we see there. So, let's recognize that and switch that. Added the use of cookie parser right before the session. Just moved it down. Then it removed the array brackets and added this get session identifier from the request session.id. This is very interesting. I'll ensure there's a single app.use cookie parser before the session middleware and that double CSRF config is correct. One more try. Okay. I did get that. The model's stuck. I'll try smaller changes. It's talking about itself that the model is stuck? Like the large language model is stuck? What happened there? Trying to edit file and reapply. Both failed. I'll have to rewrite the entire file. It's not ideal, but I'm out of options. What is going on right now? I'll read the file one last time, then use edit file to replace its contents. I don't know how I feel about this. Okay. It's adding error handling for this invalid CSRF token. Edit file is failing. I'll try applying the full file content one more time. If that fails, I'll notify the user and give them the code to apply manually. By default. Okay. We can resume. I'm a little scared to resume, honestly. How many tool calls did it do? It says it stops after 25 tool calls, but it only used the sneak tool like a couple of times earlier on in this thread and then shouldn't need it anymore. I'm still available to help with any other vulnerabilities you would like to address. Okay. So it's telling me to apply this. I can just click on apply here, right? Or copy it. This is for what file? This is for server.js. So if I go over to server.js, let's make some room here really quick. Oh, you know what? It might be because a lot of this is in flight changes. Yeah. All right. At this point, I've accepted all the changes that Gemini 2.5 Pro made in response to the output from the sneak MCP server reporting vulnerabilities in it. And just as a quick recap, the vulnerabilities it reported was the bcrypt one, missing release of resource after effective lifetime. Cross-site scripting vulnerability introduced via Csurf. And last but not least, the improper link resolution before file access that's found via SQLite dependency. Okay. Of those three, it did address the Csurf one because when I scan the project using the sneak VS code extension, we can see we only have two issues being reported for our open source dependencies. And it's that tarfs one, the improper link resolution, and then the in-flight one that's introduced via the SQLite dependency as well. So as a result, we can essentially vibe code a little bit more confidently and safely knowing that it's going to be secure and more production ready thanks to the MCP server from sneak. On that note, that does it for this video. I hope you got value out of it. And if you did, be sure to like it down below and share with somebody who could put it to use. And if you made it this far, subscribe to the channel so you don't miss out on upcoming videos. Thanks for watching and happy safe coding, everyone.
