Security Team Panel

This talk features a security team panel discussing various aspects of security within the Drupal community. The speakers introduce themselves while sharing their favorite food and security vulnerabilities. They describe the functions of the Drupal security team, which includes managing coordinated vulnerability disclosures, triaging reports, and supporting both core and contributed project maintainers. The panel touches on security advisories, the migration to GitLab for managing vulnerabilities, and the concept of Drupal Steward to enhance security for critical vulnerabilities. They emphasize the importance of community participation and the evolving challenges posed by AI-generated vulnerabilities and supply chain attacks.

Well, good afternoon. Thank you for coming to the post-lunch security team panel. Um Welcome. Uh we'll go ahead and go over some team member introductions before we get started. Uh I'm looking for my uh team members' names, uh pronouns, the company who sponsors their work, their favorite food or song, um and your favorite security vulnerability. And I guess I'm already talking, so I'm going to go ahead

and go first here. Uh my name is Michael Haas. I go by he/his pronouns. I work for the Regents of the University of Michigan, aka the University of Michigan. my favorite food would be a nice grilled chicken sandwich with a good bun, uh and three dipping sauces that someone can surprise me on. Uh anybody who's ever had lunch with me knows this order. Um and my favorite

security vulnerability is the new ones that we're kind of talking about where they're AI-generated vulnerabilities. And so, these are exciting to me. Kathy. Hi everybody. Uh I'm Kathy Finney. I work for Lullabot, uh which is a Drupal agency. We do a lot of uh big government system platforms, uh lots of devops-y things. A lot of our customers have security as their high concern. I like to be

uh she/they. and if you forget how to pronounce my last name, don't worry about it, but it's just they with a Z on the end. Finney's. Anyway. my favorite food is eggs. Uh and uh my favorite security is, uh, uh, AI prompt injection. Ta-da! Cool. Great. Hi folks. Uh, I'm Greg Knudson or Gregels. I see him and I am part of the team at the Colorado Digital

Service, part of the state of Colorado, and where I build websites. I help people to use websites. I'm going to say for my favorite food, my favorite thing from last week was a black bean soup with some, uh, with some toast and cheese. And then, favorite security vulnerability, I really like, uh, cross-site request forgeries. I feel like they could be kind of fun. Um, DrupalCon, uh, DC,

I think it was 2009 or so, um, I used a cross-site request forgery vulnerability in the, in the Drupal website to vote on sessions and I got, um, the security panel session to be the number one most popular session. I explained it. Uh, I'm Neil Tron. Uh, he/him. Uh, I'm with the Drupal Association, uh, helping build Drupal.org. Uh, favorite food, uh, I'll say noodles. And, uh, cross-site

scripting for security vulnerability. My name is Jess. I'm XJM on Drupal.org. Um, I'm one of the Drupal core release managers, which means that it's uh, my responsibility to release the security updates that you can install for core on your sites every third Wednesday of every month. Not every that you can potentially install every third Wednesday of every month. That's a cool vulnerability. Um, see what we have.

My pronouns are she/her. Um, my favorite food is avocado toast with over medium eggs and arugula. And this combines three of my favorite foods, which are avocados, over medium eggs, and arugula. And I I would try to get chocolate in there, too, but really kind of ruined the dish, so we're leaving it off the list. And every time we have the favorite security vulnerability question, I try

to come up with a different answer for it. Um the thing that I'm finding really interesting currently um is gadget chains. We have a member of our security team who this past year, this past November, uh we had a set of four gadget chain vulnerabilities that we released security advisories for. I think they're very interesting because people come up with extremely complicated, creative ways to find a

path to exploit these things. Usually they're In theory, they could be very, very serious, but in practice, it's very, very hard to exploit them. And I think that makes them a really interesting place to be as a researcher because on the one hand, there's a lot that is possible if you happen to find just the right code running with your phone, but the core, um it's almost

always going to be something that core if you don't have to buy it yourself. Um so that's something to say about that. Thank you, everybody. So, I'm going to get a little closer over here, so people can hear me a little better. Sorry. Uh so, security team member has a bunch of permanent members. Uh these are four of Uh and we've got a bunch of provisional members.

I'm wondering if there's any provisional members here today. No. Okay. Well, we have some provisional members as well who are in the process of going through and potentially joining the security team. So, why are we here? We're going to kind of the the layout today is we're going to kind of do a little uh uh overview of what the security team does, how it does it, when

