00:00 Welcome and Agenda
01:26 Why Automate Triage
03:20 Where Triage Engine Fits
05:16 How Rules Work and Who Can Run Them
08:42 What's New vs. the Classic Rules Engine
11:17 Turning On Triage Engine and Custom Roles
13:33 Triggers, Logic, and Actions
16:31 Guardrails: Validate, Preview, and Simulate
17:58 Runs and Deliveries
19:46 Common Automation Use Cases
21:54 Live Demo
29:02 Migrating Classic Rules
30:33 Asset Rules, AI Nodes, and Webhooks
32:35 Next Steps

All right. Yes, we are gonna talk Triage Engine today, for what it's worth. Um, so welcome. Thank you for showing up. Uh, we're scheduling this at about 30 minutes, so 25 minutes of me talking with some fudge time for if I go long or if questions come in or what have you.

And please ask questions whenever you get them. Um, there's a little question button somewhere on Zoom. All these lovely, uh, webinar people move their buttons around, but I'm sure you can find it. So what we're gonna cover in roughly 20 minutes, maybe 25, like I said, fudge time, um, is what the re- what the Triage En- Engine is, why we built it, kind of its history, what it does for you, what its sort of goal and purpose is.

I'm gonna talk about, okay, you have a rule that runs in the Triage Engine, how do I make sure it works like I want it to work? Like, how do I simulate this thing? Because one of the, the pluses and minuses of automation is it's awesome 'cause it does stuff quick, but it's not so awesome when it does the wrong thing quick.

So how do we make sure the wrong thing doesn't happen? Then we give you lots of bells and whistles there, so we'll talk through those. We'll talk through some common use cases that we've seen from our customers and users of DefectDojo Pro, and then I'll do a demo 'cause I don't like myself and I like taking risk.

So let's just start with the premise. So every time you run a scan of whatever, right? You do a CI/CD run, maybe you run several scans, right? But you're gonna drop findings into Dojo, right? Suddenly there's more data in Dojo that you need to deal with. And generally speaking, when that data drops, you need to figure out, like, who owns that problem, who's gonna do the mitigation, is it gonna get risk accepted or not?

Do I have to create a ticket for this? If so, who gets the ticket? Do I have to tell somebody about this? Do I have to do reporting? All kinds of questions around it. And, and these are generally your... the place where you work, your company, whatever, has a, a either a policy or an unwritten sort of procedure of like, oh, well, these findings go to this team, and this type, oh, but it's critical, so I have to escalate it to this other group, or whatever the case is.

But they're generally repeatable, right? These aren't ad hoc, I have to decide on the fly for every one. You just have to do this same sort of process for the findings that come in. And so the nice thing about the Triage Engine is you can codify that. You can make a graph, and I'll show you a picture of this, or I'll show you it live when I, when I do the demo.

But you can make a graph of that decision, then just have it rinse and repeat for you, and you decide once what that decision process looks like, and you let the machines handle the work for you. And like I said, there is a risk, obviously, any time you write a rule and apply that rule automagically. If the rule does the wrong thing, you just get automagic, a repetition of the wrong rule.

So I will talk through the sort of safeguards we have and guardrails around, uh, doing things with the Triage Engine, how you can see what's gonna happen before it happens and decide, yes, this is good, and how you can sort of... if you don't wanna do the cannonball into the pool, you can wade in slowly.

So where does Triage Engine fit in in the DefectDojo universe? Um, it is currently available in Pro. It's still marked beta. I th- we really only marked that one beta because it's one of those interesting features of Dojo that w- we know it works, and I'm happy with how it works, but we also know the goal of Triage Engine was to give you sort of this last mile of customization.

We picked what we thought the common use cases are, but shoot, in the last two weeks I've had two different meetings with customers that said, "Hey, Triage Engine is really cool, but I want it to do this thing." And I look, I'm like, "Oh, shoot, we didn't add that. Let's add it." So it's beta because we know we haven't caught all the use cases yet, and we really want that customer feedback to get us those ones that we just didn't think of or s- you know, particular to how you do things wherever you work.

Um, if you do have the original rules engine, uh, the classic rules engine, so to speak, um, you can keep running it. So if you already have existing rules, this isn't a forklift replace, you know, nuke from orbit kind of thing. You can run them in parallel. You can migrate them. I have a slide on that later. Um, so this isn't a hard cutover, basically.

