WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=UW8Qkk7MG8A NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/UW8Qkk7MG8A.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.360 --> 00:00:21.440 Well, hello, good afternoon, and welcome all to my session on the SonarQube Hunter Agent. s3 00:00:21.440 --> 00:00:33.520 It's an AI security agent and built to detect the classes of vulnerabilities that SAST cannot and before attackers can. s4 00:00:33.520 --> 00:00:35.160 My name is Taylor Luttrell. s5 00:00:35.160 --> 00:00:37.600 I create developer content at Sonar. s6 00:00:37.600 --> 00:00:39.960 We're the makers of SonarQube. s7 00:00:39.960 --> 00:00:46.040 Today, I am very hyped to get y'all up and running with SonarQube Hunter Agent. s8 00:00:46.040 --> 00:00:58.720 So, to start, as we all know, in the agentic era, code is shipping at both agentic velocity and agentic volume, and as a result, an unprecedented number of vulnerabilities s9 00:00:58.720 --> 00:01:05.280 are reaching production environments, leaving companies exposed and vulnerable. s10 00:01:05.280 --> 00:01:20.680 And if you're familiar or you actively use traditional pattern-based scanners like SAST, you may very well understand that there are classes of issues which it is simply not designed to account for. s11 00:01:20.680 --> 00:01:26.520 These are issues of intent rather than the patterns that it is adept at finding. s12 00:01:26.520 --> 00:01:35.760 And so, in explaining this, um basically, not all vulnerabilities are bugs in your code, at least according to SAST. s13 00:01:35.760 --> 00:01:44.680 And that's to say that the issues that it can find are not always accounted for. s14 00:01:44.680 --> 00:01:55.520 These are issues of intent, issues related to logic-level vulnerabilities, wherein the code may very well be valid, but the intent itself is not. s15 00:01:55.520 --> 00:02:03.800 And that's to say that it's technically or it's functionally correct, but the intent behind it is flawed, right? s16 00:02:03.800 --> 00:02:09.840 It contradicts your underlying business logic, for example. s17 00:02:09.880 --> 00:02:16.880 Now, in many companies, pentests happen at most twice per year, perhaps once per quarter. s18 00:02:16.880 --> 00:02:35.680 But, as attackers are now enabled with better models than ever, um and as the time between which these uh agent-generated changes are shipping, we need a new class of agents to suss out, to detect, and to fix s19 00:02:35.680 --> 00:02:37.440 these vulnerabilities. s20 00:02:37.440 --> 00:02:43.800 So, I introduce SonarQube Hunter Agent to fill that gap exactly. s21 00:02:44.000 --> 00:02:50.760 So, in order to accomplish this, there's first an agent that maps the repository globally. s22 00:02:50.760 --> 00:02:59.400 And then, based on that global map, it starts three specialized agents, one per class of issue that it can find. s23 00:02:59.400 --> 00:03:08.560 And these issues look at relationships between all the components and try to define the security expectations, if you will. s24 00:03:08.560 --> 00:03:13.840 We then run adversarial validation to make sure that the issues are actually correct and not false positives. s25 00:03:13.840 --> 00:03:21.800 And we have noise gates as well to reduce the really low um validity uh issues or issues that would be by design. s26 00:03:21.800 --> 00:03:26.560 And so, these playbooks essentially take a repository as input. s27 00:03:26.560 --> 00:03:35.280 They handle all the complex agent orchestration, and they output high-quality issues that you can then assign to your developers. s28 00:03:35.280 --> 00:03:38.720 In doing so, we assign a severity to these issues. s29 00:03:38.720 --> 00:03:48.720 We determine the impact that it can have on your overall codebase, and we point you to the exact location where they can be addressed directly. s30 00:03:50.840 --> 00:04:04.520 So, in representing these findings, if you already use SonarQube, these issues will surface alongside all of the other issues that we already look for using our SAST tool. s31 00:04:04.520 --> 00:04:11.800 As I said, you can assign a um You can assign a severity to all of these. s32 00:04:11.800 --> 00:04:22.720 Um in the agentic era, where attackers are moving faster than ever, you need a solution that can keep pace with just that. s33 00:04:22.720 --> 00:04:31.560 As the time between a vulnerability being discovered and weaponized is shrinking, and it's shrinking now ever faster. s34 00:04:32.160 --> 00:04:42.680 And so, we are very excited to announce today, y'all are among the first to hear this, that Sonar is joining the Open AI Daybreak Cyber Partner Program. s35 00:04:42.680 --> 00:04:52.600 This is going to bring you governed access to advanced cybersecurity frontier models directly in products like SonarQube Hunter Agent. s36 00:04:55.680 --> 00:05:03.160 Because we recognize that security teams need frontier intelligence, too. s37 00:05:03.160 --> 00:05:14.080 We have to keep pace with the very attackers that we are fighting against, and so we saw fit to include this as part of the very agent that susses out s38 00:05:14.080 --> 00:05:19.840 the classes of vulnerabilities that may be slipping through the cracks. s39 00:05:19.840 --> 00:05:24.560 We provide frontier reasoning inside SonarQube Hunter Agent. s40 00:05:24.560 --> 00:05:27.560 Playbooks run across the whole codebase. s41 00:05:27.560 --> 00:05:40.800 Every lead is investigated and validated before it surfaces, and these Daybreak class reasonings deepen the reasoning behind each playbook to ensure that all the findings are precise, they are repeatable, s42 00:05:40.800 --> 00:05:44.400 and are auditable, as well. s43 00:05:44.400 --> 00:05:57.640 In doing so, we recommend combining SAST and Hunter Agent and we do so in a single platform to provide two layers of verification so that nothing slips through the cracks. s44 00:05:57.640 --> 00:06:03.600 SAST and SCA on one hand and Hunter Agent picking up the slack. s45 00:06:03.600 --> 00:06:06.200 This is layered security by design. s46 00:06:06.200 --> 00:06:18.320 It's zero trust, it's multi-layered, and it's independent to ensure that we can find zero-day vulnerabilities with precision and a repeatable manner. s47 00:06:22.880 --> 00:06:27.120 And that is SonarQube Hunter Agent in a nutshell. s48 00:06:27.120 --> 00:06:37.160 I'm now going to switch gears and I'm going to demo the product directly to give you all a sense of how it works in a real production setting. s49 00:06:37.160 --> 00:06:45.840 So, I have on screen a simple Python application of mine which I have scanned with SonarQube Hunter Agent. s50 00:06:45.840 --> 00:06:58.360 I've logged in to my SonarQube Cloud dashboard here and if I navigate to Hunter Agent you can see that within the very same UI you can trigger an on-demand s51 00:06:58.360 --> 00:07:03.520 scan by clicking the scan now button. s52 00:07:03.680 --> 00:07:16.000 This is going to give you an estimation of the number of units required to perform the deep whole code base reasoning pass over your project on SonarQube. s53 00:07:16.000 --> 00:07:23.840 You should also note that this works either with SonarQube Cloud or with our self-hosted variant SonarQube server. s54 00:07:23.840 --> 00:07:28.960 So, were I to click scan now, it would kick off a scan of the project. s55 00:07:28.960 --> 00:07:40.760 Depending on the size and the complexity of the project it can take upwards of an hour so I I went ahead and ran a scan on this project already which I'm going to walk you through now. s56 00:07:40.760 --> 00:07:53.040 The scan took about an hour to complete and then scanning the project at first securely clones the target repository to grant the AI engine direct access to the source code. s57 00:07:53.040 --> 00:08:00.640 It then analyzes the application architecture to map potential attack surfaces and build a comprehensive threat model. s58 00:08:00.640 --> 00:08:17.760 It next executes deep contextual scans to detect critical flaws like IDOR, broken access control, and business logic vulnerabilities and it aggregates and deduplicates findings from all specialized AI sub-agents into a single s59 00:08:17.760 --> 00:08:29.800 unified issue list before lastly automatically exporting and logging validated vulnerabilities directly into your SonarQube's issue list. s60 00:08:29.800 --> 00:08:39.159 So after having completed, I can click into scan results to surface all of those issues that the Hunter agent found. s61 00:08:39.159 --> 00:08:48.160 You can see here that there are 46 open issues on this project broken across the three issue categories that I touched on earlier. s62 00:08:48.160 --> 00:08:57.240 Those being broken access control vulnerabilities, business logic vulnerabilities, and authentication and session vulnerabilities. s63 00:08:57.240 --> 00:09:11.760 So to quickly recap, these broken access control vulnerabilities relate to such things as insecure direct object references or IDOR, missing or incorrect authorization checks, privilege escalations, sensitive data exposure, s64 00:09:11.760 --> 00:09:14.440 and cross-site request forgery. s65 00:09:14.440 --> 00:09:23.920 Moving on to business logic, this relates to such things as skipping required workflow steps, abusing repeatable actions, and missing rate limits. s66 00:09:23.920 --> 00:09:37.720 And then lastly, those authentication and session issues as I had mentioned pertaining to broken access or broken authentication, I should say, session fixation, non-expiring sessions, weak password recovery, missing multi-factor authentication, and brute-force s67 00:09:37.720 --> 00:09:39.560 gaps. s68 00:09:39.560 --> 00:09:45.360 So, I'll go ahead and click into these broken access control and I'll pick an issue at random. s69 00:09:45.360 --> 00:09:57.640 Note that these surface in the same issues list as every other issue that's scanned by SonarQube, so you don't have to navigate to a new dashboard to surface um and inspect all of these. s70 00:09:57.640 --> 00:10:01.640 So, I'll go ahead and click into broken access control. s71 00:10:01.640 --> 00:10:08.800 You can see at the very top we have a an issue which has been rated high in severity. s72 00:10:08.800 --> 00:10:16.680 All of the issues are tagged with Hunter Agent as this was the AI agent used to surface them in the first place, and then also the class of issue s73 00:10:16.680 --> 00:10:20.320 that it pertains to as well. s74 00:10:21.880 --> 00:10:35.680 In trying to help you remediate these issues, we first show you where specifically within your code base the issue has surfaced, as well as providing an explanation as to why this is an issue. s75 00:10:35.680 --> 00:10:46.240 So, in this instance, as you can see, the issue pertains to any signed-in user being able to pass the admin access check because they can write their own role field. s76 00:10:46.240 --> 00:10:56.640 So, you we walk you through basically why this is an issue and then also point you to how you can go about fixing it as well. s77 00:10:56.640 --> 00:11:08.080 Any activity as well related to the issue at hand, and you can assign the issue like you can any other SonarQube issue to the developers of your choosing. s78 00:11:08.080 --> 00:11:19.720 All issues um open uh are uh started in an open state by default, and you can either accept the issue, meaning that it is indeed valid, it's not a false positive, s79 00:11:19.720 --> 00:11:26.640 but it will not affect your quality gates, and therefore it will not prevent the code you're trying to ship from entering uh production. s80 00:11:26.640 --> 00:11:40.840 You can confirm it, meaning that the issue is valid and it will will fact have an impact on the quality gate or you can mark it as a false positive if you really and truly believe that the fix is incorrect. s81 00:11:41.280 --> 00:11:45.160 So, navigate back to the scan that we had conducted. s82 00:11:45.160 --> 00:11:53.600 We have also uh five business logic findings and a number of authentication and session findings as well. s83 00:11:53.600 --> 00:11:56.960 I'll go ahead and click into one of these just for more breadth. s84 00:11:56.960 --> 00:12:02.800 You can see here at the very top, we have another high severity security vulnerability. s85 00:12:02.800 --> 00:12:13.800 This one pertaining to any user with only an account password being able to reach every protected route including admin functions without completing multi-factor authentication. s86 00:12:13.800 --> 00:12:24.160 Again, we point you to where in your code the issue resides as well as why it's an issue, how you can fix the issue, and then again, any activity s87 00:12:24.160 --> 00:12:26.840 related to it. s88 00:12:26.840 --> 00:12:35.839 Note that while the Hunter Agent can be run on demand, it can also be run on a scheduled basis. s89 00:12:35.839 --> 00:12:45.000 So, if I navigate here to Hunter Agent, I can configure a scheduled scan whereby I can run it at the frequency of my choosing. s90 00:12:45.000 --> 00:12:46.760 It's highly configurable. s91 00:12:46.760 --> 00:12:51.120 Uh be that daily or weekly or monthly. s92 00:12:51.120 --> 00:12:56.838 And I can also select a specific branch should I not want to scan the main branch specifically. s93 00:12:56.838 --> 00:12:58.838 [snorts] s94 00:12:59.240 --> 00:13:03.440 This case, I scanned the main branch. s95 00:13:08.160 --> 00:13:12.680 And that is Hunter Agent in a nutshell. s96 00:13:12.680 --> 00:13:27.600 In pointing you towards these classes of business logic level vulnerabilities, we suggest fixes, but I am excited to announce that as of this week these issues will also be able to be fixed s97 00:13:27.600 --> 00:13:31.000 in a remediated or in a automatic fashion. s98 00:13:31.000 --> 00:13:32.360 I should note. s99 00:13:32.360 --> 00:13:47.520 You can in fact assign these issues to the SonarQube remediation agent which can take care of remediating these classes of security issues for you and also on a scheduled basis. s100 00:13:47.520 --> 00:14:01.480 And that is SonarQube Hunter Agent which will enable you to catch logic level vulnerabilities before anybody else does so that you can hunt for issues before you yourself are hunted. s101 00:14:01.480 --> 00:14:03.880 Thank you very much.