it does it, and then we're going to turn this into a Q&A panel. So, I will slowly be doing less talking soon and hoping all of you ask some questions. So, security team is a group of volunteer individuals who work to improve the security of the Drupal project. Like all mission statements, it's got a lot of words, but not a lot of actions. So, let's jump down

to what the actions are around the We will coordinate uh we we help with the coordinated disclosure process to keep Drupal secure. So, if you're familiar with coordinated disclosure, great. If not, I've got a slide in like three slides. Uh we will triage security researchers' reports. We will help core maintainers fix security-related bugs in core. We support contributed project maintainers in fixing bugs in contributed projects. We

coordinate and assist with educational events related to security, aka this. Uh we coordinate groups with we coordinate our work with other open source security teams. Uh we work with third parties who are interested in helping maintain core security. We monitor trends around uh hack sites, and we help with security-related initiatives. Of course, the list of things we don't do or that we do would not be complete

with the list of things we don't do. For the most part, the security team as an entity does not proactively search for vulnerabilities in uh code. However, I think everyone up here at some point has done that work. Um looking to find vulnerabilities in code. It's just not like an assigned task in the security team. And we don't really help fix compromised sites. You can't reach out

to us and be like, "Hey, my site got compromised. Come fix it for me." Uh we like to receive reports of them cuz we track trends. Oh, wait. Hold on, Michael. Yeah. Is it okay if I interrupt you? Not for that. Oh, well, uh go for it. I'll save my questions till later. Okay. I will say that we have security team members who through their employment do

that work. That we know. Okay. So, yes, there are, but the security team as an entity doesn't do it, but lots of people who are members of the security team may do that through their employment uh if you're looking for that service. one of the core things that we do is what's known as coordinated vulnerability disclosure. And, you know, there's lots of ways to disclose vulnerabilities. Uh,

we prefer uh, coordinated vulnerability disclosure. Kind of the inverse of this would just be a, "Hey, I found a security vulnerability. Let me post it in as many channels as I can, as quickly as I can, without notifying anybody." We don't like that approach. That's effectively a zero day. Uh, coordinated vulnerability disclosure is the process of gathering all the issues around a vulnerability, the people who found

it, the technical details, uh, the people who can fix it, all of the stakeholders, and working through how to fix it, and then fixing it in a, here's the keyword, if you haven't guessed it yet, a coordinated fashion, as opposed to a random fashion. we we release what are known as security advisories. Uh, we've been doing this longer than the internet has had other words for this

process, uh, which is effectively the details, what you need to do to remediate, and some assessment of trying to help you figure out what your risk is, and letting you know what happens. And so, because everybody loves a good flowchart, effectively, what will happen here is that there is a a vulnerability that gets reported to the security team. The team does a little bit of validation to

determine, is this a vulnerability? Sometimes that's more in-depth than other times, but most of the time we're weeding out spam and and saying, "Yeah, but you know, this is a real thing." We'll get reports like, "Hey, as an admin user, if I enable full HTML, I can inject JavaScript on a page." Well, yes, that's by design. Um, so if it's invalid, we'll explain that back why, and

and encourage the reporter to to find another vulnerability. Lots of people get started finding vulnerabilities like that. Uh, they just new to Drupal. If it does appear to be an actual vulnerability, we pull the maintainer in to look at it. The maintainer will look at it and say, "Yes, this is real." or "No, actually this is the way my my module's designed to work." or this is,

you know, "I can't validate this." and there's a back and forth with the reporter there. Assuming there is a change that needs to be done, the maintainer will draft a security advisory and sets a release date for an upcoming Wednesday avoiding the third Wednesday of the month because that's when we specifically do core releases. Um unless unless it's a core release that's being fixed. Security advisory gets

released along with a new release the path of project containing a patch and then uh Drupal site owners get to update their sites. So, that's kind of how this works. Um from a stats review, we've had eight core advisories so far, 156 contribute advisories. We had our first exploit for via AI, which I'll talk about. This is last year, not this year. Thank you. Yes. And OSV

database, that was that was still last year. Yeah. Yeah. it's always interesting to see the types of vulnerabilities. This is for core, uh cross-site scripting and gadget chain, which Jess was talking about earlier, uh are the ones that are probably the most popular here. Contrib, this gets a little bit tinier to see, but effectively access bypass and cross-site scripting are the two top vulnerabilities in the last