And then for Community Edition, I mean, I'll be candid with you. When we were designing the original classic rules engine, the use cases that we were looking to solve were ones that I had solved by writing code outside of Dojo that talked to the REST API. So although you don't get it nice wrapped up in a pretty bow, there's nothing stopping you from doing similar things with DefectDojo, 'cause that's what I did back years ago when I was using Dojo at a company that I worked for and I didn't have, um, a rules engine.

I just made my own. Um, and so everything you're gonna see today is in Pro, um, because that's where this, this particular feature lives. So a rule in Triage Engine speak is a, is a graph. It's a, it's a bunch of boxes that you connect with lines à la, you know, visual or, uh, uh, what's that? Um, oh shoot, Visio style thing or your old flowcharting stuff in essence.

Uh, but it's a graph. So I have an event, what we call a trigger. Something happens that says, "Ooh, I need to run a rule." There's potentially logic that filters or does if/then kind of things to sort that data that has been, uh... that is part of that event. Then you can change that data either for findings or assets, like setting an owner or turning it from critical to high, 'cause there's a mitigation in place, whatever the change is needed.

And then there's optional egress. Egress is... I like to think of egress as sending something outside of DefectDojo. Um, technically not all of them leave Dojo. There's create report, which stays inside of Dojo, and create an alert inside of Dojo, which also obviously stays inside of Dojo. But a lot of these are talk to outside systems.

SNS, Jira, Teams, Slack, those kind of things. Each rule has only one trigger, so if you wanted something that triggered on an event and you wanted to be able to manually run that thing, you'd actually have to create two rules because w- it would be hard for DefectDojo to understand. Well, I guess you could ad hoc run them.

But anyway, I would generally write rules so there's one that you know that's a one-off and one that's an event-based. And then as you're going through your collection of little blocks with, with lines connecting them, à la n8n style, each one of those carries a collection of data with it. Think of it like a snapshot of the data in Dojo, like DB transactional if you wanna get that into the weeds.

But then you have data that you can interact with. So like in this example on screen, finding.severity gives you the severity of that finding in that collection of data. ctx, the context.count gives you the count of things. So if I'm doing assets, that would be how many assets are in, going into this rule, this block of this node in this rule.

And then because rules allow you to change kind of a lot of data in Dojo in a lot of interesting ways, you have to be fairly privileged. Um, in fact, you have to be, uh... By default, it is a, uh, global owner, AKA superuser in Dojo speak, um, to create rules. There's also a special, and I have another slide on this, a special custom, uh, role you can create to do different things with, with, uh, Triage Engine.

But because you can change a lot of data in Dojo, you obviously have to have a lot of privilege. Like a read-only user writing rules makes no sense, so you can't change anything. And then those rules, because of the RBAC system of Dojo, run as the person that created those rules. And if that person leaves, um, the rule will no longer run until someone else takes ownership of it, because we want to make sure that the RBAC is preserved in Dojo and those rules run as a, as somebody, basically.

So what was the difference between, I mentioned the classic rules engine, um, which was basically us saying, "We think customers are gonna wanna write rules. We're not quite sure what they look at. Let's give them a very narrow-focused MVP kind of a thing and see how it plays out." And obviously it played out well, 'cause we ended up creating the Triage Engine based on that early experimentation.

But the four things that Triage Engine can do over the classic rules engine is you can do this branching, right? It used to be if you wanted to do something with all the findings that were high, you had to write a rule for that. And then if you wanted to do for all the findings that are less than high, you had to do a second rule.

Now you can just do one with branches, or multiple branches if you wanna have a even more complex, uh, sort of case. Egress is new to, uh, Triage Engine. Um, this was something we, we knew was gonna come, but we didn't wanna muddy up the original MVP just to see if that, that need was there in our customer base, and it definitely was.

Um, we had audit logging on rules, but we really, like, upped the game on traceability, and I'll show you this when we do the demo. But you can see every block or node or step in that rule, you get a, a, a trace of what happened in each of those steps. Oh, you know, five findings came into this, two went out to this branch, three went out to this other branch, whatever, right?

Including deliveries, uh, if you're using egress. And then, like I was talking about making sure your rules act like they, you want them to, you can preview a rule. Well, let me step one even back. After you write a rule, you can validate a rule to make sure you haven't made any sort of mistakes in terms of syntactically or what have you, doing things that don't make sense.

