Problem/Motivation

During the January 26th 2022 'mass drop' of modules as unsupported the 'colorbox_node' module was marked unsupported for security issues, see https://www.drupal.org/node/1580102/revisions/view/9850899/12531683 for confirmation.

A similar named module 'colorbox' was also included during the drops of January 26th see https://www.drupal.org/node/632214/revisions/view/12483569/12531845.

The error was mentioned to and acknowledge by security team members via Slack on February 2nd and February 10th.

I believe this was an honest error due to the large number of modules and having a set of modules similarly named causing no public SA notice to be published.

Since the Security Team has not resolved the situation for the module it appears either a policy on how to handle the situation OR introducing automation with technical lockouts (automate the publishing of the release, marking the module insecure, and publishing the SA notice to not require manual interaction) may be required.

Classifying as Major as it has significant repercussions for consumers of the SA Notice system(not made aware of a security vulnerability, and no SA# assigned) however it has a workaround of using the update feed to see when a release status has changed.

Proposed resolution

Develop a policy on how to publish a missed SA notice and required actions and responsibilities of the security team when made aware of such an error.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Comments

cmlara created an issue. See original summary.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Can you suggest a draft of this policy? Are you aware of other policies in the project that cover a similar situation?

I'm not sure that we have policies like this in general.

cmlara’s picture

cmlara
he/him
commented

To my knowledge there is not anywhere else in D.O. that has a policy around this. The SA notice system is somewhat a unique position inside of the D.O. that the content on it is important as a security stream. This is also likely not the sort of policy most organization create until after it has occurred once.

The closest scenario that I have seen on D.O. that compare to this are:

  • A SA notice is published but the release for the module was not.
  • A covered module has published a release but not tagged it as containing a security fix

Key questions to ask for writing the policy:

  • How to contact the Security Team to alert them to the scenario
  • When should the notice be published (immediately even though outside an SA window or does it get delayed to the next SA window.)

A draft policy:
The security team shall publish a SA for any covered module that has been marked insecure. If the Security Team become aware that an SA notice was not published the Security Team will promptly proceeded to make the SA notice publicly available through all normal publication channels.

Using 'promptly' as a placeholder for everything in the range of "immediately" to "the next security release window" based on the question above.

Text to place on the Security advisory process and permissions policy page

<h3>Missing Security Advisory:</h3>
It is the intention of the Security Team to promptly publish Security Advisory Notices to all normal notice communication channels.

If the Security Team become aware that an Advisory Notice was not published during its scheduled security window it will ensure that the notice is published. A corrective notice due to a missing notification may be publish outside a normal security advisory window.

If you discover a module that is/was covered by this policy that has had a releases marked insecure, the project page modified to indicate there is a known security vulnerability, or a new release marked as containing security fixes without a corresponding SA notice available please contact the Security Team through --- security team preferred contact method ---"
mlhess’s picture

mlhess commented
Category: Bug report » Task
Priority: Major » Normal
greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Has this situation come up again?

It seems uncommon enough that more documentation is not warranted.

cmlara’s picture

cmlara
he/him
commented

It seems uncommon enough that more documentation is not warranted.

I would suggest that is exactly why this should have documentation. You do not want to be writing your "(Emergency) Response Procedures" in the middle of a situation, you want them documented before the situation so that you "pull the binder off the shelf" and start following what has already been written.

As long as we allow human error as a variable the risk of recurrence is there.

Quick slack search:
https://drupal.slack.com/archives/C5B7P7294/p1723053635495029?thread_ts=...
SA was published to D.O. but not announced to mailing list, not as significant as what started this thread, however it is closely related as it is part of the 'publishing' stage of Drupal Advisories and provides evidence the human error factor is still occurring.

I would have to dig deeper, however part of this has also been that many of us are now scrutinizing the security team's every action and flagging the issues publicly in the #security-team room when faults happen in the release cycle (Failing to publish a release, failing to publish the SA even though its been linked in the room, the SA being released to Composer when its not available on D.O.) etc. This does not mean the issue has disappeared nor is it a reliable solution.