year. Neil. Let's talk about the GitLab migration from security.drupal.org. So, where we do our work is security.drupal.org. This is a Drupal 7 site. Uh if you're not aware from seeing me talking at previous DrupalCon, Drupal 7 is end of life. Uh and so we are slowly migrating from that into GitLab. So, Neil. Uh yeah. So, yeah, we're doing the GitLab migration along with my co-workers at the

association. and GitLab comes with the the checkbox on every issue that uh, turn on confidentiality uh, for that issue. GitLab comes with that checkbox. We can't customize it, uh, but it's uh, makes it real good way to view report security issues. Uh, we both uh, building some tooling around that to uh, make sure security team members can see the uh, see those and uh, triage you know,

if you were to file a security issue, you'd see uh, a flag uh, make I work for Apple mostly for access control, and then if a fix is needed, the maintainers uh, collaborative collaborators that they find manage this for the class as well. Uh, ask a little bit of context about uh, whether the project is uh, supported or not, whether they'll likely will be notified or not

if the issue is valid. and yeah, triage the issue from there. We play with the rounds, yeah, slides. splash screen. And yeah, I've added a few automations you know, manage access uh, if I want to add more collaborators to an issue. Uh, and the security advisory drafting that's the little title issue for Drupal.org itself. So, uh, we don't have to actually copy paste the advisories to release

them. We uh, and uh, GitLab uh, has a bot they maintain uh, GitLab triage bot that I've set up to to kind you know, something's been untouched for 2 weeks, put a reminder in there, that's that kind of thing. Thank you, Neil, for your work on migrating to uh, GitLab. So, the next thing I want to talk about is Drupal Steward. Tim, do you want these or

do you want me to do them? Okay, so Drupal Steward is a service that allows for some delay in patching core for highly critical vulnerabilities. So, you know, the coordinated release process gets us to a Wednesday afternoon when we publish a security advisory and say, "Hey, there's this issue. Go update your your sites." For some organizations, there's a delay. Maybe it's a time zone issue and that

they don't have people available in that time zone. Maybe there's a more rigorous quality control and they've got to run a bunch of like tests and have automated approval. Whatever it is, they have a And so, Drupal Steward is a web application firewall service that is basically sits between your site and the world and when an SA is going to be released, it will cover your site,

potentially depending on the type of vulnerability, from the time that information becomes public until the time you can actually patch your site. What's a web application firewall? It's effectively a middle layer that whenever a request comes into your site, it looks at the request, inspects it, and either takes action to either allow the request through or deny it or in some instances it can actually modify the

request. This is useful when you've got lots of sites, when you've got multi-site installations, when you've got international teams, when you have enterprise organizations that have more work. It It closes that gap. It does not replace the need to update your site. It buys you some extra time. Currently, we are only doing this on highly critical core vulnerabilities. There are some vulnerabilities that may be highly critical

that we that can't be stopped by a web application firewall. and there are instances where this may cause a false positive. Um and so that is that, you know, that's the risk you take with this. So, how does this actually work in practice? Security team identifies that a vulnerability that's going to be released has a highly critical and is mass exploitable. the security team will determine whether

that vulnerability can be mitigated with a WAF. And if it can be, the security team will publish a public service announcement, which goes out almost exactly like our normal security advisories, basically saying, "Hey, people should be aware this is going to be a highly critical release, and Drupal steward will cover it." And it's got a little logo We use marketing. Yes. We spend some time drafting those

WAF rules, and we share them with our partners, and we turn them on in monitor only mode. This gives the security team a little bit of benefit cuz we can see if people are attempting to exploit this prior to release. It also lets us know, you know, are these rules working? Are they, you know, are they going to cause legitimate traffic to be uh problematic? Um cuz

that would be bad. Uh security team and the partners will go through those logs, make refinements as necessary to the rules. you know, are we good to go? And then we will, prior to the patch, those WAF rules are taken out of monitor mode and put into enforcing, meaning they'll actually block traffic, not just log it. And the security team uh will then publish the release. There's

three tiers of this service, uh community, standard, and enterprise, and this is a paid service from the Drupal Association and from their partners. Um and so if you're interested in this, you either come up and talk to us afterwards, or talk to uh Tim. Hi, Tim. Tim is the the for the Drupal uh and we're we're we're happy to get you uh uh running. We recently actually

