首先，npm 社区不是第一次出问题，每次出现问题都会带来整个 js 社区的一次讨论。

其次，这种问题也不仅是出现在 npm 社区。Python 社区的 pipi 也出现过问题，就连几年前 xcode 也出现了问题。

但是从这次事件的经过和相关讨论看，这种问题在 js 社区很难解决。

这次事件的经过可以用一张图来解释：

我们再来简单的看看事件的经过，我更倾向于这是一次蓄谋已久的定向投毒事件。投毒的目标是比特币相关的 package，目的是盗取比特币。

1. 然后作者把 event-stream 的所有权移交给了攻击者
2. 不久后攻击者开始给 3.3.6 版本的代码投毒，此时 copay 使用了已经被投毒的代码，中毒了
3. 不久后攻击者又移除了恶意代码，发布了 4.x
4. 但是 npm 的使用原则是，很少有人直接更新大版本，于是 copay 就一直使用 3.x 的最新版（中毒版）
5. 也就是说，从 9 月份开始，所有 copay 开发者都是使用了中毒的 copay 库

虽然攻击者 right9ctrl 的 GitHub 账号已经被删除了，但是我在删除之前把他的账号截图了：

我们可以看到，vue-cli 才是最无辜的。因为作者的投毒对象很可能是 React。

为什么这么久才被发现呢？因为发现此恶意代码也完全是偶然（这才是细思恐极的）。

1、nodemon 是一个在开发过程中监视 node.js 中的任何更改并自动重启的服务

2、有开发者在使用过程中遇到了一件奇怪的事：在控制台日志中出现了一个警告

一般的开发者都会忽略 warning，只关于 error。偏偏这个开发者比较认真（莫非是处女座?），于是他给 nodemon 发了 issue

3、crypto 是一个加密解密相关的库

4、但是作为一个监控 node 的工具，为什么要使用一个加密解密的库呢？

5、在其他开发者的帮助下，此用户打印了更加详细的堆栈信息

试想，如果 crypto 没有更换新的 API，没有将 createDecipher 方法标记为 deprecated，也许直到现在这个恶意代码都不会被发现。

相关的 issue 在讨论了 666 条回复后被关闭，有人分析了前 200 条评论，整理了大家都在关注什么内容。

可见大家对于此次事件的态度。

责怪的声音占到了约 20%：

1、有责怪作者的，因为作者把这个库交给了一个陌生人。我觉得作者其实也是一个受害者，我们不应该去责怪作者，这一点 大大应该解释的够清楚了。

2、有责怪用户的，因为开发者没有向作者支付“维修费”。这个论点是，包的安全检验应该由包的使用者而不是开发者负责。

俗话说，能用钱解决的问题就不是问题（删掉~问题是没钱~）。

解决方案1：用户支付使用费和维护费，将包的安全问题交给作者解决。如果我们使用了 A，那么我们向 A 的作者支付费用，那么如果 A 依赖了 B 呢，很简单，A 向 B 的作者支付手续费。如果 A 不想支付费用呢，也简单，自己造一个 B 的轮子。666，我觉得这会杀死 npm 社区的。

解决方案2：用户来负责所有依赖库的安全，但是。。。你以为 npm install 真的那么简单吗

看来，这种方案也不行啊

解决方案3：由社区负责。难道 npm 不想做的完美吗，关键是没有可行的实施方案啊。

我们可以依靠数字证书来确保包没有被恶意篡改，确保软件的发行包是由作者开发的。那么现在的问题是，如果某个软件包更换了作者，你会放弃使用这个包吗。还有另一种情况，如果软件包的作者没有变更，但是作者在这个包里面添加恶意代码呢，参考之前的某国人开发的绘图库里面包含了挖矿代码。

