API BOM重要性

API BOM让用户能够更好地了解用户的应用对外暴露情况，进而更轻松地：

• 确保用户的所有 API 都经过适当的安全审查程序。这对于管理新添加的 API 的审核特别有帮助。
• 管理 API 中危险的请求方式，即使它们是合法且有意包含在代码中的。比如：一个包含 DELETE 方法可能会改变用户的应用程序配置或用户数据。安全人员要意识到代码中存在此方法，这可能存在潜在的风险。
• 方便安全运营人员优先考虑 API 暴露的风险（攻击者可以利用暴露的API，优先进行利用）。

API BOM 数据分析实践

将源代码、开源组件、漏洞、情报等信息关联映射到API上，通常从以下两个维度将API和源代码进行关联 • API 是通过源代码检测发现的。 • API 是用支持此功能的语言或者框架编写的。 当 API 处理程序函数和包含问题的函数之间存在函数调用路径时，就可以认为该 API 的暴露进一步增加检出风险的威胁等级。

此处说的可能有些模糊，我举个例子来说明：

1、通过分析源代码，发现对外暴露的接口，此处目前有部分Jetbrians插件(Apipost-Helper、Cool Request)可以支持，目前这两个插件都是闭源产品，忍不住分析了一下，重新逆向实现后发现都是利用Jetbrians psiClass来解析api接口，效果如下：

也可以使用JavaParser来实现，实现效果如下：

以上两种API解析，对于参数声明复杂参数，暂时解析不准，可以和API管理平台或者声明文件进行关联和补全。

2、将所有的数据存储到数据库或者数据湖当中，然后进行关联分析，利用API进行汇总分析，可以关联xAST分析结果，如果SCA支持漏洞可达性分析，可以将组件漏洞通过代码和API进行关联。当安全事件发生时，可以通过API迅速定位漏洞位置，及时止损。

3、利用漏洞优先级排序(VPT)模型或者平台，对所有检出结果进行排序，根据排序结果分配工单依次进行修复。其中，对外暴露的API在VPT计算模型的权重较高，修复优先级也越高。

注意：以上笔者目前只预研完成了第一步，后续关联分析都只是设想，如果哪位同学成功运营实现，请不吝赐教。

OX API BOM信息汇总效果如下：

目前OX Security 攻击路径实现效果如下：

可以直观分析受影响的应用、请求API、源代码提交信息、源代码路径、漏洞信息、情报等信息，提高安全运营人员的效率。此处使用的是理想的测试数据，但是在日常的安全运营工作当中，可以尽可能的关联有效信息，减少海量告警信息，优化工单分配，这就极大的提升运营效率。

总结

1、API BOM可以将代码和xAST工具的检测结果进行关联，拉通API和 Source Code之间关联，进而拉通所有数据之间的关系。 

2、丰富ASPM管理的维度。 

3、丰富VPT计算因素，如：暴露的API，URL请求路径可达等

 4、可以进行漏洞去重，并不局限于必须有漏洞编号、必须有统一的漏洞评价标准，可以通过API及关联的漏洞类型进行去重

 5、降低运营人员排查难度，通过API关联数据，一个统一的平台可以检测所有受影响的系统、代码、组件，利用AI或者人工研判灵活处置分析漏洞，根据实际情况进行漏洞修复。

参考

• https://docs.ox.security/a-tour-of-ox/api-bom
• https://www.apipost.cn/
• https://coolrequest.dev/
• https://apiparrot.com/

阅读原文

跳转微信打开

真心不清楚这篇博文该以什么样的形式开头，写了删，删了写，也无法抒发内心种种不甘，直到今天拿到离职证明，一切尘埃落定，四年时光如白驹过隙，一晃而过，百感交集。以下都是自己的碎碎念，也没啥逻辑，将就看吧。

21年从nsfocus离职的时候，当时也是受了委屈，看着前辈们意气风发，指点江山，激昂澎湃，自己却被蛀虫掣肘，由于直系领导都离职了，蛀虫看人下菜碟，欺负年轻人没背景，好好的项目拱手让人，当时还被蛀虫倒打一耙，说我这边项目报价有问题，项目规划有问题，我TMD，后来我才知道，当时蛀虫是收了好处费的，活生生把POC第一变成了陪标的。后面碰巧遇到现在的老板成立新公司招人，当时和老板在苏帮袁喝了一顿酒，聊得也挺开心的，也没聊薪资待遇，只想着大家一起做些事，等安排好原团队的其他成员后，加入到现在的公司。

加入新公司后，新公司当时没有核心产品，当时也是基于最早DevSecOps的思路，靠关系接一些客户定制开发订单，帮客户提升自己的开发安全能力，预研团队就两个人，我带着另一个同事去做创新，做交付，先后孵化SCA,VPT,ASOC（ASPM），可达性，TMA，服务可观测等产品和方案。主要的工作内容基本上就是先做DEMO开发或者方案制定，如果效果还可以，将DEMO工程化，后续由研发团队来对接。公司整体以研发的同事居多，安全方向的预研只能由我们这边来完成。这个合作模式的好处就是能降低预研团队和研发团队的投入，预研这边只管输出方案、DEMO，不用关注UI、系统管理等功能设计，研发团队不用刻意关注安全技术原理，只管对接就行，产品统一规划。这套模式可以有效运作，前提是团队间的配合默契，人员分工合理，没有JSG在作妖。这套模式一直有效运作，直到今年年中，不太清楚老板是如何考虑的，收购并引入了一个新的研发合伙人LT，加入后没有实质性的效果，反而开始打压老员工、搞派系斗争、积极向上管理，抢功。这个确实让人猝不及防，小公司这么搞，是要伤筋动骨的，但是现实就是，老板给予新来的研发合伙人绝对信任，认为我们老员工就是在针对新来的研发副总裁（个人看法），老员工不服从管理，老员工能力差，你也不看看LT做的事。老同事订婚时间都确定了，提前和LT请假被拒绝，这TMD是正常人能干出的事，诸如此类的事有很多，LT人品差，但是任何LT认为是挑战他的权威都要被挤兑。刚开始LT以方便管理，要全盘接手SCA，让预研这边交出SCA所有的预研工作，我当时不满意但是无可奈何，只能和老板商量，借此把和LT不对付的W保下来，划分到我的团队。此时SCA刚进行产品立项，大家加班加点开发出一个个人觉得较满意的版本，客户侧交付已经初见效果，本来这块市场很小，做出一个基础产品，技术含量也没那么高深，此时待预研的功能有很多，个人感觉一切都向着好的方向发展，团队可以继续扩张，此时LT以一个蹩脚的理由来交接，明显是来摘果子的。由于老板在中间调解，没办法只能交接了。LT觉得SCA很容易，很自信，后续看着git上交接的几十个相关项目，开始让我们要写详细的交接文档，技术实现逻辑，技术坑点，我也是服了。

一个月后，LT并不能顺利接手，只能边边角角开发一些无关功能，积极向上汇报，张口闭口就是战役、卷、加班，动不动开会复盘甩锅，为了让自己带过来的人尽快熟悉项目，开始重构项目，有问题就甩锅我们这边，虽说已经交接了，TMD，有新进展就是自己功劳，有问题就是之前的锅，明摆的就是说我们不行，你行你倒是上啊，自己嫡系接手后，搞不定，招新人背锅，我第一次发现还可以这么玩，和这种人合作，真心恶心。虽说交接快一个月了，正常来说当初吹下的牛逼该兑现了，然后新的骚操作来了，LT根本搞不定后续的开发，连个直接依赖和间接依赖都区分不清楚的人，他怎么去开发，不太清楚他和老板怎么沟通的，把团队内之前和他不和的W和另一个做数据运营的小伙伴强行划分到LT的团队了，做数据运营的小伙伴被划分过去，我还能自我安慰，是为了项目，但是把W划分过去就是单纯的打击报复了。公司是老板，这里私下也做了一些工作，都是无用功，老板只是通知了一下，就把两个小伙伴划分过去了。划过去一个多月，两个小伙伴先后离职。

内耗，不断内耗，有时候猜测老板可能只是为了降本增效，借LT来挤兑老员工。所有的都是猜测，直到今天我被辞退，我也不清楚原因，老板只说了未来不需要预研团队了，预研的技术方向在未来两年没有资源支持落地推广。然而公司在下半年不断招聘，人员也扩张不少，老员工不断离职，新人短暂停留后也提桶跑路了，其中一个最搞笑，把W挤兑走，之前运维的活都是研发的W和我兼职，现在低价找个新运维，入职第一周就删库跑路了，以前的段子就发生在身边，我也是无语了。我离职其中的原因有一部分来自LT，主要是我反感LT，人品拉胯，我不太愿意逢迎他，另外为了不和他产生冲突，预研的方向和他现在主要开发的业务要区分开，否则后续麻烦，先后做了一个EBPF方向的服务可观测（攻击可视化+自动阻断），API BOM（支撑ASPM的），SAST（利用Neo4j的能力，进行代码漏洞分析）。本以为我苟着，我没必要和LT内耗，我自己做调研，自己做新的方向，和三年前一样，一起从头再来，本月月中还在规划API被动扫描的事情，方案DEMO还在开发过程中，老板来了个消息，要谈一下团队的规划，总之就是要降本增效，开猿节流。收到这个消息，我也不知道该怎么做了，是该继续敲代码还是该做什么，浑浑噩噩到中午，和老板聊完后，无非两个方案，一个就是划到LT部门，另外就是拿着补偿走人。没别的选择，只能收拾东西走人。我并不讨厌老板，如果我在他的位置上，我感觉我承受不了他的压力，但是我单纯只是为他可惜，毕竟疫情三年，公司成长不容易，好不容易走向正轨，LT可能会毁掉它。后来我想了一下，总体原因还是自己太弱了，如果自己可以做出一个吊炸天的产品，全栈一条龙，就不会出现现在的窘迫了。

这一切都不是自己该关心的了，从月中到现在，早晚接送媳妇上下班，每天窝在家里，啥都不想做，之前还想着看看书，重拾一下之前的爱好，现在只想颓废，好久没有享受过这么长的假期了，就当给自己放个假了。颓废，很大程度上就是迷茫，之前每日按时上下班，每日压力山大，上班骑车途中，还得考虑技术方向如何实现，当日工作如何安排，现在突然什么都不用做了，有些不适应。第一次被辞退，这TMD都得适应，也是够贱的。

今天上午拿到离职证明，宣告着一切都结束了，后续我可能和公司不会再产生其他交集了，只能祝贺老板恭喜发财，公司业绩蒸蒸日上，就这样吧。

晚上去接媳妇回家，北风呼啸，今年的冬天异常寒冷。上个月还有个朋友和我说，他领导总在挤兑他，目前已经降薪，正在找下家，但是当前就业现状低迷，短时间找不到合适的工作，我当时还拉了个行业招聘交流群，方便抱团取暖，这也没过多长时间，就轮到我了，人生无常。

想起冬至那天从公司搬运个人物品，发现这四年，为了方便技术研究和学习，自己带了两台电脑、一台自己攒的服务器到公司，至于公司配的笔记本性能太弱，太耽误事。离职的时候真心难受，不光心里难受，搬家也费事，没事别付费上班，为了给公司省钱，自己组装机器，后来才发现，自己纯属智障，瞎操心，公司不做大语言模型相关内容，可以做其他业余，资源不够，等着老板买设备就行，LLM方向落地后，公司商业宣传，你这边也没有啥实质性的奖励，自己还是年轻，以后还是长点儿心吧。