did do this with SA core 2025001 where we went through and were able to actually go through this process and doing it. It wasn't a highly critical issue, but it was something that we mitigate with a laugh, so we went through it. And it was critical. And it was critical, just not highly critical. So, OSV database. Greg. So, there's a lot of ways to find out about

security vulnerabilities. There's you know, we publish them on the Drupal website and then through social channels or RSS feeds, Slack. Uh you can also find out about it from like the CVE database. We've been publishing there somewhat consistently on and off throughout the years. You can also get it from other places like there are third parties that aggregate that information. Um There's the OSV dev project is

sponsored in part by Google and is a project to create a meta database that pulls in a lot of information from a lot of different sources and then provide a free scanner that can look at not just your Drupal code, not just the like Symphony code that Drupal relies on, not just the other projects like CKEditor, other JavaScript, other CSS maybe that you have in your site,

but it looks at everything about your hosting environment to determine if there are any security vulnerabilities. So, it will look at your whole whole container, whole virtual environment and scan for all different kinds of vulnerabilities. So, it's not just like composer audit, it's composer audit but for all types of Uh Drupal previously was included but in like uh inconsistent way and last year mostly through the work

of a company called Akamai and also Longwave, or Dave Long from I think Full Fat Things in the UK. Um and uh Peter Wolanin helped I helped to get Drupal's advisories automatically integrated into the OSV database. So, we now have faster information, more complete information in that tool. And uh I I guess uh one question and answer uh Uno reverse card, who's using OSV scanner today? Everybody?

Who's about to use it? Who's about to Yeah, who's about to use it? There we go. That's the right question. >> Yeah, there we go. Okay, great. Great. Thank you, Greg. So, you know, we've always had and I I I remember back to the when we had the Drupal 7 security slides, we had that you remember the check plain check markup filter access slide? We always had

this slide where we do this thing where, you know, if you had humans entering content, humans could enter like malicious code and then try to get other people to run that code. And now we have a new paradigm here where AI can generate code in real time, and AI can either be prompted to or mistakenly generate code that contains things that it shouldn't, whether those environmental variables

or credentials or just someone has somehow prompted this to generate, save, and then execute JavaScript. This is a different type of vulnerability. We're really used to saying, you always have to filter your user input. Now you have to filter your AI input, right? Your AI output? Little confused on the direction here. You know, it and this is a this will this this pushes up a little bit

against uh business goals to some extent. You know, I I've worked with marketing teams who, you know, find code on the internet and want to run it and because it does something some formatting thing and you know, it's okay. Well, what what exactly are the tags and okay, you want to be able to change the style. That's cool. Well, now we're doing the same thing with AI

in real-time for personalization when users visit a site were personalizing content on them. So nothing changes. We're always struggling with people wanting to run code in a web browser basically. Anybody have any thoughts on on AI generated I'm worried about you know, tomorrow. That's that's true. So, Drupal 7 is end-of-life. Uh if you are still running a Drupal 7 site, you probably should update it to not

Drupal 7. Um the security team no longer What's that? Drupal 11. Sorry, that was a little bit sneaky. I was trying to think about it. I heard it from over there. I'm like There are some vendors that are doing paid support for Drupal uh 7 still and the security team and the DA is doing shepherding would probably be the word there, but we're not actively maintaining Drupal

7 uh or doing core releases or anything of that nature. Um Participation with the security team collaboration with us is a requirement for them to be in the program. So, you can if you use one of the listed vendors on Drupal.org, you can trust that um they're being responsible to your organization. They've been vetted by the Drupal Association and by security. Supply chain attacks. Does anybody want

to talk about supply chain attacks especially after what I was looking at earlier today? You? I can. This was my favorite kind of vulnerability the last time I spoke. You want to I Do you want me to do your slide? >> No, I I can. So, supply chain attacks are the concept that your software uses other people's software, which uses other people's software to work. And so,

anywhere down that chain, someone can grab an item that's being used up the chain and compromise it. So, you know, Drupal has a really decent vetting process. Some composer modules that Drupal relies on doesn't. Uh there was a you know, a a a story about I think it was Node that deleted something like left pad or left string and broke half the internet because everything relied on

what was effectively eight lines of Node code imported as a package, and when that stopped working, lots of things that relied on it uh broke. So, you know, it's important to have an idea of where all of the components in your project are coming from. We have a really good, you know, this module is covered by the security team. Uh that doesn't necessarily mean that third-party libraries

