[Security-team] security-team policy

Vladimir Lettiev thecrux на gmail.com
Вт Апр 28 09:08:53 MSD 2009


28 апреля 2009 г. 1:27 пользователь Dmitry V. Levin <ldv@> написал:
> On Mon, Apr 27, 2009 at 11:16:22AM +0400, Vladimir Lettiev wrote:
>
> CVE является базой данных, куда в конечном итоге стекается информация обо
> всех зарегистрированных уязвимостях в ПО.  Однако рассматривать CVE в
> качестве источника информации о _новых_ уязвимостях в ПО совершенно
> нереально из-за латентности.

лучше поздно, чем никогда. slackware, например, недавно закрыла дыры
2-х летней давности.

>> Другие источники (возможно вторичные):
>
> + Важным публичным источником информации (как вторичной, так и первичной)
> является oss-security на lists.openwall.com

да, это тоже надо отслеживать

> + Кроме того, ещё есть и непубличные источники первичной информации,
> они же места, где договариваются о CRD.

Что тут скажешь, это большая удача, если знаешь о проблеме до публичного анонса.
...
> А чего не хватает в багзилле?  Может быть, прикрутить к ней будет проще?

Предположим обнаружена уязвимость в пакете foo. foo присутствует в
sisyphus, и во всех поддерживаемых бранчах. Как мне повесить баг на
всех этих foo? Вдруг выясняется, что из исходников foo собираются
бинарные пакеты libfoo и foo-tools, каждый из которых уязвим, на кого
повесить баг?
Нужен хотя бы какой-то посреднический инструмент, который по имени src
пакета выстрелит в багзиллу набором багов по всем реинкарнациям foo +
сделает один мета-баг на сущность "security", зависяший от всех
остальных багов.
Опять же нужен инструмент, который бы сформировал человеческий
security advisory по данным внесённым в багзиллу.
Или я всё усложняю?

-- 
Vladimir Lettiev aka crux <theCrux на gmail.com>


Подробная информация о списке рассылки Security-team