The ASF security team assign a security health level to a project based on "how worried the security team is" about the project being able to handle security issues.  There is no automation in assigning the levels. Instead we do a case by case, risk & potential impact based triage analysis..  It is only based on vulnerability response (so not security features implemented in code etc.)

We track these levels in an ASF-private github instance using issues with labels and structured comments.  A script is run every month which parses the open issues to compile the draft for the board report.  The draft is manually reviewed and edited before being submitted to the board, usually by the VP Security.

Although the levels are mostly for internal use for now, they are reported to the board and therefore become public with the board minutes. We may in the future more actively publish the security health levels (i.e. like a scorecard).

Health level 'watch':

A project is put on 'watch' if there is something of concern within the project that we need to ensure the security team pay attention to, ideally at least monthly.  This level might be used for example where we believe a project will soon have solved the issue (by doing a release or having recruited new PMC members) but we need to keep track of that.  This level is not reported to the board.

Health level 'Amber'

'Amber' is used for projects that have some issue that we need to keep our attention on more than monthly; so for example a project which has outstanding non-severe issues that are over a year old would generally trigger amber, as would a project which has a temporary inability to produce releases, or has just recently stopped being responsive to issue reporters.  Without progress these may in time result in formal escalation processes and promotion to 'Red'.

Health level 'Red'

'Red' is used for projects which have some issue that we need to keep our close attention on, weekly or even daily.  These are projects that have outstanding old issues that look severe, projects that are unable to produce releases, or projects that are ignoring the security team.  It's likely projects with this level have other community health issues.  Security team will be using our escalation process, defined at a high level: https://cwiki.apache.org/confluence/display/SECURITY/Project+Security+Response+Formal+Escalation .  Unless progress is made to address the issues, these projects are likely to progress in the escalation process to a security roll call or being moved to the attic.

Note that a project would not be given a Red status for having a current high-severity or known-exploited critical vulnerability if that project was handling the issue appropriately according to our defined processes.

  • No labels