have that same level of security team or any security team oversight. Um so, software bills of material, which is what that SBOM is, is basically everything and where it comes from in a software package. but also today there was a a compromise that happened because a CI prevent a CI provider got compromised and was reading environmental variables sent to the PI sent to the CI, and someone

was actually able to publish a Python package using those environmental variables that stole people's credentials. So, yeah, fun. Um this is probably the one thing that would keep me up at night is cuz if there's no way to keep track of all this and all the changing uh things and and what happens. The other thing I'll add is that if you are using third-party dependencies, Everyone is

using third-party dependencies. Yes. >> There is you you have thousands of them even if you don't realize it. But if if you are writing code using third-party dependencies yourself, pin the Um pin the version. And know which ones they are. if you're interested in joining the security team, come there's a process on drupal.org. You can also help without um formally joining. You can review security patches for

public hardings on drupal.org, help find the security issues in contributed modules, and file security reports when you find them. Um you can also talk to all of us. Uh if you find something the security team is working and working well, come talk to us. Tell us what's working well. If there's things we can do differently or better or improve, also come talk to us. We're here for

that. Um stay connected. Uh we release our information in a bunch of different channels. email is probably the one that we pay the closest attention to, probably. But we have the socials, we have LinkedIn, which is somewhat new, thank you, Greg. channels on Slack. stay connected with us. We don't normally post things on social that aren't security advisories. Um so it's not like a normal social media

engagement. Uh we we post our advisories as just another channel. I have talked successfully for 30 minutes. Uh let's go ahead and I said I was going to try to keep it short. Let's go ahead and just ask some folks some questions. and I'm going to just kick the first one off with the one that's either going to get me a lot of hate or a lot

of kudos, uh and then we'll turn it out to the audience for any types of questions and answers. Can be almost any topic. So, how many people are using AI in their workflows, and if so, how? Let's start with Kathy. Oh. Just because you're next to me. Yeah, don't worry. well, I work at Valotalo and I work in the uh extended support uh department. I'm the support

team manager and our support team is uh 15 people including me and our uh vice president. Uh so, uh Uh my point is is that that's our gosh, I don't know. Maybe a fifth of Valotalo or something. It's a small part of Valotalo. But, it's 15 people. And we are doing an experiment where we're uh keeping track of when we use AI, how we use it, uh

what tool it was, uh if it was uh complete failure, medium, uh like it needed significant interaction to get to a mergeable state, that's like medium, uh or a success, which is like needed barely any help produce the actual good result. Uh and then we are also tracking the volume of the chains. Uh and a couple of other things. Anyway, we're gathering some statistics. Uh I don't

know what percentage yet uh of our work that accounts for because we haven't gotten to like the end of the quarter. Uh we just started uh gathering the data. Uh so, I would say What was that question, Michael? Uh how are you using AI in your daily or workflows or are you using AI? The answer can be no. Yeah, so yes, we are and we are currently

using it I think to measure its impact to see if it costs us more time because if we have bottlenecks QA because we're generating a lot of work that doesn't get merged. Like we have a lot of questions we want to answer but right now we're just measuring and if I were to make a wild guess, I would say in each of our tasks if you're if

we're a PM a front ender or a devops person in our department, I would say we might personally be using AI like a proportion of our tasks and I would guess at least once a day on something. Uh so we're definitely using it. We have AI policy at WillowTree that we just generated that includes that we are transparent with our AI use present work and also that

the person who uses that tool and presents it is ultimately the one responsible for understanding how it works and testing it themselves before they ask anybody else to test it. Uh so we have a company policy guiding us and we can we have a first version of it out there and I'm sure it will change as we learn some more things. Uh Sorry. Anyway, I didn't know.

Thank you so much, Greg. Yeah, I'll I'll I'll say another way that companies using AI in volunteering. So the on drupal.org in the issue queue for the Drupal security team, it's the security drupal.org is the Q name. we create CBDs. I mentioned the CBD database and so every just about every month we need to assign CWE and the CAPEC for each vulnerability and CAPEC was using AI

to do that and we disclosed exactly the prompt we used and and how it worked and if it makes sense to you. So yeah, I feel like that's another that I have encountered it and I have been using it there. Um I've I've used AI I guess just for my use cases it's mostly been like generating Python scripts. I've been writing a lot of Python scripts to

analyze websites recently and it'll get me like 80% of the way there and then a little bit of review and and changes that are needed to prove it and get to like exactly what I need. So that's that's been my use. Mostly Gemini based. Cool. Yeah. Yeah, hold on. I want to add to that. I think that's a really great example. I that use case where you

