Yeah. Good morning. So since we're all here, we probably
want to talk quite loud. Sorry. Since we're all here, you probably, thanks, all use open
source, which is great because it offers us functionality without us having to write
it ourselves. But the downside is for the dependencies that we declare, we tend to pull
in a bunch of transitive dependencies, and any of those can contain vulnerabilities.
So you might remember December of 21, because I do. And from your laughter, you probably
spent those days in much the same way I did. I was working at a Dutch retail platform
that uses microservices, and because of Log4Shell, we got to update everything, urgently, twice
because after the first CVE was fixed, there are multiple other CVEs. So, you know, fun
times. And then in March, we got to do it again, because of Spring4Shell. But at least
we got the practice in the first time. So it was fascinating this time, right? As we
know, using external dependencies has pros and cons. I have more on that, but not in
these 20 minutes. I'll share a link to my website that has all of this information
at the end. So we have to maintain our dependencies and make sure we keep them up to date. So
I'm going to give you an overview of different tools that you can use, ending with, normally
I would end with open rewrite, but Tim is here, so he's going to do the honors for that
one. You probably use Maven or Gradle to manage your dependencies, so you will probably also
know that you can use Maven dependency tree to get your dependency tree of your declared
dependencies and their transitive dependencies. And you can ask Maven, hey, which ones have
updates available so that you know what you could be updating? And you can use a command
to analyze your dependencies to see which transitive dependencies you're using but haven't
declared, and also which you have declared and aren't using that you might want to remove
or in the case of JUnit, add some tests. Gradle has a command as well to get your dependency
tree. As far as I know, it doesn't have a command to get updated versions, but you can
use a plug-in, like the Ben Main's version plug-in. And I'm also not familiar with an
analyze command. If you're a Gradle user and you do know how to do that, please tell me.
And as I currently work for JetBrains, I'm also going to tell you what IntelliJ IDEA can
do to help you manage your dependencies. So you can view your dependency hierarchy in
the built-in window, either for Maven or for Gradle. And here you can see, again, the hierarchy
of the direct dependencies and their transitive dependencies. And you can expand and collapse
as you like, which is easier than reading it from the terminal. And you can analyze dependencies
as well. We use the dependency analyzer in IntelliJ IDEA. This year we, or past year,
we added a functionality called PackageSearch, which allows you to manage your dependencies
right inside your IDE. So you can use code completion, for example, to add dependencies
right inside your build file without having to go outside of your IDE. So, and it will
also tell you, with a little squiggly line, I don't know what the official name is, so
we're going with squiggly line, that will highlight, hey, there's a new version available
for this, and then either with a hover or the familiar alt enter, or option enter that
will suggest fixes. So, for example, to update this version, I'm using a project that's really
outdated from my GitHub graveyard of projects. The project itself is pretty useless, but
it's a perfect example of outdated dependencies. So, don't worry, this is not being used in
production. So, yeah, you can use intention actions, like I said, to update the dependencies,
and this works in build gradles too. And there's the dependency tools window that you can open
where you can manage your dependencies. So you can, as you can see in this example, you
can upgrade all of them at once, or you can upgrade individual ones, or you can select
the version to use from the list of versions. You see information about the dependency right
in this window. You can search for dependencies and find information about those dependencies
right inside your IDE, so you don't have to go to search Maven or somewhere else. And
in IntelliJ Ultimate, we have the package checker functionality, which even provides
information. So this is if you hover over a vulnerable dependency that's highlighted
in yellow-ish. It will tell you these are the vulnerabilities that were found in this
dependency, and you can click the links to go to the checkmarks advisory for more information
on that. And you can also see that information in the vulnerable dependencies tool window,
so you can see which of your dependencies have vulnerabilities, what the severity is,
find more information, and fix it right inside your IDE. So all of these tools are great
because you can use them right as you're working on your code, but the downside is you need
to be actually working on that project. And like I did at my last job, you have a bunch
of microservices that adds up to a bunch of repos. You'd have to check out each individual
repo and check for updates. And then, of course, you still have to apply those and verify that
everything still works, et cetera. So hopefully, your company will have some kind of software
composition analysis that can scan your repositories and sometimes also your Docker containers
and provide you with an overview of your repos and which ones have which vulnerable dependencies.
And the upside is that, as a developer, you won't have to individually check all of your
repositories, but the downside is I still have to check the dashboard to see what's outdated
and then, again, still apply and verify all of those updates. The next generation of tools
that is useful are bots that can create PRs for you. Since we're in the Java room, I'm
assuming we use Java, and these are the options that we have, dependable, renovate, and stick
open source. Dependable is now GitHub native, and it offers three features. It can alert
on your repositories. It can create security updates, so PRs for dependencies that have
no vulnerabilities to update them, and it can do version updates. So, then there's a version
for other reasons. Since it's GitHub native, you can configure it in your settings on GitHub.
It's also available on other platforms, but I use GitHub just to compare the three-box.
So if you have alerts, you'll see a yellow box with a button to press for more information.
If it generates PRs for security updates, that's what this would look like. And if you want
to use the version updates as well, you'll need to add a dependable YAML, insert obligatory
YAML sounds like a Dutch word, jammer, which means too bad or unfortunate. And you have
to provide a little bit of configuration. You can set the frequency, the maximum number
of PRs scheduled, and some minor details on how to manage these PRs. The next option is
a renovate, which is an open source project, but also with a vendor behind it. This offers
the security updates and the version updates, like dependable, but also a project and a
jobs dashboard for some more information. On GitHub, it's also fairly easy to apply this
to your projects. You can use the app, and you can choose to apply it to either all of
your projects or only certain projects. So if you want to just, if you've never used
one of these bolts and you want to try it out, this is one that you can try out on just
one repository. And as far as I know, the only one of these three. It will then generate
a configuration for you. And once you merge that basic configuration, it will start doing
its thing and generating PRs. You can also specify the maximum number of PRs and the
maximum number of branches that you want open at a certain time. And it has more options
and those options are more fine grained than the dependable options. The PRs provide more
information as well. Why is it trying to update these versions as well as some information
on how old is this package? This is an old screenshot, sorry. The adoption rate among
renovate users, how many percentage of the builds that pass with this update, and how
confident they feel about doing this update where neutral means either they can't tell
based on the information they have or they don't have enough information yet. It will
also add a dashboard to your project with a list of all of the things that you need
to update. And there will be a jobs dashboard where you can check the details of all of
the jobs that have run. The last option is sneak open source, which also offers security
updates and version updates and some dashboards as well as the option to check for vulnerabilities
in new PRs, making sure that you're not adding vulnerable dependencies and it can check your
source code. Slightly more steps to enable that. You can go to their website, authorize
your GitHub, select which repositories, either public or public and private, add a token
that it will generate PRs for you, also providing some information on why they are giving you
this update with more information about the vulnerability, if it's for vulnerability reasons.
And what sneak does by default is it will bundle PRs that are related, so it generates
less noise, so less individual PRs. You can configure renovate to do that as well, but
then you have to configure that yourself. So sneak also checks on incoming PRs and provides
a dashboard, again, with outdated projects. I hope your dashboard doesn't look like this.
And it has some configuration options for frequency and to enable or disable either
for new or known vulnerabilities. So if you want to start with only making sure you're
not getting new ones in and separately tackle your backlog or if you want to apply it to
some projects, you can configure that. So the pros and cons of these bots are they're
fairly straightforward to add to your repositories. It's a lot less work doing this just once
than manually checking it every time that you're working on a repository. They can create
automatic PRs, so it doesn't depend on you checking for updates anymore. It will do that
automatically. The downside of that is it can create a lot of noise, especially depending
on how outdated your projects are and the maximum number of PRs that you've set. And
you will still need to manage those PRs. So if the build fails, you know that you have
more work to do, because either some stuff doesn't compile anymore or your tests are
failing and you need to look into it. That's at least good to know. But even if it's green,
you still need to find the time to deploy that and make sure that everything still works
depending on how confident you are with your test suite. We had a fail-safe update that
managed to stop running the integration test. So, you know, it looked green, but really
wasn't. So we have to revert that. And these bots only update the versions and they don't
make any changes to your code. So that's when we get to migration tools. You might not be
aware IntelliJ IDEA has a migration refactor, and it offers several standard or well-known
refactoring, so Java EE to Jakarta EE, JUnit 4 to 5, as well as the option to create your
own. If you're interested in the JUnit or Java EE refactoring, we have videos on our
IntelliJ IDEA YouTube channel that detail all of that. Basically, what it does is it
will update the imports, but there are some manual steps that you still have to do. So
it can help you a little bit. Then there are other tools. Error-prone is one of those tools.
It's not intended to be a migration tool. It's a static analysis tool to check for known
bug patterns in your code. It offers a number of standard bug patterns that have been identified.
It can either report on them or fix them. And included with Error-prone is Refaster,
which is a refactoring based on before and after templates. So you can help or you can
use that to help you migrate from one pattern to the next. And I know, for example, that
Sander Muck at Picnic has said that they used it to upgrade to newer Java versions. And he's
done talks on that at, for example, NLJ conference, J Spring and Jful, if you want to go find
that on YouTube. And then another migration tool is OpenRee, right? That Tim is going
to tell you all about. Thank you.