To respond to your later point:
On Mon, Mar 14, 2022 at 6:59 PM Hen <[email protected]> wrote:
> I know we have the process for a security incident defined from a project's
> point of view. If we assume that someone central is managing each item, can
> we define the process from the central-management point of view to help
> scale the current folk more by making it a more clearly defined role?
We do have a defined internal workflow process for the folks who work on
ASF Security Handling and it's based very much around a "Getting Things
Done" (David Allen) perspective where we're clear what the "next action" is
on every issue we're tracking. (The doc is internal just because it's
pretty much all about the mechanics of using our internal tools and
mailboxes to support the workflow). That means we can swap between
security handlers and it's obvious what the next state is and what needs an
action. We do refine that as we learn from issues and from looking at the
yearly reports we write. We've also recently had more ASF members join the
team and help out handling issues, which has freed up time to spend going
through the open issues on a regular basis ("Weekly review") and helping
projects respond to them. I'd personally say that the biggest room for
improvement is that we tend to concentrate more on critical and important
issues, so things that are pretty low risk and low severity in projects
that are busy or short of resources can tend to linger around for too
long. It is often the lowest risk issues that require the most work!
There's a good list of some things we want to do better called out in the
Brainstorm doc.
Mark