阅读原文

跳转微信打开

fortify sca rules 标签分析

RulePack标签分析

<?xml version="1.0" encoding="UTF-8"?>
<RulePack xmlns:mask="xmlns://www.fortifysoftware.com/schema/mask" xmlns="xmlns://www.fortifysoftware.com/schema/rules">
    <RulePackID>D044EBBB-7081-4451-BDD6-5A163AD639C3</RulePackID>
    <SKU>RUL13040</SKU>
    <Name>
        <![CDATA[Fortify 安全编码规则、核心、Java]]>
    </Name>
    <Activated>true</Activated>
    <Version>2024.2.1.0003</Version>
    <Language>java</Language>
    <Description>
        <![CDATA[为 Java 提供安全相关核心语言 API 范围。此规则包的部分内容来自 Cigital Java Rulepack (c) 2008 Cigital。 Copyright 2004 - 2024 Open Text.]]>
    </Description>
    <Locale>zh_CN</Locale>
    <Rules version="3.2" minimumSCA="17.10">
    ......
    </Rules>
    <Masks revision="0">
    ......
    </Masks>
    <Localization>
    ......
    </Localization>
</RulePack>

xml标签属性说明

• RulePackID：规则包的唯一标识符

• SKU：全局唯一标识符

• Name：规则包的名称

• Activated：可以使用的(猜测，没找到定义内容)

• Version：规则版本

• Language：规则包适配编程语言

• Description：规则包描述信息

• Locale：规则包语言

• Rules：规则主体，其中version是版本代号，minimumSCA 标识规则最低支持的fortify sca版本

• Masks ：掩码

• Localization：本地化

Rules标签分析

<Rules version="3.2" minimumSCA="17.10">
        <Notes>
        ......
        </Notes>
        <RuleDefinitions>
        ......
        </RuleDefinitions>
        <LabelDefinitions>
        ......
        </LabelDefinitions>
        <Descriptions>
        ......
        </Descriptions>
        <ControlflowStateStrings>
        ......
        </ControlflowStateStrings>
        <TaintFlagDeclarations>
        ......
        </TaintFlagDeclarations>
        <TaintFlagDescriptions>
        ......
        </TaintFlagDescriptions>
        <Coverage>
        ......
        </Coverage>
        <ScriptDefinitions/>
</Rules>

xml标签属性说明

• Notes：规则备注信息，许可声明信息

• RuleDefinitions：规则集合

• LabelDefinitions：标签定义

• Descriptions：描述信息

• ControlflowStateStrings：控制流状态字符串

• TaintFlagDeclarations：污染标志声明

• TaintFlagDescriptions：污染标志说明

• Coverage：覆盖度

• ScriptDefinitions：脚本定义

DataflowSourceRule 标签分析

<DataflowSourceRule formatVersion="3.2" language="java">
  <MetaInfo>
    <Group name="package">Java Core Accessibility</Group>
    <Group name="inputsource">Web</Group>
  </MetaInfo>
  <RuleID>58B43BC7-05D2-4289-B0CE-BECAFC28A45E</RuleID>
  <FunctionIdentifier>
    <NamespaceName>
      <Value>javax.accessibility</Value>
    </NamespaceName>
    <ClassName>
      <Value>AccessibleText</Value>
    </ClassName>
    <FunctionName>
      <Pattern>(get.+Index)|getSelectedText</Pattern>
    </FunctionName>
    <Parameters>
      <ParamType>int</ParamType>
      <ParamType>int</ParamType>
    </Parameters>
    <ApplyTo implements="true" overrides="true" extends="true" />
  </FunctionIdentifier>
  <OutArguments>return</OutArguments>
</DataflowSourceRule>

DataflowSourceRule识别受污染的数据进入程序的位置。

• MetaInfo：元信息，规则分类信息

• package：包信息， <Groupname="package">Java Core Accessibility</Group> 表示这条规则属于 "Java Core Accessibility" 包。

• inputsource：输入源， <Groupname="inputsource">Web</Group> 表示这条规则关注的是来自 Web 的输入源。

• Group：组标签

• RuleID：唯一的标识符，用于区分不同的规则。

• FunctionIdentifier：函数标识

• NamespaceName：命名空间， <NamespaceName><Value>javax.accessibility</Value></NamespaceName> 指定了方法所在的命名空间。

• ClassName：类名， <ClassName><Value>AccessibleText</Value></ClassName> 指定了方法所在的类。

• FunctionName：函数名， <FunctionName><Pattern>(get.+Index)|getSelectedText</Pattern></FunctionName> 使用正则表达式匹配方法名，包括 getCharIndex, getWordIndex, getSentenceIndex, 和 getSelectedText。

• Parameters：参数， <Parameters><ParamType>int</ParamType><ParamType>int</ParamType></Parameters> 指定了方法的参数类型，这里有两个 int 类型的参数。

• OutArguments：输出参数，用于指定方法调用后哪些参数或返回值应被视为污染（tainted）数据， <OutArguments>return</OutArguments> 指定了方法的返回值应被视为污染数据。

LabelDefinitions标签分析

<CharacterizationRule formatVersion="3.7" language="java">
    <MetaInfo>
        <Group name="package">Java Core JMX</Group>
    </MetaInfo>
    <RuleID>04DC0B4B-6AC5-4B93-9B46-486D7B4778A8</RuleID>
    <StructuralMatch>
        <![CDATA[
        FunctionCall fc: function is [Function:
                name == "registerMBean"
                and enclosingClass.supers contains [Class: name == "javax.management.MBeanServer"]
            ]
            and arguments[0] is [Expression:
                reachingTypes contains [Type: definition is [Class jmxbean:]]
            ]
    ]]>
    </StructuralMatch>
    <Definition>
        <![CDATA[
        foreach jmxbean {
            Label(jmxbean, "JMXBean")
        }
    ]]>
    </Definition>
</CharacterizationRule>

字符化规则（ <CharacterizationRule>），用于识别和标记 Java 代码中特定的结构模式。

• CharacterizationRule：

• formatVersion：格式版本， formatVersion="3.7" 指明了规则使用的格式版本。

• language：语言， language="java" 指明了这条规则适用于 Java 语言。

• MetaInfo：元数据， <MetaInfo> 元素提供了关于规则的分类信息。

• Group： <Groupname="package">Java Core JMX</Group> 表示这条规则属于 "Java Core JMX" 包。

• RuleID：规则唯一的标识符

• StructuralMatch：结构匹配， <StructuralMatch> 元素定义了要匹配的代码结构。

• FunctionCallfc 表示要匹配的函数调用。

• functionis[Function:name=="registerMBean"andenclosingClass.supers contains[Class:name=="javax.management.MBeanServer"]] 表示要匹配的函数名为 registerMBean，并且该函数所在类的超类包含 javax.management.MBeanServer。

• arguments[0]is[Expression:reachingTypes contains[Type:definitionis[Classjmxbean:]]] 表示第一个参数的类型是某个类 jmxbean。

• Definition：定义， <Definition> 元素定义了在匹配到特定结构时要执行的操作。

• foreachjmxbean{Label(jmxbean,"JMXBean")} 表示对每一个匹配到的 jmxbean 类型，为其添加一个标签 "JMXBean"。

Descirptions标签分析

