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