use AI to that can be committed and reviewed and then counted on to be deterministic. I think that it's part of being part of the process about it but still safe. Anyway, good job. Thank you. Yeah. Uh yeah, I started using Claude a little bit for some code code work. I got a project left upgrade. GitLab is a big movie as it do the release scripts to

manage applications. I still don't know Ruby I it makes it seems to work. Uh so yeah. Nothing that's like 10x productivity but And yeah, it's like having an intern is is in ways more work, but uh, maybe it's worth it. It's really valuable. Yeah. I hate you, Michael. So, I'm going to make a statement that may seem unrelated, but to me the answer is the same. So,

I do software development in Emacs as I have done for the past 28 years or whatever. Um, taking things that's something that I like in my tooling. Um, I would say the amount of false information and increasingly AI hallucinations that I it's ev- in every aspect of its use that I encounter fills me with increasing existential dread. And so, I try to avoid using it deliberately because

I don't want to get myself caught in the trap of assuming the results are good, but I've recently, in the past couple of months, started to challenge myself with this, which is that if I'm not familiar with the tool or tools, the many, many tools, that means that I will not develop good skills for using them well. I welcome everyone to come on this journey with me,

but I 0% except where I have no choice because it's in all of my devices, but I I think we're all on a journey with this. Um, I have eight more questions. Four of them were generated by AI, four of them were and so, uh, but I figured that if I wanted to disclose that I'm using AI to generate security team panel I finally I don't actually

hate Michael. He's one of my favorite people. I just want to clarify for the recording and the people Um, but I I did generate four questions with AI by uploading the slides to it and then I I've done this for a while now. I also generate my own questions. But before I start asking questions and doing more talking, does anybody in the room have any questions for

the security team on process, outlook, literally anything? Yes. Today I learned about the concept of an S-bomb. How can I learn more about best practices if I'm not in a regulatory environment and just want to use it for my own projects or my client's projects you know, for to improve my security practices. Well, who's going to repeat the question? Regular as in Uh question was how do

I how do I generate an S-bomb or and how do I learn more about the subject of S-bombs or software bill of materials? This is Yes. As in style, not Oh, yeah. Yes. We're not cursing here. Yes. This is not an F-bomb. It is a software bill of materials, not a four-letter word. Yeah. There was an article, I want to say from Civic Actions. So, I think

Michael mentioned in talking about this that S-bombs come or like that they're sort of becoming more popular in part due to contracts or regulatory requirements. So, if your contract says you have to do it, then then you really need to learn about it. Um and a lot of those are federal, you know, US federal or European government contracts. Um and so and so, you know, that if

you have to do that, then you're delivering your S-bomb to somebody and they're going to say what they want to see in it. Um and they can maybe provide more guidance, but also there's I think a Civic Actions, do you Civic Actions is like a something company that does a lot of work in the US federal space and they have the article about S-bombs. Um I would

say like you know, I um the slide that Michael and we can share the slides after, but the slide about that I think talked about S-bombs and then also about OSV scanner. Personally, if I were choosing like between one of those, like if you've learned about both those things today and you're going to open up one of them in the next month, I would most spend time

on OSV scanner first. I think that's more valuable to individual sites. S bombs I think are better from like a large organization trying to manage hundreds or thousands of different technology stacks where you don't know about all of them. They can help you to inventory and then audit and have awareness of the exposure. But yeah, so I would I would look, you know, to that sort of

questions regarding Yeah? Any other question? Yes. Hi. So I'm primarily a front end engineer. I don't have any background in security, but I'm kind of curious about about security. Like do you have any recommendations how someone can get started with security? Well, I'll take I'll take a try at answering and then I'll give some other people more time to think of a better answer. Uh I said

I'm trying to be funny. Um So I think uh do you have an account on drupal.org yet? >> Yes. Yes. Oh, that's great. and have you experimented with the issue queue? Yeah, I'm on the I'm on the Canvas team actually. Oh, you're on the Canvas team. Wait, did anybody repeat the question? That was I was supposed to do that. Uh so the question was I'm primarily a

front end engineer and I'm curious about how to get involved in security. Did I get that right? >> Yeah. Okay. so I would use the drupal.org uh issue search and look for uh in in the label field uh put things like uh security or security hardening security improvements security improvements. Thank you, Jess. I will also gladly add you to any core private security issue if you agree

