内容归档
按栏目浏览往期内容，用关键词、分类和日期找到需要的信息。
移动应用安全测试（MAST）是在 App 发布前检查应用代码、内置 SDK 和运行时行为中漏洞的做法。已发布的应用相当于任何人都能下载分析的二进制文件，硬编码的密钥等于公开。MAST 把静态分析（SAST）、第三方依赖检查（SCA）和动态分析（DAST）结合起来，贯穿每次构建，而不是上线前只做一次渗透测试；OWASP MASVS 是参考标准，OWASP Mobile Top 10（2024 年更新）是常见的风险清单。文章还列出评估测试工具的五个标准，如覆盖二进制与依赖、按可达性排优先级、融入 CI/CD、跨扫描器结果去重、提供含预编译 SDK 的 SBOM。需注意文中未点名具体工具产品，也主要引用了一项 2026 年调查称 86% 的工程负责人希望安全检查更自动化。
提供的材料未提及具体可用工具。
PHP 官方在 2026 年 10 月 21 日紧急修复了两个严重漏洞，统称 php2shell（CVE-2026-109618 和 CVE-2026-109619，严重程度均为 9.2 分）。问题出在 PHP 本身：当请求耗尽内存等致命错误发生时，PHP 会中途跳出、跳过清理步骤，留下半完成的内存状态；攻击者可以用特制上传和后续请求利用这块烂摊子，读取内存片段甚至执行任意命令。Harness 推出了 WAF 虚拟补丁规则，先以监控模式观察、确认后切到拦截，还可在 API 安全扫描发现暴露端点时一键生成补丁，帮你在逐个服务器更新重启之前挡住攻击。普通读者要明白：约七成已知服务器软件的网站跑在 PHP 上，受影响面很大，虚拟补丁只是临时桥梁，最终仍需把每台 PHP 装好补丁并重启。
Harness 为自托管的 MCP 服务器新增了 OAuth 代理模式。以前企业自建 MCP 服务器时，只能把 Harness 的个人访问令牌（PAT）或服务账号令牌放在服务器或开发者电脑上，这种令牌长期有效、容易被复制和共享，泄露后照样能用，审计日志也分不清是谁在操作。新模式下，MCP 服务器充当中间人：开发者先用公司自己的身份提供商登录，服务器再在后台换成短期有效的 HarnessID 令牌并加密保存，开发者机器上不再出现 Harness 凭证。这样，受到严格监管、只信任内部身份系统的企业也能把 Harness 接入自己的 AI 开发平台，同时每次操作都能对应到具体的人。该功能已随文章发布，具体开通条件和限制原文未说明。
Harness 这家工程公司发现，AI 工具费用涨得飞快，但没人看得清钱花在谁身上、花在哪个模型上。他们用自家的 Harness Cloud Management Agent 把各家 AI 服务商的用量和费用汇总到一处，按开发者、供应商、模型、token 类型拆分展示，还引入「每百万 token 成本」这个效率指标，让开发者能看到自己用得贵不贵。接着他们给每位开发者设了每周预算：用到 90% 先提醒，超过 100% 才停用，而且可以自助申请加预算、按金额分级审批，不用提工单。2026 年 7 月中旬上线后，每百万 token 成本从约 1.80 美元明显下降，总支出也先降后小幅回升；作者认为这说明开发者不是少用了 AI，而是不再拿高价模型干便宜模型的活。以上是该公司自述的效果，文中未给出具体降幅百分比，也未附第三方验证。
Harness 发布了一款叫 VegaLoad 的免费开源负载测试工具，采用 Apache 2.0 许可证，由其韧性测试团队开发。以前做负载测试往往要另外找工具、把脚本放在别的仓库，还得提工单排队等运行，很多服务没做压测就上线了。VegaLoad 把压测脚本变成一个放在代码旁边的小文件，AI 编程助手可以直接写测试、运行测试，返回通过或失败结果和一份 HTML 报告，测试在本机跑，还能设延迟和错误率上限拦截合并或发布。对开发者来说，压测能在几分钟内试起来，代码可读可改；不过若需要多机集群压测或跨团队历史记录，则要另用 Harness 的商业产品。
Harness 在它的成本管理 Agent 里新增了“AI 预算”功能，把写在纸面上的 AI 花钱规则变成实时能看见的限额。以前很多公司虽然定了 AI 费用政策，却没法知道有没有被执行，往往要等到下个月账单出来才发现超支。现在可以按团队、开发者、模型或项目设预算，每周重置，用到 90% 时提醒，超过 100% 就暂停使用，直到下周重置或有人批准加钱，加预算也能在系统里自助申请。这样超支几天内就能被发现，也方便留出审计记录。目前是早期开放阶段，文中未说明具体收费和全面上线时间。
这篇文章讲的是 AI 编程智能体（能自己读代码、跑命令、提 PR 的编程助手）的安全隐患。过去自动补全只是猜你下一行代码，不会自己动手；现在的智能体却会直接操作系统，但大家沿用的信任模型没有跟着改。问题在于两点：智能体读到的文字既当资料又当命令，而且信任是看“来源渠道”而不是看内容——文件、hooks、MCP 工具只要被打上可信标签，里面藏的指令就会被照做。文章说，仅靠权限提示和沙箱不够，因为没人负责提示之间智能体自己干了什么；作者通过拆解一次会话从启动到执行的各个阶段，展示攻击面在哪里，帮开发者想清楚怎么加固工作流。
提供的材料未提及具体可用工具。
Harness 在 2026 年 2 月调查了 700 名工程人员，发现团队部署越快，发布失败越多，倦怠也越严重。部署失败率低于 11% 的团队里只有 4% 的管理者说团队长期倦怠，而失败率超过 30% 时这一比例升到 55%。有意思的是，84% 的受访者说 AI 反而减轻了倦怠，但因为 AI 让交付门槛提高，底层流水线没跟上，更多发布就带来更多故障和熬夜。文章建议减少每次发布的手工步骤、让回滚变得轻松，并用 AI 智能体自动处理安全问题；这些只是相关性数据，不是受控实验，原文没有给出完整报告的更多细节。
Harness 这家做软件发布工具的公司，把审批环节直接搬进了部署流水线里。以前每次上线前要等好几位负责人签字，人不在就得干等，有时发布要拖到第二天。现在审批步骤就在流水线内部运行，可以设置审批人、超时时间，还能对接 Jira 或 ServiceNow 走变更流程。对开发团队来说，发布等待时间有望缩短，不用再为一个签字等上大半天。
Harness Builds 把测试智能（Test Intelligence）、代码覆盖率和质量信号结合起来，帮助开发者和 AI 智能体更快验证代码改动。问题是：AI 让写代码变快了，但每次改动仍要构建、测试、审查，改动越多，验证和判断代码好不好的时间就越关键，光跑得快不够。Harness 的做法是用测试智能挑出与改动真正相关的测试来跑，再用代码覆盖率显示哪些代码路径实际被测试执行过、哪些没被碰过；覆盖率还能在流水线里设阈值，低于标准就让构建失败。这样开发者可以更容易发现测试盲区，而不是只看一个覆盖率数字。文中未说明该功能目前是否已正式可用，还是处于演示或未来计划阶段。
这篇文章面向银行等金融机构，讲怎么在满足监管合规和安全要求的前提下管好云上花的钱。银行和普通互联网公司不一样：一项改动往往要经过多个部门审批，云账单又常常延迟才到，导致没人能单独为成本负责，四成支出可能都算不清归属。文章建议先把资源标签和成本分摊规则定好，让每笔钱都能追溯到业务部门并通过审计，再在保证速度的前提下做治理和自动化控制。读者能借此了解银行做云成本优化时该从哪里下手、要避开哪些坑，但文中只给了方向和步骤，没有具体工具或数字效果。
提供的材料未提及具体可用工具。
Harness 和 Cosmos 想把软件开发变成一条受管控的“流水线”：Harness 负责把代码变更安全送进生产环境，并在构建、测试、安全和部署等环节留下证据；Cosmos 负责用事件触发并协调各种 AI 代理，按固定流程把规格变成 PR、把告警变成修复。过去企业担心自动化流程不可信、不可控，这次的做法是让代理只在受限制的容器里运行、令牌按次发放、策略不通过就不执行，变更失败还能自动回滚。对读者来说，这意味着未来更多重复性工程工作可由流程化代理完成，人只在关键检查点审批，但目前材料没有说明具体可用时间、价格或独立验证结果。
软件交付工具公司 Harness 调查了 700 名工程人员，想弄清 AI 编程工具如何影响软件发布。他们发现：发布越快，失败越多，团队倦怠也越严重——比如部署失败率超过 30% 的团队中，55% 的管理者说团队长期倦怠，而失败率低于 11% 的团队只有约 4%。有意思的是，84% 的受访者说 AI 其实减轻了倦怠，问题出在 AI 提高了交付期望，而底层的发布流程没跟着升级。对读者来说，这意味着：如果你的团队也在被发布拖垮，先别怪 AI，优先减少手工步骤、让回滚变简单，可能是最有效的抓手。
提供的材料未提及具体可用工具。
Harness 收购了 Augment Code 的部分资产，包括 Cosmos、Auggie CLI 和代码上下文引擎。以前，AI 写代码和把代码安全部署到生产环境是两件分开的事，中间要人工搬运信息。现在 Harness 想把这些环节连起来：让 AI 代理从工单或 bug 出发，自动规划、写代码和测试、提 PR，再交给 Harness 的交付、安全、成本等代理一路管到上线。对读者来说，这意味着软件开发可能从「AI 帮写代码」走向「AI 跑通整条流水线」，但具体开放时间和可用范围原文未说明。
Harness 发布了一篇入门教程，手把手教没有用过 Harness CD 的开发者部署一个示例 Java 应用。原来很多团队用 SSH 脚本手动部署，一旦要加第二个环境、回滚或上线审批，脚本就会变得混乱，回滚往往要凭记忆找回上一个可用的镜像版本。这次教程把“构建”和“部署”拆开：部署目标、策略和失败处理只需配置一次、到处复用，从测试环境切到生产环境只改少量设置，出错一键回滚并保留完整发布历史。教程需要 GitHub 等代码仓库账号、Docker Hub 账号、Kubernetes 集群和 Harness 账号，并说明仓库里已带一份可用的流水线配置，可直接指过去跳过手动步骤，但整篇是演示性质，是否已在正式产品中可用原文未明确说明。
这篇博客记录了作者用 Harness 搭建 CI 流水线的一次实际体验：他有一个 Java Maven 项目（含 42 个单元测试和 Dockerfile），以前搭流水线要手写一堆 YAML 配置，这次他把 GitHub 仓库授权给 Harness，让内置 AI 扫描代码、自动识别 Java + Maven 并生成构建、测试、缓存步骤，再手动加一步把镜像推到 DockerHub。整个过程不用写一行流水线 YAML，首次运行 2 分 34 秒全部通过，加上推送 DockerHub 后整条流水线也只跑了 3 分多钟，适合想快速体验 Harness CI 的开发者参考。
安全平台 Harness 的 AppSec 团队用自研决策模型 Jev 替换了原来生成式大模型做的「是/否判断」环节，用来识别客户 API 里哪些在和 LLM 通信。原来这条流水线要先用两次 LLM 摘要、再做分类，成本高、延迟大，而且模型自报的置信度几乎不能用来判断对错。换成 Jev 后，系统不再让模型写文字，只输出一个概率：每条 API 的判断成本比原流水线降约 1200 倍，比单次 LLM 方案降约 150 倍；出错的样本都落在 0.3–0.8 的不确定区间，只占 3.4%。对读者来说，这提供了一种思路：把流水线中重复的「判断」和「生成」拆开，用专门的决策模型替代，能大幅降本，同时保留可回滚的接口。
很多工程团队的数据散落在 CI、部署、安全扫描等不同系统里，同一个服务在不同系统中叫不同名字，工程师和 AI 每次问“这次部署为什么失败？”都要手动拼数据，答案还每次都变。文章提出用“软件交付知识图谱”解决：把实体、关系和数据格式用“schema 即代码”明确定义，再统一同步和查询，让跨系统的知识变得可靠、确定。还强调图谱质量取决于数据质量，需要监控数据填充率、记录数据来源、持续评估，否则图谱也会退化。文章以博客形式给出架构和指南，未说明配套产品何时可用。
提供的材料未提及具体可用工具。
Harness 发布博客文章，解释工程师为什么常常忽略云成本：传统 FinOps 工具把成本数据放在独立的财务仪表盘里，开发者得中断写代码去查，而且反馈往往要等 30 天才来，和日常交付节奏脱节。文章提出的做法是把成本信息“左移”进 CI/CD 和 IaC 流程：在合并请求合并前就评估这次改动是不是申请了没批准的实例类型、会不会超预算，超了就自动拦截或交给负责人审批；同时用 Harness Cost Management Agent 在服务级别做实时成本可见性。对平台团队来说，意义在于不用牺牲开发速度也能让开发者对云支出负责。目前文中提到的产品能力和模式来自厂商博客，具体发布时间和可用范围原文未说明。
Harness 在 30 天内发布了 102 项产品更新，差不多每 7 小时就有一项。它解决的是：代码写得很快，但后面的构建、测试、安全检查、审批和部署仍然很慢。这个月它把合并队列、命令行工具、基础设施密钥扫描等能力补齐，还让 ChatGPT 可以直接管理 Harness 流水线。对开发团队来说，等待构建和部署的时间可能缩短，安全扫描也更容易内嵌进流程。部分功能已可用，但具体开放范围原文未说明。