You can preview a rule which says, "If I ran this rule, this is what would happen," but nothing, uh, nothing happens. And then you can simulate a rule, which is, "I'm gonna do everything of the rule except for egress," because you can undo things inside of Dojo. You can't undo... Well, it's harder to undo things that leave Dojo.

You certainly, like if you add a bunch of tickets to Jira accidentally, and they're the wrong tickets, it's a little more fun to clean that up than to simulate it and make sure, yep, what's gonna go to those tickets is exactly what I want. I'm gonna now turn it on to live and let those flow all the way to whatever external system those are going to.

So we give you lots of options to make sure your rules behave exactly like you want them to. So, yay, you're excited about Triage Engine. You logged into your Dojo, and you don't see it. Well, it is a feature flag, like we've started this process of most of our new things end up being feature flags that you can turn off or on based on whether or not you want to use them, and that's under your, uh, like admin superuser, um, control.

But if you go to the feature flag section, you can search for Rules Engine 2.0. That's our sort of internal name. It's now called Triage Engine. That'll actually change shortly. It'll soon say, uh, Triage Engine. But you go to that, and you turn it on. It's just a off/on button, basically. And once it's there on the side menu, it'll show up under Act.

There'll be Triage Engine with view all rules, runs, deliveries, and webhook receivers. I don't think I've mentioned this yet, but we do actually have the ability to receive inbound webhooks to Dojo as well, if you wanna have events outside of Dojo cause a rule to run. And then the third step is if you want more than superusers to interact with rules, you can do, use these custom, uh, roles I was talking about.

There is a, a grant rule view, rule add, rule edit, rule delete. Um, these are global roles obviously, 'cause you're c- talking about the entire data set of DefectDojo. But say if you had an auditor that wanted to be able to review your rules to make sure they're doing the right thing, you could give them the, uh, rule view, uh, custom role, and they could kind of look over your shoulder and make sure you're doing what's right.

Um, and even if you are somewhat highly privileged in RBAC, like I can see all the assets in an organization, that doesn't mean you can do rules. So this is where those custom roles, if you have, say, a team that do- that, or a, a whatever, uh, an employee that does all of the, uh, work under an org in DefectDojo and you want them to write rules, you can do that.

You just have to give them that custom role, because Dojo itself can't understand, you know, your RBAC needs, so we just give you all the, uh, gears and levers you need to make that happen.

Okay, uh, and the nodes, those little Lego blocks that you use to build these rules, uh, we're gonna say 40 plus forever. Like I mentioned earlier, we just added two more, or I think... I don't know if they came out on Monday, or if they're coming out next Monday, or if we had one on one, but this number of nodes is gonna increase 'cause people keep finding interesting and cool things they wanna do with Dojo, and so we're adding to them.

So 40 plus for now, and that number will go up, I'm certain. But in terms of triggers, finding event, asset event, schedule, manual run, those make pretty much sense. When a scan has landed, that means you've done an import and the, the data is now in Dojo, so you can trigger things. If this scanner that always gives me these annoying highs that are really mediums because of mitigations I have in place that the scanner won't let me adjust for, I can go in, and once that scan lands, bump all those things down to medium, let's say.

Right? So now you can start to adjust dynamically at near import time what's going on in Dojo. On a scan missing was a customer ask, a beautiful customer ask. This, they had CI/CD, and they wanted to know when it didn't happen. This was a regular, like, cron-ish, uh, CI/CD run. They wanted to know when it didn't run.

Now we have on a missing scan, and I mentioned the, the inbound webhook as well. Logic you can do if/then. You can limit if you only want, like, if you only wanna send a PagerDuty to the, for the top 25 highest priority things across all of Dojo, you can limit it to 25. Those kind of things. You can do if.

You'll see that, um, if with filters. You'll see that in the demo. You can also deduplicate within a run as well. Uh, for findings, you can set a whole bunch of things about findings. A risk priority, accept the risk. Set owners and reviewers is very frequently used, so is tagging, right? I need to tag, um, particular things and findings so that when I do reporting, I can pull them out via tag.

Uh, same thing for assets. There's tags, SLAs. Uh, we have custom risk prioritization calculations. You can assign those to specific assets based on some filtering criteria. And then egress, like I mentioned earlier, this is sending to external systems. Slack, Jira, email, uh, outbound webhook, a simple notification service.