to be responsible with the information according to policy and are interested in helping us solve it. 100% if you're interested. Yeah. I I would Yeah. We will help you. So, there there We are really good at We will help you by giving you things to do, but I mean to answer your question directly, there's two ways to go about doing this. Three ways, really, if if I

were doing this. One is look at a security advisory impacting a front-end system and reverse engineer the security advisory. What was the issue? How would you exploit it pre-being patched? What would the payload need to be? And then how did the patch fix it? And, you know, obviously as part of that did the patch fix it. Uh the other is to go and find security vulnerabilities. So,

go and look at, you know, how can I get a front-end to run JavaScript that it shouldn't run? How can I, you know, do something here that I shouldn't do? One of my favorites was, you know, I had a software package on the front-end that was including JavaScript from a variable. Well, the domain name was part of that variable. And so, you could just include JavaScript from

anywhere you wanted, and yes, some browsers would stop this. Sometimes they didn't. It's great. This was a while ago. Um and then you can ask to be, you know, added to some of the uh some of the private issues or the security hardening issues that aren't quite like, you know, sensitive enough to be private, but they're still security issues that need to be fixed, and they're in

the front-end code that you're familiar with. There's actually the stuff in the public queue is I I know that a lot of the stuff in the public queue is kind of boring. Um but that there are there's more interesting information in the private queue. And since a lot, you know, you if you saw Michael's chart, a lot of the issues we deal with are cross-site scripting. Um

it's it's a great way to learn this to learn exactly like by going stepping through and trying to exploit yourself, you can learn really quickly a lot of how stuff works and learn a lot Okay. Any other questions? Yes. Uh so the Drupal core releases, uh you mentioned that your team doesn't really scan the code. Does anyone scan the code before major core releases as well as

the minor one like 11.2, 11.1, like are they also Could you clarify uh the statement like we don't So so the question was the question is um You say I think what you mean is like the question was you say you say that the team doesn't scan the code prior to releases, but I think what you mean is look for security issues. Because there are lots of

organizations scanning Drupal code all the time with automated scanners. And there are also lots of individual people who do security research. Um with regard to significant release milestones and auditing core new vulnerabilities that may have been introduced in the new code, we do occasionally um raise funds to contract with an organization that does a security audit to actually have them do an audit of Um so we

we did this before the release Drupal 8. We did this before the release 10, I think. We may We discussed doing it for Canvas. I know that there was a private company that did their own audit related to it. Um so there are as for significant releases, but um the Drupal core release process is continuous, so we don't do these big bang releases anymore. Each release is

meant to be a gradual, continuous improvement over the previous one, but this the change that has been each minor and major release is actually fairly small. Um it's it's usually it's usually sort of sort of incremental things. So, if if we add So, we add some code in you know, say it's your build 11.2 that has a vulnerability in it. We we're not going to stop every

6 months and block the whole thing again. Um I I would say that it it might be interesting to have some statistics on how what the time is between when code is added that introduces a vulnerability and when it gets fixed, but I will say though from my experience that time has gotten significantly shorter um since in the in the decade last that I've been on the

security team, we're expected to get faster. And part of that is because instead of having big bang releases where we we write it in small little code. We're we're adding to these increments. So, So, how do you know when you're ready to to release? Is there a process where you as a team agree that you're ready for a >> So, our our releases are on fixed schedule.

Um it's the when the train is leaving the station. Um we have a minor release window every 6 months for the typical core. And this is core only. Core contributors they follow their own rules. Um so, every 6 months we um have a release that is just all of features and API additions and so forth have that are ready whatever's done up until that point. And then

every 2 years we have a new major release. And the major release um it doesn't include anything different over the previous major release. It just gets rid of all the old backwards compatibility there. So, when we add a new API Uh-huh. we keep the old API there at the same time with backwards And then we made your release. This then gets rid of those old back up

back ability links. So, that's what I'm saying. It's a continuous process. It's just this Yeah. I So, so six-month minors, two-year majors, um and then we have like three windows. So, right now we're in the second phase where you would the next potential release for Drupal 12 is in August. And then if we don't get all the changes done with the December release this year. I'm going

to Well, we can come back to this. I mean, I There was a question over here. Yeah, there's two I think there were Yeah, let me go there and then I'll go there. I'm one of the release managers for core. You also apply back and talk to you about our process. Yeah, that's a simple cycle. My question didn't get answered, but I can come back. Yeah. Come.

