[00:00.000 --> 00:08.340]  Yeah. Good morning. So since we're all here, we probably
[00:08.340 --> 00:15.240]  want to talk quite loud. Sorry. Since we're all here, you probably, thanks, all use open
[00:15.240 --> 00:20.520]  source, which is great because it offers us functionality without us having to write
[00:20.520 --> 00:26.480]  it ourselves. But the downside is for the dependencies that we declare, we tend to pull
[00:26.480 --> 00:33.560]  in a bunch of transitive dependencies, and any of those can contain vulnerabilities.
[00:33.560 --> 00:42.280]  So you might remember December of 21, because I do. And from your laughter, you probably
[00:42.280 --> 00:47.280]  spent those days in much the same way I did. I was working at a Dutch retail platform
[00:47.280 --> 00:55.080]  that uses microservices, and because of Log4Shell, we got to update everything, urgently, twice
[00:55.080 --> 01:01.640]  because after the first CVE was fixed, there are multiple other CVEs. So, you know, fun
[01:01.640 --> 01:07.040]  times. And then in March, we got to do it again, because of Spring4Shell. But at least
[01:07.040 --> 01:12.600]  we got the practice in the first time. So it was fascinating this time, right? As we
[01:12.600 --> 01:19.800]  know, using external dependencies has pros and cons. I have more on that, but not in
[01:19.800 --> 01:25.440]  these 20 minutes. I'll share a link to my website that has all of this information
[01:25.440 --> 01:30.800]  at the end. So we have to maintain our dependencies and make sure we keep them up to date. So
[01:30.800 --> 01:35.760]  I'm going to give you an overview of different tools that you can use, ending with, normally
[01:35.760 --> 01:39.760]  I would end with open rewrite, but Tim is here, so he's going to do the honors for that
[01:39.760 --> 01:47.320]  one. You probably use Maven or Gradle to manage your dependencies, so you will probably also
[01:47.320 --> 01:52.560]  know that you can use Maven dependency tree to get your dependency tree of your declared
[01:52.560 --> 01:59.160]  dependencies and their transitive dependencies. And you can ask Maven, hey, which ones have
[01:59.160 --> 02:04.720]  updates available so that you know what you could be updating? And you can use a command
[02:04.720 --> 02:10.120]  to analyze your dependencies to see which transitive dependencies you're using but haven't
[02:10.120 --> 02:16.520]  declared, and also which you have declared and aren't using that you might want to remove
[02:16.520 --> 02:24.520]  or in the case of JUnit, add some tests. Gradle has a command as well to get your dependency
[02:24.520 --> 02:31.800]  tree. As far as I know, it doesn't have a command to get updated versions, but you can
[02:31.800 --> 02:37.640]  use a plug-in, like the Ben Main's version plug-in. And I'm also not familiar with an
[02:37.640 --> 02:43.520]  analyze command. If you're a Gradle user and you do know how to do that, please tell me.
[02:43.520 --> 02:47.960]  And as I currently work for JetBrains, I'm also going to tell you what IntelliJ IDEA can
[02:47.960 --> 02:54.480]  do to help you manage your dependencies. So you can view your dependency hierarchy in
[02:54.480 --> 03:00.640]  the built-in window, either for Maven or for Gradle. And here you can see, again, the hierarchy
[03:00.640 --> 03:06.320]  of the direct dependencies and their transitive dependencies. And you can expand and collapse
[03:06.320 --> 03:12.680]  as you like, which is easier than reading it from the terminal. And you can analyze dependencies
[03:12.680 --> 03:19.920]  as well. We use the dependency analyzer in IntelliJ IDEA. This year we, or past year,
[03:19.920 --> 03:24.640]  we added a functionality called PackageSearch, which allows you to manage your dependencies
[03:24.640 --> 03:30.720]  right inside your IDE. So you can use code completion, for example, to add dependencies
[03:30.720 --> 03:40.560]  right inside your build file without having to go outside of your IDE. So, and it will
[03:40.560 --> 03:44.440]  also tell you, with a little squiggly line, I don't know what the official name is, so
[03:44.440 --> 03:49.680]  we're going with squiggly line, that will highlight, hey, there's a new version available
[03:49.680 --> 03:59.120]  for this, and then either with a hover or the familiar alt enter, or option enter that
[03:59.120 --> 04:05.920]  will suggest fixes. So, for example, to update this version, I'm using a project that's really
[04:05.920 --> 04:10.520]  outdated from my GitHub graveyard of projects. The project itself is pretty useless, but
[04:10.520 --> 04:15.560]  it's a perfect example of outdated dependencies. So, don't worry, this is not being used in
[04:15.560 --> 04:25.360]  production. So, yeah, you can use intention actions, like I said, to update the dependencies,
[04:25.360 --> 04:31.240]  and this works in build gradles too. And there's the dependency tools window that you can open
[04:31.240 --> 04:37.200]  where you can manage your dependencies. So you can, as you can see in this example, you
[04:37.200 --> 04:42.760]  can upgrade all of them at once, or you can upgrade individual ones, or you can select
[04:42.760 --> 04:47.880]  the version to use from the list of versions. You see information about the dependency right
[04:47.880 --> 04:53.440]  in this window. You can search for dependencies and find information about those dependencies
[04:53.440 --> 04:59.800]  right inside your IDE, so you don't have to go to search Maven or somewhere else. And
[04:59.800 --> 05:04.680]  in IntelliJ Ultimate, we have the package checker functionality, which even provides
[05:04.680 --> 05:09.720]  information. So this is if you hover over a vulnerable dependency that's highlighted
[05:09.720 --> 05:17.080]  in yellow-ish. It will tell you these are the vulnerabilities that were found in this
[05:17.080 --> 05:23.040]  dependency, and you can click the links to go to the checkmarks advisory for more information
[05:23.040 --> 05:30.840]  on that. And you can also see that information in the vulnerable dependencies tool window,
[05:30.840 --> 05:37.040]  so you can see which of your dependencies have vulnerabilities, what the severity is,
[05:37.040 --> 05:44.000]  find more information, and fix it right inside your IDE. So all of these tools are great
[05:44.000 --> 05:48.360]  because you can use them right as you're working on your code, but the downside is you need
[05:48.360 --> 05:52.960]  to be actually working on that project. And like I did at my last job, you have a bunch
[05:52.960 --> 05:57.880]  of microservices that adds up to a bunch of repos. You'd have to check out each individual
[05:57.880 --> 06:03.360]  repo and check for updates. And then, of course, you still have to apply those and verify that
[06:03.360 --> 06:11.040]  everything still works, et cetera. So hopefully, your company will have some kind of software
[06:11.040 --> 06:18.720]  composition analysis that can scan your repositories and sometimes also your Docker containers
[06:18.720 --> 06:26.280]  and provide you with an overview of your repos and which ones have which vulnerable dependencies.
[06:26.280 --> 06:31.120]  And the upside is that, as a developer, you won't have to individually check all of your
[06:31.120 --> 06:37.080]  repositories, but the downside is I still have to check the dashboard to see what's outdated
[06:37.080 --> 06:44.720]  and then, again, still apply and verify all of those updates. The next generation of tools
[06:44.720 --> 06:51.200]  that is useful are bots that can create PRs for you. Since we're in the Java room, I'm
[06:51.200 --> 06:56.000]  assuming we use Java, and these are the options that we have, dependable, renovate, and stick
[06:56.000 --> 07:03.720]  open source. Dependable is now GitHub native, and it offers three features. It can alert
[07:03.720 --> 07:11.040]  on your repositories. It can create security updates, so PRs for dependencies that have
[07:11.040 --> 07:16.560]  no vulnerabilities to update them, and it can do version updates. So, then there's a version
[07:16.560 --> 07:25.520]  for other reasons. Since it's GitHub native, you can configure it in your settings on GitHub.
[07:25.520 --> 07:33.360]  It's also available on other platforms, but I use GitHub just to compare the three-box.
[07:33.360 --> 07:39.720]  So if you have alerts, you'll see a yellow box with a button to press for more information.
[07:39.720 --> 07:46.600]  If it generates PRs for security updates, that's what this would look like. And if you want
[07:46.600 --> 07:53.320]  to use the version updates as well, you'll need to add a dependable YAML, insert obligatory
[07:53.320 --> 07:59.920]  YAML sounds like a Dutch word, jammer, which means too bad or unfortunate. And you have
[07:59.920 --> 08:05.480]  to provide a little bit of configuration. You can set the frequency, the maximum number
[08:05.480 --> 08:13.560]  of PRs scheduled, and some minor details on how to manage these PRs. The next option is
[08:13.560 --> 08:18.920]  a renovate, which is an open source project, but also with a vendor behind it. This offers
[08:18.920 --> 08:23.760]  the security updates and the version updates, like dependable, but also a project and a
[08:23.760 --> 08:30.720]  jobs dashboard for some more information. On GitHub, it's also fairly easy to apply this
[08:30.720 --> 08:36.080]  to your projects. You can use the app, and you can choose to apply it to either all of
[08:36.080 --> 08:41.280]  your projects or only certain projects. So if you want to just, if you've never used
[08:41.280 --> 08:45.280]  one of these bolts and you want to try it out, this is one that you can try out on just
[08:45.280 --> 08:51.160]  one repository. And as far as I know, the only one of these three. It will then generate
[08:51.160 --> 08:56.440]  a configuration for you. And once you merge that basic configuration, it will start doing
[08:56.440 --> 09:05.080]  its thing and generating PRs. You can also specify the maximum number of PRs and the
[09:05.080 --> 09:10.720]  maximum number of branches that you want open at a certain time. And it has more options
[09:10.720 --> 09:16.960]  and those options are more fine grained than the dependable options. The PRs provide more
[09:16.960 --> 09:22.600]  information as well. Why is it trying to update these versions as well as some information
[09:22.600 --> 09:28.280]  on how old is this package? This is an old screenshot, sorry. The adoption rate among
[09:28.280 --> 09:35.120]  renovate users, how many percentage of the builds that pass with this update, and how
[09:35.120 --> 09:41.920]  confident they feel about doing this update where neutral means either they can't tell
[09:41.920 --> 09:46.640]  based on the information they have or they don't have enough information yet. It will
[09:46.640 --> 09:50.640]  also add a dashboard to your project with a list of all of the things that you need
[09:50.640 --> 09:56.280]  to update. And there will be a jobs dashboard where you can check the details of all of
[09:56.280 --> 10:02.000]  the jobs that have run. The last option is sneak open source, which also offers security
[10:02.000 --> 10:08.520]  updates and version updates and some dashboards as well as the option to check for vulnerabilities
[10:08.520 --> 10:13.400]  in new PRs, making sure that you're not adding vulnerable dependencies and it can check your
[10:13.400 --> 10:21.040]  source code. Slightly more steps to enable that. You can go to their website, authorize
[10:21.040 --> 10:30.880]  your GitHub, select which repositories, either public or public and private, add a token
[10:30.880 --> 10:36.800]  that it will generate PRs for you, also providing some information on why they are giving you
[10:36.800 --> 10:43.400]  this update with more information about the vulnerability, if it's for vulnerability reasons.
[10:43.400 --> 10:50.760]  And what sneak does by default is it will bundle PRs that are related, so it generates
[10:50.760 --> 10:56.360]  less noise, so less individual PRs. You can configure renovate to do that as well, but
[10:56.360 --> 11:03.200]  then you have to configure that yourself. So sneak also checks on incoming PRs and provides
[11:03.200 --> 11:08.680]  a dashboard, again, with outdated projects. I hope your dashboard doesn't look like this.
[11:08.680 --> 11:15.440]  And it has some configuration options for frequency and to enable or disable either
[11:15.440 --> 11:20.160]  for new or known vulnerabilities. So if you want to start with only making sure you're
[11:20.160 --> 11:26.440]  not getting new ones in and separately tackle your backlog or if you want to apply it to
[11:26.440 --> 11:33.400]  some projects, you can configure that. So the pros and cons of these bots are they're
[11:33.400 --> 11:39.040]  fairly straightforward to add to your repositories. It's a lot less work doing this just once
[11:39.040 --> 11:44.240]  than manually checking it every time that you're working on a repository. They can create
[11:44.240 --> 11:48.600]  automatic PRs, so it doesn't depend on you checking for updates anymore. It will do that
[11:48.600 --> 11:54.320]  automatically. The downside of that is it can create a lot of noise, especially depending
[11:54.320 --> 12:00.040]  on how outdated your projects are and the maximum number of PRs that you've set. And
[12:00.040 --> 12:04.760]  you will still need to manage those PRs. So if the build fails, you know that you have
[12:04.760 --> 12:09.160]  more work to do, because either some stuff doesn't compile anymore or your tests are
[12:09.160 --> 12:15.280]  failing and you need to look into it. That's at least good to know. But even if it's green,
[12:15.280 --> 12:19.720]  you still need to find the time to deploy that and make sure that everything still works
[12:19.720 --> 12:26.840]  depending on how confident you are with your test suite. We had a fail-safe update that
[12:26.840 --> 12:31.160]  managed to stop running the integration test. So, you know, it looked green, but really
[12:31.160 --> 12:39.200]  wasn't. So we have to revert that. And these bots only update the versions and they don't
[12:39.200 --> 12:47.400]  make any changes to your code. So that's when we get to migration tools. You might not be
[12:47.400 --> 12:55.160]  aware IntelliJ IDEA has a migration refactor, and it offers several standard or well-known
[12:55.160 --> 13:02.800]  refactoring, so Java EE to Jakarta EE, JUnit 4 to 5, as well as the option to create your
[13:02.800 --> 13:11.520]  own. If you're interested in the JUnit or Java EE refactoring, we have videos on our
[13:11.520 --> 13:16.920]  IntelliJ IDEA YouTube channel that detail all of that. Basically, what it does is it
[13:16.920 --> 13:22.000]  will update the imports, but there are some manual steps that you still have to do. So
[13:22.000 --> 13:28.560]  it can help you a little bit. Then there are other tools. Error-prone is one of those tools.
[13:28.560 --> 13:36.480]  It's not intended to be a migration tool. It's a static analysis tool to check for known
[13:36.480 --> 13:44.280]  bug patterns in your code. It offers a number of standard bug patterns that have been identified.
[13:44.280 --> 13:50.240]  It can either report on them or fix them. And included with Error-prone is Refaster,
[13:50.240 --> 13:55.680]  which is a refactoring based on before and after templates. So you can help or you can
[13:55.680 --> 14:00.720]  use that to help you migrate from one pattern to the next. And I know, for example, that
[14:00.720 --> 14:07.240]  Sander Muck at Picnic has said that they used it to upgrade to newer Java versions. And he's
[14:07.240 --> 14:13.040]  done talks on that at, for example, NLJ conference, J Spring and Jful, if you want to go find
[14:13.040 --> 14:19.040]  that on YouTube. And then another migration tool is OpenRee, right? That Tim is going
[14:19.040 --> 14:26.040]  to tell you all about. Thank you.