docs: add a PSIRT engagement playbook - #14
Conversation
benhoyt
left a comment
benhoyt
left a comment
There was a problem hiding this comment.
I haven't checked the upstream SEC specs, but is a lot of this (embargo time windows and handling details, etc) standardised in those, and we can just point there? It seems a lot to have here, and I'm wondering if we can cut this back.
One other minor thing: it'd be good to avoid listing things that will go out of date, for example the list of all Charm Tech repos. Can we instead just say "all Charm Tech's repositories" and we know what those are (or they're listed elsewhere, like our How Charm Tech Team Operates doc)?
…olicy drift - accidental disclosure: PSIRT/GRC immediately, other parties within 4h, plus make-unavailable/investigation/retro obligations (was: 4h to PSIRT) - add the 7-day embargo floor; state the 90-day cap's actual mechanism - 24h-notice section reduced to the actual SEC0037 requirement - drop the per-repo advisory-links table and the routing flow diagram - information classification collapsed to one line + SEC0061 link; allow private Mattermost per SEC0061/SEC0037 - subteam: repo list -> 'all Charm Tech repositories'; add manager to the roster (embargo policy requires the management chain in the embargo); add a personnel-change note - applicability compressed to mandatory (Pebble) vs best-of-class Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
I've reworked things, cutting about 30% of words, and about 45% of lines.
Mostly these were not really needed because when you end up here you're coming from a notification for one of those repos. So mostly I've just removed these. There's still a lot here and I haven't replaced everything with links out (I believe it still covers what's required by the SSDLC). In my experience, incidents are stressful, and it's helpful to know there is one place to go that has the info you need and doesn't require then opening up lots of secondary tabs with extra info. So I'd prefer to not cut it much more. Probably a good discussion for our next 1-1. |
benhoyt
left a comment
benhoyt
left a comment
There was a problem hiding this comment.
Thanks for this. I've added a few questions and comments, but approving optimistically to avoid blocking this.
One high-level question: what does an embargoed fix actually mean or how does it go out, when we push releases out to public PyPI and suchlike?
I've added a small bit of text about this. I believe yes it's that we push out fixes to PyPI, snap store, etc, at the same time (more or less) as when the advisory goes public. |
…y disclosure - Remove Launchpad as a channel (unused). - Pick CVSS 4.0, link CVSS and CISA KEV. - Define PSIRT and GRC on first use; drop RAF acronym. - Single accidental-disclosure address with CC. - Add a "publish at disclosure" bullet clarifying how an embargoed fix reaches public channels. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
3 participants
This is a requirement of the SSDLC. It seems like living in this repo makes sense: it does have three people's names but they are easily found all over the repo. I believe all of the standard parts of this process are public, and should be anyway so that reporters know what to expect.
I've made some assumptions about people, but most of this is fairly boilerplate and based on the SSDLC requirements and specs.