最新

在过去十年中，网络攻击的模式发生了显著变化。虽然大型企业仍然成为新闻的焦点，但现在最常见的受害者是家庭用户、承包商、托管服务提供商（MSP）和中小企业（SMB）。较低的可见性、较弱的控制措施以及对云服务和第三方平台的依赖，使这些环境对犯罪团伙和与国家相关的行为者变得具有吸引力。 我整理了一份从2016年到2025年的重大攻击时间线，以展示这一趋势是如何演变的。以下是文本版本，供喜欢直接阅读的人参考。 **攻击时间线（2016–2025）** • 2016年 — Mirai僵尸网络DDoS 使用消费级物联网设备的家庭用户受到攻击，变成了一个大型DDoS僵尸网络。多个犯罪团伙重用了泄露的Mirai代码。 • 2017年 — WannaCry勒索软件 家庭用户和中小企业受到利用SMBv1漏洞的蠕虫攻击，广泛归因于拉撒路集团（Lazarus Group）。 • 2017年 — NotPetya清除工具 中小企业受到伪装成勒索软件的破坏性清除工具的影响，与俄罗斯国家相关的行为者有关。 • 2018–2020年 — Emotet/TrickBot → Ryuk/Conti 针对中小企业的凭证盗窃和勒索软件攻击，由多个犯罪团伙实施。 • 2019年 — 云服务和第三方数据泄露 中小企业和家庭用户因各种云平台上的弱访问控制和数据暴露而受到影响。 • 2020年 — Toll Group勒索软件 承包商和服务提供商因影响物流运营的勒索软件攻击而受到干扰。 • 2020–2021年 — SolarWinds供应链漏洞 通过被植入恶意代码的软件更新，第三方供应商受到攻击，归因于与俄罗斯国家相关的APT（高级持续威胁）。 • 2021年 — Kaseya VSA勒索软件 通过供应链勒索软件攻击，MSP和中小企业受到影响，归因于REvil集团。 • 2021–2023年 — 勒索软件即服务（RaaS）激增 中小企业成为多个RaaS团伙驱动的附属勒索软件操作的目标。 • 2022–2024年 — SaaS和第三方平台漏洞 家庭用户和中小企业客户因云平台上的凭证盗窃和数据外泄而受到影响。 • 2023–2025年 — 针对MSP和专业承包商 MSP和专业承包商受到犯罪和与国家相关的行为者的勒索、数据盗窃和敲诈攻击。 我一直在开发一款专注于Windows的威胁狩猎工具（www.sapience-tech.com），旨在帮助没有EDR或SIEM工具的家庭用户和中小企业。这个工具的产生源于希望帮助较小的环境在不需要企业级基础设施的情况下，识别早期的妥协迹象。欢迎对数据、时间线或方法提出问题。

在使用 codex CLI 的 gpt-5.3-codex 模型时，我遇到了一个特定错误消息的流断开问题。看起来我被引导到了 5.4 分支的 A/B 测试中：<p>``` 流在完成之前断开：该用户对 gpt-5.4-ab-arm2-1020-1p-codexswic-ev3 的访问因与网络安全相关的潜在可疑活动而暂时受到限制。 ```<p>还有其他人看到 GPT 5.4 的变体吗？

大家好，我最近开源了我的项目，希望能帮助大家在求职过程中。我没想到在一周内就获得了超过500个星标和50万次的Reddit浏览量。<p>你们觉得怎么样？<p>附言：招聘人员和创业公司创始人可以联系我！

在过去的一年里，我一直在开发 GM Pro——一个提升 Google Meet 聊天体验的 Chrome 扩展程序。<p>一开始很简单：反应、回复、提及、聊天的黑暗模式。然后我添加了自动加入、自动静音、转录工具、大厅通知、与会者随机分配。基本上就是你希望 Meet 聊天默认具备的所有功能。<p>人们对此非常喜爱，获得了五星好评，安装量稳定，实际使用频繁。<p>然而，在多年乏善可陈的聊天体验后，谷歌宣布将 Meet 聊天与 Google Chat 直接整合——持久的对话、反应、文件共享等等。<p>这意味着……我所构建的功能正好成为了一个第一方特性。<p>一方面，这验证了我的想法。方向是正确的，需求是真实的。<p>另一方面，平台风险让我感到措手不及。<p>当你在一个巨型平台上构建时，实际上是在为他们原型设计功能。如果这个功能有效，他们会吸收它；如果无效，你就会悄然消失。无论如何，他们都是赢家。<p>现在我在思考：<p>我是否应该转向那些谷歌不会优先考虑的强用户工具？<p>加大对自动化和工作流功能的投入？<p>还是远离聊天，转向会议智能？<p>或者接受消费者 Chrome 扩展程序在核心用户界面上本质上是脆弱的？<p>我很好奇其他开发者是如何看待平台依赖性的。<p>你是否曾经在所构建的平台上经历过产品被“Sherlocked”的情况？你接下来做了什么？