<Descriptions>
    <Description
        id="desc.controlflow.java.intent_manipulation_implicit_internal_intent" formatVersion="3.4">
        <Abstract>
                    <![CDATA[<Paragraph>在 <Replace key="PrimaryLocation.file"/> 的第 <Replace key="PrimaryLocation.line"/> 行检测到隐式内部 <code>Intent</code>。隐式的内部意图可能会使系统遭受对内部组件的中间人攻击。<AltParagraph>检测到隐式内部 <code>Intent</code>。隐式的内部意图可能会使系统遭受对内部组件的中间人攻击。</AltParagraph></Paragraph>]]>
        </Abstract>
        <Explanation>
                    <![CDATA[内部 <code>Intent</code> 使用内部组件定义的自定义操作。隐式意图可以促进从任何给定外部组件调用意图，而无需了解特定组件。将两者结合起来使应用程序能够从所需的应用程序上下文外部访问为特定内部使用指定的意图。
                    通过外部应用程序处理内部 <code>Intent</code> 的能力可以实现各种严重程度不等的中间人攻击，从信息泄露、拒绝服务到远程代码执行，具体取决于 <code>Intent</code> 指定的内部操作的能力。
                    <b>示例 1：</b>以下代码使用隐式内部 <code>Intent</code>。
                    <pre>
                    ...
                    val imp_internal_intent_action = Intent("INTERNAL_ACTION_HERE")
                    startActivity(imp_internal_intent_action)
                    ...
                    </pre>]]>
        </Explanation>
        <Recommendations>
                    <![CDATA[仅调用具有明确意图的内部应用程序。显式 <code>Intent</code> 是显式设置其组件、类、类名和包的意图。
                    <b>示例 2：</b>以下代码使用显式内部 <code>Intent</code>。
                    <pre>
                    ...
                    val exp_internal_intent = Intent("INTERNAL_ACTION_HERE", Uri.EMPTY, this, DownloadService::class.java)
                    startActivity(exp_internal_intent)
                    ...
                    </pre>
                    <b>示例 3：</b>以下代码使用隐式内部 <code>Intent</code>，该意图已通过 setter 更新为显式。
                    <pre>
                    ...
                    val imp_internal_intent_remediate_action = Intent("INTERNAL_ACTION_HERE")
                    imp_internal_intent_remediate_action.`package` = "package"
                    imp_internal_intent_remediate_action.setClass(this, DownloadService::class.java)
                    imp_internal_intent_remediate_action.component = componentName
                    startActivity(imp_internal_intent_remediate_action)
                    ...
                    </pre>]]>
                </Recommendations>
        <References>
            <Reference>
                <Title>
                            <![CDATA[Remediation of Implicit Internal Intent Vulnerability]]>
                        </Title>
                <Source>
                            <![CDATA[https://support.google.com/faqs/answer/10399926]]>
                        </Source>
            </Reference>
            <Reference>
                <Title>
                            <![CDATA[CWE ID 99]]>
                        </Title>
                <Author>
                            <![CDATA[Standards Mapping - Common Weakness Enumeration]]>
                        </Author>
            </Reference>
            <Reference>
                <Title>
                            <![CDATA[CCI-001094]]>
                        </Title>
                <Author>
                            <![CDATA[Standards Mapping - DISA Control Correlation Identifier Version 2]]>
                        </Author>
            </Reference>
            <Reference>
                <Title>
                            <![CDATA[Indirect Access to Sensitive Data]]>
                        </Title>
                <Author>
                            <![CDATA[Standards Mapping - General Data Protection Regulation]]>
                        </Author>
            </Reference>
            <Reference>
                <Title>
                            <![CDATA[SC-5 Denial of Service Protection (P1)]]>
                        </Title>
                <Author>
                            <![CDATA[Standards Mapping - NIST Special Publication 800-53 Revision 4]]>
                        </Author>
            </Reference>
            <Reference>
                <Title>
                            <![CDATA[SC-5 Denial of Service Protection]]>
                        </Title>
                <Author>
                            <![CDATA[Standards Mapping - NIST Special Publication 800-53 Revision 5]]>
                        </Author>
            </Reference>
            <Reference>
                <Title>
                            <![CDATA[A9 Application Denial of Service]]>
                        </Title>
                <Author>
                            <![CDATA[Standards Mapping - OWASP Top 10 2004]]>
                        </Author>
            </Reference>
            <Reference>
                <Title>
                            <![CDATA[Requirement 6.5.1]]>
                        </Title>
                <Author>
                            <![CDATA[Standards Mapping - Payment Card Industry Data Security Standard Version 1.1]]>
                        </Author>
            </Reference>
        </References>
    </Description>
</Descriptions>

• Description：规则描述，这里将描述信息单独拎出来，使用的化直接引用就行，类似这种：

• 版本格式： formatVersion="3.4" 指明了规则使用的格式版本。

• ID： id="desc.controlflow.java.intent_manipulation_implicit_internal_intent" 是一个唯一的标识符，用于区分不同的描述性规则。

• Abstract： <Abstract> 元素提供了规则的简要说明。

• Paragraph： <Paragraph> 描述了在特定文件和行号检测到隐式内部 Intent，并指出隐式内部意图可能会使系统遭受中间人攻击。

• AltParagraph： <AltParagraph> 提供了一个简短的备用描述。

• Explanation：详细解释

• Recommendations：推荐措施

• References：参考

ControlflowStateStrings标签分析

<ControlflowStateStrings>
    <StateStrings id="statedesc.java.null_assigned">
        <Enter>%{p} is assigned null</Enter>
    </StateStrings>
</ControlflowStateStrings>

控制流状态字符串概述

• StateStrings：状态字符串，元素包含了描述状态变化的字符串。

• Enter：进入状态， <Enter>%{p} is assigned null</Enter> 描述了当变量被赋值为 null 时的状态变化。

• id： id="statedesc.java.null_assigned" 是一个唯一的标识符，用于区分不同的控制流状态字符串。

说明：

• id： statedesc.java.null_assigned 这个 id 表示这是一个与 Java 语言相关的状态描述，具体描述了变量被赋值为 null 的情况。

• 进入状态： %{p}isassignednull 这个字符串使用占位符 %{p} 来表示变量名。当工具检测到某个变量被赋值为 null 时，会用实际的变量名替换 %{p}，从而生成具体的描述信息。

TaintFlagDeclarations标签分析

<TaintFlagDescriptions>
    <FlagDescription name="ARGS">Command Line Arguments</FlagDescription>
    <FlagDescription name="PRIVATE">Private Information</FlagDescription>
</TaintFlagDescriptions>

<TaintFlagDescriptions>污点标志描述

• FlagDescription：污点标志描述， <FlagDescription> 元素定义了每个污点标志的名称和描述。

• name 属性指定了污点标志的名称。

• value描述：元素的文本内容提供了污点标志的描述。

这段 XML 代码定义了两个污点标志描述：

• ARGS：表示数据来源于命令行参数。

• PRIVATE：表示数据包含私有信息。

Coverage 标签分析

<Coverage>
    <FunctionIdentifier formatVersion="3.8">
        <MatchExpression>java.io/
            File.{toPath,getPath,getAbsolutePath,getCanonicalPath,getCanonicalFile}()</MatchExpression>
    </FunctionIdentifier>
    <FunctionIdentifier formatVersion="6.10">
        <MatchExpression>java.io / ObjectOutputStream.init^()</MatchExpression>
    </FunctionIdentifier>
</Coverage>

覆盖率配置

• FunctionIdentifier：函数标识符，定义了需要覆盖的函数或方法。

• formatVersion：函数标识符的格式版本。

• MatchExpression：匹配函数或方法的表达式。

表达式描述：

java.io/File.{toPath,getPath,getAbsolutePath,getCanonicalPath,getCanonicalFile}()

匹配表达式指定了 java.io.File 类中的多个方法，包括 toPath、 getPath、 getAbsolutePath、 getCanonicalPath 和 getCanonicalFile。这些方法都与文件路径的获取有关。

Masks标签分析

<Masks revision="0">
    <mask:Mask builtin="true" name="Targeted">
        <mask:Exclusion>
            <mask:Attribute name="inputsource" value="Serialized Data" />
        </mask:Exclusion>
        <mask:Exclusion>
            <mask:Attribute name="inputsource" value="Windows Registry" />
        </mask:Exclusion>
    </mask:Mask>
    <mask:Mask builtin="true" default="true" name="Broad">
        <mask:Description>
            <![CDATA[此设置向源代码分析器提供了一套最全面的规则。通过它的使用可以发现一系列需要审核的安全问题。]]>
        </mask:Description>
    </mask:Mask>
    <mask:Mask builtin="true" name="Medium">
    </mask:Mask>
</Masks>

Mask：掩码，用于静态代码分析工具（如 Fortify SCA）来配置不同的分析规则集。

• <mask:Mask>： 元素定义了不同的分析规则集。

• builtin="true"： 表示这是一个预定义的掩码。

• name ：属性指定了掩码的名称。

• default="true" ：表示这是默认的掩码。

Localization 标签分析

<Localization>
  <Mapping>
    <KeyString>Weak Encryption</KeyString>
    <LocalString>Weak Encryption</LocalString>
  </Mapping>
  <Mapping>
    <KeyString>User-Controlled Key Size</KeyString>
    <LocalString>User-Controlled Key Size</LocalString>
  </Mapping>
</Localization>;

本地化配置，管理和翻译不同的字符串

• <Localization> 是根元素，包含多个映射（ <Mapping>）。

• <Mapping> 元素定义了键字符串（ <KeyString>）和本地化字符串（ <LocalString>）之间的对应关系。

参考

• SCACustRulesGuide23.2.0.pdf

• SCA_Cust_Rules_Guide_23.2.0.zip

• 2024.2.1.0003-zh_CN.zip

参考文件，已托管到知识星球，自取。

阅读原文

跳转微信打开

fortify sca rules 一直处于加密状态，只有在扫描的时候才会被加载，网上发现已经有大佬破解了，这里分享给大家，jar包知识星球自取，解密代码如下，自行编译即可：

import java.io.*;import java.nio.file.Files;import java.security.*;import java.util.Properties;import java.util.StringTokenizer;import java.util.zip.GZIPInputStream;import java.util.zip.GZIPOutputStream;
public class Main {    // 定义常量    private static final String MESSAGE_DIGEST_ALGORITHM = "SHA-1"; // 消息摘要算法    private static final String CRYPTO_PROVIDER = "SUN"; // 加密提供者    private static final int BUFFER_SIZE = 262144; // 缓冲区大小    private static final String STD = "1fea047f-dee0ac89-b5db25a6-b0c3a4cf"; // 默认密钥
    // 构造函数    public Main() {    }
    // 获取消息摘要算法实例    public static MessageDigest getMessageDigestAlgorithm() {        try {            return MessageDigest.getInstance(MESSAGE_DIGEST_ALGORITHM, CRYPTO_PROVIDER);        } catch (GeneralSecurityException e) {            throw new RuntimeException(e);        }    }
    // 计算输入流的摘要    public static byte[] makeDigest(InputStream inStream) throws IOException {        return makeDigest(inStream, getMessageDigestAlgorithm());    }
    // 计算输入流的摘要，使用指定的消息摘要算法    public static byte[] makeDigest(InputStream inStream, MessageDigest md) throws IOException {        md.reset();        DigestInputStream in = new DigestInputStream(inStream, md);        return md.digest(); // 返回摘要结果    }
    // 加密函数    private static void encrypt(long[] v, long[] k) {        long y = v[0];        long z = v[1];        long sum = 0L;        long delta = 2654435769L; // 常量 delta        long n = 32L; // 迭代次数        long top = 4294967295L; // 掩码
        // 加密循环        for (; n-- > 0L; z &= top) {            sum += delta;            sum &= top;            y += (z << 4) + k[0] ^ z + sum ^ (z >> 5) + k[1];            y &= top;            z += (y << 4) + k[2] ^ y + sum ^ (y >> 5) + k[3];        }
        v[0] = y;        v[1] = z;    }
    // 解密函数    private static void decrypt(long[] v, long[] k) {        long n = 32L; // 迭代次数        long y = v[0];        long z = v[1];        long delta = 2654435769L; // 常量 delta        long top = 4294967295L; // 掩码        long sum = delta << 5;
        // 解密循环        for (sum &= top; n-- > 0L; sum &= top) {            z -= (y << 4) + k[2] ^ y + sum ^ (y >> 5) + k[3];            z &= top;            y -= (z << 4) + k[0] ^ z + sum ^ (z >> 5) + k[1];            y &= top;            sum -= delta;        }
        v[0] = y;        v[1] = z;    }
    // 加密输入流到输出流    private static void enc(InputStream source, OutputStream dest, long[] usrKey) throws IOException {        long[] k = usrKey.clone(); // 克隆密钥        byte[] byteBuf = new byte[8]; // 字节缓冲区        byte[] tail = new byte[]{32, 32, 32, 32, 32, 32, 32, 8}; // 尾部字节        long[] unsigned32Buf = new long[2]; // 无符号32位缓冲区        long top = 4294967295L; // 掩码
        int bytesRead;        // 读取输入流并加密        while ((bytesRead = source.read(byteBuf)) != -1) {            if (bytesRead < 8) {                tail[7] = (byte) bytesRead; // 设置尾部字节            }
            byteArrayToUnsigned32(byteBuf, unsigned32Buf); // 字节数组转换为无符号32位数组            encrypt(unsigned32Buf, k); // 加密            k[0] = k[0] + 17L & top; // 更新密钥            k[1] = k[1] + 17L & top;            k[2] = k[2] + 17L & top;            k[3] = k[3] + 17L & top;            unsigned32ToByteArray(unsigned32Buf, byteBuf); // 无符号32位数组转换为字节数组            dest.write(byteBuf); // 写入输出流        }
        byteArrayToUnsigned32(tail, unsigned32Buf); // 处理尾部字节        encrypt(unsigned32Buf, k);        k[0] = k[0] + 17L & top;        k[1] = k[1] + 17L & top;        k[2] = k[2] + 17L & top;        k[3] = k[3] + 17L & top;        unsigned32ToByteArray(unsigned32Buf, tail);        dest.write(tail); // 写入尾部字节    }
    // 解密输入流到输出流    private static void dec(InputStream source, OutputStream dest, long[] usrKey) throws IOException {        long[] k = usrKey.clone(); // 克隆密钥        byte[] byteBuf = new byte[8]; // 字节缓冲区        byte[] byteBufDelay = null; // 延迟字节缓冲区        long[] unsigned32Buf = new long[2]; // 无符号32位缓冲区        long top = 4294967295L; // 掩码
        int bytesRead;        // 读取输入流并解密        while ((bytesRead = source.read(byteBuf)) != -1) {            if (bytesRead < 8) {                throw new IOException("invalid encrypted stream"); // 无效的加密流            }
            byteArrayToUnsigned32(byteBuf, unsigned32Buf); // 字节数组转换为无符号32位数组            decrypt(unsigned32Buf, k); // 解密            k[0] = k[0] + 17L & top; // 更新密钥            k[1] = k[1] + 17L & top;            k[2] = k[2] + 17L & top;            k[3] = k[3] + 17L & top;            unsigned32ToByteArray(unsigned32Buf, byteBuf); // 无符号32位数组转换为字节数组
            if (source.available() == 0) {                int bytesToWrite = byteBuf[7];                if (bytesToWrite > 8 || bytesToWrite < 0 || byteBufDelay == null) {                    throw new IOException("invalid encrypted stream"); // 无效的加密流                }
                dest.write(byteBufDelay, 0, bytesToWrite); // 写入延迟字节            }
            if (byteBufDelay != null) {                dest.write(byteBufDelay, 0, 8); // 写入延迟字节                byte[] t = byteBufDelay;                byteBufDelay = byteBuf;                byteBuf = t;            } else {                byteBufDelay = byteBuf;                byteBuf = new byte[8];            }        }    }
    // 执行块加密或解密    private static void doBlockCipher(InputStream source, OutputStream dest, boolean encrypt, long[] usrKey) throws IOException {        if (encrypt) {            enc(source, dest, usrKey); // 加密        } else {            dec(source, dest, usrKey); // 解密        }    }
    // 读取加密流中的头部信息    public static void readHeaders(InputStream encrypted) throws IOException {        Properties props = new Properties();        final PushbackInputStream src = new PushbackInputStream(encrypted);        props.load(new InputStream() {            boolean closed = false;
            public int read() throws IOException {                if (closed) {                    return -1;                } else {                    int c = src.read();                    if (c == 0) {                        src.unread(c);                        closed = true;                        return -1;                    } else {                        return c;                    }                }            }        });
        int read = src.read();        if (read != 0) {            throw new IOException("invalid encrypted stream"); // 无效的加密流        }    }
    // 解密并解压缩加密流中的数据    public static byte[] decryptCompressedAfterHeaders(InputStream encrypted, String keyString) throws IOException {        return decryptAfterHeaders(encrypted, keyString, true);    }
    // 解密加密流中的数据，可以选择是否解压缩    public static byte[] decryptAfterHeaders(InputStream encrypted, String keyString, boolean compressed) throws IOException {        long[] key = makeKeyFromString(keyString != null ? keyString : STD); // 生成密钥        ByteArrayOutputStream cleartext = new ByteArrayOutputStream();        doBlockCipher(encrypted, cleartext, false, key); // 解密        cleartext.close();        byte[] bytes = cleartext.toByteArray();        if (compressed) {            bytes = uncompressString(bytes); // 解压缩        }
        return bytes;    }
    // 解密并解压缩加密流中的数据    public static byte[] decryptCompressed(InputStream encrypted, String keyString) throws IOException {        readHeaders(encrypted); // 读取头部信息        return decryptCompressedAfterHeaders(encrypted, keyString);    }
    // 加密并压缩明文数据    public static void encryptAndCompress(InputStream cleartext, OutputStream ciphertext, String keyString, Properties properties) throws IOException {        if (properties != null) {            properties.store(ciphertext, null); // 存储属性        }
        ciphertext.write(new byte[]{0}); // 写入分隔符        encryptAfterHeaders(cleartext, ciphertext, keyString, true); // 加密并压缩    }
    // 加密明文数据，可以选择是否压缩    public static void encryptAfterHeaders(InputStream stream, OutputStream ciphertext, String keyString, boolean compress) throws IOException {        long[] key = makeKeyFromString(keyString != null ? keyString : STD); // 生成密钥        if (compress) {            stream = compressInputStream(stream); // 压缩输入流        }
        doBlockCipher(stream, ciphertext, true, key); // 加密        stream.close();    }
    // 从字符串生成密钥    private static long[] makeKeyFromString(String keyString) {        long[] k = new long[4];        String[] splitString = new String[4];        StringTokenizer st = new StringTokenizer(keyString, "-");
        int i;        for (i = 0; i < splitString.length; ++i) {            if (!st.hasMoreTokens()) {                throw new Error("invalid key"); // 无效的密钥            }
            splitString[i] = st.nextToken();        }
        for (i = 0; i < 4; ++i) {            try {                k[i] = Long.parseLong(splitString[i], 16); // 解析密钥            } catch (NumberFormatException e) {                throw new Error("invalid key"); // 无效的密钥            }        }
        return k;    }
    // 解压缩字节数组    private static byte[] uncompressString(byte[] in) throws IOException {        GZIPInputStream gis = new GZIPInputStream(new ByteArrayInputStream(in));        ByteArrayOutputStream out = new ByteArrayOutputStream();        int bufferSize = 10240;        byte[] buffer = new byte[bufferSize];
        while (true) {            int bytesRead = gis.read(buffer, 0, bufferSize);            if (bytesRead == -1) {                return out.toByteArray(); // 返回解压缩后的数据            }
            out.write(buffer, 0, bytesRead);        }    }
    // 压缩输入流    private static InputStream compressInputStream(InputStream in) throws IOException {        ByteArrayOutputStream baos = new ByteArrayOutputStream();        GZIPOutputStream gz = new GZIPOutputStream(baos);        int bufferSize = 10240;        byte[] buffer = new byte[bufferSize];        int var5 = 0;
        while (true) {            int bytesRead = in.read(buffer, 0, bufferSize);            if (bytesRead == -1) {                gz.close();                return new ByteArrayInputStream(baos.toByteArray()); // 返回压缩后的数据            }
            gz.write(buffer, 0, bytesRead);            var5 += bytesRead;        }    }
    // 字节数组转换为无符号32位数组    public static void byteArrayToUnsigned32(byte[] byteBuf, long[] unsigned32Buf) {        for (int i = 0; i < unsigned32Buf.length; ++i) {            unsigned32Buf[i] = ((long) byteBuf[i * 4] & 255L) + (((long) byteBuf[i * 4 + 1] & 255L) << 8) + (((long) byteBuf[i * 4 + 2] & 255L) << 16) + (((long) byteBuf[i * 4 + 3] & 255L) << 24);        }    }
    // 无符号32位数组转换为字节数组    public static void unsigned32ToByteArray(long[] unsigned32Buf, byte[] byteBuf) {        for (int i = 0; i < unsigned32Buf.length; ++i) {            long l = unsigned32Buf[i];            byteBuf[i * 4] = (byte) ((int) (l & 255L));            byteBuf[i * 4 + 1] = (byte) ((int) (l >> 8 & 255L));            byteBuf[i * 4 + 2] = (byte) ((int) (l >> 16 & 255L));            byteBuf[i * 4 + 3] = (byte) ((int) (l >> 24 & 255L));        }    }
    // 解密文件    public static void decryptFile(File src, File dst) throws Exception {        InputStream inputStream = Files.newInputStream(src.toPath());        byte[] rule = decryptCompressed(inputStream, null); // 解密并解压缩        OutputStream outputStream = Files.newOutputStream(dst.toPath());        outputStream.write(rule); // 写入解密后的数据        outputStream.close();    }
    // 主函数    public static void main(String[] args) throws Exception {        String rulesDir = "F:\\rules\\2024.2.1.0003-zh_CN\\rules";        String decryptDir = "F:\\rules\\2024.2.1.0003-zh_CN\\decrypt";        File file = new File(rulesDir);        if (file.isDirectory()) {            File[] files = file.listFiles();            for (File f : files) {                if (f.getName().endsWith(".bin")) {                    decryptFile(f, new File(decryptDir + "/" + f.getName() + ".xml")); // 解密文件                }            }        } else {            decryptFile(file, new File(decryptDir + "/" + file.getName() + ".xml")); // 解密文件        }    }}

阅读原文

跳转微信打开

提前声明，本文无焦虑营销、无卖课、无软文、无广告，单纯聊聊经济下行安全行业的现状，解答某个同学的问题，文章观点仅供参考。

今天在群里看到有师傅在讨论某企业为了降本增效干掉了自己的安全团队负责人，消息来源不可信，但是也能看出来安全行业在企业中的尴尬地位。没问题的时候在老板看来要你何用，出问题的时候同样会觉得要你何用，这都防不住。

干了这么多年安全，老板通常不在乎你的技战法、纵深防御，老板在乎的是在有限的资金支持下，尽可能降低网络安全风险，这就带给甲乙方人员严峻挑战。之前也有同学问过，自己刚入职参与一家甲方安全建设，有什么可以参考的资料没，我想了想，目前权威一点儿的书籍也就是《企业安全建设指南：金融行业安全架构与技术实践》，这本书内容不做解读，各位有空可以从知识星球自行下载电子版观看，也可以购买实体书阅读。

其实我想聊的是，对甲方安全人员来说，你得心里有谱，充分考虑当前现状，也就是现状调研，不能照搬乙方片子，乙方的片子主要是为了推销自家产品，与企业当前现状契合度没有那么高。先为企业把脉，看看在有限的资金支持下，优先来补全自己企业里的短板，没必要一上来就整那些高大上的东西，容易把自己拖垮。评估参考的方向有以下几点：

1、企业规模

不足百人的小公司，也没啥专业的安全团队，通常可能只有一两个运维或者压根没有，如果不是短而精的公司或者大集团的小公司（安全能力靠集团统一管控），重点对公司的网络、服务器进行管控，最好将服务器和办公网络进行划分，对网络进行监控，使用一些如panabit或者其他开源产品，对网络进行准入控制；使用一些如：jumpserver或者闭源堡垒机来控制服务器；如果涉及对外业务，可以部署一些开源或者社区版的waf，没必要裸奔；另外如果怕企业被入侵，可以部署一些蜜罐，不奢求反制，好歹做到被攻击了还能给自己提个醒。对于中大型公司，公司都有统一规划，个人服从公司统一安排就行，盯着自己的OKR，做好自己本职工作就行。

2、企业业务

不同行业其实安全建设的方向是不同的。举个简单的例子，金融行业安全运营的同学侧重在有限的预算下，优先满足监管单位的要求，满足要求下，多花一分钱都是罪过，除非对自己工作或者钱包有利。对于电力行业，虽说也有监管要求，但是保障业务稳定性是第一要义，网络和系统只要能稳定运行，就不会去动，除非你能拍着胸脯对领导说出了问题我负责。另外电力行业的网络尽可能做隔离，对比其他行业(笔者只是调研了发电网络，基于发电网络得出的观点)，网络的承载很低，设备吞吐很弱，但是网络有隔离，相对来说是安全的，做好终端管控，做好网络隔离，减少攻击面，降低整体安全风险。

3、当前安全建设现状

梳理当前企业安全建设都有哪些，重点梳理防护手段，安全人员数量，做到心里有数，判断当前安全建设是否合理，是否有可以迅速提升的建设方向，主要是经济实惠成熟稳定，要不后续乙方离场，留下一地鸡毛。另外不少建设方向是需要投入安全人员进行运营的，得考虑当前安全人员的数量及是否能满足运营能力。

4、安全预算

安全预算是很重要的，预算的多少，决定你当年或者明年的重点工作方向，举个简单的例子，预算充足，那就可以着重在保障公司的业务的上进行投入，在公司的短板上进行补齐。一定要清楚，设备是要钱的，乙方也是要钱的，如果没钱乙方销售可能连跟烟都不舍得招呼你，另外安装社区版或者开源平台的服务器也是要花钱的。以前在为企业规划SDL体系建设的时候，在调研的时候通常和安全团队聊的都是是否可以得到企业高层的支持，如果没有，对于那些安全团队可能会和其他团队产生冲突的制度规范就得慎重制定。

当前安全行业存在极端行径，工作内容复杂，行业不被理解，工作容易背锅等等情况，个人是无法改变当前现状的。笔者也是一个普通人，智商垫底，普通家庭，普通学校背景，普通工作背景，没有满满一页CVE编号PPT，也没有大佬悉心教导，这么多年也一点一滴走过来的。对于那些刚入行的同学，网安肯定不是一条康庄大道，但是山就在那里，如果决定前行，那就努力踏出一条路，相信未来也会有不一样的收获。

阅读原文

跳转微信打开

有研发的同学询问zip slip漏洞的修复，碰巧最近在批量找一些cms的zip slip漏洞，提供以下两种修复方式，仅供参考：

修复方式1

private static final int DEFAULT_BUFFER_SIZE = 8192;
public static void unzip(File zipFile, File destDir, String encoding) {        if (destDir.exists() && !destDir.isDirectory()) {            throw new IllegalArgumentException("destDir is not a directory!");        }        ZipFile zip = null;        InputStream is = null;        FileOutputStream fos = null;        File file;        String name;        byte[] buff = new byte[DEFAULT_BUFFER_SIZE];        int read;        ZipEntry entry;        try {            try {                if (StringUtils.isNotBlank(encoding)) {                    zip = new ZipFile(zipFile, encoding);                } else {                    zip = new ZipFile(zipFile);                }                Enumeration<?> en = zip.getEntries();                while (en.hasMoreElements()) {                    entry = (ZipEntry) en.nextElement();                    name = entry.getName();                    name = name.replace('/', File.separatorChar);                    // 防止zip包里面的使用`../..`之类的文件名，将文件解压到指定目录之外。                    name = name.replace("..", "");                    file = new File(destDir, name);                    if (entry.isDirectory()) {                        file.mkdirs();                    } else {                        // 创建父目录                        file.getParentFile().mkdirs();                        is = zip.getInputStream(entry);                        fos = new FileOutputStream(file);                        while ((read = is.read(buff)) > 0) {                            fos.write(buff, 0, read);                        }                        fos.close();                        is.close();                    }                }            } finally {                if (fos != null) {                    fos.close();                }                if (is != null) {                    is.close();                }                if (zip != null) {                    zip.close();                }            }        } catch (IOException e) {            e.printStackTrace();        }
    }

zip解压主要使用的是ant组件，依赖相关如下：

<dependency>    <groupId>org.apache.ant</groupId>    <artifactId>ant</artifactId>    <version>1.9.6</version></dependency><dependency>    <groupId>commons-io</groupId>    <artifactId>commons-io</artifactId>    <version>2.4</version></dependency><dependency>    <groupId>org.apache.commons</groupId>    <artifactId>commons-lang3</artifactId>    <version>3.4</version></dependency>

修复方式2

public static void unZipFiles(File zipFile,String descDir) throws IOException {    File pathFile = new File(descDir);    if (!pathFile.exists()) {        pathFile.mkdirs();    }    // 解决zip文件中有中文目录或者中文文件    ZipFile zip = new ZipFile(zipFile, Charset.forName("UTF-8"));    for (Enumeration entries = zip.entries(); entries.hasMoreElements();) {        ZipEntry entry = (ZipEntry) entries.nextElement();        String entryName = entry.getName();
        Pattern pattern = Pattern.compile("[^a-zA-Z0-9_\\-\\.]");        Matcher matcher = pattern.matcher(entryName);
        if(entryName.contains("../") || entryName.contains("..\\") || matcher.find()){            System.out.println("压缩包中文件名疑似不安全，详情： "+ entryName);            throw new IOException("压缩包中文件名疑似不安全，详情： "+ entryName);        }        InputStream in = zip.getInputStream(entry);        String outPath = Paths.get(descDir, entryName).toString().replaceAll("\\*", "/");        // 判断路径是否存在,不存在则创建文件路径        File file = new File(outPath.substring(0, outPath.lastIndexOf('/')));
        if (!file.exists()) {            file.mkdirs();        }        // 判断文件全路径是否为文件夹,如果是上面已经上传,不需要解压        if (new File(outPath).isDirectory()) {            continue;        }
        OutputStream out = new FileOutputStream(outPath);        byte[] buf1 = new byte[1024];        int len;        while ((len = in.read(buf1)) > 0) {            out.write(buf1, 0, len);        }        in.close();        out.close();    }    zip.close();}

修复方式2，代码直接使用java.util.zip，未使用第三方组件

另外Hutool也提供解压方法，Hutool在4.1.12之前的版本存在zip slip漏洞，这点需要注意。

阅读原文

跳转微信打开

AIGC安全评估

阅读原文

跳转微信打开

Uber—大型单体仓库的可持续部署 翻译稿

说明：文章来源uber 博客，笔者日常对DevSecOps相关内容进行研究和学习，今天看到这篇文章，忍不住与各位分享Uber在CD上面的建设经验，文章内容仅供参考，本文只是译稿，如果翻译不妥或者错误，请斧正。

内容原文地址：https://www.uber.com/en-HK/blog/continuous-deployment/

译文如下：

介绍

Uber的业务依赖于众多微服务。确保对所有这些服务的更改能够安全、及时地部署至关重要。通过利用持续部署自动化这一过程，我们确保新功能、库更新和安全补丁都能及时交付至生产环境，从而提高了服务业务的整体代码质量。

在本文中，我们将分享如何重新构想Uber的微服务持续部署，以改善部署自动化和微服务管理的用户体验，同时应对处理大规模单一代码库及其不断增加的提交量所带来的一些特殊挑战。

背景

在过去几年里，我们在成熟工具方面投入了大量资源，以适应业务的持续增长，并减少生产事件。随着代码输出的稳步增长，超过50%的生产事件直接由代码更改引起，我们能够在业务扩展过程中实现持续、安全的部署而不妨碍生产力，对于Uber的成功至关重要。

业界普遍认为[1][2]，代码的持续部署（CD）本质上降低了引入错误或缺陷的风险。这不仅仅是因为CD本身确保了及时修补漏洞和缺陷，更因为在工程师获得足够信心让机器自动部署代码之前，必须建立起最佳实践、文化和纪律。在启用CD之前，工程师通常会确保采用良好的工程实践，例如：

• 代码审查

• 持续集成（单元测试、集成测试和负载测试）

• 监测（持续监控和警报，自动回滚机制）

什么构成良好的代码审查、足够的单元/集成测试覆盖等，是一个有争议的话题，超出了本文的范围。

Uber拥有广泛的工程和开发工具平台（如Ballast、SLATE），支持工程师采用良好的实践。然而，历史上，存在多种部署流程，公司内部标准或最佳实践有限。随着我们最近将所有微服务迁移到内部云平台Up，我们发现了改善这一状况的机会。

在2022年启动该项目时，我们大约有：

• 4500个微服务分布在3个单一代码库（Go、Java和Web）

• 每周5600次提交，许多提交影响超过一个服务

• 每周7000次生产部署

• 34%为手动触发（完全没有使用CD）

• 7%的服务使用CD自动部署到生产环境

Uber的CD现状

CD在Uber并不是一个新学科。历史上，Uber的CD系统作为一个独立且单独的系统运行，采用了选择加入的方式，留给各个团队自行配置。

它具有高度的灵活性，并提供了在基于YAML的DSL中构建完全自定义CD管道的能力。由于这种灵活性，我们不可避免地产生了超过100种独特的管道模板用于部署微服务，除了运行一系列动作外，没有对测试、监控或其他操作进行强制执行。

图1：Uber旧版CD系统中的管道操作

因此，CD管道缺乏标准化阻碍了我们在全公司范围内提高部署安全性和可靠性的能力，这在Uber这样规模的微服务管理中风险巨大，因为每天都有大量更改投入生产。

除此之外，拥有两个独立的部署系统本身就是令人困惑和不理想的。因此，鉴于最近迁移到Up平台以及其成熟性和采用程度，我们决定逐步淘汰现有的CD系统，转而采用新的集成CD体验：Up CD。

目标

我们从零开始构建了一个CD系统，旨在以可重复和安全的方式持续应用更改，我们希望通过自动化部署来防止人为错误，整合现有的测试工具，并确保在更改应用过程中监控回归。

为此，Up CD 提供了：

• 标准化和自动化的生产部署

• 以安全性为核心，与Uber的可观察性和测试堆栈紧密集成

• 与Up平台紧密集成的CD体验，并默认启用

• 针对Uber工程师需求量身定制的UI/UX，支持基于单一代码库的开发

通过构建具备这些功能的CD系统，我们期望能够提高自动化的采用率，使更多服务能够自动部署到生产环境。此外，至关重要的是，在实现这一目标的同时，我们需要降低（或至少不增加）生产环境中的事件发生率。

设计自动化

为了实现我们的愿景，我们设定了设计最简化部署体验的目标。该系统应安全地推进每个服务的生产环境，以便在Git代码库的主分支上运行包含所有相关更改的构建。

图2：新CD系统的架构

在以下部分，我们将突出我们重新设计的CD系统中的一些重要原则。

简单的核心数据结构

正如Uber许多博客文章中所述，我们面临的一个挑战是单一代码库的规模。例如，到2024年时，我们的Go单一代码库每天会有超过1000次提交，并且是近3000个微服务的源，这些微服务都可能受到单次提交的影响。显然，为每次提交构建和部署库中的每个服务将极其低效。更重要的是，这样做也没有太大意义，因为大多数提交只会影响一小部分服务。通过代码库的Bazel图，可以计算出哪些服务的代码二进制文件实际受到了提交的影响。

考虑到这一点，我们确定虽然我们的CD系统必须理解Git代码库的整个历史，以确保提交按正确的顺序部署，但对于单个服务，我们可以并且应该大幅度缩小范围。通过将每个服务限定在实际更改了代码二进制文件的提交子集上，服务所有者也能更轻松地识别他们的服务在每次部署中实际采纳了哪些更改，而不必深入到庞大的单一代码库的Git日志中。

这使我们能够采用相对简单的数据结构，每个服务都会与历史中所有实际与之关联的提交相链接。如下图所示：

图3：服务与提交历史的映射

所有服务的统一提交流模型

为了实现这一点，我们决定利用Uber的Kafka消费者代理来消费一个Kafka主题，该主题会在提交推送到Git代码库时发出事件。每当发生这种情况时，会进行一个分析阶段，以将提交组织成适当的结构，并确定受提交影响（更改）的服务集合：

图4：统一的提交流程，从推送到服务处理

显然，对于每个受提交影响的服务，第一步是将其构建成可部署的容器镜像。随后，我们允许工程师自定义一系列与其服务相关的部署阶段。对于一个任意服务，单个提交的流程可能会如下图所示：

图5：统一的提交流程，从构建到部署

根据我们对之前高度可定制CD系统的经验，我们知道流程必须是有明确意见的。因此，我们决定各个阶段本身必须保持相对简单。配置选项主要限于门控条件，用户可以结合各种预定义的选项来表达在部署阶段开始之前必须满足的条件。这些条件可能包括：

• 提交是否在上一阶段中停留了所需的时间？

• 是否在用户定义的部署时间窗口内（例如，在团队的工作时间内）？

• 是否有其他操作正在为该服务运行（例如，手动触发的部署或自动水平扩展）？

• 是否有任何触发服务警报的情况，这会导致部署回滚？

每个阶段独立于其他阶段运行。对于每个阶段，最新的提交如果成功完成了上一阶段，并满足所有门控条件（如有），就会立即推进到下一个阶段。

为了实现这些机制，我们利用了Cadence，这是一个由Uber开发的开源工作流编排引擎。实现按需启动的构建和部署工作流非常简单。此外，我们将门控机制实现为工作流。每个部署阶段都有自己的门控工作流，该工作流定期运行以检查是否有提交通过了上一阶段。如果是这样，它会考虑门控条件，以确定是否现在应该触发部署。

直观的用户体验

为了确保我们设计的产品符合需求，我们进行了用户研究和调研，以了解工程师们在考虑现有工具和单一代码库规模时，实际需要什么样的CD系统。基于此，我们围绕服务的提交历史设计了用户体验，工程师可以轻松查看影响其服务的所有提交的完整列表，以及服务的当前状态。

鉴于单一代码库的提交量，即使是自动部署，也不可能（也不应该）将每个影响服务的提交都部署到生产阶段。为了简化对生产流量或其他被认为“有趣”的提交的理解，我们合并了中间提交，以提供更清晰的视图，解决了工程师的一个关键痛点。这意味着，如果发现给定生产部署存在问题，可以很容易地展开到之前的部署，以查看该部署对服务所做的确切更改。这个视图如何由服务级别的提交历史数据结构支撑应该是立刻显而易见的。

图6：提交历史的折叠视图，仅显示对服务当前状态相关的提交

当前世界状态通过提交历史左侧的“泳道”被简洁地呈现。每条泳道显示了在不同服务环境中部署的代码状态和历史。通过悬停在泳道上，可以获取有关该环境部署状态的详细信息。见下图：

图8：特定提交的历史记录，接着是当前状态和计划中的部署操作

紧密耦合

为了提高对自动化的信任和增加其采纳率，我们明确意识到必须提供统一且简化的部署体验；仅仅在部署系统上叠加一个独立的CD编排层是不够的。

我们构建的新CD系统不仅要独立运行，还要紧密耦合于Up，并关注其他操作，确保其行动不会让用户感到意外。例如，这意味着如果工程师在CD管道之外手动启动了生产环境的部署，那么CD用户界面将把这个部署纳入服务的提交历史中。此外，系统的内部状态会被更新，反映出提交（及其之前的任何内容）已经部署到目标环境中。

如果工程师构建了一个与服务不完全相关的提交（例如，从主分支的HEAD构建）并将其部署到服务中，那么这个提交也会被添加到内部状态中，从而确保CD视图始终能够正确表示实际情况，而不会误导用户，使他们能够正确理解服务的状态。

这是一个重要的战略决策，因为它允许从手动部署逐步过渡到CD，而不是采取全有或全无的方法。这也意味着每当工程师采取某些手动操作，例如缓解事故时，CD系统能够自动做出正确的响应（通常是避免做任何操作或暂停），根据情况进行处理。

发布后的观测

在这一部分，我们重点介绍了Up CD发布后的效果。

自动化采纳率的提高

在内部发布我们的CD体验后，我们开始看到行为上的显著变化。正如我们所希望的那样，工程师们开始接受它，我们看到了立即的采纳，且这种采纳率不断上升：具体来说，我们看到自动部署的服务数量在12个月内从不到10%增加到近70%。

随着服务部署的频率增加，归因于特定提交的错误也变得更容易，因为每次部署的提交数量减少了。

生产事故率未增加

尽管部署频率提高，我们高兴地发现生产事故的整体发生率并没有按比例增加。实际上，在CD采纳率上升的同一12个月期间，我们看到每1000次代码更改报告的事故数量减少了超过50%。

由于在实施过程中还有其他努力（将在另一篇博客文章中详细介绍），我们不能声称这是因果关系。然而，很明显，我们确实成功实现了让工程师自动将服务部署到生产环境中，而不会增加事故的频率或严重性。

新挑战

然而，我们也开始看到新的挑战。特别是，我们发现对许多服务共享的单一代码库进行更改的风险（例如，更改一个所有服务共享的公共RPC库）突然增加，因为这些更改会更快地部署到所有受影响的服务中（而且这些部署可能会并行发生）。这意味着，如果这样的更改引入了一个显著的错误，而在CI过程中没有被捕捉到，自动化可能会同时破坏许多服务。

通常，一些服务会有机制来检测问题并自动回滚部署，但不太可能每个服务都能自动检测到问题。

因此，我们引入了跨服务利用提交信号的功能，以便如果某些服务未能成功部署，提交将被视为有问题。

为了获得尽可能明确的信号，我们根据内部服务分级对有风险的跨领域提交进行分阶段部署。最初，Up CD将其部署到我们最不重要的服务组中，当这些服务中的足够百分比成功部署后，才会推进到下一个级别。如果大量服务开始出现问题，部署会被停止，并通知提交作者可能存在的问题。

通过这种部署策略，我们将此类有风险更改对客户的影响降到可接受的水平，并且同样重要的是，通过为特别有风险的更改提供额外的保护措施，增加了对自动化生产部署的信任。

关键指标

为了量化该项目的结果，我们总结了项目期间一些关键指标的变化，见下表：

结论

正如我们在前述部分详细说明的那样，我们重新设计的CD系统——Up CD，体现了我们在部署方法学中的战略转变，即将自动化作为核心原则。我们认为，这一转变对以更高的安全性和效率管理我们的复杂性和规模至关重要，将将代码交付到生产环境的负担从工程师转移到了自动化系统上。

阅读原文

跳转微信打开

Scorecard是一个自动化工具，用于评估开源项目的健康度。

SELECT date, score FROM `openssf.scorecardcron.scorecard-v2` WHERE repo.name="github.com/alibaba/fastjson" ORDER BY date ASC

# 获取最新的PARTITION_IDbq query --nouse_legacy_sql 'SELECT partition_id FROM openssf.scorecardcron.INFORMATION_SCHEMA.PARTITIONS WHERE table_name="scorecard-v2" AND partition_id!="__NULL__" ORDER BY partition_id DESC LIMIT 1'
# 提取到GCSbq extract --destination_format=NEWLINE_DELIMITED_JSON 'openssf:scorecardcron.scorecard-v2$<partition_id>' gs://bucket-name/filename-*.json

docker pull gcr.io/openssf/scorecard:stable

docker pull gcr.io/openssf/scorecard:v3.2.1

make build

export GITHUB_AUTH_TOKEN=<your access token>

scorecard --repo=<repo_url>

scorecard --repo=https://github.com/alibaba/fastjson

Starting [Token-Permissions]Starting [Signed-Releases]Starting [Packaging]Starting [Dangerous-Workflow]Starting [Contributors]Starting [Security-Policy]Starting [CI-Tests]Starting [SAST]Starting [License]Starting [Binary-Artifacts]Starting [CII-Best-Practices]Starting [Pinned-Dependencies]Starting [Code-Review]Starting [Fuzzing]Starting [Branch-Protection]Starting [Vulnerabilities]Starting [Dependency-Update-Tool]Starting [Maintained]Finished [Binary-Artifacts]Finished [CII-Best-Practices]Finished [Pinned-Dependencies]Finished [Vulnerabilities]Finished [Dependency-Update-Tool]Finished [Maintained]Finished [Code-Review]Finished [Fuzzing]Finished [Branch-Protection]Finished [Token-Permissions]Finished [Signed-Releases]Finished [Packaging]Finished [CI-Tests]Finished [SAST]Finished [License]Finished [Dangerous-Workflow]Finished [Contributors]Finished [Security-Policy]
RESULTS-------Aggregate score: 3.9 / 10
Check scores:|---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------||  SCORE  |          NAME          |             REASON             |                                               DOCUMENTATION/REMEDIATION                                               ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 10 / 10 | Binary-Artifacts       | no binaries found in the repo  | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#binary-artifacts       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | Branch-Protection      | branch protection not enabled  | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#branch-protection      ||         |                        | on development/release         |                                                                                                                       ||         |                        | branches                       |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | CI-Tests               | 0 out of 4 merged PRs          | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#ci-tests               ||         |                        | checked by a CI test -- score  |                                                                                                                       ||         |                        | normalized to 0                |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | CII-Best-Practices     | no effort to earn an OpenSSF   | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#cii-best-practices     ||         |                        | best practices badge detected  |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 1 / 10  | Code-Review            | Found 3/28 approved changesets | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#code-review            ||         |                        | -- score normalized to 1       |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 10 / 10 | Contributors           | project has 18 contributing    | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#contributors           ||         |                        | companies or organizations     |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 10 / 10 | Dangerous-Workflow     | no dangerous workflow patterns | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#dangerous-workflow     ||         |                        | detected                       |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 10 / 10 | Dependency-Update-Tool | update tool detected           | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#dependency-update-tool ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | Fuzzing                | project is not fuzzed          | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#fuzzing                ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 10 / 10 | License                | license file detected          | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#license                ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | Maintained             | 0 commit(s) and 0 issue        | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#maintained             ||         |                        | activity found in the last 90  |                                                                                                                       ||         |                        | days -- score normalized to 0  |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| ?       | Packaging              | packaging workflow not         | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#packaging              ||         |                        | detected                       |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | Pinned-Dependencies    | dependency not pinned by hash  | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#pinned-dependencies    ||         |                        | detected -- score normalized   |                                                                                                                       ||         |                        | to 0                           |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | SAST                   | SAST tool is not run on all    | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#sast                   ||         |                        | commits -- score normalized to |                                                                                                                       ||         |                        | 0                              |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 10 / 10 | Security-Policy        | security policy file detected  | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#security-policy        ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| ?       | Signed-Releases        | no releases found              | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#signed-releases        ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | Token-Permissions      | detected GitHub workflow       | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#token-permissions      ||         |                        | tokens with excessive          |                                                                                                                       ||         |                        | permissions                    |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|| 0 / 10  | Vulnerabilities        | 22 existing vulnerabilities    | https://github.com/ossf/scorecard/blob/a8eae2d833553e93021a22f5641661cb6ad3e24c/docs/checks.md#vulnerabilities        ||         |                        | detected                       |                                                                                                                       ||---------|------------------------|--------------------------------|-----------------------------------------------------------------------------------------------------------------------|

scorecard --repo=<repo_url> --checks <check1,check2>

scorecard --repo=https://github.com/ossf/scorecard --checks Code-Review,Maintained

scorecard --repo=<repo_url> --format sarif > results.sarifgh upload results.sarif

scorecard --repo=<repo_url> --format json --show-details > results.json

阅读原文

跳转微信打开

MinerU之Magic-PDF文档提取介绍

conda create -n mineru python=3.10conda activate mineru

pip install detectron2 --extra-index-url https://wheels.myhloli.com -i https://pypi.tuna.tsinghua.edu.cn/simple 

pip install magic-pdf[full]==0.6.2b1 -i https://pypi.tuna.tsinghua.edu.cn/simple

git clone https://www.modelscope.cn/wanderkid/PDF-Extract-Kit.git

cp magic-pdf.template.json ~/magic-pdf.json

{    "bucket_info":{        "bucket-name-1":["ak", "sk", "endpoint"],        "bucket-name-2":["ak", "sk", "endpoint"]    },    "models-dir":"/data/models",    "device-mode":"cuda",    "table-config": {        "is_table_recog_enable": false,        "max_time": 400    }}

magic-pdf pdf-command --pdf "pdf_path" --inside_model true

magic-pdf pdf-command --pdf "pdf_path" --model "model_json_path"

magic-pdf --help

image_writer = DiskReaderWriter(local_image_dir)image_dir = str(os.path.basename(local_image_dir))jso_useful_key = {"_pdf_type": "", "model_list": model_json}pipe = UNIPipe(pdf_bytes, jso_useful_key, image_writer)pipe.pipe_classify()pipe.pipe_parse()md_content = pipe.pipe_mk_markdown(image_dir, drop_mode="none")

s3pdf_cli = S3ReaderWriter(pdf_ak, pdf_sk, pdf_endpoint)image_dir = "s3://img_bucket/"s3image_cli = S3ReaderWriter(img_ak, img_sk, img_endpoint, parent_path=image_dir)pdf_bytes = s3pdf_cli.read(s3_pdf_path, mode=s3pdf_cli.MODE_BIN)jso_useful_key = {"_pdf_type": "", "model_list": model_json}pipe = UNIPipe(pdf_bytes, jso_useful_key, s3image_cli)pipe.pipe_classify()pipe.pipe_parse()md_content = pipe.pipe_mk_markdown(image_dir, drop_mode="none")

magic-pdf pdf-command --pdf ../PDF-Extract-Kit/inputs/18.4《信息安全技术\ \ 安全漏洞标识与描述规范》GB_T\ 28458-2012.pdf --inside_model true

pip install "numpy<2"

阅读原文

跳转微信打开

安全从业人员焦虑的几点看法

之前有看到不少安全公众号在营销焦虑，如同营销程序员35岁失业。由于信安或者整个IT行业都是不断迭代和更新的，当前流行的技术可能在几年以后就会被淘汰，所以要求IT人员需要全面发展，不断提升自身软实力。换另一个角度来分析，技术的不断淘汰，才能创造新的就业需求，提高IT人员的竞争力。

现在安全不好干，尤其是安全服务，原因有很多，包括经济下行，客户要求较高等等，其实我更想聊的一个现象是政策的导向，导致安全人员缺口较大，部分学生，跨行IT人员被拉到现场做值守，人肉盯设备，有问题按照流程及时上报就行，薪酬待遇还将就，导致了不少人员自以为安全行业也就这样简单，盯盯设备轻轻松松就能把钱赚了，殊不知，已错过了提升自己的最佳时间，能踏实学习的，有精力学习的也就大学毕业前后那几年。

前段时间和我领导聊网络安全相关的话题，领导问了一个问题，为什么现在网络安全能挣钱，而且越来越多的厂商加入进来，我回答是政策，领导认为是国产化，如果将国外成熟的产品配合市场化的打法，国内安全厂商，尤其是小厂商估计会被吃的连渣都剩不下来，现在大环境让安全从业人员的数量增多，如果国家的政策让你挣钱，钱会源源不断的涌来，如果不让你赚钱，吃进去的都会吐出来，比如教培，（这里只是举个例子，打击教培的原因有很多，这里不要硬杠）。个人感觉，当前IT或者信安行业由于国际环境和国内政策扶持，无论甲方还是乙方都是缺安全人员的，但是由于安全的属性，这个缺口或者安全相关的市场并不会特别大，对于一线安全人员，我个人的建议是找一个自己感兴趣的方向，先积累安全能力，综合发展个人软实力，对于大部分安全从业人员，待在甲方，基本上慢慢偏向安全运营、方案输出、监管合规之类的，待在乙方，基本上就是技术管理，项目经理之类的岗位，无论甲乙方，上升无非比拼的学历、能力、资质、关系等等，与其杞人忧天，还不如对比一下师傅们的差距，花一定的时间和精力去提升。

对于甲乙方安全人员，如果有进入金融、能源、政企的机会，就一定把握住，烟草就算了，99.99%都进不去，不做考虑，但是可以做烟草的项目，利润还是很可观的。对于安服仔，一定要想好自己的退路和职业规划。

提升的方式有很多，参加培训，考试认证，挑战不同技术方向，社区共享等等。如果有疑问可以在群里沟通，聆听一下各位师傅意见，我想你会收获不少。

考证方向的建议：CISSP/OSCP/CISA/PMP/CISP

其中国测的证书有一个就行，没啥含金量，其他的各位师傅看自身能力、精力和物力。

以上为个人观点，分享出来与各位共勉，内容仅供参考。

附一张cyber-security技能路线图 https://roadmap.sh/cyber-security

阅读原文

跳转微信打开

Nvtop-适用于NVIDIA、AMD和英特尔GPU的Linux任务监视器

写在最前：公众号一直是佛系运营的，有时候看到私信都超过一周了，由于超过平台限制时间，被禁止了，没法答复。这篇文章是一个水文，和公众号的内容不怎么相关，主要是应对一个网友提出的疑问，我在后台私信回答不了，也联系不上，就在这里单独写篇文章回复一下。如果遇到长时间未回复，可以加我微信私聊或者给我留言都行。

nvtop 命令是适用于 NVIDIA、AMD 和 Intel GPU（图形处理单元）的 Linux 用户的出色任务监视器。基于 ncurses（用于在终端中显示信息的全新 curses 库）的 GPU 状态查看器，可以像 top 命令或 htop 命令，可以高效地处理系统中的多个 GPU，并以 htop 格式显示有关它们的详细信息。

适用于以下 GPU：

• • 使用 amdgpu 驱动的 AMD GPU。

• • 使用 i915 Linux 驱动的英特尔显卡。

• • 使用 NVIDIA 驱动程序的 Nvidia GPU，从 GeForce 600、GeForce 800M 开始的任何后继产品都应该可以正常工作。

• • 高通的 Adreno GPU

• • Apple GPU（M 系列）

• • Ascend NVTOP 通过 DCMI API（版本 6.0.0）支持 Ascend（在 Altas 800 (910B) 上测试）。

安装

Ubuntu / Debian

如果发行的版本提供了 snap 命令，请按照 snap 安装过程 获取最新版本的 nvtop。

Ubuntu Impish (21.10)、Debian buster (stable) 或者更新版本

sudo apt install nvtop

Ubuntu PPA

一个 支持 Ubuntu 20.04、22.04 及更新版本 的 PPA 由 Martin Wimpress 提供，它提供了一个针对 NVIDIA、AMD 和英特尔启用的最新版本 nvtop。

sudo add-apt-repository ppa:flexiondotorg/nvtop
sudo apt install nvtop

旧版本

• • AMD 和英特尔依赖项

  sudo apt install libdrm-dev libsystemd-dev
  # Ubuntu 18.04
  sudo apt install libudev-dev

• • NVIDIA 依赖项

• • NVIDIA 驱动程序（参见 Ubuntu Wiki 或 Ubuntu PPA 或 Debian Wiki)

• • NVTOP 依赖项

• • CMake、ncurses 和 Git

sudo apt install cmake libncurses5-dev libncursesw5-dev git

• • NVTOP

• • 按照 NVTOP 构建命令进行操作。

Fedora / Red Hat / CentOS

一个独立的应用程序以 AppImage 的形式提供。

Fedora 36 及更新版本

sudo dnf install nvtop

Red Hat Enterprise Linux 8 和 9

sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E %{rhel}).noarch.rpm
sudo dnf install nvtop

CentOS Stream、Rocky Linux、AlmaLinux

sudo dnf install -y epel-release
sudo dnf install nvtop

Fedora / Red Hat / CentOS 的构建过程：

• • AMD 和英特尔依赖项

  sudo dnf install libdrm-devel systemd-devel

• • NVIDIA 依赖项

• • NVIDIA 驱动程序，nvml 库需要 CUDA（参见 RPM Fusion)

• • NVTOP 依赖项

• • CMake、ncurses、C++ 和 Git

sudo dnf install cmake ncurses-devel git gcc-c++

• • NVTOP

• • 按照 NVTOP 构建命令进行操作。

OpenSUSE

一个独立的应用程序以 AppImage 的形式提供。

OpenSUSE 的构建过程：

• • AMD 依赖项

  sudo zypper install libdrm-devel

• • NVIDIA 依赖项

• • NVIDIA 驱动程序（参见 SUSE 支持数据库)

• • NVTOP 依赖项

• • CMake、ncurses 和 Git

  sudo zypper install cmake ncurses-devel git

• • NVTOP

• • 按照 NVTOP 构建命令进行操作。

Arch Linux

sudo pacman -S nvtop

Gentoo

sudo layman -a guru && sudo emerge -av nvtop

AppImage

AppImage 是一个独立的应用程序。只需下载 AppImage，使其可执行并运行即可！

• • 转到 发布页面 并下载 nvtop-x86_64.AppImage

• # 转到下载位置 **路径可能因系统而异**
  cd $HOME/Downloads
  # 使 AppImage 可执行
  chmod u+x nvtop-x86_64.AppImage
  # 享受 nvtop
  ./nvtop-x86_64.AppImage

如果您好奇它是如何工作的，请访问 AppImage 网站。

Snap

snap install nvtop
# 添加在 nvtop 中杀死进程的功能
snap connect nvtop:process-control
# 添加检查 GPU 信息（风扇、PCIe、电源等）的功能
snap connect nvtop:hardware-observe
# AMDGPU 进程列表支持（读取 /proc/<pid>）
snap connect nvtop:system-observe
# 临时解决方法，以获取每个进程的 GPU 使用情况（读取 /proc/<pid>/fdinfo）
snap connect nvtop:kubernetes-support

使用

安装完成以后，在终端中直接输入nvtop命令，即可调用该工具

参考

• • https://github.com/Syllo/nvtop【nvtop github】

• • https://www.cyberciti.biz/hardware/nvtop-command-in-linux-to-monitor-nvidia-amd-intel-gpus/【nvtop command in linux to monitor nvidia amd intel gpus】

阅读原文

跳转微信打开

ollama是一个在本地启动并运行大型语言模型的框架。

curl -fsSL [https://ollama.com/install.sh](https://ollama.com/install.sh) | sh

#!/bin/bash# enable global accessexport OLLAMA_HOST=0.0.0.0
/usr/local/bin/ollama  serve

ollama run gemma:7b

FROM ./mistral-7b-v0.1.Q4_0.gguf

FROM ./mistral-7b-v0.1.Q4_0.ggufTEMPLATE "[INST] {{ .Prompt }} [/INST]"

ollama create example -f Modelfile

ollama run example "What is your favourite condiment?"

git clone https://github.com/ollama/ollama

git submodule initgit submodule update llm/llama.cpp

conda create -n ollama python=3.10conda activate ollamapip install -r llm/llama.cpp/requirements.txt

make -C llm/llama.cpp quantize

python llm/llama.cpp/convert.py ./model --outtype f16 --outfile converted.bin

python llm/llama.cpp/convert-hf-to-gguf.py /data/models/Qwen1.5-14B-Chat-GPTQ-Int8 --outtype q8_0 --outfile converted.bin

Loading model: Qwen1.5-14B-Chat-GPTQ-Int8gguf: This GGUF file is for Little Endian onlySet model parametersSet model tokenizerSpecial tokens have been added in the vocabulary, make sure the associated word embeddings are fine-tuned or trained.gguf: Adding 151387 merge(s).gguf: Setting special token type eos to 151643gguf: Setting special token type pad to 151643gguf: Setting special token type bos to 151643gguf: Setting chat_template to {% for message in messages %}{{'<|im_start|>' + message['role'] + '' + message['content'] + '<|im_end|>' + ''}}{% endfor %}{% if add_generation_prompt %}{{ '<|im_start|>assistant' }}{% endif %}Exporting model to 'converted.bin'gguf: loading model part 'model-00001-of-00005.safetensors'token_embd.weight, n_dims = 2, torch.float16 --> float16blk.0.attn_norm.weight, n_dims = 1, torch.float16 --> float32blk.0.ffn_down.bias, n_dims = 1, torch.float16 --> float32Can not map tensor 'model.layers.0.mlp.down_proj.g_idx'

gguf: loading model part 'model-00001-of-00008.safetensors'Traceback (most recent call last):  File "/data/project/qwen-ollama/ollama/llm/llama.cpp/convert-hf-to-gguf.py", line 1937, in <module>    main()  File "/data/project/qwen-ollama/ollama/llm/llama.cpp/convert-hf-to-gguf.py", line 1931, in main    model_instance.write()  File "/data/project/qwen-ollama/ollama/llm/llama.cpp/convert-hf-to-gguf.py", line 152, in write    self.write_tensors()  File "/data/project/qwen-ollama/ollama/llm/llama.cpp/convert-hf-to-gguf.py", line 113, in write_tensors    for name, data_torch in self.get_tensors():  File "/data/project/qwen-ollama/ollama/llm/llama.cpp/convert-hf-to-gguf.py", line 71, in get_tensors    ctx = cast(ContextManager[Any], safe_open(self.dir_model / part_name, framework="pt", device="cpu"))safetensors_rust.SafetensorError: Error while deserializing header: HeaderTooLarge

llm/llama.cpp/quantize converted.bin quantized.bin q4_0

llm/llama.cpp/quantize converted.bin qwen_v1.5_quantized_int8.bin q8_0

FROM qwen_v1.5_quantized_int8.binTEMPLATE "[INST] {{ .Prompt }} [/INST]"

ollama create example -f Modelfile

ollama create qwen1.5-int8 -f Modelfile

ollama run qwen1.5-int8 "who are you?"

curl http://192.168.3.199:11434/api/generate -d '{  "model": "qwen1.5-int8:latest",  "prompt": "Why is the sky blue?"}'

curl http://192.168.3.199:11434/api/generate -d '{  "model": "qwen1.5-int8:latest",  "prompt": "Why is the sky blue?",  "stream": false}'

阅读原文

跳转微信打开

解锁应用安全的未来:从ASOC到ASPM的演进

阅读原文

跳转微信打开

Go 模块库劫持 (repojacking) 介绍 from VulnCheck

背景

VulnCheck是一家漏洞情报初创公司，今天在浏览VulnCheck博客时发现一篇文章：Hijackable Go Module Repositories，对于Go 模块库劫持的漏洞原理讲解十分清晰明了，以下内容大部分来源于原文博客，个人只做整理，分析和总结。

VulnCheck 分析了 Go 模块生态系统，寻找其源代码存储库可能容易受到存储库劫持（repojacking）的模块。由于 GitHub 用户名更改，超过 9,000 个存储库容易受到重新劫持。VulnCheck 发现超过 6,000 个存储库由于帐户删除而容易受到重新劫持。这 15000 个存储库加起来支持超过 800000 个 Go 模块。

为什么 Go 特别容易受到存储库劫持（repojacking）

Go 模块生态系统是去中心化设计的，是独一无二的。其他打包系统（例如 Pypi 或 NPM）要求开发人员创建帐户才能上传其包。这使得软件包平台能够管理用户和内容。Go语言比较特殊，Go 开发人员通过将代码推送到 GitHub 等源代码控制平台来发布模块。然后任何人都可以从软件源获取 Go 模块和 pkg.go.dev 缓存模块的详细信息。这种去中心化使得 Go 模块存储库特别容易受到重新劫持。当模块作者更改其用户名或删除其帐户时，存储库就会变得容易受到攻击。此时，攻击者可以注册新未使用的用户名，复制模块存储库，并将新模块发布到 proxy.golang.org 和 go.pkg.dev 。GitHub 确实有一些针对重新劫持的保护措施，受欢迎的仓库命名空间回退功能可以防止任何仓库“在所有者的帐户被重命名或删除之前的一周内有超过100个克隆”的再劫持。这听起来可能很合理，但对于 Go 来说却不一定。Go 模块通常由 Module 镜像缓存，因此不需要与源存储库交互或从源存储库克隆。对于某些情况，在 GitHub 上托管了一个开源库，我们每天都使用它，并且有 170 多个星，但该存储库在上周只看到了 20 个克隆。基于此，100 个克隆的保护并不一定像 GitHub 想象的那么好。

寻找可劫持的 Go 模块

2023 年 6 月，Aquasec 发表了研究报告，指出数百万个可劫持的 GitHub 存储库。了解到 Go 特别容易受到这种攻击向量的影响，我们开始准确枚举有多少 Go 模块版本可能受到影响。模块版本是指一个模块及其所有版本。跟踪超过 2000 万个 Go 模块版本。它不完全是一个小数据集，但追踪可重复劫持模块的算法相对简单：

1. 1. 对于每个模块，从模块名称推断存储库 URL。例如， github.com/vulncheck-oss/go-exploit 是一个Go模块，其源代码托管在https://github.com/vulncheck-oss/go-exploit。

2. 2. 尝试连接到每个存储库。

3. 3. HTTP 301 响应表示用户名更改、存储库名称更改或两者兼而有之。出于我们的目的，我们验证了存储库名称是否相同（例如 go-exploit ），但用户名已更改。我们还验证了原始用户帐户（例如 vulncheck-oss ）不存在。这进一步消除了存储库传输之类的东西。通过所有这些步骤的存储库被认为可能容易受到重新劫持。

4. 4. HTTP 404 响应表明存储库不再存在。然后我们将查看用户名是否仍然存在。如果不是，那么这也可能容易受到重新劫持。

5. 5. HTTP 200 响应表明存储库不易受到攻击。

6. 6. 然后我们验证了潜在可劫持的存储库实际上在 go.pkg.dev 中有一个条目（您可以使用模块镜像缓存几乎所有内容，因此清除非 Go 模块内容非常重要）。剩下的就是大量可以被重新劫持的存储库（假设过去 7 天问题中的 100 个克隆不是问题）。我们的第一个发现是，由于用户名更改，超过 9,000 个 Go 模块 GitHub 存储库容易受到重新劫持。潜在的重新劫持会影响超过 500,000 个 Go 模块版本。为了确定存储库的受欢迎程度，我们获取了每个存储库的 GitHub 星数。我们以 0 到 1000 的桶形式绘制了结果。按星号分组的可劫持 Go 模块存储库统计图如下:

7. 

大多数存储库的星级为零。这些对于攻击者来说几乎没有价值。其余 3,000 个存储库的星级在 1 到 1000 之间。存储库对攻击者有价值的可能性随着星级的增加而增加，但仅靠星级并不能说明攻击有多有用。Go 生态系统中的实际使用很重要，因为利用依赖于开发人员更新到新模块。我们跟踪的另一个类别是可劫持的存储库，因为 GitHub 帐户已被删除。我们发现了超过 6,000 个此类存储库，最终影响了近 300,000 个模块版本。由于存储库已被删除，我们无法找到它们有多少颗星。攻击者必须依赖于查找使用模式 - 最终搜索代码的导入。

这是一个沉重的负担，但对于合适的攻击者来说是值得的。尽管如此，即使在野外找到用途也是不够的。最终，受害者将需要更新到攻击者的新模块，因为攻击者无法覆盖旧模块。因此，尽管威胁确实存在，但 Go 生态系统内的重新劫持对于攻击者来说并不是立竿见影的胜利。

结论

VulnCheck认为缓解重新劫持漏洞是 Go 或 GitHub 必须承担的任务，这个和禅道创始人王春生前段时间分享了一个开源协议在中国面临的 bug：开源软件许可协议通常会表明作者不对用户使用该开源软件所造成的任何问题负责，但是，这种条款，在中国，是违法的观点类似。这个观点博主不做置评，对于重劫持漏洞，博主个人观点则认为github只是一个代码托管的平台，应提供更为灵活的重劫持保护措施，责任方应由go官方来负责和承担。在那之前，Go 开发人员应了解他们使用的模块以及这些模块源自的存储库的状态非常重要。

参考

• • https://vulncheck.com/blog/go-repojacking【go-repojacking】

阅读原文

跳转微信打开

使用codeshell进行代码安全评估

背景

北京大学软件工程国家工程研究中心知识计算实验室联合四川天府银行AI实验室，正式开源70亿参数的代码大模型CodeShell，成为同等规模最强代码基座。与此同时，团队将软件开发代码助手的完整解决方案全部开源，人手一个本地化轻量化的智能代码助手的时代已经来临！

CodeShell代码：https://github.com/WisdomShell/codeshell
CodeShell基座模型：https://huggingface.co/WisdomShell/CodeShell-7B
代码助手VSCode插件：https://github.com/WisdomShell/codeshell-vscode

目前拥有以下优势：

• • 强大的性能：CodelShell在HumanEval和MBPP上达到了7B代码基座大模型的最优性能

• • 完整的体系：除了代码大模型，同时开源IDE（VS Code与JetBrains）插件，形成开源的全栈技术体系

• • 轻量化部署：支持本地C++部署，提供轻量快速的本地化软件开发助手解决方案

• • 全面的评测：提供支持完整项目上下文、覆盖代码生成、代码缺陷检测与修复、测试用例生成等常见软件开发活动的多任务评测体系（即将开源）

• • 高效的训练：基于高效的数据治理体系，CodeShell在完全冷启动情况下，只训练了五千亿Token即获得了优异的性能

安全狗，重点关注安全检测功能。codeshell号称可以检测代码中的潜在安全风险，如可能出现的SQL注入、跨站脚本攻击等，帮助排查安全性风险。对代码进行深入分析，检测潜在的错误、冗余代码和性能瓶颈，并为开发者提供相应的修复建议；基于代码逻辑，自动创建测试用例，以辅助进行代码测试和验证，确保代码的正确性和稳定性。

准备

获取模型 我这里选取的是CodeShell-7B-Chat，如果资源不够，可以采用量化模型。

git clone https://huggingface.co/WisdomShell/CodeShell-7B-Chat

安装

首先克隆项目

git clone https://github.com/WisdomShell/codeshell
cd codeshell
conda create -n codeshell python=3.10
conda activate codeshell
pip install requirements.txt

昨天作者遗漏requirements.txt，作者响应很及时，很快就补上了，如果需要评估web demo，还需要另外安装依赖

pip install demos/requirements_web_demo.txt

个人环境还缺乏部分依赖，手动安装就行，灵活处理。

pip install bitsandbytes

运行

python web_demo.py --server-port=80 --server-name=0.0.0.0 -c /data/models/CodeShell-7B-Chat 

正常加载demo

注意：我这里使用显卡为3090ti，显存为24G，运行全量模型占用显存大约16G，仅供参考。

错误：

ImportError: Using low_cpu_mem_usage=True or a device_map requires Accelerate: pip install accelerate

手动安装

pip install accelerate 

torch.cuda.OutOfMemoryError: CUDA out of memory.

换模型或者换显卡资源

评估

prompt参考：

检查以下java代码，是否存在安全性问题,请给出优化建议:

评估代码片段为：

package com.suyu.secexample.rce.controller;
import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
@Controller
public class rcecontroller {
    @RequestMapping("/rce")
    public String input(){
        return "rce/rce";
    }
    @PostMapping("/rceoutput")
    public String index(@RequestParam("command") String command, Model model){
        if(command=="" | command==null){
            command= "whoami";
        }
        Process p = null;
        String result = null;
        try {
            p = Runtime.getRuntime().exec(command);
        } catch (IOException e) {
            e.printStackTrace();
        }
        InputStream is = p.getInputStream();
        BufferedReader reader = new BufferedReader(new InputStreamReader(is));
        String s = null;
        while (true) {
            try {
                if (!((s = reader.readLine()) != null)) break;
            } catch (IOException e) {
                e.printStackTrace();
            }
            result = s;
        }
        model.addAttribute("result",result);
        return "rce/rceoutput";
    }
}