You can create a Jira issue, generate a report, et cetera. Bunch of different things. So you could have... If you had to re- do a, uh, like a regular quarterly scan and send off a report to somebody, you could have the rule, have a rule once that scan lands, create, generate the report, and then have a second rule that takes that report and ships it off, right?

Those kind of things. I think you can actually gen and ship. I'm not sure. I haven't tried that yet. I bet you can.

So, and then the guardrails that I talked about earlier, and this is where you, you sort of have to, to... There, there's a nuance here that's important. So preview is truly a dry run. Nothing changes, right? So if you've created a rule, you've validated it, it looks good, preview is how you can ask, answer the question: What's gonna happen if I was to run this rule?

But nothing changes in Dojo. It's all sort of theoretical. It is theoretical, um, not sort of. So it does cap it. It doesn't do all of Dojo. So if you did a rule that was gonna change a million findings, I think it caps at, like, 25, just so you can get an idea of what would happen. Um, but if it does cap it, it'll tell you that it did.

And then the next step for me doing this is, particularly if I have an egress, is to do the simulate, and this runs it for real and changes data. So simulate does change data. However, it simulates a delivery, AKA you don't actually drop a thing in Teams, shoot out an email, what have you. So this is a great way to make sure that the inside of Dojo stuff is working exactly like you want it to before you send it outside of Dojo, is how I like to think about simulate.

Simulate what would happen if I sent this outside of Dojo is, is kind of how I keep it in my head.

So Runs is one of the UIs that'll show you, uh, the runs that have happened for all the rules you've written. It will give you a trace of the node. This is much better. I'll show you this. It's hard to explain, but it's easy to see. Um, it'll tell you if there's failures. You can rerun that rule now if you want to.

Um, and it'll show you, like, what question, what things were changed by this rule, like if it was assets or findings, what assets or findings were impacted by this rule. And this is one that's way easier to show than tell, so you'll see more about this in the demo. And then deliveries. Um, deliveries are sort of an audit log or a logging or whatever you wanna call it, a, a tracking of all of the things that got sent, those outbound egress, uh, uh, actions.

They have a bunch of different statuses. They were simulated, they were sent, they were skipped. Uh, they can fail and it'll retry them, but if it retries enough times, they'll become dead, meaning that like, yeah, I tried my N times or six... Yes. I tried five, six times, it's not working. I'm just gonna quit and not be in this forever retry r- loop. Um, if you do get skipped, it'll say why.

Like, you told me to send all of the critical findings to this Teams channel, but there weren't any critical, so I didn't send anything, right? That kind of a thing. And you can replay failed or dead rows if for some reason there was an intermittent outage, and you're not quite sure if it's back up and running.

You can replay a rule just to see and make sure that that thing is working like you think it should. More, more guardrails to make your lives a little better. Um, automations we've seen. T- today's demo, I'm going to look at the incoming events of a, of a particular asset, and then set the... Based on the severity, I'm going to assign them an owner and either create or not create a ticket, um, based on severity.

That's today's demo. Um, I've seen all kinds of interesting things. Notify a channel in, say, Slack or Teams if criticals come into a specific asset. There's a really high profile asset that you can't have criticals in or maybe it's got some very specific compliance requirements, and you need to know yesterday, well, really now, when something happens, that's this notify a channel.

Great example. Um, accept or lower risks for known noisy issues. This is the case where a scanner is producing things that don't match your reality, but you can't tune it out of the scanner. So you can tune it out in the Dojo layer, which is a wonderful thing, 'cause then that incorrect data doesn't make it to the teams that are actually doing the remediations.

You can fix it before you share it, which is beautiful. Um, if you're onboarding assets or you're adding new things or there's a new app that just got deployed, you can tag, set SLA, set the risk calculation, um, assign it to teams, all those kind of things as assets are added. So you... If there's a sort of post-adding process that, oh, teams in this organization get these tags and have this SLA, you don't have to remember that.

You can just say, whenever an asset gets added, do these things to it. And now very consistently, new asset config is consistent. And then we also used, uh, these, uh, Triage Engine rules for the new, uh, Jira two-way. So Jira, uh, for two-way integrations with Jira, we have a webhook listener that listens for events coming out of Jira, and then matches those up with things in Dojo.

This is where we've done it now because it just made more sense to put it in the same place as the rest of our webhook stuff. So, demo time. So for the BodgeIt asset in DefectDojo, I'm gonna look at the findings, and for those findings that are either critical or high, they're gonna go down this left path, this true side.