Yeah. Security isn't a blocker to releasing. That's what I'm saying. It needs to be That was part of my question, by the way. It isn't. So, catch. So, nobody's looking at it. That's the answer? Uh Lots of people are looking at it. Lots of people are looking at it, yeah. Every merge request gets reviewed as it's merged with uh with extra attention on security if it's something

that is risky. Catch. Thank you. Yeah, not just getting anything to core. Everything gets reviewed. Every time. Uh often by multiple people, Mention people joining the team. Are there any skills that you're looking for? What expertise would you like to have in your group? Uh we we we want uh any uh every type of role that would be on a standard team we look for in the

security team. Um and so if you're interested, bring your skills, come talk to us afterwards, and we can we can see where that applies. But yeah, there there is because there's a lot of trust cuz we we see all the issues, there are some high bars to getting on. We have a provisional membership Um but please do come talk to us uh afterwards if interested. Yeah. As

far as skills, like a lot of it's just project management. Yeah. You don't necessarily have to be a developer. Uh and yeah, front-end stuff. Uh is strong on that base. Yeah, front end work. Yeah. I'm sorry. Regarding Drupal Stewart, yes. So, the I think the question if I heard it correctly was can we share the rules for Drupal Stewart out as opposed to going through the program?

Is that Is that the question? Yeah, I get it. Um so, we can't really share the rules cuz the rules often contain an exploit path in them. Like, "Hey, we're blocking this specific payload." Well, that specific payload is therefore the exploit path. the DA does have some mechanisms in which we we we can do some of this. So, I would talk to Tim who left, but if

you come up afterwards, I'll get you his email address. Um is it just Tim at Tim? Uh I believe so. And it's guy knows Tim that it's Drupal Association for the for the next half hour or so. >> Yeah, in the convention hall. The uh we did look at one point of using like packaging the rules for other WAFs. So, Amazon has one. There's a large vendor

with the initial CF that that has one. And there was there's there's been some pushback and from some of those vendors in different ways. But, Tim is the one who's been exploring that. So, come chat with me or Tim afterwards, and we're we're happy to point you in the right direction. I'm sorry? Yes, it's all. Uh we are here tomorrow, yes. And there's a vent above my

head that is making it hard for me to hear. I'm Uh any last questions, comments, or concerns? Real quick, could you tell us about the governance of your team? Like is this like do you have to have a quorum? Do you vote? Do you work independently? Do you divide and conquer? Just tell a little bit about >> Yeah. So there's a security working group which Greg and

I sit on that kind of does some of the the It's not really management. It's the It's the coordination with other other organizations within the Drupal ecosystem is the way I would describe it. Everything else is pretty much uh open voting for everybody. Triage We have triage calls where we'll talk through technical issues and kind of work through, you know, the technical problems. Um and then other

than that it's it's a it's a very open internally open process. You want to Maybe you can go. Yeah. Well, I would say for the security working group, I think about it like we are there to unblock things when they get blocked. So if there's like a decision that needs to be made and everybody's like got different opinions, but it's not there's not a clear consensus, Mike

and I try to facilitate a clear consensus and get to a decision. Or if there's support that people need, new tooling that people need, we'll try to advocate to get that. Um Like a vendor contact. Like Yeah. Like the point person and those kinds of things. But mostly the work is done by whoever shows up to do the work. Um and so like there's a phrase "do-ocracy"

to describe that. So if whoever, you know, people who come to the triage meeting make decisions about triage. We do also try We recommend getting people around the globe and so we document everything, you know, like it's quite common in the Drupal community. We document everything that we're saying or doing and then wait a little while for people to have a moment to give input on that

before taking action. In terms of the provisional members that are going to that are added to the team, people apply, there's a discussion period, then they're added into if they're accepted, they're added into the provisional process. They get mentored through that. We have meetings so that we know that the person is a person, that they nominally say who they are or they are who they say they

are. So we don't want just, you know, AI to be jumping in as a team member or, you know, somebody who's like pretending to be somebody else. So we try to validate the identities of people joining the as much as we can in a world where you you're not going to get face-to-face. And like, well, so all volunteers, so we're not checking ID or doing a background

check. So on that note, I think it is at the time of our session, so I'm going to go ahead and call this. But thank you all for coming today. And if you've got any other questions, come come up and chat with us. We'll be up here and we're around the con all all week. Thank you,