WEBVTT 00:12.950 --> 00:17.630 Good morning, good afternoon, and good morning to our fellow viewers across the globe. 00:17.890 --> 00:23.230 My name is Joe Christian and I'd like to personally welcome you to day three of AppSec Village at DEF CON 28. 00:23.610 --> 00:28.370 First, I'd like to thank our sponsors for check marks, Google, and Offensive Security. 00:28.510 --> 00:32.210 Without them, we could not have provided you all this amazing village this year. 00:32.290 --> 00:39.170 I'd like to issue another thank you to DEF CON and all of our volunteers for their blood, sweat, and tears poured into this incredible effort. 00:39.570 --> 00:43.690 Lastly, I'd like to thank the community for supporting us another wonderful year. 00:43.710 --> 00:45.110 This village is for you. 00:45.210 --> 00:48.970 With that being said, I'd like to introduce our first speaker today, Christian Snyder. 00:49.390 --> 00:55.490 Christian's talk is titled ThreadGile, Agile Threat Modeling with Open Source Tools from Within Your IDE. 00:55.870 --> 01:03.950 Christian has pursued a successful career as a freelance Java software developer since 1997 and expanded in 2005 to include the focus on IT security. 01:03.950 --> 01:09.170 His major areas of work are penetration testing, security architecture consulting, and threat modeling. 01:09.510 --> 01:20.170 As a trainer, Christian regularly conducts in-house training courses on topics like web application security and coaches Agile projects to include security as part of their processes by applying DevSecOps concepts. 01:20.730 --> 01:25.490 Christian regularly enjoys speaking and giving trainings on major national and international conferences. 01:25.490 --> 01:27.330 Please give a warm welcome to Christian. 01:28.210 --> 01:30.410 Hello, welcome to my talk. 01:30.410 --> 01:37.290 My name is Christian Snyder and I'd like to introduce you to ThreadGile, the new open source toolkit for Agile Threat Modeling. 01:37.670 --> 01:48.990 I'm working as a freelance security architect, penetration tester, and trainer, mainly focusing on areas like DevSecOps, security architecture consulting, and Agile Threat Modeling. 01:48.990 --> 02:15.290 With ThreadGile, the idea is to bridge the gap between classic, more workshop-like threat modeling approaches and Agile development with a fast pace of rollouts and a fast set of commits and eventually using DevSecOps approaches, a very Agile and very quick way of rolling out into production and not neglecting threat modeling in these kinds of setups. 02:15.750 --> 02:32.850 And the idea is to let developers create some declarative threat model inside their IDE that is basically not required to go to a different tool or switch the work mode of operation, just maintain in a declarative fashion, everything about your application, 02:32.850 --> 02:37.030 your architecture, in a very simple-to-read, human-readable YAML file. 02:37.090 --> 02:51.910 That includes like classic threat modeling approaches, the data assets, the components, technical components, and the communication links between them, where the data flows, and trust boundaries that might be crossed by communication links. 02:52.670 --> 02:56.810 That YAML file can be checked in in the source tree as any other artifact. 02:56.890 --> 03:05.990 So the benefits of that, it's diffable, it's collaboration capable, it's testable, verifiable, you can easily just start along with the project. 03:07.050 --> 03:24.550 And the modeled elements, especially the technical elements in that YAML file, contain very detailed levels of the technology and the protocols that are chosen in order to be able to have a very good risk generation from some kind of risk rules. 03:24.550 --> 03:41.510 So ThreadGeneral has a set of built-in risk rules that analyzes these kinds of sets and treats this as a connected graph of components, and deriving risks, potential risks, threats, hardening recommendations, documentations, model graphs, data flow diagrams, 03:41.510 --> 03:44.150 and different output formats from that. 03:44.670 --> 03:51.230 And even custom risks can be added, because as any tool, you cannot identify every risk with a tool. 03:51.350 --> 04:05.290 So you need to have some manually identified risks that can be added to that model as well, because sometimes in these kinds of workshops, you come up with new risks that have not been identified by any kind of tool. 04:05.290 --> 04:08.190 And this can be added into the YAML file as well. 04:08.630 --> 04:13.270 ThreadGeneral is a technology-aware way of modeling your architecture. 04:13.270 --> 04:20.970 So you define what type of technology is used, what protocols are used, so it understands from that whether it's encrypted or not, for example. 04:20.970 --> 04:24.430 It has around 40 risk rules, so it's growing. 04:24.650 --> 04:27.150 And you can even create custom risk rules. 04:27.150 --> 04:32.990 It calculates some attacker attractiveness and data loss probabilities more on that later on. 04:32.990 --> 04:38.390 And you can even automate things using model macros in a very wizard-style approach. 04:38.390 --> 04:49.410 And even the risk mitigation can be maintained in that YAML file, so that even the tracking and the remaining risks that you want to accept are documented that way. 04:49.670 --> 04:52.250 And of course, it's released as an open-source software. 04:53.610 --> 04:57.650 So in ThreadGeneral, basically you run it as a command -line interface. 04:57.650 --> 05:03.970 It's shipped as a docker container, or you can execute it as a web server with a REST interface. 05:04.310 --> 05:11.290 Here you just see the command-line interface with just a few of the many switches and options that you can use. 05:12.130 --> 05:23.850 So the first steps within ThreadGeneral are that you create either a minimal stub model that can be created from ThreadGeneral as well, or a filled example model if you want to play with it and see how it works. 05:24.130 --> 05:34.990 And it's basically containing that YAML file that's the input into ThreadGeneral, the data assets, the technical assets, the communication links, and the trust boundaries, and a little bit more if you like. 05:35.450 --> 05:50.110 So here you see the YAML example of data assets, customer contracts, has some kind of owner, some kind of origin, especially the confidentiality, integrity, and availability ratings are interesting. 05:50.110 --> 05:55.310 So you can rate the data assets, how confidential for example they are. 05:55.310 --> 05:59.110 And you can model technical assets as well in that YAML file. 05:59.250 --> 06:09.250 So for example here, an Apache web server where you can define again the confidentiality, integrity, and availability ratings. 06:09.250 --> 06:13.610 But you can also define a technology out of a bunch of possible technologies. 06:14.030 --> 06:21.050 And you could define a little bit more whether it's used by a human, that would be more like being a client or browser for example. 06:21.050 --> 06:25.750 What type it is, like a process , external entity, or data store. 06:25.750 --> 06:29.070 And you can tag it if you like, and whether it's encrypted or not. 06:29.070 --> 06:32.710 So a few questions you can answer there as well. 06:34.010 --> 06:41.970 Then you can reference data assets that are processed or stored on that kind of technical asset just by their ID. 06:42.050 --> 06:51.610 So from the ID referencing Threja learns the distribution of data and the distribution of data that's processed on those kinds of technical assets. 06:52.690 --> 06:55.230 And then you just model the communication links. 06:55.230 --> 07:02.090 So basically pointing from one system, from one technical asset to another component, another technical asset. 07:02.090 --> 07:09.510 So it's an outgoing communication link and you can even attribute that with the kind of protocol that's being used. 07:09.510 --> 07:15.050 Whether it's let's say here HTTPS or it could be FTP or whatever whatever you'd like, LLAP. 07:15.170 --> 07:19.710 That's a big list of protocol values that you can choose from. 07:20.010 --> 07:24.190 And Threja even knows whether it's an encrypted or not encrypted protocol. 07:24.390 --> 07:33.510 You can define what kind of authentication is happening, whether it's not authenticated, that communication link or just uses credentials or a token-based approach. 07:33.790 --> 07:37.750 And if it's authenticated you can define with what kind of authorization. 07:37.750 --> 07:42.750 Either the technical user or an end user identity or something like that. 07:42.750 --> 07:52.630 And you can answer a little bit more questions and you can reference the data assets that are sent and eventually received from that kind of communication link. 07:54.070 --> 07:56.810 Finally, you model the trust boundaries. 07:57.010 --> 08:10.170 These are basically the let's say virtual network areas where you want to have some kind of network trust boundary between them or in a containerized world eventually namespace isolation, something like that. 08:10.170 --> 08:11.290 You can model that. 08:11.290 --> 08:14.130 So different types of trust boundaries are existing. 08:14.270 --> 08:18.230 And then you just reference the technical assets that are used inside. 08:18.310 --> 08:24.510 And if you do nest trust boundaries, definitely something that's possible, you can reference them as well. 08:25.210 --> 08:33.670 Then when you execute fragile on the command line, it processes the YAML input and applies the RISC rules. 08:33.670 --> 08:39.310 So there are lots of built-in RISC rules and you can even add your custom ones and it creates some nice output. 08:39.310 --> 08:41.150 First of all, here an example. 08:41.150 --> 08:43.190 It gives a model graph. 08:43.190 --> 08:51.370 It generates a model graph that you can see whether you have modeled something wrong or something is missing from your architecture. 08:51.690 --> 09:04.490 The colors in the lines as well as in the shapes are referring, depending on the data ratings that are being stored there, to the sensitivity of that kind of asset. 09:04.490 --> 09:13.690 So a red border means that there are very sensitive data stored or a red line means there's very sensitive data being transferred. 09:13.990 --> 09:25.670 And the color like the yellow ones means there's custom developed code and the shape is a little bit depending whether it's a data store, process, external entity or a client used by a human. 09:25.670 --> 09:31.310 So there's a set of semantics behind these kinds of colors. 09:32.010 --> 09:34.610 And it generates a PDF and Excel report. 09:34.610 --> 09:40.790 So very long in terms of being also some kind of documentation artifact. 09:40.790 --> 09:46.990 And this kind of report has some redundancy in it because it has two different views. 09:46.990 --> 09:53.310 It has a view of risks by vulnerability category and a view of risks by technical asset. 09:53.910 --> 09:57.410 So let's dive a little bit into the reports that have been generated. 09:57.410 --> 10:04.990 You see some management summary with some pie charts depending on the risk severity and also on the risk tracking state. 10:04.990 --> 10:07.750 You can add your custom management summary text as well. 10:08.150 --> 10:09.410 And you have got the impact. 10:09.410 --> 10:15.290 That's basically the impact from the identified risks, including some individual added one here, the critical one. 10:15.290 --> 10:16.530 More on that later. 10:16.850 --> 10:20.970 And also you can define and see the risk mitigation here. 10:20.970 --> 10:24.770 So in the risk mitigation chart, you see bar charts going up. 10:24.770 --> 10:34.610 So where basically the distribution of the risks that have been identified are grouped by the tracking state, which you maintain as well in the YAML file. 10:34.610 --> 10:45.910 So you can have something that's in progress here in blue or mitigated in green or something that has been accepted as a risk in pink or the red ones are just unchecked. 10:45.910 --> 10:48.750 And you've got the impact analysis of the remaining ones. 10:49.370 --> 11:01.870 Also for classic threat modeling, you do have the stride classification of the identified risks, spoofing, tempering, repudiation, information disclosure, and other kinds of categories. 11:01.870 --> 11:03.950 And you've got an assignment by function. 11:03.950 --> 11:10.030 So who, what kind of party in your corporation or team shall basically handle that kind of risk? 11:10.030 --> 11:11.330 So who should address that? 11:11.330 --> 11:16.690 So is it business side, architecture side, development, operations, something like that. 11:17.670 --> 11:27.230 Also ThreadGile calculates the RAA, the relative attacker attractiveness value, which is just a percentage value ranging from zero to 100%. 11:27.230 --> 11:31.430 The higher, more attractive for attackers, the technical asset is. 11:31.430 --> 11:34.870 So these values are assigned to technical assets. 11:35.390 --> 11:37.650 And there's an algorithm which is pluggable. 11:37.650 --> 11:40.930 You can plug in your own custom algorithm if you like. 11:40.930 --> 11:51.550 And that algorithm basically treats the amount and the sensitivity of data on the assets and as well as the communication links and the paths that attackers can take to go to these. 11:51.550 --> 12:05.010 If a sibling of another system is having less sensitive data, but connects to that very high sensitive data carrying system, that kind of neighboring system is also rated a little bit higher. 12:06.110 --> 12:09.570 And DLP, data loss probabilities, are also calculated. 12:09.690 --> 12:18.750 So here you see inside the report a graph, which here on the left side contains lots of red data assets. 12:18.850 --> 12:32.650 And the right side of the shapes are basically the components and the errors, depending whether it's a dashed or a solid error is whether it's processed on that asset or stored on that asset. 12:32.810 --> 12:40.870 And depending on the sensitivity of the data, you can see here if you eventually have some risks where you might want to handle that. 12:41.110 --> 13:01.250 And the colors here reflect the risk of the data loss probability, which is basically depending on how many data assets, how many technical assets the data assets are stored or processed, and how many risks are there on these assets that might have a blast impact of losing that data. 13:01.250 --> 13:16.610 So in the detailed report, you even have the individual risks listed that you should mitigate, especially the red ones, which would yield the biggest benefit of going from red to amber or even a better color that you're not risking the data loss there. 13:16.610 --> 13:27.370 So that way you can basically prioritize, depending on the data risks that you might lose them, your efforts of mitigation of those identified risks. 13:27.910 --> 13:30.830 And the risk mitigation recommendations are also created here. 13:30.830 --> 13:45.910 So you see some server-side request forgery or XML external entity attack in these examples here, where you have risk mitigation texts, including links to the OWASP ASVS chapters and to the OWASP cheat sheet. 13:45.910 --> 13:53.190 That's basically if it's available for that kind of risk, giving the developer and team some kind of hints on how to mitigate that. 13:54.030 --> 13:57.590 The risk instances are also obviously inside the report. 13:57.590 --> 14:03.270 Everything's linked and clickable, so you can click and easily navigate around in that report. 14:03.270 --> 14:17.670 And you have it either grouped by the vulnerability type on the left side, or on the right side, you've got the risks by a technical asset, so that you can get from that kind of view also to the risks and the descriptions of how you can mitigate them. 14:18.170 --> 14:23.970 Of course, you get an Excel report as well for easier filtering, sorting, and stuff like that. 14:23.970 --> 14:26.270 Same data, different format. 14:26.390 --> 14:31.970 And being DevSecOps ready, that means the results are also available as a JSON output. 14:32.190 --> 14:40.870 So you can process them inside Jenkins or any kind of other GitLab CI, or whatever you like, some kind of DevSecOps pipelines. 14:40.870 --> 14:48.710 So CICD pipelines can then execute fragile as a command line or via the REST server, if you like, depends on what you want to do. 14:48.730 --> 14:56.010 And the result is a JSON file listing the remaining risks and their distribution across the different severity levels. 14:56.010 --> 15:05.070 And then you can, for example, automatically break a build if a system includes or a build includes some yet unchecked high risks. 15:06.470 --> 15:09.890 And the risk rules, that's a set of constantly growing risk rules. 15:09.890 --> 15:16.430 So there are around 40-ish something in it, and you can extend that with more risk rules if you like. 15:16.430 --> 15:19.090 So that's growing on a day-by-day basis. 15:19.610 --> 15:23.250 And risk rules are written in Go inside Fragile. 15:23.250 --> 15:25.890 Fragile is itself written completely in Go. 15:26.230 --> 15:29.390 And here you see an example for a risk rule. 15:29.390 --> 15:30.730 This is an LDAP injection. 15:30.730 --> 15:40.510 So you have some category definition where you have the texts and the cheat sheet links and basically the metadata that the report is generated properly for that kind of risk. 15:40.510 --> 15:45.270 And on the right side, you see the very simple code to identify those risks. 15:45.270 --> 15:53.450 So it's basically some kind of graph identification from the assets that you modeled and the communication links that you modeled. 15:54.650 --> 16:00.970 You can even, if you like, add manually identified risks to Fragile in the same YAML file. 16:00.970 --> 16:04.970 So the same input file can include manually identified risks. 16:04.970 --> 16:09.270 These that are not usually identifiable by tool. 16:09.270 --> 16:16.950 So for example, in a classic threat modeling workshop, you identify those additional risks and you do not want to track them in a separate way. 16:16.950 --> 16:24.330 You want to keep them in the same way that you track the tool-based identified risks inside Fragile. 16:24.330 --> 16:29.650 And that can be done by simply enhancing the YAML input file with individual risks. 16:29.650 --> 16:38.130 So here you provide the metadata of the text, what happened in that kind of risk that you identified, how it should be mitigated and stuff like that. 16:38.130 --> 16:42.070 Here you provide that basically as values inside the YAML file. 16:42.070 --> 16:45.890 And on the right side, you see that this risk has two instances. 16:45.890 --> 16:51.630 So it has, for example, been identified at some database and on some file system server here. 16:51.630 --> 17:02.010 And you can even link to the technical assets that are the most relevant, have the most relevance of losing that kind of data when that risk manifests itself. 17:02.010 --> 17:10.610 So that way, the blast impact of the data loss probability is also reflected with that kind of manually added risk. 17:11.510 --> 17:15.830 You do have very good editing support in IDEs for YAML files. 17:15.830 --> 17:20.250 That's definitely something that's been around for some time, even in VI, if you like. 17:20.250 --> 17:22.450 So there are many YAML editors available. 17:22.550 --> 17:24.550 It's easily readable by humans. 17:24.590 --> 17:31.770 For example, in my IDE, I do have here on the right side a tree that I can click to navigate inside the YAML file. 17:31.770 --> 17:35.410 So that's automatically populated from the structure of the YAML file. 17:35.410 --> 17:40.910 So that's definitely something that's having a very good support of IDEs. 17:41.690 --> 17:43.170 It doesn't stop there. 17:43.170 --> 17:47.870 It goes even into schema validation and auto-completion. 17:47.870 --> 17:55.000 So Thragil supports IDEs by having a YAML schema available for the Thragil model. 17:55.790 --> 18:00.510 That basically means you can import that YAML file into the IDE. 18:00.510 --> 18:04.090 And then you have some kind of automated checking of the syntax. 18:04.090 --> 18:05.890 And you get some error flags. 18:05.890 --> 18:09.770 For example, here on the left side, I've got a typo web server with many Rs. 18:09.770 --> 18:13.410 So that's definitely flagged as an invalid technology type. 18:13.410 --> 18:17.870 And that's something that has been validated by the IDE due to the schema. 18:18.070 --> 18:20.910 And that schema gives me also some kind of auto-completion. 18:20.910 --> 18:30.690 So when I type on the technology web and hit a control space, the pop-up basically includes everything that begins with web, like web application, web server, or what else. 18:30.690 --> 18:43.150 So that's some kind of auto-completion that you just get for free by simply importing the Thragil YAML file schema into your whatever IDE or YAML editor you use. 18:43.730 --> 18:57.170 You can also have some kind of live templates for quicker editing of and creation of those elements, like technical assets, communication links, or data assets, or something like that. 18:57.170 --> 19:12.730 So importing these templates in major IDEs allows you just to hit a tech asset, enter, bam, you've got a pre-populated template where you just give it a name and then you tap through those elements and hit control space to open the auto-completion pop-ups. 19:12.730 --> 19:15.190 And that's a little bit like a Zen coding style. 19:15.290 --> 19:16.770 Definitely something nice. 19:17.810 --> 19:20.470 And we do have model macros inside Thragil. 19:20.470 --> 19:23.330 That's basically some kind of interactive wizard. 19:23.330 --> 19:26.270 So that's a little bit like a state machine that you can create. 19:26.270 --> 19:32.670 And each model macro has a set of questions that are being asked in a sequential, interactive way. 19:33.150 --> 19:41.810 And it reads, each model macro reads the YAML file of an existing model and it asks you questions of what you would like to do. 19:41.830 --> 19:50.190 And so we do have different model macros like adding a build pipeline or adding a vault or adding identity provider, including an identity storage to the model. 19:50.190 --> 19:58.730 And that way you can codify and reuse and make this a little bit individual due to the questions that you ask the user. 19:59.130 --> 20:11.350 The kinds of repeating model elements that you have in your corporation or in your teams and make them, adding these, modifying the model files that way in a very easy way. 20:11.350 --> 20:15.010 So a pluggable interface also allows you to create your own model macros. 20:15.570 --> 20:16.910 So how does this look like? 20:16.910 --> 20:19.030 It's on the command line. 20:19.090 --> 20:30.770 So you do have, for example, here a add build pipeline model macro where you have just a few questions that you answer and then you can select on which kind of components this build pipeline should deploy, for example. 20:30.930 --> 20:36.690 So it reads the model and it modifies it accordingly and you can create new trust boundaries for that. 20:37.010 --> 20:39.870 Is it either push-based or pull-based deployments? 20:39.870 --> 20:42.510 More on the GitOps style. 20:43.250 --> 20:55.750 And then you've got a summary, like a dry run, of what would be added to the model and adding new data assets, adding new technical assets, including the communication links, adding new trust boundaries. 20:55.750 --> 20:58.550 So all these modifications are done automatically then. 20:58.550 --> 21:01.470 And the result is you get something more out of that. 21:01.470 --> 21:04.850 So you get the communication paths added as well. 21:05.970 --> 21:08.130 Okay, so what about risk tracking? 21:08.130 --> 21:17.510 So inside the YAML file, you also have a way to track the identified risks by a unique risk ID. 21:17.510 --> 21:28.810 And you can even group them with bytecards to have some kind of sets of risks of the same type for the same component or something like that, to be tracked in the same style. 21:28.810 --> 21:45.110 And you can assign a status, like whether it's unchecked, that's the default state if it's not being tracked yet, or the risk is in discussion, or whether the risk has been accepted and it just remains as a remaining risk, or whether it's in progress, 21:45.110 --> 21:51.010 so you're working on mitigating it, or it has been mitigated, or whether it's a false positive. 21:51.010 --> 21:53.770 Sometimes tools also have false positives, definitely. 21:54.830 --> 21:56.730 And you can add a justification. 21:56.730 --> 22:03.770 Optionally, you can add a ticket ID, a date, and a check by name tag, so you can track that in a very good way. 22:03.770 --> 22:25.090 And even a model macro is existing that reads an existing YAML file, applies the risk tracking, and then it generates the yet-untracked risk instance IDs, and they're tracking with the unchecked still, obviously, state that you can then individually shift to some kind of other state. 22:25.630 --> 22:37.850 And out of the risk tracking definitions in the same YAML file, you get the risk mitigation state you just saw recently here in the talk, in the PDF file, you see it on the right side. 22:38.870 --> 22:40.470 What about bigger models? 22:40.470 --> 22:44.650 Of course, bigger models work well, and even way bigger models work well. 22:44.650 --> 22:50.730 Something we did in beta testing of Thragil, definitely, even way bigger models work quite good. 22:51.730 --> 23:06.670 Also, a REST server is existing inside Thragil, so you do have some, in the Docker container, some way to start it and expose a port, and that port is basically giving you a way to use Thragil like a REST API. 23:06.670 --> 23:14.730 That means you can send in the YAML file and get a zip file where all those artifacts are in that Thragil generates. 23:15.110 --> 23:22.590 And you can also, in the next version, then basically create a model on the server side that start that way in an encrypted fashion. 23:22.610 --> 23:32.150 And then you can add data assets to it, you can add technical assets to it, you can add communication links to it, apply the risk tracking, import or export the model file, if you like, something like that. 23:32.150 --> 23:36.170 And if you want to play a little bit with that, there's even a playground online. 23:36.170 --> 23:38.610 It's just on run.thragil.io. 23:40.250 --> 23:53.870 So what are the possible effects of modeling risks or modeling threats or applying threat modeling actually in some kind of YAML file and letting the risks and the threats being generated by an open source tool that way? 23:53.890 --> 24:10.190 So not leaving the IDE, making it pluggable, the risk rating scheme or the risk rules means that corporations can even have their individual policies coded in some kind of easy to code and go long risk rules. 24:10.310 --> 24:16.650 And these custom code risk rules can analyze the model graph according to the corporate individual policies. 24:17.770 --> 24:31.150 Also, if many more projects are using it inside a corporation, you can then, for example, have some kind of uniform documentation of the system landscape built bottom up, project by project, system by system. 24:31.150 --> 24:34.170 You can even try to link them in a very good way if you like. 24:34.770 --> 24:37.330 And it's built by the dev teams in their IDEs. 24:37.330 --> 24:42.010 They're not leaving their tools of choice and they do it in their favorite IDE. 24:42.010 --> 24:46.870 And it's just running along within the code base, checked in in some kind of YAML file. 24:46.870 --> 24:47.650 That's it. 24:47.650 --> 24:52.070 So it's easy to keep that up to date compared to classic threat model approaches. 24:52.070 --> 24:54.930 So it's a way to have continuous threat modeling. 24:55.990 --> 25:02.510 It's easy to instantly regenerate from some kind of project, the risk landscape. 25:02.510 --> 25:12.670 So if something changes, for example, so for example, a data classification changes, being more confidential, or some component is moved into the cloud. 25:12.670 --> 25:14.210 So something like that. 25:14.210 --> 25:19.410 Then you can just regenerate it and see if some new risks might emerge from that kind of change. 25:20.230 --> 25:24.530 And you can do that instant risk regeneration even on corporate level. 25:24.530 --> 25:39.870 So for example, when a policy changes or a new policy is introduced, some new regulatory policies, for example, then you can adjust your custom risk rules accordingly or create a new one and then just execute Threadger on all of your projects. 25:39.870 --> 25:51.790 And then you might see which of these projects eventually have some kind of to-do to mitigate some newly emerging risks, not matching something like a new policy that has been put into place. 25:52.510 --> 26:07.070 Also, CICD pipelines can check the generated JSON to automatically fail the build or at least flag it as unstable, something like that, if some unmitigated high risks are still there. 26:07.070 --> 26:15.890 So having the risk tracking state inside Threadger and having the remaining risks, that way you can also just evaluate that data in the JSON file. 26:15.890 --> 26:27.150 And then you can just fail the build if you want to avoid an automatic rollout into production where new high risks have not yet been checked, at least. 26:27.150 --> 26:31.190 So that's something that is definitely ready for DevSecOps approaches. 26:31.190 --> 26:37.930 That means Thread modeling, continuous Thread modeling, becomes part of a DevSecOps approach. 26:38.150 --> 26:42.090 And that's basically what Threadger is about, about agile Thread modeling. 26:43.210 --> 26:47.590 Hopefully, security is then less bottleneck for Thread model sign-offs. 26:47.590 --> 26:59.370 That basically means the security team can more focus on the individual risks and not the standard that have been easy to identify in some kind of coded risk rules. 26:59.370 --> 27:15.950 So that's easy and it's shifting things more on the left side, so that by development teams beginning from early on to maintain and create the YAML file, then you have a very early integration of Thread modeling that doesn't do any kind of bottleneck effects on your security. 27:16.790 --> 27:19.750 So it's released as an open source tool. 27:19.770 --> 27:22.070 The website is Threadger.io. 27:22.070 --> 27:25.250 There's a Playground available, run Threadger.io. 27:25.250 --> 27:29.110 The source is available on GitHub and Docker images are available as well. 27:29.110 --> 27:31.410 If you have any questions, feel free to ask. 27:31.410 --> 27:33.690 You've got my contact data there as well. 27:34.510 --> 27:48.930 Special thanks definitely to those valuable feedbacks from all the beta users, especially to those here, like in alphabetical order, very early adapters of Threadger.io and very valuable feedback. 27:48.930 --> 27:49.810 Thanks. 27:50.770 --> 27:52.630 And I'd like to thank you as well. 27:52.630 --> 27:58.470 So a little bit of Q&A if you like, and look forward to seeing you later in the chat.