I'm gonna set owners to the AppSec on-call team and create a Jira issue, 'cause this is important enough that we need to react now. And then on the other side, I'm gonna set owners to the dev team and raise an in-app alert so the next time the dev team logs in, they can see, hey, I've got stuff I need to go handle. So let me jump over to DefectDojo.

Um, let me go down here, expand this for a minute. We go down here to the Triage Engine. This is where you'll find it. If I open this up, there are the rules, runs, deliveries, and webhook receivers I told you about. In this case, we're gonna look at rules. Um, I got two rules right now, this exploit-driven triage.

So if something is exploitable, AKA has a KEV or an EPSS of a certain threshold, I'm gonna do something special with it. For the, the sake of this demo, we're looking at this first rule, sort and assign, um, owners for BodgeIt findings. Let me give myself a little more screen real estate. So if we zoom in on this guy, I'm gonna close this for a minute.

If we zoom in on this guy, you will see that this first on finding event, when a finding is created in product one, which happens to be BodgeIt, and it's active, I'm gonna go on to the next block, right? In this case, if the finding severity is critical or high, then therefore it's true, I'm gonna go up here.

If it's false, I'm gonna go down here. So in the case that it's true, I have critical or, uh, high, I'm gonna set that group to on-call, and I'm gonna create a Jira issue, right? Straightforward. And then if it's not critical or high, I'm gonna make the team be the dev team for the commerce group, and then I'm gonna set an egress that just does an in-app alert with...

You can see me using those context rule names. So this rule created this alert inside of Dojo with so many lower severity findings, et cetera, et cetera. You can set who gets it, all those kind of things. So you've written your first rule. You think it's all correct. What I would do is validate it, right? So, hey, we're valid.

We got no problems. You can preview it, like I mentioned earlier, which in this case it does default to twenty-five. It was successful. You'll see this little table of what it's changes, what changes it's making to those twenty-five. So these are setting those owners appropriately to owner number twelve or whatever the other owner is for that other group.

And it skipped, obviously, simulations, like I said, skip the outbound thing, so I didn't do anything in Jira. Um, when I'm ready, I can run the rule now just ad hoc. If I want this to actually work, um, on events, I can enable it and click Live, and then if events happen, this rule runs. Um, I can run it now if you wanna just ad hoc it, so I ran it now.

Uh, this will go and set ownerships and, and create Jira. You can see that it added the count, so if I s- zoom in a little bit, right, we had zero in and two fifteen out. We did the if filter. Um, I did that if, uh, s- critical or, um, high, right? And then eight fell into that critical or high category. That got the owner set to, um, the AppSec on call and created eight Jira issues.

And then down here, I have two hundred and seven going to the dev team with an in-app alert. Two hundred and seven. So this all worked like we thought, which is beautiful. Um, if you bounce over to the Run, uh, option, y- here's our last run, right? Two hundred and fifteen items changed. I can look here. This was that tree...

or the, uh, the audit trail I was telling you about, right? So the if filter had eight true, two oh seven false set owners. Two hundred and seven were affected there, right? I can look at here. I can look at what... how many we raised in-app alerts for, how many we created Jira tickets. This is a link, if I open up in a new tab, to all the findings that changed, right, for that rule run.

I don't think we have owner column here. Nope. So if I add owner column and I scroll over, you will see way over here, they all got assigned to the right. Here's those eight that got the AppSec on call, and the rest got the dev team. So this all just worked like we planned, which is beautiful. Um, you can also look at the, um, deliveries, right?

So here's... I have it still in simulation. It's not live. So it simulated those Jira tickets. Um, but you can see that here, and you can, and look at what happened, right? Yep. Here's, here's the actual, uh, findings that got handled by simulation.

And then if I, I have a particular finding pulled up, which was one of those findings, and I purposely did this so I could leave it un-refreshed. And you'll notice there is no owner showing here. However, if I refresh, you will see now that we have an owner, which is that AppSec on-call team. And if I scroll to the bottom, you can see we have a Jira ticket, which is SEC-66, which is right here, and here is that Jira ticket.

Now, I created this prior when I was practicing the demo in all candor, and you can't like re-recreate a ticket. Um, I, I guess I could have deleted it, but I didn't. Um, so here's what the ticket you get when that rule runs, and it's a standard, uh, Dojo integration with, uh, Jira, right? So everything just kind of works, which is pretty sweet.

