[00:00.000 --> 00:14.120]  Hello, everybody. Welcome back. Our next talk is from Fraser Tudel, Fraser Tweedow. He lives
[00:14.120 --> 00:19.640]  in Brisbane, Australia, where he works in identity management in PKI at Red Hat. He's
[00:19.640 --> 00:22.800]  passionate about functional programming and security and really likes playing with little
[00:22.800 --> 00:27.000]  plastic bricks from Denmark, a detail which he clearly included to pander to his co-organizer
[00:27.000 --> 00:42.160]  tools. Okay. So, just a very quick talk, giving an update about the Haskell Security Advisory
[00:42.160 --> 00:52.520]  Database. So, why do we want one? Well, security matters a lot. It is very important. And many
[00:52.520 --> 00:58.960]  programming languages have been improving their security tooling and introducing vulnerability
[00:58.960 --> 01:05.760]  databases of their own, audit tools in the package management and build systems. And
[01:05.760 --> 01:11.280]  so we should follow suit. We should not just follow, we should try and lead, in fact, and
[01:11.280 --> 01:18.560]  have best-in-class security tooling for our best-in-class language. It's increasingly
[01:18.560 --> 01:25.040]  important for industry adoption that language ecosystems have a way of reporting security
[01:25.040 --> 01:31.720]  vulnerabilities and disseminating that information, so that commercial users of the language or
[01:31.720 --> 01:38.240]  non-commercial users of the language can find out about security issues when they arise
[01:38.240 --> 01:47.840]  and respond to them. It's also needed for some industry certifications like ISO 27001,
[01:47.840 --> 01:58.520]  which is therefore also important for industry adoption. So, in August 2022, there was a
[01:58.520 --> 02:07.480]  tech proposal through the Haskell Foundation Tech Proposal Procedures to establish a security
[02:07.480 --> 02:16.720]  advisory database and a team who would manage it. And that proposal was refined and accepted.
[02:16.720 --> 02:24.880]  The database repository was created, bootstrapped, if you will, in November 2022, but as of now
[02:24.880 --> 02:32.720]  it's still empty. So the next step is to assemble a security response team who will populate
[02:32.720 --> 02:39.360]  and manage that database. And the call for nominations for the Haskell security response
[02:39.360 --> 02:48.040]  team will be going out in the next couple of days. The responsibilities of the security
[02:48.040 --> 02:57.480]  response team or SRT will be to triage and assess incoming security reports and for real
[02:57.480 --> 03:05.480]  vulnerabilities to move them into the database. So we will update and maintain the advisory
[03:05.480 --> 03:12.480]  database and ensure that the data is in a form that is useful for downstream security
[03:12.480 --> 03:18.600]  tooling. So these could be tools like Cabal Install. We can implement an audit command
[03:18.600 --> 03:25.960]  to check whether your program or any of its dependencies have known security vulnerabilities.
[03:25.960 --> 03:32.040]  GitHub Dependabot is another tool on GitHub that can consume the data in the advisory
[03:32.040 --> 03:39.440]  database and automatically notify maintainers and project owners when there are security
[03:39.440 --> 03:46.600]  issues and potentially even do bumping of bounds and automatically creating pull requests
[03:46.600 --> 03:54.600]  and testing the projects in order to make life easier for maintainers to move when a
[03:54.600 --> 04:00.840]  security issue is found. So developing those tools is not the responsibility
[04:00.840 --> 04:06.680]  of the SRT, but working with and liaising with the developers of those downstream tools
[04:06.680 --> 04:14.360]  is a responsibility. And there will be a quarterly report on the team's activities and on the
[04:14.360 --> 04:26.120]  trends in the reported security issues. So who will be on the SRT? We're looking for
[04:26.120 --> 04:32.800]  five volunteers who can commit to an initial term of six or 12 months. And in that way
[04:32.800 --> 04:39.960]  the terms will then be staggered. We're looking for people with experience in security topics
[04:39.960 --> 04:47.360]  such as this is not an exhaustive list, but topics like secure development and web application
[04:47.360 --> 04:55.880]  security, pen testing, incident response and vulnerability research, cryptography, authentication,
[04:55.880 --> 05:02.720]  security management, GRC, that's governance risk and compliance and any other security
[05:02.720 --> 05:08.960]  related topics. Obviously no one has all of these, but we're looking for people to bring
[05:08.960 --> 05:15.320]  different experience in these different topic areas so that we have a broad coverage within
[05:15.320 --> 05:22.040]  the security response team. So as I mentioned the call for nominations will go out in the
[05:22.040 --> 05:26.440]  next day or so. We're looking for people to self nominate, so if you know someone who
[05:26.440 --> 05:31.920]  you think would be great, please encourage them to nominate themselves. The nomination
[05:31.920 --> 05:40.440]  process will be to email me on that address and say I want to do it and give a brief overview
[05:40.440 --> 05:48.200]  of your background in security. And we will aim to announce the initial security response
[05:48.200 --> 05:54.240]  team around the end of February. And that's the update. Thanks for listening.