另外一点就是，如何保证最终的发行包是由可信的源码构建的。因为这次事件中，攻击者在 GitHub 上维护着 2 个 js 文件，一个是未添加恶意代码的源文件，另一个是打包后的压缩文件，但是这个压缩文件里面包含了恶意代码。莫非强制作者只能在 npm 提交源代码，然后由 npm 进行编译，如此一来，很多不想提供源代码的 js 包就无法在 npm 发布。

老 A 和我聊起了她当年运营知乎渠道，给公司增粉和扩大品牌影响力的经历。

听完后，我觉得这套方法论，对我们运营其他渠道（贴吧、微博等）来实现增粉、品牌宣传、付费转化同样有帮助，于是结合老 A 的分享，我整理出这篇文稿。

运营渠道前，该做些什么

老 A 说，在公司干运营其实蛮苦逼的，尤其是新媒体渠道运营，很多公司并不够重视。但是作为有追求的运营人，作为背着一堆 KPI 的运营人，她是如何在知乎这个渠道搞事情的呢？

首先，老 A 对知乎这个渠道进行了数据分析，以验证渠道质量。也许你会说，用脚趾头想一想都知道知乎是个优质渠道，还用得着多此一举吗？

但是，没有实实在在的数据做支撑（且是两三年前），你怎么以专业的姿态说服你领导？

知乎既有 PC 端，又有 App 端，需要从两个角度综合考虑。PC 端需要重点关注UV（独立访客）、PV（页面访问量）、IP 这三个数据。App 端重点关注注册用户数、活跃用户数。

通过 Alexa、站长之家及知乎官方披露的数据，老 A 得出了知乎的以下关键数据信息（以下均是我在老 A 指导下查的最新数据，我以实例证明这招好学易用）

从流量趋势来看，知乎的流量也呈上升趋势：

据 Alexa 数据统计显示，知乎全球网站排名（三月平均）127 名。

单从知乎这个渠道本身看，它的流量情况自然不用怀疑，这是一个质量很高的渠道。

在确保渠道流量没问题后，需要进一步考虑这个渠道与公司业务的相关性。换句话说，就是这个渠道对你们公司业务的价值，该渠道是否有/是你们的目标用户。

对老 A 而言，她需要验证知乎这个渠道，是否有以及有多少用户对宠物相关话题感兴趣。

如果对“宠物”感兴趣的人很少，那知乎自身的流量再高，对老 A 来说都起不了大作用。

好比去养老院推广化妆品，即使这个场所里有 10 万、20 万人，但是他们对你的产品没有需求，这些人对你完成指标并没有用。

之后老 A 就对知乎上的话题进行了一番分析， 归纳出如下数据：

从以上数据，我们可以看到知乎上关注“宠物”的人已经有了很大的体量，精华问题的数量也算可观，将知乎作为推广宠物相关业务的渠道，具备一定的可行性。

以上的分析步骤，适用于任何一个渠道的分析，大家可以视自己的情况套用。

你可能觉得这个环节不重要，但是如果你过不了老板那关，那之前所做的分析都是白费，所以抓紧拿起小本本做笔记，看老司机如何说服老板获得支持的。

结合老 A 的经历，她要说服领导运营知乎这个渠道，就要向领导证明知乎这个渠道能给公司带来价值。

带来价值其实是一个非常笼统的说法，具体到运营某一个渠道来说，可以细分为、品牌推广、付费转化等不同的核心价值。

老 A 所在的公司是宠物一站式综合服务平台，她想通过运营知乎这个渠道，实现和品牌推广这两个核心价值。

而有了前面两个步骤的渠道数据分析及业务关联性分析数据，老 A 要说服领导已经比较容易了。

首先，知乎这个渠道自身的流量很大，当前注册用户数已经超 ）

增长黑客（Growth Hacker）是依靠技术和数据来达成各种营销目标的新型团队角色。从单线思维者时常忽略的角度和高度，梳理整合产品发展的因素，实现低成本甚至零成本带来的有效增长…

本文经授权发布，不代表增长黑客立场，如若转载，请注明出处：/cgo/product/12755.html