Uh, jumping back to the prezo.

So I, I showed you how you can branch. You can do the eight went down true, the rest went down the false. I- you got counts that I showed you. Um, you got... I can simulate, I can preview, I can understand what's gonna happen, which is really nice. Um, if you simulate, obviously the, uh, egresses get skipped. Um, and then you can run it and get findings for real.

Uh, if, if I had set it to live and, uh, enabled it, I didn't do that 'cause I was a little afraid. There's a lot of automation that happens in this demo. I didn't want stuff changing out as I was doing the demo, so I cheated a bit. Uh, but going live is just those two clicks. I go over here and I do enabled and live, and I'm done, and this rule is just running now.

I don't have to do anything.

Um, if you do have the classic rules engine, there is a way to convert them. If you're in SaaS, that's a ask customer support, we'll run this for you. If you're on-prem, there's a manage.py command to do this. Um, we map filters to triggers, schedules to on schedule. If there isn't a schedule, we make it a manual run, and each action in that, uh, classic rules engine becomes a node in Triage Engine.

Ugh. Um, we're either gonna convert conveniently, uh, cleanly or not. Um, converted rules are disabled, and then, uh, the rule converts only once. You, y- we won't reconvert rules. We'll know that we can r- you know, classic rule seven became Triage Engine rule 12, and we won't repeat that process. So it's idempotent, basically.

Um, and then we... things that don't get carried over in the migration, the run history, right? Obviously, 'cause that's the run history of the rules engine, not the run history of Triage Engine. Schedules don't, unless you pass --activate-schedules, and it will actually move those schedules over. Um, and things like set false positive to false.

There's a different way we do that in Triage Engine, so those weren't able to be converted cleanly, so we chose to leave them running as classic rules instead of give you breakage, which I think is a fair trade. Um, didn't show you this, but, uh, there, there's a whole set of rules available for assets. Um, actually, if I pop over here, you can see they are, they will be grayed out because I started with a finding, so you can't mix these models.

And by the way, since I'm here, we did add a bunch of AI tests as well. You can group by fix. You can, uh, uh, access, assess the exploitability of a thing, as well as check for false positives if you don't have trust in your tool and you wanna mark some false positives, which is pretty sweet. Um, yeah, so there's, there's some triggers created.

Um, you can sweep all the assets on a schedule. You can shape what that asset looks like. Um, this is like I was saying, if you're adding things, you know that they get added consistently. It's sort of a, a deterministic way to make sure that assets created have the right tags and everything, and you don't have to remember or have a cheat sheet with you, which is quite nice.

Um, and everything else works the same. The runs, the previews, all that stuff is all the same. Um, and then we do have webhook receivers, so DefectDojo can now take inbound webhook receivers. Uh, this is that URL that you will use to do that. And this is how we did the two-way sync with Jira. Um, you can paste the sample payload when you're creating custom ones, um, and then, and do whatever you need to with that.

If you're shipping in things that look like findings, you can turn them into findings. Um, yeah, and that's it. And obviously, like, testing webhooks is different than testing things that are all internal to Dojo, obviously. You have to either generate or send a curl. Th- It's just testing webhooks are different.

If you've ever messed with webhooks, you realize you end up having little curls that simulate the submission of different events so you can test things. At least that's how I've done it. Uh, next steps. Well, this is fully documented in, in, in gory detail on our documentation site. Um, if you're excited, you can go turn it on with your feature flags.

Like I said, I like to at least validate and do a preview, if not simulate, so I understand what's happening with that rule before I actually really, really turn it on. I sometimes will even dry run them a couple of times just to make sure everything happens like I want it to, uh, but I'm kind of paranoid.

Uh, if you have classic rules, we can convert them, and if you're not on Pro yet and this was interesting to you, you know, please come talk to us. We'll happily give you a, a demo, um, and you can see what it's like to use this for real. That's kind of the end. I'm not sure where I am on time. I loved... I had to do this.

I wanted a thank you graphic, so I asked, in this case, uh, Nano Banana, "Can you give me a," what was it? A large friendly thank you with a transparent background, but it made the transparent background visibly look like if it had made a transparent background in a graphics editor. So I just had to leave it there, 'cause that was just beautiful.

But that's all I have today. I don't know if we've gotten any questions in or not, um, but I'm, I'm ready to answer them if there are any.