我开发了一个音乐发现应用，现在是开源的。 BlackTape 使用 MusicBrainz 和 Discogs 这两个开放的、由社区维护的数据库，来索引艺术家并根据他们在各自流派中的独特性进行排名。艺术家越小众，他们的排名就越高。这与 Spotify 的算法正好相反。 我对推荐算法使发现变得单一感到沮丧。在超过 1000 万个索引艺术家中，总是出现相同的艺术家。MusicBrainz 记录了 260 万个艺术家，并提供丰富的流派标签、场景数据和地区元数据。Discogs 则有长达 80 年的发行元数据。将这两个数据库结合起来，根据独特性而非流行度对艺术家进行评分，发现的空间就完全打开了。 它的功能包括： - 按流派/场景进行原子标签组合搜索 - 根据独特性评分排名的发现推荐（稀有 = 可被发现） - 完整的艺术家页面：唱片目录、标签、相关艺术家、场景数据 - Spotify 播放集成（可选） - 时间机器：按年代浏览艺术家 - 风格地图：可视化流派/场景导航 - 知识库：流派关系图 没有追踪，也不依赖平台 API 来获取核心发现数据。桌面应用使用 Tauri + SvelteKit 构建。 GitHub: https://github.com/AllTheMachines/BlackTape 网站: https://blacktape.org 欢迎讨论 MusicBrainz 流程、独特性评分或开放数据的发现方法。

嘿，HN， 我开发了 Decision Guardian——一个开源的 GitHub Action 和命令行工具，它会在代码修改受保护文件时自动将架构决策以 PR 评论的形式呈现出来。 它解决的问题： Spotify 在 2020 年发布了一篇关于何时编写架构决策记录（ADR）的精彩文章。我遵循了这个建议。我的团队编写了 ADR，但它们被放在 docs/adr/ 中，没人会在打开 PR 之前阅读它们。 [Spotify 文章链接](https://engineering.atspotify.com/2020/04/when-should-i-write-an-architecture-decision-record) 问题不在于文档，而在于如何呈现。呈现决策的最佳时机不是在入职培训或冲刺计划时，而是在有人积极编辑受决策保护的代码时。 它是如何工作的： 1) 在 Markdown 文件中编写决策（与现有的 ADR 兼容） 2) 将 GitHub Action 添加到你的工作流中 3) 当 PR 修改受保护的文件时，Decision Guardian 会自动将相关决策作为评论发布 决策格式（普通 Markdown）： ```markdown <!-- DECISION-DB-001 --> ## 决策：使用 Postgres 进行计费 *状态*: 活跃 *严重性*: 关键 *文件*: - `src/db/*/*.ts` ### 背景 我们评估了 Postgres 和 MongoDB。计费需要 ACID 兼容性。 MongoDB 被拒绝——没有事务保证。 值得注意的功能： 1) 严重性级别（关键 / 警告 / 信息）——可以在关键违规时阻止 PR 2) 高级匹配：通配符模式、正则表达式、基于内容的规则、布尔逻辑 3) CLI 可与任何 CI 工具配合使用（GitLab、Jenkins、CircleCI、pre-commit hooks） 4) 处理超过 3000 个文件的 PR 而不会出现内存溢出 5) 幂等评论——无垃圾信息，更新就位 6) 零外部网络调用——没有任何数据离开你的 GitHub 运行器 7) 109 个测试，ReDoS 保护，路径遍历保护 与 CODEOWNERS 的对比：CODEOWNERS 指定审阅者。这解释了审查的重要性。最好一起使用。 与 Danger.js 的对比：Danger 需要代码，而这个工具需要 Markdown。非 JS 工程师也可以管理他们的决策。 它是 MIT 许可的，单步骤 GitHub Action 或 npx decision-guardian CLI。 欢迎提问。 仓库链接：[GitHub 仓库](https://github.com/DecispherHQ/decision-guardian)