Почему мой менеджер пакетов по-прежнему путает мои внутренние пакеты с общедоступными?
Возможность
Большинство организаций хранят частные пакеты во внутреннем реестре наряду с общедоступными зависимостями из npm или PyPI. Когда инструмент сборки разрешает имя, он может незаметно отдать предпочтение общедоступной версии, если злоумышленник опубликует пакет с таким же именем, но с более высоким номером версии, поскольку ни один реестр не обеспечивает криптографическую защиту прав собственности на пространство имен для частных областей. В мае 2026 года компания Microsoft зафиксировала 33 вредоносных пакета npm, активно использующих эту уязвимость и нацеленных на девять отдельных корпоративных пространств. Компания Orca Security сообщает, что 49 процентов организаций имеют по крайней мере один ресурс, уязвимый для атак этого типа. Ни одна из крупных экосистем пакетов не внедрила стандарт, позволяющий инструменту сборки отклонять публичный пакет, дублирующий заявленный внутренний.
Почему это важно
Права владения криптографическим пространством имён на уровне реестра — это недостающий базовый элемент, который позволяет устранить целый класс угроз безопасности цепочки поставок, не требуя от организаций изменения своих конвейеров сборки.
Как я оцениваю возможность
Оценка возможности отражает моё личное суждение, а не точное измерение: насколько проблема болезненна, как часто она встречается и насколько мало существует решений сегодня. Чем выше оценка, тем более достойной реализации я считаю эту задачу.
Насколько серьёзные проблемы это создаёт.
Как часто люди с этим сталкиваются.
Насколько мало хороших инструментов для этого существует сегодня.
Ещё задачи, достойные решения
Почему программное обеспечение, от которого мы зависим больше всего, так неудобно использовать?
TechПочему я по-прежнему не владею ни одними из данных, которые генерирую?
TechThis is a fundamental limitation of how most data deletion works today, and it comes down to a few core problems: **Deletion is an absence, not a presence** A receipt is a positive artifact -- proof that something *happened*. Proving a negative ("this data no longer exists anywhere") is cryptographically and architecturally much harder than proving a positive ("this file was signed at time T"). **No standard audit trail** Most systems are not built to emit a verifiable, tamper-proof log of what was deleted, when, and from which storage layer. Even if a company tells you "your data was deleted," that statement lives in their system, which they control. **Backups and replication** Data often lives in dozens of places: primary DBs, read replicas, backups, logs, caches, CDN edge nodes, analytics pipelines. A deletion receipt would need to account for all of them -- and companies rarely track this end-to-end. **No legal requirement to provide one** GDPR Article 17 gives you the right to erasure, and Article 19 requires notification to recipients -- but neither mandates a cryptographically verifiable receipt. Companies only have to confirm deletion, not *prove* it in a way you can independently verify. **Technical proof would require architectural changes** A trustworthy receipt would need something like: a Merkle-tree deletion proof, a signed timestamp from an independent witness, and a commitment scheme proving the original data existed before deletion. Almost no consumer product is built this way. The gap here is a policy and incentive problem as much as a technical one -- companies have little motivation to build verifiable deletion infrastructure when regulators don't require it.
TechПочему я не могу знать, соответствует ли то, что запущено, тому, что задекларировано в моём SBOM?
TechПочему мой сканер безопасности не обнаруживает тот класс уязвимостей, который чаще всего указывает мой ИИ-помощник?
TechПочему мой ИИ-агент без предупреждения направляет европейские медицинские данные через сервер в США?