一、概述
SCA全称 Software Compostition Analysis，译为软件成分分析，即通过分析软件源码提取项目依赖的第三方组件及其版本、许可证、模块、框架和库等信息，生成软件物料清单（SBOM，Software Bill-of-Materials），根据SBOM分析项目是否使用了存在已知漏洞的组件，后期其它组件爆出漏洞时可根据SBOM快速排查受影响项目。解决针对开源软件的漏洞扫描、检测和管理问题。
二、概要分析
国内趋势
开源技术的应用极大的推动了大数据、云计算等各行业领域的快速发展。2021年3月12日,开源被明确列入《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》,支持数字技术开源社区等创新联合体发展,完善开源知识产权和法律体系,鼓励企业开放软件源代码、硬件设计和应用服务。
需求分析
首先，在企业应用多语言软件开发过程中，引入的开源代码和组件可能会含有漏洞，企业需保证软件安全性。原本采用开源软件就是为了降本增效，避免软件厂商的束缚，若因安全问题导致损失则得不偿失。再者，开源社区大部分都没有管理开源软件项目流程，而是公开由参与者共同维护，及其容易被恶意利用。
云原生下，开源软件中的漏洞容易遭到利用，扩大攻击面至整个软件供应链组成部分，由此影响至其他应用此软件供应链的项目。随着DevSecOps发展，SCA也是CI/CD流水线集成必须应用的工具。
此外，有效避免还有数据泄漏、知识产权或法律纠纷。
难点分析
☆特征：对于二进制或者代码片段提取到的特征的检测，目前二进制SCA能力上还有待突破，代码级SCA国内已有多种选择；
漏报：例如很多时候待测程序没有直接使用log4j，但是log4j可能被其他组件间接调用，没有完整的调用链分析，导致SCA漏报；
误报：因为SCA本身基于漏洞库检测的机制，一旦有漏洞组件被引入项目，即使漏洞并未被触发，且某些漏洞有及其复杂的触发条件，SCA都会报告。但有组件有的时候不得不用，那就对SCA提出了新的要求：在客户环境中针对性判断漏洞是否会触发、触发条件、触发可能性、高中低危等；
策略配置：需要有综合性的因素来组织策略，如上所述，不能仅靠漏洞高中低级别来配置封禁策略；
实际落地：①SCA要高效衔接企业内部开发流程，不能影响原开发流程及计划
②大规模开源组件的使用管理，加大对安全部门的负荷
③检测报告需要全面，因为需面对不同专业对象
可用性分析
兼容性要求：SCA工具需较大的开发量实现语言种类的覆盖，需支持多格式语言源码/多格式二进制；比如说Java，GO、Python、NodeJs；对于以上几种语言，可以通过分析pom.xml、go.mod、requirements.txt、yarn.lock等文件中的关键字段实现软件成分分析；
漏洞关联要求：SCA的各种漏洞信息来自于多种渠道，包括：NVD, CNVD, CNNVD, SCMs（如Github, Gitlab, Bitbucket等）, 还有来自流行库上的公共提交，如Bugzilla和Confluence等漏洞追踪器。还需关注漏洞信息更新的及时性，持续优化。
易用性要求：SCA需轻量化嵌入DevSecOps内，若能与黄金管道中的SAST/DAST/IAST测试过程集成，使得CI/CD更平滑，那么SCA的易用性是极高的；
三、主要功能
漏洞管理：首先SCA本身需要有漏洞及配置扫描的功能，且漏洞库是否完整（完整是一个相对概念，部分厂家维护着自己的漏洞库），识别出的开源组件指纹是否能与漏洞库进行关联。
开源组件/许可证识别及管理：主要的几种方式有，源码包管理器内的依赖配置文件、基于哈希指纹匹配C/C++代码、代码片段克隆扫描、二进制/APK扫描、容器扫描；
SBOM清单：通过SAC扫描生成，其中含基本信息：组件/库相关信息（名称、厂家、版本、许可证日期等）、漏洞信息（编号、类型、等级、影响组件修复建议等）、许可证信息（名称、链接、授权范围、合规性）
修复建议：因开发人员不是专门的安全人员，所以修复时需要有专业的建议；除了加速漏洞修复和应用上线时间外，参考建议可实现根级别修复，包括兼容性分析；
eg：log4j的真正漏洞代码出现在log4j-core的子组件。修复其他组件不一定能有效消除漏洞。很多产品都产生了误报的行为，让客户白忙一场。CNVD-2021-95914真实影响的是log4j-core这个组件，但由于log4j的<group_id>org.apache.logging.log4j</group_id>下有很多组件，如log4j-api, log4j-slf4j-impl等。但市面上部分SCA系统中，部分厂商会错误的把单独出现的非log4j-core的组件，比如log4j-api标为有CNVD-2021-95914漏洞，这会给修复工作制造噪音。
5.合规管理：SCA自带许可和策略管理系统，可以基于扫描到的信息（例如：数据库使用年限、许可证使用限制条款等），匹配用户需求（阻止项目违规开发、提前进入修复进程），进行相应的策略配置；
四、技术原理
SCA 的目标是第三方基础组件/可执行程序/源代码等类型的以二进制形式存储的文件，包括但不限于源代码片段或 Package，可执行的二进制组件/程序，基础 lib，tar/tgz 压缩文件，镜像/镜像层，广义的软件构建过程等等。因此，所有以二进制形式存储的文件皆可以是其分析目标。通过对软件汇编代码指令、代码结构、控制流图、函数调用关系等特征值对比，分析出二进制代码成分以及代码之间的相似性。
SCA 的方法不局限于具体的软件开发语言技术栈，即不关注是 Java、Python、C/C++、Golang 或者是 Node，还是 Docker（OCI）Image ，或者是广义的构建过程，而是从文件层面关注目标的各组成文件本身，以及文件与文件之间的关联关系以及彼此组合成目标的过程细节。简而言之，SCA 是一种跨开发语言的二进制文件分析技术。
五、其他相关
1.SBOM释义
SBOM（Software Bill of Material，软件物料清单）的概念源自制造业，其中物料清单 BOM 是用来详细说明产品中包含的所有项目的清单。例如在汽车行业，制造商为每辆车提供一份详细的物料清单，列出原始设备制造商制造的部件以及来自第三方供应商的部件。当发现有缺陷的部件时，汽车制造商可以准确地知道哪些车辆受到影响，进而通知车主维修或更换。
SBOM作为软件供应链安全关键的落地治理条件之一，能够统一软件信息接口，对采购软件和自研软件风险评判进行标准统一。关于SBOM信息数据的组成，可通过安全检测工具链接实现，管理过程中必要的技术控制卡点。SBOM常规包含内容如下：
Refer
版权归原作者 MingXS2021 所有， 如有侵权，请联系我们删除。