应用安全供应链安全漏洞扫描开发工具【免费下载链接】DependencyCheckOWASP dependency-check is a software composition analysis utility that detects publicly disclosed vulnerabilities in application dependencies.项目地址https://gitcode.com/GitHub_Trending/dep/DependencyCheck点击查看免费下载本文以 OWASP dependency-check 的 Assembly Analyzer程序集分析器为核心系统讲解它如何扫描 .NET 的 DLL/EXE 文件、从程序集元数据中提取 vendor/product/version 三类证据evidence以及这些证据如何为后续的 CPECommon Platform Enumeration匹配和漏洞识别提供支撑。读完本文你将掌握 Assembly Analyzer 的运行前置条件、源码级工作原理、证据置信度规则、相关配置项以及验证方法可以直接指导你在实际项目中配置和使用这一分析器。什么是 Assembly AnalyzerOWASP dependency-check 是开源的软件成分分析SCA工具它内置了一组分析器analyzer来从不同技术栈的依赖文件中提取可识别的信息。其中Assembly Analyzer 专门面向 .NET 程序集它扫描 .NET 的 dll 和 exe 文件尽可能多地收集这些文件携带的元数据信息。在 dependency-check 内部这些收集到的信息被称为证据evidence并被归入三类桶vendor厂商通常来自程序集的公司名称、产品名、命名空间等product产品通常来自产品名、文件描述、内部名称等version版本通常来自产品版本号与文件版本号。这些证据在完成信息收集后会被后续的 CPEAnalyzer 等分析器用来匹配适用的 CPE 标识符从而定位公开披露的安全漏洞。也就是说Assembly Analyzer 处在信息收集阶段INFORMATION_COLLECTION它本身不直接判定漏洞而是为漏洞判定提供高质量的原料。从源码定义来看AssemblyAnalyzer.java分析器名称Assembly Analyzer分析阶段AnalysisPhase.INFORMATION_COLLECTION依赖生态Ecosystem.DOTNET即dotnet支持的文件扩展名dll、exe。运行前置条件.NET 8 运行时运行 Assembly Analyzer 需要在本机安装 .NET Core 8.x运行时或 SDK这是官方文档明确标注的硬性要求。其原因是Assembly Analyzer 并不直接解析 PE 文件而是将打包在依赖包中的GrokAssembly.dll解压到临时目录然后通过dotnet GrokAssembly.dll 目标文件这样的子进程方式调用 .NET 运行时来完成程序集元数据的解析。因此若环境中没有可用的dotnet可执行文件分析器在初始化阶段会直接自动禁用自身日志中会输出类似.NET Assembly Analyzer could not be initialized...的错误并提示需要安装 dotnet 8.0 core runtime 或 SDK这种自动禁用是有意设计对于没有 .NET 依赖的扫描任务缺少 dotnet 并不影响整体扫描只有真正扫描 DLL/EXE 时才需要它。从 AssemblyAnalyzer.prepareFileTypeAnalyzer() 的初始化逻辑可以看到完整的禁用判断链路将资源中的GrokAssembly.zip解压到临时目录得到GrokAssembly.dll构建调用参数列表下文详述若无法构建参数列表找不到 dotnet记录错误并setEnabled(false)若参数构建成功则先裸跑一次GrokAssembly.dll做自检若进程退出码不是 1 或有错误输出同样视为初始化失败并禁用分析器同时抛出InitializationException其消息为Could not execute .NET AssemblyAnalyzer, is the dotnet 8.0 runtime or sdk installed?。在 AssemblyAnalyzerTest 中有一个专门针对该场景的测试testWithSettingMono当把 dotnet 路径指向一个不存在的可执行文件测试中用/yooser/bine/mono模拟时prepare会抛出InitializationException且错误消息与上文一致。这验证了找不到可用的 dotnet 8 运行时即初始化失败的行为。扫描的文件类型EXE 与 DLLAssembly Analyzer 通过文件过滤器FileFilter匹配待扫描文件支持的扩展名.dll与.exe过滤器由 FileFilterBuilder 构建定义于 AssemblyAnalyzer.java 的SUPPORTED_EXTENSIONS与FILTER字段。需要注意扩展名匹配只是入口条件即使文件扩展名是.dll或.exe如果它并不是合法的 .NET 程序集GrokAssembly 会返回退出码 3AssemblyAnalyzer 将跳过该文件并输出 debug 级日志{} is not a .NET assembly or executable...见 analyzeDependency()。因此非托管 DLL、原生 EXE 或损坏的二进制文件不会导致扫描报错只会被静默跳过。工作原理GrokAssembly 子进程调用链Assembly Analyzer 的工作流程可以概括为外部工具解析 内部证据建模两个阶段。阶段一提取并调用 GrokAssembly在prepareFileTypeAnalyzer中分析器通过 extractGrokAssembly() 从 classpath 资源GrokAssembly.zip中解压出GrokAssembly.dll这是一个随 dependency-check-core 打包分发的 .NET 辅助工具放入临时目录。随后buildArgumentList() 决定实际调用的命令若配置了analyzer.assembly.dotnet.path则以该路径作为可执行文件否则调用isDotnetPath()探测 PATH 中是否存在dotnet通过执行dotnet --info判断找到 dotnet 后参数列表为dotnet GrokAssembly.dll 路径分析阶段再追加目标文件路径最终以ProcessBuilder启动子进程。阶段二解析 XML 输出并建模GrokAssembly 执行后会输出 XML 格式的程序集元数据由 GrokAssemblyProcessor 配合 ProcessReader 读取子进程输出并交给 GrokParser 解析。GrokParser是严格的校验型 SAX 解析器使用随包携带的 XSD 模式schema/grok-assembly.1.0.xsd对输出做校验通过XmlUtils.buildSecureValidatingXmlReader构建安全校验阅读器内容处理器为GrokHandler解析结果封装为 AssemblyData 对象。AssemblyData是 GrokAssembly 输出信息的领域模型字段包括companyName公司名、productName产品名、productVersion产品版本、fileVersion文件版本、fileDescription文件描述、comments注释、internalName内部名称、originalFilename原始文件名、legalCopyright版权信息、legalTrademarks商标信息、fullName程序集全名以及namespaces程序集内命名空间列表。同时它还携带error和warning两个字段用于表达 GrokAssembly 处理过程中产生的错误与警告。子进程退出码的语义在 analyzeDependency() 中AssemblyAnalyzer 对 GrokAssembly 的退出码做了分类处理退出码含义处理方式0解析成功使用返回的AssemblyData更新依赖3目标不是 .NET 程序集/可执行文件debug 日志后跳过该文件其他非 0 值GrokAssembly 内部异常debug 日志后跳过不中断扫描若AssemblyData中携带error字段则会抛出AnalysisException将该错误提升为扫描失败若有warning例如无法获取命名空间则仅记录 debug 日志不阻断流程。此外analyzeDependency开头会先校验目标文件是否存在不存在时抛出AnalysisException测试 testNonexistent 验证了该行为。证据提取与置信度规则Assembly Analyzer 的核心价值在于把 .NET 程序集的元数据转换成结构化证据。在 updateDependency() 中可以看到每条证据的来源source、键名key与置信度Confidence的完整映射这是理解该分析器判定逻辑的关键。VERSION 证据来源键置信度grokassemblyProductVersionHIGHESTgrokassemblyFileVersionHIGHAssemblyAnalyzerFilteredVersionHIGHEST当 FileVersion 与 ProductVersion 存在共同前缀且前缀可解析为合法版本时VENDOR 证据来源键置信度grokassemblyCompanyNameHIGHESTgrokassemblyProductNameMEDIUMgrokassemblyFileDescriptionLOWgrokassemblyInternalNameLOWgrokassemblyOriginalFilenameLOWdllnamespaceHIGHEST当命名空间与描述/公司名/产品名等文本匹配时PRODUCT 证据来源键置信度grokassemblyProductNameHIGHESTgrokassemblyFileDescriptionHIGHgrokassemblyInternalNameMEDIUMgrokassemblyOriginalFilenameMEDIUMgrokassemblyCompanyNameLOWdllnamespaceHIGHEST匹配时命名空间的交叉印证机制值得注意的亮点是 addMatchingValues()它会将AssemblyData中的命名空间列表与描述、公司名、产品名、内部名称等文本进行大小写不敏感的匹配一旦某个命名空间片段如Azure.Core以完整词形式出现在这些文本中就会以HIGHEST 置信度添加一条 vendor 或 product 证据。其设计意图很明确——当元数据字段与程序集真实命名空间互相印证时可信度最高。testAzureIdentity测试AssemblyAnalyzerTest完整验证了上述证据映射针对一个模拟的 Azure.Identity 程序集断言了 VERSION、PRODUCT、VENDOR 三组证据的精确集合以及依赖名称Azure.Identity、版本1.7.0、描述、软件标识符pkg:generic/Azure.Identity1.7.0和生态dotnet的最终结果。版本判定与依赖信息组装在生成证据之后AssemblyAnalyzer 还会进一步裁定依赖的最终名称与版本版本裁定顺序公共前缀优先若FileVersion与ProductVersion有共同前缀例如1.7.0与1.700.22.46903的前缀1.7且该前缀可解析为包含至少 3 段的版本则直接以FilteredVersion作为依赖版本HIGHEST 置信度。这正是testAzureIdentity中依赖版本被裁定为1.7.0的原因——ProductVersion为1.7.03627e3...FileVersion为1.700.22.46903二者通过公共前缀和版本解析规则收敛到1.7.0互相包含若两个版本字符串一方以另一方开头则取较长者回退优先使用ProductVersion其次使用FileVersion均需能通过 DependencyVersionUtil.parseVersion 解析。名称与描述裁定依赖名称优先来自文件名与InternalName/OriginalFilename的匹配忽略大小写并自动剥离扩展名依赖描述由fileDescription、comments、legalCopyright、legalTrademarks拼接而成各项之间以空行/换行分隔名称和版本都确定后会生成pkg:generic/nameversion形式的 Package URL 软件标识符PurlIdentifier置信度 MEDIUM若 PackageURL 构造失败则回退为GenericIdentifier。最终依赖的生态系统ecosystem被固定设置为dotnet供后续分析器与报告系统识别。相关配置项Assembly Analyzer 的可配置项定义在 Settings.KEYS 中默认值位于 dependencycheck.properties配置键默认值说明analyzer.assembly.enabledtrue是否启用 Assembly Analyzeranalyzer.assembly.dotnet.path空自动探测 PATHdotnet 可执行文件的显式路径典型使用场景禁用当扫描目标中不含 .NET 组件或环境中无法安装 .NET 8 时可显式设置analyzer.assembly.enabledfalse以消除初始化告警CLI 测试资源 sample2.properties 展示了该用法显式指定 dotnet 路径当 dotnet 不在 PATH 中例如 Docker 镜像里安装在非标准位置时通过-Danalyzer.assembly.dotnet.path/usr/bin/dotnet传入。Dockerfile 正是这样做的它通过JAVA_OPTS将/usr/bin/dotnet显式注入到分析器的探测逻辑中。配置方式取决于使用入口CLI 可通过-D系统属性、sample.properties属性文件或环境变量注入Maven/Gradle 插件则有各自的配置节点原理均为向上述设置键赋值。如何验证分析器是否正常工作仓库提供了两类可直接参考的验证途径单元测试AssemblyAnalyzerTest 覆盖了testAnalysis直接对打包的GrokAssembly.dll自身做分析断言可提取出CompanyNameOWASP ContributorsHIGHEST与ProductNameGrokAssemblyHIGHESTtestLog4Net使用测试资源log4net.dll断言提取出FileVersion1.2.13.0、公司名The Apache Software Foundation、产品名log4net并最终将依赖命名为log4net、版本为1.2.13.0——这是证据 → CPE 匹配 → 漏洞报告链路最直观的前置验证testAzureIdentity验证复杂版本号带 build metadata 的1.7.0...与文件版本1.700.22.46903的裁决逻辑testNonexistent验证文件不存在时的异常行为。这些测试在运行时都会做 dotnet 可用性假设assumeTrue(analyzer.buildArgumentList() ! null)即没有安装 .NET 8 时相关测试会自动跳过与生产环境的行为保持一致。实际扫描在配置好 .NET 8 环境后直接对含 DLL 的项目目录运行 dependency-check如dependency-check.sh --scan 项目目录 --format HTML然后在生成的报告中查看依赖列表若 .NET 依赖的名称、版本与厂商信息正确出现且漏洞条目能够关联到对应 CPE即说明 Assembly Analyzer 工作正常。常见问题排查现象 1日志提示.NET Assembly Analyzer could not be initialized原因analyzer.assembly.dotnet.path未配置且 PATH 中找不到dotnet或dotnet --info执行失败。解决方法安装 .NET 8 SDK/运行时或通过analyzer.assembly.dotnet.path显式指定路径。现象 2扫描包含 DLL 但没有产生任何 .NET 依赖信息可能原因目标 DLL 不是托管程序集GrokAssembly 返回退出码 3被静默跳过或 GrokAssembly 初始化自检失败导致分析器被自动禁用。可通过开启 debug 日志观察对应is not a .NET assembly或GrokAssembly.dll is not working properly日志。现象 3版本号出现怪异值如1.700.22.46903这是正常的FileVersion 是 .NET 编译产物的内部版本可能含四段数字Assembly Analyzer 会尝试与 ProductVersion 求公共前缀来收敛到语义化版本若无法收敛则会回退采用 ProductVersion 或 FileVersion 本身。小结Assembly Analyzer 是 dependency-check 面向 .NET 生态的信息收集枢纽它以dll/exe为入口借助内置的 GrokAssembly 工具与 .NET 8 运行时解析程序集元数据将公司名、产品名、版本号、命名空间等信息沉淀为带置信度等级的 vendor/product/version 三类证据并通过公共前缀算法、命名空间交叉印证等机制提升识别质量最终为 CPE 匹配与漏洞报告提供可靠输入。理解它的证据模型与配置项是准确解读 .NET 依赖扫描结果、排查漏报/误报的第一步。赞分享应用安全供应链安全漏洞扫描开发工具【免费下载链接】DependencyCheckOWASP dependency-check is a software composition analysis utility that detects publicly disclosed vulnerabilities in application dependencies.项目地址https://gitcode.com/GitHub_Trending/dep/DependencyCheck点击查看免费下载相关推荐用 baoyu-slide-deck 打造 Sketch Notes 手绘风幻灯片设计规范、调色板与完整配置指南用 baoyu slide deck 打造 Sketch Notes 手绘风幻灯片设计规范、调色板与完整配置指南 Sketch Notes视觉笔记风格是应用安全供应链安全漏洞扫描开发工具VCTK 多说话人语音合成实战基于 fairseq S² 工具包的 Transformer TTS 全流程指南VCTK 多说话人语音合成实战基于 fairseq S² 工具包的 Transformer TTS 全流程指南 VCTK 是 open 的多说话人英语语音语料应用安全供应链安全漏洞扫描开发工具大麦网自动化抢票终极指南告别手速焦虑的完整解决方案大麦网自动化抢票终极指南告别手速焦虑的完整解决方案 还在为抢不到热门演唱会门票而烦恼吗当心仪演出的门票在几秒钟内售罄时手动抢票的成功率几乎为零。大麦网自动GUI 自动化RPA上一篇三步上手 OpenDocMan一个新手也能搞定的 PHP 文档管理系统下一篇QQ空间说说导出免费3步把全部历史说说和评论完整归档到本地创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
