# Basic Security for Open Source Maintainers

Gina Häußge // [foosel.net](https://foosel.net)

<p style="font-size: 1.3rem; margin: 5em 0 0 0;">
    PyCon Italia 2026
</p>

---

## Gina Häußge

- Software Engineer
- Maker & Boulderer
- PSF Fellow & GitHub Star
- 100% Nerd
- Creator & full-time maintainer of [OctoPrint](https://octoprint.org)

Notes:

- Gina Häußge aka foosel
- 43 years old Software Enginner
- also a maker & boulderer, PSF fellow and GitHub Star and 100% Nerd
- most importantly: full time Open Source maintainer on my project OctoPrint
  - web interface for 3d printers
  - created in 2012, maintaining this since

---

## First things first

1. I'm an Open Source Maintainer, *not* a Security Researcher
2. Security should not be a game of "us vs. them".

Notes:

- you are getting a talk here based on my perspective and experiences as a maintainer
  - security is a hobby, but first and foremost I'm a developer
- this talk might sound here and there as if I think security reporters are posers
  - this is not the case
  - some hints on how to identify and protect against abuse by the bad apples
  - best experiences:
    - cooperation with security researcher
    - productive brain storming on possible solutions of an issue
    - even made friends & recruited regular contributors through interactions like that!
---

## How to get your project ready for reports?

---

### Establish preferred way of secure contact

- Email
- GitHub? Security Advisories! (*enable them!*)
- HackerOne, huntr.dev, etc 😐

Notes:

- Email == 1:1
  - not in public
  - but: not easy to assign CVEs (Common Vulnerabilities and Exposures)
    - important notification mechanism
- GitHub is a CVE Numbering Authority (CNA):
  - *can* assign CVEs
  - private reporting, even with private PRs
  - but we all know that GitHub is in trouble these days
  - would love to see something like GHSA from the likes of Codeberg! (forgejo issue #42)
- personally I now avoid these "hacker platforms" like HackerOne, huntr.dev etc
  - story time: huntr.dev once opted in a ton of open source projects into their platform
  - funded bounties themselves
  - I ended up getting DDOSed with some valid and a ton of invalid security reports
  - in the end had to use some connections to get on a call with the CTO
    - explained their DDOS
    - got OctoPrint off the platform
  - not a fun experience
    - too many self declared hackers trying to make a name for themselves
    - can't recommend
- GHSA & email works just fine for me, YMMV

---

### Project security policy

- Supported version range? 
- Non-qualifying vulnerabilities? 
- Response time?
- Bounty?
- GenAI policy

Notes:

- what's the version range you accept vulnerabilities for?
  - e.g. only current stable
- what kind of vulnerabilities do you not accept
  - e.g. automated reports, theoretical attacks without POC, attacks requiring physical access, ...
  - any limitations on deployment scenarios?
    - e.g. no network vector if the software is supposed to run in a secure network (adjacent)
- response time
  - when will you respond to the report?
  - when will you try to fix any vulnerabilities?
  - sole maintainer? 90 days imho fair
  - enough time to put together a fix & release
  - but: try to *aim* lower
- can you pay bounty money for vulnerabilities?
  - my guess is, for most maintainers the answer here is "no"
  - I know it is for ME
- GenAI for communication = no go for me
  - tool supported findings ok, IF reviewed *before* reporting
  - want to talk to and collaborate with people, not stochastic parrots

---

### security.txt

Example:

``` http
Contact: mailto:security@octoprint.org
Expires: 2027-05-14T22:00:00.000Z
Preferred-Languages: en, de
Canonical: https://octoprint.org/.well-known/security.txt
Policy: https://octoprint.org/security/
Bug-Bounty: False
```

https://octoprint.org/.well-known/security.txt

Notes:

- simple txt file located at predefined location under your domain
- contains:
  - how to reach you & languages you can communicate in
  - where to find your security policy
  - bug bounty?
  - expiry date (remember to update this!)
- word of warning: those get crawled and cause some beg bounty spam, will come to this

---

## What to do when you get a report?

- acknowledge reception
- be friendly, but firm
- check if this is a valid report

Notes:

- acknowledge in a timely manner (my target: 7d)
  - you don't have to accept or solve the vulnerability right away!
  - signal to the reporter that you are there & responsive
    - communicate expected time frame
    - communicate next steps
  - know from friends in security that often they don't get a reaction at all
  - don't be that kind of maintainer :)
- but also: don't get steamrolled by a 10/10 CRITICAL, stop and breathe
  - try to check if this is a valid report as soon as time permits

---

## How to spot bad reports (and reporters)?

---

### There be (some) dragons!

> I found a vulnerability but I won't tell you details until you pay me!

> I found this generic vulnerability somewhere and now I want to get paid by you for my research!

🚨 Scam alert, beg bounty!

Notes:

- mail address of your `security.txt` file
- termed "beg bounty" by Troy Hunt
- attempt at blackmailing/scamming you
  - unlikely that there's actually a vulnerability here
- look for usual signs of scam mails
  - your name isn't mentioned
  - your project's name isn't mentioned ("the application")
  - your contact address is in BCC (spray and pray)
  - generic AF details (if at all)
- don't reply
  - or reply *just* with link to security policy
- email filters are your friend
  - this one person sent me close to 100 mails last year
  - generic AF reports about "the company's application"
  - kept switching name expression and email accounts
  - that's now the longest filter in my mail client
  - I'm not sure if it's over or I'll get to continue extending this filter

---

### Common red flags 🚩

- overstated severity, fear mongering
- no valid POC, or POC that introduces the vulnerability
- AI hallucinations

Notes:

- emails with you only in bcc
- CRITICAL 10.0 turns out to be a case of "step 1: log in as an administrator and then install this malicious piece of code"
- Goal: CV padding with published CVEs, beg bounty
- story time, one experience on huntr.dev:
  - had someone report a vulnerability with HIGH severity (8.something according to CVSS)
  - re-scored it, came to 2.something, asked how they arrived at their score
  - answer:
    - I don't understand CVSS
    - but this FEELS really bad!
  - that went a bit back and forth and in the end I had to report them

---

***You* are the authority on how your code works, not the reporter!**

👉 Rescore as needed!

Notes:

- important: you are the authority
  - be open minded, but don't just blindly accept everything
  - try to reproduce the issue
  - try to fully understand it
  - if necessary, read up on the specific nature of the vulnerability on your own
  - ask for details, examples, clarification
  - rescore as needed

---

### Rescore? CVSS 4.0!

- established standard: Common Vulnerability Scoring System (CVSS)
- methodology for scoring security vulnerabilities
- several online calculators available

Notes:

- read the CVSS specification & guide
  - can be done in an afternoon, is actually kinda fun
- plenty of self declared security researchers have *not* done that, as we saw earlier
- score your vulnerability yourself
- can sometimes be a bit of a puzzle
  - check examples!
  - ask trusted contributors to help (or security interested friends)
    - sometimes throw report to a buddy in security
    - we both score and compare notes
    - (nerdy) fun and educational!
  - if push comes to shove, err on the side of caution (score higher)

---

## How to fix vulnerabilities in a safe way?

- fix in secret, don't put your users at risk!
- request a CVE (if possible)
- acknowledge vulnerability report & reporter in your release notes!

Notes:

- best practice:
  - fix in secret - NOT LIKE GOOGLE!
  - push fix in stable release(s)
  - this doesn't put your users at risk
  - they can update as soon as the new release is there
- ideally: CVE (e.g. via GHSA)
  - explain issue, possible workarounds, patched version
  - target audience: your users!
- document vulnerability in release notes (even if you have a GHSA/CVE out!)
  - explain issue, possible workarounds etc (see also CVE)
  - *Thank you*
- my approach:
  - reports on GHSA, request CVES
  - private security specific repo
  - fixes get prepared in branches there, CI runs tests etc.
  - just prior to release: merge

---

## Further reading

**security.txt**<br />
`https://securitytxt.org`

</div>
<div>

**CVSS 4.0 Documentation**<br />
`https://www.first.org/cvss/v4.0/`

</div>
</div>

Notes:

- security.txt spec
  - quite short, easy to implement
- CVSS 4.0 documentation
  - recommend to at least read spec & guide

---

## Thank you for your attention!

📖 [foosel.github.io/pyconit2026](https://foosel.github.io/pyconit2026)

🌐 [foosel.net](https://foosel.net)

🦣 [@foosel@chaos.social](https://chaos.social/@foosel)

🦋 [@foosel.net](https://bsky.app/profile/foosel.net)